Jump to content

Wikipedia talk:Manual of Style/Dates and numbers: Difference between revisions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Content deleted Content added
→‎Revised summary of the present state of play on YYYY-MM-DD in footnotes: Why is so much discussion transpiring on an issue that is so easily solved?
Line 862: Line 862:
:::::#Where dates ''do'' need to be parsed, primarily in sortable tables, use the same as above but wrap it inside {{tlx|dts}}
:::::#Where dates ''do'' need to be parsed, primarily in sortable tables, use the same as above but wrap it inside {{tlx|dts}}
:::::I'm not sure if everybody's read it up, but [[Template:Dts/doc]] implies that {{tlx|dts|2009|September|28}}, {{tlx|dts|2009-09-28}}, {{tlx|dts|September 28, 2009}} and {{tlx|dts|28 September 2009}} are all valid and give identical behaviour when sorted. Therefore, should it be necessary for {{para|accessdate}} to be parsable (and I've yet to see a reason for requiring that), the same code as used by {{tlx|dts}} to derive <code><nowiki><span style="display:none">2009-09-28</span></nowiki></code> could be utilised. Or there's {{tlx|Start date}}. The ''point'' is, that forcing the {{para|accessdate}} to appear in different format to all the other dates is jarring. --[[User:Redrose64|Redrose64]] ([[User talk:Redrose64|talk]]) 10:51, 28 September 2009 (UTC)
:::::I'm not sure if everybody's read it up, but [[Template:Dts/doc]] implies that {{tlx|dts|2009|September|28}}, {{tlx|dts|2009-09-28}}, {{tlx|dts|September 28, 2009}} and {{tlx|dts|28 September 2009}} are all valid and give identical behaviour when sorted. Therefore, should it be necessary for {{para|accessdate}} to be parsable (and I've yet to see a reason for requiring that), the same code as used by {{tlx|dts}} to derive <code><nowiki><span style="display:none">2009-09-28</span></nowiki></code> could be utilised. Or there's {{tlx|Start date}}. The ''point'' is, that forcing the {{para|accessdate}} to appear in different format to all the other dates is jarring. --[[User:Redrose64|Redrose64]] ([[User talk:Redrose64|talk]]) 10:51, 28 September 2009 (UTC)

I think it infinitely clear that the professional editors in the editorial rooms of fine encyclopedias, when they are pondering how best to communicate dates to readers, don’t ask “well, what computer-readable, all-numeric format is used on Canadian bank checks?” So… Have we developed a consensus to use machine-readable date formats only where machines (Wikipedia’s servers) need to understand dates, and to ensure dates are rendered in ''human''-readable form for the humans? You know, where…

# In main-body prose, we write the month’s name out in full: “On 7&nbsp;April 1795, the gram was decreed in France to be equal to…”.
# For citations, we use A.P. short-form: [http://theunquietlibrary.files.wordpress.com/2007/10/cover.jpg “(''Science News'', Vol. 172, Oct.&nbsp;17, 2007)”.]
# For tables, we use fixed, three-letter abbreviations and we modify [[2009_L%27Aquila_earthquake#List_of_foreshocks_and_aftershocks|USGS data-ralphs]] so the temporal column reads {{nowrap|“Mar 9, 2009, 7:30PM”}} instead of {{nowrap|“ “2009-03-09T19:30”}}. They’re both two-fingers wide on my screen and the first example is much easier to read.

None of this is technical-writing rocket science. Why is so much discussion transpiring on an issue that is so easily solved? [[User:Greg L|Greg L]] ([[User talk:Greg L|talk]]) 19:46, 28 September 2009 (UTC)


== C'mon... ==
== C'mon... ==

Revision as of 19:46, 28 September 2009

WikiProject iconManual of Style
WikiProject iconThis page falls within the scope of the Wikipedia:Manual of Style, a collaborative effort focused on enhancing clarity, consistency, and cohesiveness across the Manual of Style (MoS) guidelines by addressing inconsistencies, refining language, and integrating guidance effectively.
Note icon
This page falls under the contentious topics procedure and is given additional attention, as it closely associated to the English Wikipedia Manual of Style, and the article titles policy. Both areas are subjects of debate.
Contributors are urged to review the awareness criteria carefully and exercise caution when editing.
Note icon
For information on Wikipedia's approach to the establishment of new policies and guidelines, refer to WP:PROPOSAL. Additionally, guidance on how to contribute to the development and revision of Wikipedia policies of Wikipedia's policy and guideline documents is available, offering valuable insights and recommendations.

This talk page is for discussion of the page WP:Manual of Style (dates and numbers). Please use it to make constructive suggestions as to the wording of that page.

This is a test
+
This was a test!

Guidance needed

It's easy to edit the text to include {{xt}}, but I'm having a bit of trouble working out where, and would appreciate some confirmation before I start:

I cannot see any other quoted text that needs conversion, although there are probably some more phrases in italics or just plain text that I'll notice later. Johnuniq (talk) 11:58, 11 September 2009 (UTC)[reply]

  • This is why this was so time-consuming for me. There is some gray area as to what text should be given the “xt-treatment”. I suggest you approach the issue this way: The name “xt” stands for “example text.” So, generally speaking, if the verbiage you are going to convert is preceded with language such as the following…
  1. Editors should write…
  2. …or write this…
  3. …but not this…
  4. …such as…
  5. …for example,
…and the verbiage that follows clearly can be categorized as “example text”, then give it the {xt} treatment.
The whole purpose of {xt} was to solve the problem of what to do when we were giving examples of what to do with quotes, such as “When giving a quote that itself contains quoted text, change the double-quote to a single-quote as follows…” Thus, the entire bit of example text that followed those words couldn’t itself be set off within quotes without serious limitations and complications. The alternative, of course, was to use italic text to set off example text, but then that screwed up examples where we touched upon how to properly use italics. MOSNUM previously used both techniques to avoid this limitation. So…
We have {xt} to give us complete freedom to no longer need either italics nor quotes to set off example text. Once we are using {xt} for those, we should finish the job and use it for all instances of example text. I know there are some gray areas where what can be considered “example” text isn’t entirely clear. However, I’m sure you will find the proper answer in each case. I really appreciate, Johnuniq, that you 1) stepped up to the plate and volunteered to perform this service, and 2) take your responsibilities so seriously that you saw fit to check in and clarify the scope and definition of the task, as you did above.
I suggest that you not worry too much about goofing. So long as you break up your edits into small, clear, logical sections and frequently post, it should be easy for you or someone other editor to go back and just hit [undo] in the history and keep the reverted text (and wasted effort) at a minimum.
In advance, thanks. Greg L (talk) 19:28, 11 September 2009 (UTC)[reply]
P.S. I use {xt} when quoting editors because debate here on WT:MOSNUM frequently contains quotes and type-style changes. So the use of {xt} avoids my having to switch back and forth from using italics and quotes when quoting other editors. It also more distinctly sets off the quoted passage. For MOSNUM itself, {xt} is used as an alternative to all other ways of setting off example text; namely, quotes, italics, and bolding. So, to (finally) answer a question you posed above, here is how the following text currently on MOSNUM would be addressed:

There is no such ambiguity with recurring events, such as January 1 is New Year's Day.

Greg L (talk) 20:04, 11 September 2009 (UTC)[reply]

Thanks for info. I made quite a lot of changes and will wait at least 24 hours before doing more (I'm up to "Scientific notation, engineering notation, and uncertainty"). In the line starting "The ordinal suffix", I used xt, but (owing to the font), it is not entirely successful in appearance. I tried xt for the italics at "Non-base-10 notations" but it looks bad with xt, so I did not use it. Johnuniq (talk) 04:32, 12 September 2009 (UTC)[reply]

  • I think your judgement was spot-on on how to evaluate the suitability of {xt} for given pieces of example text. Indeed, the Georgian font that {xt} uses treats its numbers with a, uhm… stylistic flourish (abcdefg - 1627384950). Georgian was chosen because it is found on Mac, Windows, and Linux with native installations—or, at least, exceedingly common ones. Perhaps one day, we can again take a look at using some other font. Times proved too problematic because it is smaller than its same-size, sans-serif counterparts. Giving Times a proportional percentage boost in size (like 107.5%) proved unsatisfactory for use across widely different platforms.

    I am really impressed with your conservative, stepped approach to improving MOSNUM. Your style should be widely emulated. Greg L (talk) 18:09, 12 September 2009 (UTC)[reply]

P.S. I just realized that if you edited numeric examples so their digits, when they are used in significands, superscripts, and subscripts, are segregated into—and chosen from pallets of—three families: 012, and 34579, and 68, then that ought to fix the appearance problem you are wrestling with. For instance: The chance that 68 editors on Wikipedia will have 100% agreement on any one issue on WT:MOSNUM is 9.7435×10−21. Greg L (talk) 18:51, 12 September 2009 (UTC)[reply]

Good idea for most examples; but in one example the fact that 1, 2, 3, and 4 are aligned together is the point. It is "the Unicode characters ² and ³ ... are not aligned with superscript characters (e.g., x1x²x³x4 vs. x1x2x3x4)". I'd fall back on not using {{xt}} on that example, or on using a kluge such as "the Unicode characters ² and ³ ... are not aligned with superscript characters (e.g., x1x²x³x4 vs. x1x2x3x4)". (If it weren't the case that so many people's default serif font is Times which has a ridiculously tiny x-height, I'd just propose that Xt just specify "serif".) --___A. di M. 19:19, 12 September 2009 (UTC)[reply]
  • As the saying goes: If anything works in this world, thank an engineer.

    I see you coded the good-looking one as follows:

    {{xt|1=<span style="font-family: sans">''x''<sup>1</sup>''x''²''x''³''x''<sup>4</sup></span>}} vs. {{xt|1=<span style="font-family: sans">''x''<sup>1</sup>''x''<sup>2</sup>''x''<sup>3</sup>''x''<sup>4</sup></span>}}.

    Indeed, the example text appears small on my Mac because it uses Times, but it still looks nice, and—indeed—that is quite the kluge to code.

    So let me try the {{xt}} treatment: x1x²x³x4 vs. x1x2x3x4. I see. A big, stupid superscripted “3” and “4” because one must do a progression, where choosing from a segregated pallet isn’t possible.

    However, this is an situation where the example text is sufficiently clear from context since it is numerics surrounded by words. Greg L (talk) 19:35, 12 September 2009 (UTC)[reply]

  • A. di M.: What do you think of {xtc} where the only change is to the custom green color? It would be used where you have to deal with alphanumeric formulas. As regards color blindness, it would be merely be an assistive technology that facilitates the distinction of what is example text and what isn’t. So I don’t see adding green as being a problem, such as Wikipedia’s practice of using a dark blue to indicate there is a link that can be clicked. And the prudent use of {xtc} on alphanumeric formulas on MOSNUM (and similar WP: uses) would be a lightyear from the same class as using color alone to differentiate important distinctions, like “this is good” but “this is bad”. Greg L (talk) 19:54, 12 September 2009 (UTC)[reply]
Update

My edit finished converting all "quoted examples" and italic examples to use {{xt}}. It turned out that there were very few changes in that last edit; I included changing "US" to "US gallon" at one point where it looked like an oversight.

In the line beginning "Use nautical mile or statute mile" (and some other places) I used xt for the examples which included links, so they are blue and look a tiny bit strange (but I think ok). I did not touch the examples in the "Quantities of bytes and bits" section because 10003 renders unsatisfactorily as 10003 and the 3 can't really be changed to follow Greg's above suggestion. The idea of an xtc template sounds useful for rendering the numeric examples mentioned above, and it looks very simple to do for a trial. Johnuniq (talk) 09:26, 14 September 2009 (UTC)[reply]

  • Thank you so much (again) for stepping up to the plate and doing such a meticulous job. If it rocks your boat, you can give math expressions like 10003 an “xt-treatment” that looks like this: 10003. Here’s how to do a really useful trial until an {xtc} template comes along…
    • This is link-blue, which is coded <font color="#002BB8">fake link</font color>.
    • This is “xt”-green, which is coded <font color="#006F00">example formula without the accompanying Georgia font</font color>.
It would be ultra-easy when an {xtc} template becomes available to do a search & replace in a word processor to change occurrences of <font color="#006F00"> with {{xtc|. You know the drill; same on the back end.
Greg L (talk) 02:43, 15 September 2009 (UTC)[reply]
Hmm. Why not create Template:xtc? I'll give that a go if you like. Johnuniq (talk) 02:56, 15 September 2009 (UTC)[reply]
  • I don’t know how to make templates. I usually look towards A. di M. for these sort of things. It seems his take is a good litmus test for when is the proper moment to make a template.

    My sense is that using <font color="#002BB8"> to fix the last few stragglers will be the perfect demonstration for a “trial,” as you say. It’s also been my observation in the past that having code like that in MOSNUM, if the practice sticks, is just the very sort of thing that prompts someone to make a template so they can get rid of the code. By dipping our toes into this with a color-call, we can all look at the result and see if it serves a good and valuable end.

    I know that my use of CSS spans when making really nice-looking scientific notation (like 9.743534579(35)×10−21 kg) precipitated the effort to make templates to accomplish the same end and that resulted in the {{xt}} template. People just couldn’t stand looking at my hand-written code for scientific notation, which looked like 6.022<span style="margin-left:0.25em">141<span style="margin-left:0.2em">79(30)</span></span><span style="margin-left:0.25em">×</span><span style="margin-left:0.15em">10</span><sup>–21</sup>&nbsp;kg. ;-) Greg L (talk) 19:29, 15 September 2009 (UTC)[reply]

I used Greg's font color="#006F00" in Quantities of bytes and bits. It looks good to me (although I now think I should have added a greeen period to each of the three "Acceptable examples include"). Following is what Template:xtc should be (needs documentation):

{{#ifeq:{{NAMESPACE}}|{{ns:0}}|{{FormattingError|Template:xtc is only for examples
of style and formatting. Do not use it in actual articles.}}|<span class="example"style=
"color: #006F00;">{{{1|}}}</span>}}<noinclude>
{{Documentation}}
<!-- If/when the <samp> element is included in WikiText, replace span with samp,
which would be more appropriate. -->
</noinclude>

Hmmm, interesting off-topic: Why does {{xt}} fail when used like this abc{{xt|font color="#006F00"}}def which renders as abcExample textdef? Johnuniq (talk) 04:53, 16 September 2009 (UTC)[reply]

Because when it sees an equal sign, it believes that it's a named parameter font color whose value is "#006F00". You have to use 1= to specify the value of the first unnamed parameter when it itself contains equals signs (font color="#006F00"). --___A. di M. 14:37, 16 September 2009 (UTC)[reply]
  • I think Quantities of bytes and bits looks great. Thanks, Johnuniq. Having an equal sign anywhere within the {xt} template breaks it. There are at least three ways to work around this, depending on whether the = sign is functional or only for display. For instance…
  • {{xt|1=''M''<span style="margin-left:0.15em"><sup>2</sup></span>}}M2 (one must use the “1=” technique because the = sign is functional in a CSS span… the span here is just an example that came to mind.)
  • {{xt|2 × 3 {{=}} 6}}2 × 3 = 6 ( {{=}} (template replacement of the = as it is only display)
  • {{xt|2 × 3 &#061; 6}}2 × 3 = 6 (character reference to replace the = as it is only display)
Greg L (talk) 17:40, 16 September 2009 (UTC)[reply]
Thanks both. This is a classic case of induced stupidity because I have done a fair bit of work with templates elsewhere and it was the html (that is somewhat foreign to me) that made me overlook the blunder. I'm a bit hesitant to create xtc after that, but I'll do it if wanted and A. di M. doesn't feel like it. I don't think it is worth putting any more green manually into MOSNUM, so let's wait for xtc. Johnuniq (talk) 04:36, 17 September 2009 (UTC)[reply]
  • Were it me, I’d sit back and see if the #006F00-made examples are met with bored acceptance (or interested acceptance). After maybe a month, it would, IMO, look more *formal* and cleaner to create an {xtc} template; that will make the examples look more like the etherial Wikipedia gods ordained that they be there. Greg L (talk) 00:26, 18 September 2009 (UTC)[reply]
  • While it might be unsuitable for a fine glossy-paged coffee-table book, having the bytes ‘n’ bits examples in {xt} doesn’t appear to be an abomination unto the eyes of the typography gods to me. More to the point, the {xt}-treatment doesn’t, IMO, get in the way or distract from the message. I think the whole page looks much better as a result of your exceedingly professional work and collaborative style, Johnuniq. Greg L (talk) 21:35, 21 September 2009 (UTC)[reply]

Can we finalise the YYYY-MM-DD consensus?

Folks, it's been going on for a while, and we seem to be close. Skomorokh was the admin who last commented that there wasn't yet consensus for him/her as a gatekeeper to make the change. The so-called pink version (not very pink on my monitor) seems to be the final one. Feds and anyone else, will you please state briefly here any concerns you have, and how exactly you'd like the wording to be changed (if at all)? Let's hope we can contact Skomorokh soon. Tony (talk) 04:07, 17 September 2009 (UTC)[reply]

... okay, i see that piped link leads to the second "pink div", which is currently in barely literate form - is that meant as a form of humour? Sssoul (talk) 07:38, 17 September 2009 (UTC)[reply]
I can't see one illiterate character space there. Tony (talk) 07:53, 17 September 2009 (UTC)[reply]
Looks fine to me..—MDCollins (talk) 09:53, 17 September 2009 (UTC)[reply]
Me too. What is Sssoul talking about? Alarics (talk) 10:01, 17 September 2009 (UTC)[reply]
i'm talking about the weird way it's phrased: "Months in dates. Spell out" and "All-numeric date formats. Do not use" and so on. if that's not meant as some kind of joke, what is the idea of expressing things in a string of half sentences? "MoS recommendation: Talk normal." Sssoul (talk) 18:01, 17 September 2009 (UTC)[reply]

I think we have a pretty fair consensus against using all-numeric date formats though perhaps we had better advertise it more widely before we risk a backlash from those who have grown used to the notion that refs should use YYYY-MM-DD. I'm not convinced that we have the issue on whether to allow AP dates or not settled. I'm not the only one who's expressed the opinion that they can be happily done without. A third issue which hasn't really been much discussed is whether to allow three-letter+dot abbreviations (e.g. Apr.). JIMp talk·cont 10:40, 17 September 2009 (UTC)[reply]

I agree about the dots, and I would be happy to lose them. But I don't think it worth spending ages arguing about: most people aren't even going to notice the difference. I would not want that issue to block progress here, if other people disagree with JIMp and me. -- Alarics (talk) 11:10, 17 September 2009 (UTC)[reply]
So do we let the community know via VP and Centralized Discussion? Tony (talk) 11:16, 17 September 2009 (UTC)[reply]
If you say so. I have no idea what VP and Centralized Discussion are. Alarics (talk) 11:29, 17 September 2009 (UTC)[reply]
I support the second pink div. Some people will want the dots, and some won't. The reason the policy should include them is that there is a good precedent in the AP Stylebook and I imagine that is why Greg L recommended it: it makes sense to follow a relevant and established practice (but we do not necessarily follow technical documentation standards, as seen in WP:MOSNUM#Adopting suggestions from standards bodies). Johnuniq (talk) 11:34, 17 September 2009 (UTC)[reply]
There are two sets of dots in question here. Greg is suggesting AP style with dots. The Feds is suggesting three-letter abbreviations with dots. If the dots are part of the AP style, then by accepting this style we accept these dots. What about the other set of dots? I don't see the need for these dots. JIMp talk·cont 13:44, 17 September 2009 (UTC)[reply]
I don't think the AP style guide is the be-all and end-all of style guides. It is the definitive style guide for American newspapers, but this is not an American newspaper - it is an international electronic on-line encyclopedia. The AP guidelines may not always be appropriate for such a use, and there are a lot of other style guides with differing opinions. In this case, since the objective of the exercise is to save space (why else would you use abbreviated months?) I would suggest not using dots and limiting the abbreviations to three letters. This would give you Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, and Dec; and your choices for today's date would be Sep 17, 2009 (American format) or 17 Sep 2009 (British format). I would also suggest allowing 2009 Sep 17 (modified ISO format) because, believe it or not, there are a lot of people who would use it. And I would like the true ISO format 2009-09-17, because it is the international system designer's first choice.RockyMtnGuy (talk) 17:30, 17 September 2009 (UTC)[reply]
Agree with you about the dots. On YYY-MM-DD in numerical form, it has already been explained to you, further up this page, that we are not "international system designers", we are writing an English-language encyclopaedia. We don't want dates in any numerical form, including YYYY-MM-DD. We want people to write out the month as a word, as is done in books, encyclopaedias and newspapers. Alarics (talk) 17:41, 17 September 2009 (UTC)[reply]

(outdent)

  • The A.P. method is observed by some 99% of the world’s English-speaking newspapers throughout the world. To borrow a phrase from RockyMtnGuy, it is an international practice. He is mistaken when he poo-poos it as an *American* standard (you know, those illiterate yanks who ain’t been learned good English). It is a practice observed by pretty much all half-way-professional, English-language professional print publications. It doesn’t matter if Kenya has another practice (“but… we’re a *world-wide* resource (yadda yadda)”). We use proper English-writing form and adhere to proper technical writing practices. If we are to pretend that MOSNUM is a manual of style that’s worth a darn, it had best be correct on some stuff once in a while.

    It could be that many editors don’t even recognize the common monthly short-form method when they come across it (the one memorialized by the A.P.) and wouldn’t have a clue where to look up the practice; frankly some 90+% of Wikipedia editors don’t own a single print manual of style, so WP:MOS and WP:MOSNUM are the only places they can get proper guidance. The A.P. didn’t just make this stuff up; it is a long-time practice that probably goes back to the 19th century when spittoons littered the floor of every newspaper office in the U.S.

    The short-form technique is a compromise of sorts in the effort to always write out months but to shorten the really long-named months in parentheticals; e.g., The magazine Science Week (issue 38, Sept. 15, 2007) referenced the first use of…. It is a technique to which any half-way literate reader has long been exposed and likely never noticed it in their newspaper’s Letters To the Editor section; e.g. I enjoyed your article regarding teacher pay (“Public servants’ pay lagging,” Sept. 28), and feel you…. If it is not one of the longish-looking months, then it isn’t abbreviated and appears like this one, (which is one of my own letters in Aviation Week & Space Technology): Prof. T. Nejat Vezirogluʼs letter “Hydrogen, Future Airline Fuel?” (AW&ST June 23, p. 12) says….

    The only basis I know of for not showing our many, would-be, all-volunteer editors from all walks of life how to properly abbreviate months when doing good, encyclopedic writing, would be this argument: “let editors just use common sense.” Given the chronic and obvious shortcomings endemic throughout Wikipedia, that argument makes no sense to me whatsoever as it completely flouts reality. Frankly, I often suspect such arguments from any experienced Wikipedia editor who has to know better, is just a smoke screen for “I like ta do it my way so don’t prescribe any way of doing it.” Either that, or it is being used as an excuse to push a God-awful-looking three-letter practice (that should be strictly limited to fixed-width uses in long tables) because it has “logic” and Wikipedia ought to once again Lead the Way and Show the World How Technical Writing Is Properly Done®™©. Greg L (talk) 17:48, 17 September 2009 (UTC)[reply]

Leading the way is why I always use YYYY-MM-DD everywhere, not just here. Writing out the month or using Month day, year (especially two-digit years) is just against nature. - Denimadept (talk) 17:55, 17 September 2009 (UTC)[reply]
So the practice of practically every newspaper and book is "against nature", is it? Alarics (talk) 17:58, 17 September 2009 (UTC)[reply]
Wikipedia isn't a newspaper, or a book. I don't see the problem. - Denimadept (talk) 18:13, 17 September 2009 (UTC)[reply]
  • Wow, Denimadept. You left a big chink in your armor wide open with that one. Indeed, Wikipedia is an English-language encyclopedia. Why don’t you go look at how World Book and Encyclopedia Britannica and any other English-language print encyclopedia writes out dates in order to read fluidly, naturally, and unambiguously. Go ahead… crack one of those encyclopedias open and see what’s there (dare ya). I believe this is where you retort “but… Wikipedia is read by an *international* readership.” To which I respond, “yeah, the English-speaking ones; don’t care what people in the Congo and at Star Trek conventions do.” Greg L (talk) 18:23, 17 September 2009 (UTC)[reply]
Talking about consensus when only a tiny group of people have participated does not really make sense. Why is it that some people want to forbid certain ways of expression. It goes very much against the open nature of WP. I cannot possibly see anything wrong with all-numeric dates in the practically unambiguous from of 2009-09-17 and strongly oppose banning it. It is an utterly useful format especially in tabular or sortable context. −Woodstone (talk) 18:07, 17 September 2009 (UTC)[reply]
It's like this. People will write how they write. You can edit how they write. If you're not able to convince most people to do it your way, there's no point. Like many other prohibitionist thinking, more rules just reduce the respect for all rules. Oh, and anyone who pushes (and I'm not sure if y'all are here or not) anything other than 4-digit years gets an immediate massive REJECT stamp. - Denimadept (talk) 18:16, 17 September 2009 (UTC)[reply]
Argh no, don't give up. :-o All I'm saying is that if there's no real, understandable, reason to make a change, why do it? - Denimadept (talk) 18:40, 17 September 2009 (UTC)[reply]

{{Dts}} makes YYYY-MM-DD unnecessary in sort tables nor does it save a great deal of space compared to three-letter abbreviations. Although putting the year first (whether it be numbers or letters for the month) solves the month-day vs day-month problem unambiguously, it's just not usual in English. God-awful-lookingness is in the eye of the beholder. Some would rather behold three letters than AP style. It seems I'm not the only such beholder. However, I would concede that Woodstone is correct in saying that it's too early to speak of consensus for a change which will be as wide reaching as ridding WP of YYYY-MM-DD. Though perhaps we can settle whether to allow Mar., Apr., Jun., Jul. or Sep. (i.e. three letters + dots, as suggested by The Feds, not covered by AP). JIMp talk·cont 18:48, 17 September 2009 (UTC)[reply]

I admit, I could see DD Month YYYY as good, but not MM/DD/YY, DD/MM/YY or Month day, year. Honestly, I can live with the others, as long as we have 4-digit years. I'm sorry if I upset User:Greg L. I agree that "gawd awefulness" is in the eye of the beholder. I like things regular, and month names come in various lengths: bleh. - Denimadept (talk) 18:55, 17 September 2009 (UTC)[reply]
My main objections to to the so-called pink box:
  • Too long.
  • Omits restriction on ordinal suffixes.
  • Draws unnecessary distinction between YYYY-MM-DD and other all-numeric formats. (If we're banning them all, then just ban them.)
  • Is not clear on what's meant by "limited space". (Is prose sandwiched between pictures and templates considered limited space? Or is this strictly aimed at tables, etc.?)
  • If space-saving in tables is the objective, then the three-character forms are sufficient.
  • I would oppose using abbreviated months within prose. (However, I acknowledge that the AP style is not terrible for use within prose in a date like Sept. 17, 2009; but not so good in 17 Sept. 2009.)
These aren't huge issues, but as we're here, they're worth discussing before going ahead with the revision. TheFeds 19:11, 17 September 2009 (UTC)[reply]
Denimadept, you wrote "oh, and anyone who pushes (and I'm not sure if y'all are here or not) anything other than 4-digit years gets an immediate massive REJECT stamp." I guess that means you will be nominating the article Diocletian for deletion, because it uses three-digit years. --Jc3s5h (talk) 19:18, 17 September 2009 (UTC)[reply]
Okay, ya got me, pahdna. You could also have mentioned Pompeii with the same logic. To clarify, I mean that people must use the full year. Year 79 should be a long time ago, not 30 years. - Denimadept (talk) 19:35, 17 September 2009 (UTC)[reply]
The YYYY-MM-DD date just won't work for historical articles. If we say it is ISO 8601, then we can't use it before 1583, because the standard says we have to form an agreement with our data exchange partners (that is, readers), and it is not practical to do so. If we say it isn't ISO 8601, then there is nothing to tell us what to do about years before 1000. Shall we write that Diocletian died 0311-12-03? How about 0311-12-04? Maybe 311-12-03. Shall we write that Augustus Caesar died 14-08-19? Perhaps we should write that he was born about 63-09-23 BC? With no standard to guide us, who is to say? --Jc3s5h (talk) 20:12, 17 September 2009 (UTC)[reply]
My take on Fed's objections to the pink box:
  • "Too long." I agree.
  • "Omits restriction on ordinal suffixes." The restriction should be mentioned, yes.
  • "Draws unnecessary distinction between ... all-numeric formats." I agree (MOS needn't talk about input to templates).
  • "Is not clear on what's meant by 'limited space'." True but clarification will make the box longer.
  • "If space-saving in tables is the objective, then the three-character forms are sufficient." I've said so before & would add that the dots are also unnecessary.
  • "I would oppose using abbreviated months within prose." I would too but I think this the general feeling.
"These aren't huge issues" no, I wouldn't say they were. JIMp talk·cont 19:27, 17 September 2009 (UTC)[reply]

¶ Ordinal suffixes actually make US-style dates (e.g. April 11, 1171) easier to read, because commas and spaces don't always come out well or separate numbers clearly. At the end of a sentence, they're better than a simple period (full-stop) in separating a date from the beginning of the next sentence. Although I learned to read about 55 years ago, I still listen to what I read (without moving my lips) because it helps when I have to read or act something out loud, and because it's the best way of grasping the author's logic, rhetoric, grammar and emphasis , so 1st, 14th, 2nd, 23rd, etc. reflect my normal usage. That's not an argument to impose ordinals on anyone else, but I see no reason to forbid ordinal suffixes, either. Once upon a time, ordinal suffixes interfered, I'm told, with date auto-formatting, and print publishers trying to save space chopped them, as they abbreviated months to Aug., Sept., etc, but neither of these considerations need apply. This is just another case where I differ from others on this Talk Page in not seeing great value in uniformity for its own sake, and we are trying to save space and reduce the number of rules that editors need to heed. —— Shakescene (talk) 20:54, 17 September 2009 (UTC)[reply]

  • User:Denimadept says "as long as we have 4-digit years. .... To clarify, I mean that people must use the full year". Why do people keep dragging in these red herrings, when the issue is complicated enough as it is? Absolutely nobody is proposing anything other than 4-digit years.
  • TheFeds complains that the proposal "draws unnecessary distinction between YYYY-MM-DD and other all-numeric formats". That's because it is YYYY-MM-DD that is everywhere on WP, especially in references. We need to spell out as explicitly as possible that YYYY-MM-DD is as unacceptable as any other all-numeric formats (because it looks nasty, is hard for people who aren't used to it to parse -- one has to stop and try to work out what it means -- and, as VMAsNYC notes further up the page, isn't even unambiguous to everybody, though we all agree it is the least ambiguous form of numerical date). All that is addition to the points made by Jc3s5h about why YYYY-MM-DD won't work for historical articles.
  • As between the A.P. version of the short form for months and the three-character version, I have no strong views, but I agree with several contributors who have said that, when the three-character version is used, there is no need for a dot.
  • User:Denimadept says "I could see DD Month YYYY as good, but not MM/DD/YY, DD/MM/YY or Month day, year". For heaven's sake, we are already clearly and unanimously excluding MM/DD/YY and DD/MM/YY (in numerical form), so why raise that again? As for "Month day, year", yes, as a Brit I loathe and detest it too, with every fibre of my being, and it's ridiculously illogical and completely stupid, but 300 million Americans use it, so it is utterly preposterous to suggest we should try and ban it. Please try to relate your remarks to the discussion that has already endlessly been gone over.
  • Woodstone says that YYYY-MM-DD is a "useful format especially in tabular or sortable context". We all agree about tabular; that's why the proposed text allows it in that special case. As for sortable, JIMp has explained that "{{Dts}} makes YYYY-MM-DD unnecessary in sort tables".
  • Shakescene doesn't want to ban ordinal suffixes. But this is not a new proposal -- MOSNUM already clearly bans ordinal suffixes in dates, and as far as I know it has done so for a long time. The last thing we want, surely, is to open up for discussion things that were already agreed long ago, as if we didn't have enough disagreements to resolve with all the other questions here. Who on earth uses ordinal suffixes in text nowadays, anyway? This is another total red herring. I wish people would keep focused on the questions at issue. -- Alarics (talk) 21:18, 17 September 2009 (UTC)[reply]
  • I think we're near virtual agreement here. Is it worth someone trying their hand at Pink 2 (or 3?).
  • Short not-tremendously-significant-noteworthy reply to Alarics. You guys who are steeped in this stuff may find this odd. But I actually (as of a week ago) knew perfectly well that the following article referred to September 8 -- see [1] ... and the following NFL reference was not to the Super Bowl taking place on July 2 -- see [2] (in each case because I know the entity is US, and know the US convention). And I would not have been surprised by the reverse format in [3] ... people who travel overseas run into the difference. But I would not for the life of me have known, when facing a YYYY-##-## format, whether it reflected the day first or the month first, without other clues. That format is much more foreign to me that either of the aforementioned formats (and therefore arguably the worst possible choice). I'm guessing that I'm a good rep here of the ignorant masses, who probably have low representation in this discussion.--VMAsNYC (talk) 21:43, 17 September 2009 (UTC)[reply]
OK, I stand corrected on "least ambiguous". Let's just agree that all of them are ambiguous. All the more reason, then, to avoid numerical dates of any kind. But I still think it worth singling out YYYY-MM-DD for mention as being just as unacceptable as any other format, because YYYY-MM-DD is being used all over the place on WP, and because even some people who agree that the other kinds of numerical dates won't do seem to want to keep YYYY-MM-DD as a special case, and therefore we need to spell out explicitly that it won't do, either. Alarics (talk) 22:20, 17 September 2009 (UTC)[reply]
Al -- I have no problem with that, and agree that they should not be accepted, though I expect those in favor of short guidances would feel best if the specific guidance at to that form of numerical date were in a footnote rather than the guidance text.--VMAsNYC (talk) 22:28, 17 September 2009 (UTC)[reply]
  • There is no need for all-numeric anywhere on Wikipedia, even in footnotes and tables. This is an all-electronic, adjustable-everything encyclopedia. So writing “Sept. 14, 2007” or “14 Sep 2007” is perfectly fine for all places where space is a little tight (which, frankly isn’t really that tight). Greg L (talk) 22:39, 17 September 2009 (UTC)[reply]

My two cents:

  • AP style abbreviation would be useful where space has no hard limit but you want to use as little as possible: for example, in Since 2001 the grant has been 10,000,000 Swedish kronor (approx. US$1.4M, €1.0M, or £800k as of August 2009) you might well want to replace "August" with "Aug.", and if it were "September" you might want to replace it with "Sept."; on the other hand, MOSNUM is already bloated enough without mentioning these.
  • As for YYYY-MM-DD, I have no strong opinion about that (after all 18 Sep 2009 is just one more character than 2009-09-18); but I think that if we really want to ban something which is used in about half of the articles containing at least one full date in the References section, we shouldn't be so light-hearted about that.

BTW, I suggest this:

  • Whenever practical, spell out month names fully.
  • In places where it is not desirable to spell out long month names, for example in parentheses, footnotes, and infoboxes, use the abbreviations Jan., Feb., Aug., Sept., Oct., Nov., and Dec., and spell out months from March to July. This style is recommended by The Associated Press Stylebook, for example.
  • In places where space is very tight and it is desirable that all dates have the same width, such as tables, use three-letter abbreviations for the month, i.e. 18 Sep 2009 or Sep 18, 2009.
  • Do not use date formats such as 03/04/2005, as they are ambiguous (it could refer to 3 April or to March 4); for the sake of consistency, do not use them when the day number is greater than 12, either.
  • In sortable tables, use Template:Dts or Template:Sort to ensure that the column be sorted chronologically rather than alphabetically.

--___A. di M. 10:16, 18 September 2009 (UTC)[reply]


Well, I'm afraid that won't do, because it does not ban YYYY-MM-DD, which we've agreed we need to do explicitly. Also, I don't like the idea that it is "not desirable to spell out long month names" in footnotes. Saving a maximum of four characters (yes, that is all the A.P. style achieves) is never going to be critical in a footnote. I thought we had more or less agreed that it was only in tables with narrow columns that dates need not be written out in full. I'm still not clear what is wrong with the proposal in the pink box. -- Alarics (talk) 11:58, 18 September 2009 (UTC)[reply]

BTW, I don't for a moment imagine that in practice we can stop people using YYYY-MM-DD overnight. The point is that once there is an authoritative text clearly deprecating that form, we can point to it if people complain when we change their numerical date to a proper date. -- Alarics (talk) 12:09, 18 September 2009 (UTC)[reply]

Wow! Someone thinks a local en: MOSNUM talkpage discussion will translate to "ban" the one date format that works in all languages? How provincial. This is supposed to be the English part of a multilingual encyclopedia, not an isolated English work.LeadSongDog come howl 13:40, 18 September 2009 (UTC)[reply]
The YYYY-MM-DD format does not "work" in any language for historical articles. Problems begin about 1926 and the system completely falls apart before 1000. So LeadSongDog, what do you propose to do about historical articles? --Jc3s5h (talk) 14:18, 18 September 2009 (UTC)[reply]
Reply to Alarics. If the "authoritative text" is added following a discussion which they didn't even know it existed, they won't give a damn about what it says. (Hasn't the date delinking saga taught us anything?) Changing a recommendation so that hundreds of thousands of articles will no longer conform to it is something which should be done after far wider consultation than this. Reply to LeadSongDog. So what? AFAIK en:WP:MOSNUM only applies to the English Wikipedia; all other Wikipedias won't and shouldn't give a damn about what it says; so they are irrelevant to this discussion. Reply to Jc3s5h. The YYYY-MM-DD format is already banned from sentences; and I wonder how often you're going to cite a source whose publication date is not in the Gregorian calendar, or have a table of dates, given to within a day, not in the Gregorian calendar. --___A. di M. 14:53, 18 September 2009 (UTC)[reply]
  • What A. di M. has here is logical and would normally do trick for any reasonable person. However, I think Alarics has a valid concern. There’s that I.P. editor who edited ISO 8601 to show that the standard was intended for all expressions of dates, including hand-written, internal notes and what not. So, clearly, there are some passionate *believers*.

    And to LeadSongDog, it doesn’t matter if you stridently believe that everyone from Koko to Einstein instantly understands 2009/05/12, it isn’t at all proper, encyclopedic technical writing to use all-numeric dates; one always writes out the name of the month (or an abbreviation). Always. If you don’t understand that yet, it’s beginning to dawn on me that you might never. If you do understand that, but believe (hope) that yours is a *new way and Wikipedia will show all the other encyclopedias and all the other professional publications how to properly write out dates*, you are mistaken; we will just have a second-rate-looking product that looks like it is the product of space cadets with no journalism or technical writing experience whatsoever. Go crack open an Encyclopedia Britannica if you don’t understand any of this. If your response is “well… Wikipedia is written for an *international* (*sound of blair trumpets*) audience,” I’ll respond “yeah, an English-speaking one at that; so go take a look at the language Encyclopedia Britannica is written in.” Greg L (talk) 15:02, 18 September 2009 (UTC)[reply]

    • We should base our practices on evidence. The meta:List of Wikipedias presently shows that en: is the largest WP, but still hosts just over 3 million articles out of a total of almost 14 million. Many of the other 11 million are articles with no equivalent on en:, often addressing topics we systematically neglect. Making translation to English more onerous by imposing arbitrary rules of format does not help en: to improve. Throwing roadblocks in the way of those trying to cite sources does not help the project. There's a world of difference between supporting one format and banning another.LeadSongDog come howl 17:24, 18 September 2009 (UTC)[reply]

I'm unclear where YYYY-MM-DD references the Gregorian Calendar. Maybe I missed it. Anyway, we're mostly talking about normal dates, not ancient ones. Even if we're talking about ancient dates, YYYY can either be zero or blank-filled. OTOH, if you're for some reason talking about Mayan dates or similar unusual calendars, you've lost me. - Denimadept (talk) 15:04, 18 September 2009 (UTC)[reply]

Looking back again at the existing MOSNUM text, it already says don't use YYYY-MM-DD in ordinary sentences, but it goes on, "However, they may be useful in long lists and tables for conciseness". I doubt if that was ever meant to include footnotes, so all we are doing that's new is clarifying that footnotes don't count as "long lists".
Anyway, yesterday Tony wrote, "So do we let the community know via VP and Centralized Discussion?" I don't know what those things mean, but whatever they are, if Tony thinks that is the next step (and he was agreeing with deprecating YYYY-MM-DD, by the way), let's do it. Presumably that would fulfil A. di M.'s wish for a wider consultation. -- Alarics (talk) 15:35, 18 September 2009 (UTC)[reply]
Denimadept: The current guideline addresses ancient dates by indicating the YYYY-MM-DD format should not be used before 1583. The proposals currently under discussion either ban YYYY-MM-DD, or allow it where space is constrained with no restrictions on what date values may be represented.
There are basically two ways to use the YYYY-MM-DD format: in strict conformance to a published standard like ISO 8601, or according to general consensus of the English-speaking world. However, since the YYYY-MM-DD format has mostly been used in connection with events that occurred inside a computer, or which are recorded on a computer close to the time of the event (e.g. a plane ticket) no consensus has formed about how to write ancient dates in that format. So if I see 9-10-11 in a table, is that someone's idea of how to adapt the YYYY-MM-DD format to 11 October AD 9, or was it written by someone who never heard of the YYYY-MM-DD format and means 9 October AD 11, or perhaps September 10, AD 11? Maybe it was written by someone too young to have been told by his manager to go through all the software written in the department and make sure there will be no Y2K problem, and it means September 10, 2011.
As for the Gregorian calendar, if you decide to follow general English consensus, there is no consensus for ancient dates. If you decide to follow ISO 8601 then the date must be Gregorian because the standard says so.
If you think ISO 8601 applies to the format, then you should go read the standard before commenting further. --Jc3s5h (talk) 15:37, 18 September 2009 (UTC)[reply]
By the way, another thing we shouldn't lose sight of: I gather the main reason there are now "hundreds of thousands of articles" containing YYYY-MM-DD is because people got into the habit of doing that when there was autoformatting of dates, assuming that readers wouldn't actually see it that way (an incorrect assumption, because most readers don't set reader preferences, but there we are). I doubt if many people used YYYY-MM-DD because they thought it was desirable in itself, or looked nice, or was easy to read. If that point is stressed, maybe the opposition to our proposed clarification wouldn't be so great as some think. -- Alarics (talk) 16:58, 18 September 2009 (UTC)[reply]
LeadSongDog says "Making translation to English more onerous by imposing arbitrary rules of format does not help en: to improve". This is a silly, clutching-at-straws argument. We have all sorts of rules of format and presentation, all of which could be described as "arbitrary", of which the one under discussion is one minor case. I fail to see how this one makes translation any more difficult. If you mean that it makes it more difficult for a non-native-English speaker to contribute, I don't see how, any more than any other rule (on that argument, let's abolish all rules and not have a manual of style at all), and in such a situation due allowance is made, other people will help, a bot will fix it, etc. -- Alarics (talk) 19:21, 18 September 2009 (UTC)[reply]
There's a nail hit square on the head. Where we mostly see YYYY-MM-DD on WP is as citation template output. These templates used to link these dates, the assumption being that everyone had prefs set so would see dates in the style they wanted them. This assumption has since been abandoned.
The argument that en:Wikipedia is but a small part of a greater Wikipedia doesn't sway me. Sure it is, it's the part written English. What place has YYYY-MM-DD in written English? I can't think of any (at least without contriving some special circumstances). As for the great barrier translating dates from articles written in other languages ... I'd suggest that this is probably amongst the easiest parts of the process ... and made all the easier by {{date}}. JIMp talk·cont 19:34, 18 September 2009 (UTC)[reply]
"Where we mostly see YYYY-MM-DD on WP is as citation template output". That's my subjective impression too, and if so, maybe the biggest single thing we can do to begin tackling the problem is to persuade Mr Z-man to remove the default date from his citation refTool. We might be able to do that more easily if MOSNUM has already prepared the ground, however. Alarics (talk) 19:53, 18 September 2009 (UTC)[reply]
There's the rub. "Where we mostly see" dates has little bearing on how we write them. Most citations, particularly, are now done using templates. The wikitext input shouldn't have to conform to somebody's idea of stylistic correctness, so long as it is unambiguous. Once rendered through citation bot and its template chums, the rendered html can look like anything you please. But lose the talk of "bans". It doesn't help anything in a collaborative environment.LeadSongDog come howl 21:18, 18 September 2009 (UTC)[reply]
"Bans" was just shorthand for internal purposes here. I think "deprecate" is the official word. Incidentally, my experience is that, in the vast majority of cases, nobody actually does complain when one turns their YYYY-MM-DD dates into proper dates. It would just be nice to have unambiguous, explicit official backing in the rare case when they do complain. -- Alarics (talk) 22:13, 18 September 2009 (UTC)[reply]
The connexion between where we mostly see YYYY-MM-DD and the fact that it was written that way is this. You put double square brackets around this and it gets autoformatted ... for all those who have their prefs set. The templates used to do this under the assumption that those reading the dates would have their prefs set. The assumption has since been thoroughly discredited and the template behaviour adjusted accordingly. The original intent therefore seems not to be that citations should display YYYY-MM-DD but should conform to user preference but now we have a proliferation of YYYY-MM-DD in refs. The continued use of YYYY-MM-DD I suggest has more to do with the notion that this is just how it's done than thought of how things should be done. Rethink it and surely we'll conclude that the more sensible thing will be to conform to the style of the article as a whole. JIMp talk·cont 18 September 2009 (UTC)
  • LeadSongDog: What in the world are you talking about in your 17:24, 18 September 2009 post, where you write of people here Throwing roadblocks in the way of those trying to cite sources? Is there something confusing about “January” or “Jan.” or “Jan”? Or are you suggesting that an all-electronic, adjustable-everything encyclopedia can’t possibly make room for writing (Science News, Vol. 131, Sept. 25, 2006) because the extra megabytes of text totally fills up the screen so much that all the rest of the page runs off the bottom of your screen?

    Moreover, if you really wanted to do a ‘proper’ job of citing, I’d point out that Science News, like pretty much all periodicals, has this sort of little diddley thing in the upper right-hand corner: October 13, 2007 so I find arguments that YYYY/MM/DD has some sort of intrinsic virtue in citations (or any other place on Wikipedia, for that matter) to be profoundly uncompelling. You aren’t going to convince anyone here of anything if your arguments crumble so badly and easily in the face of reality.

    It’s so profoundly simple: act like any other half-way professional publication and simply write out the month because it reads more naturally and is unambiguous. Besides looking awful, all-numeric dates are especially awkward for European readers and those in other countries where they customarily write out dates like “8 December” and “8/12.” Because of daily reinforcement, these readers are accustomed to seeing the month last and have to mentally flip this order around just because it is preceded by a year. It is of no help if ISO, JIS, ANSI, or IPSO FACTO endorse this or that standard; it’s all BS because the only thing that matters is what is most natural in the daily life of the reader. Any all-numeric date format—even if it is a “standard” (*sound of heavenly female oratorio*) endorsed by Santa Claus and Oprah herself—is inherently ambiguous. Moreover, all-numeric dates don’t look in the least bit professional—they aren’t the least bit professional—which is why quality publications don’t ever use them.

    Give it up. Can you not see the handwriting on the wall that all-numeric dates of any sort are toast? Completely burnt toast? Let’s get over this. There is no compelling reason to depart from standard practices observed by any quality publication—including all English-language encyclopedias. It is über‑stupid that so much verbiage has been devoted to something so elementary. Greg L (talk) 05:04, 19 September 2009 (UTC)[reply]

Agree with Greg L. "it's all BS..."—quite funny.  HWV258  05:38, 19 September 2009 (UTC)[reply]

Hyper-compressed dates

It just struck me yesterday that if one really needed to save space in giving a date while still avoiding ambiguity, you could use what I think of as librarians' abbreviations for the months (because they sometimes appear on due-back rubber stamps and works such as the Readers' Guide to Periodical Literature): Ja, F, Mr, Ap, My, Je, Jl, Au, S, O, N & D. So long as the year is expressed as more than two digits, there's no ambiguity, although of course these abbreviations are hardly universal or intuitive. (And, no, there's no "a" in June or July, no "e" in January or July, no "l" in January or June, no "p" in August, no "u" in April, no "r" in May and no "y" in March; unlike US State abbreviations such as AL, AR, MI or MS which often confound most Americans who don't work for the Post Office, there's no way to mistake which month "Je" refers to.) So all dates after the year 999 could theoretically be compressed to between 6 and 8 digits without dashes as 18S2009, 4Jl1776, 5N1605 or 14Jl1789. As Independence Day and Bastille Day show, however, clarity would dictate, either capitalizing the L in Jl (as with litre), or requiring spaces.

This is not a serious proposal, and, although unambiguous would be hard for the average reader to understand, but probably no more so than YYYY-MM-DD (which is ambiguous to those unfamiliar with it). But I wanted to show that YYYY-MM-DD is not the only possible way to compress dates, nor even the shortest. —— Shakescene (talk) 20:24, 18 September 2009 (UTC)[reply]

Well thanks, but as you say, "this is not a serious proposal", and it doesn't help any in the present discussion. Alarics (talk) 22:08, 18 September 2009 (UTC)[reply]
Use Julian day numbers expressed in a base 1024 counting system comprised of digits 0 to 9, the extended Latin alphabet, the Greek alphabet, Japanese kana, Chinese characters, etc. JIMp talk·cont 10:13, 19 September 2009 (UTC)[reply]

¶ That (not Klingon or Julian days) is pretty much the way I abbreviate dates for myself (e.g. 12 Ap 1861 or 4:45 Tu 20 O), so I wasn't being utterly fanciful. But while I think my system might be easier to grasp at first sight and less ambiguous than 2009-09-19, I wouldn't recommend either for Wikipedia because the average reader would be thrown unless the table or list explained the whole dating system. And with the right templates to convert and re-convert dates, Julian days (adjusted for the fact they begin at noon) would be a great way to store dates, far better than the range-limited and notorious systems for Excel in Windows (which thinks there was a 29 Feb. 1900) and Macintosh (which has an equally glaring error that I've forgotten).—— Shakescene (talk) 19:56, 19 September 2009 (UTC)[reply]

ISO 8601

There is an international standard and it is YYYY-MM-DD, so why don't we use it? To quote from the ISO site, it's

  • Easily readable and writeable by systems
  • Easily comparable and sortable
  • Language independent
  • Larger units are written in front of smaller units
  • For most representations the notation is short and of constant length

and ISO 8601 corresponds to the UN Working Party on the Facilitation of International Trade Procedures in its Recommendation 7. --Cavrdg (talk) 07:11, 19 September 2009 (UTC)[reply]

Why don't we use it? The reasons are detailed at length above but ...
  • The only system we need really concern ourselves with here is the human and it's not that easily readable to this system.
  • The only sorting that is done with dates is in automatic sorting tables for which we can use {{dts}}
  • This is the English language Wikipedia; language independence is of no concern.
  • Ascending order vs descending order, which is better? But I'd have to admit it makes more sense than putting the month first.
  • Brevity can be achieved using abbreviations add leading zeros if constant length is necessary.
We're writing an encyclopædia not trying to facilitate international trade. JIMp talk·cont 09:36, 19 September 2009 (UTC)[reply]
We should not use it because the standard itself tells us it is not to use it for dates before 1583, and Wikipedia has many articles containing early dates. I don't believe any further advocacy of ISO 8601 from Cavrdg should be given any weight at all until he or she assures us that he or she has read the standard. --Jc3s5h (talk) 15:17, 19 September 2009 (UTC)[reply]
The Recommendation 7 cited by Cavrdg is outdated; it appears to have been written before 2000. It permits expressing years in the second and third millennium with two digits, which is an abomination. --Jc3s5h (talk) 15:40, 19 September 2009 (UTC)[reply]
  • The term “ISO 8601” was mentioned 58 times on this discussion page before you raised the subject (again) here. That it is a “standard” doesn’t matter; proper writing practice is to write out the month. There was an IEC standard that computer memory should be written 256 mebibytes (MiB) of RAM. Wikipedia used this form on many of its computer articles for three years before it dawned on us that we ought to follow the practices observed by all professionally produced publications. Greg L (talk) 16:20, 19 September 2009 (UTC)[reply]

    P.S. At 2009-09-19T1630 I read Recommendation 7. Nice standard… for time-stamping the ticket for going into the Chunnel between England and France. Not to be used in encyclopedias. Greg L (talk) 16:41, 19 September 2009 (UTC)[reply]

I also strongly oppose using ISO 8601. I have two reasons. If I see 2000-10-08, I anyway have to translate this for myself into "the 8th of October 2000". And because it is not clear from the format whether it should be "October 8th" or "August 10th", and this is a possible source of confusion. Debresser (talk) 11:22, 22 September 2009 (UTC)[reply]

What the ...?

The actual reason why we can't seem to get consensus on anything is that we're trying to discuss several related but distinct issues at once. This all started with a suggestion to ban the 12/09/2009 format, and no-one seems to disagree with that; so, why don't we just add to the MoS:

Do not use date formats such as 03/04/2005, as they are ambiguous (it could refer to 3 April or to March 4); for the sake of consistency, do not use them when the day number is greater than 12, either.

meanwhile, and then continue discussing the remaining issues (YYYY-MM-DD, AP abbreviations, three-letter abbreviations) more calmly? --___A. di M. 09:00, 19 September 2009 (UTC)[reply]

I think we're a lot closer to consensus than the above tangle makes immediately clear.
  • Yes, 03/04/2005 is to be depreciated.
  • There remain some supporters of YYYY-MM-DD but I don't find their argument as strong.
  • Allowing AP dates or not is still under discussion.
  • The question of dotting three-letter abbreviation (when not AP style) is also unresolved.
JIMp talk·cont 10:32, 19 September 2009 (UTC)[reply]
I agree with Jimp. We’re closer to a consensus than you might think, A. di M. The only problem here is caused by editors who hear buzz on the grapevine that there’s a “date kegger” going on at WT:MOSNUM. They arrive late to the party, don’t have the super-human diligence to wade through these long threads (that’s understandable), and then exhibit the temerity to raise some well-worn issue that has been long resolved by those editors who’ve been in the saddle the whole time.

In my book, this phenomenon is akin to walking right up to a party at a house where everyone is heading out the door and saying “No no… everyone back in. I got here late and missed out on it all so everyone start over and begin discussions with me included this time.(*sigh*)

This seems to be the “Wikipedia way®™©” right now and we might one day establish rules that if debate is wrapping up and someone crashes his damned SUV through the living room wall and yells “start all over with me!” that we’ll just inform said editor that, with thousands of editors, we must cut off debate at some point. Greg L (talk) 16:06, 19 September 2009 (UTC)[reply]

Damn anyone for having the nerve to offer their opinion and disagree with you! The endless facetious comments from the likes of you (Greg L) do nothing to encourage people to wade into the discussion and read through all the arguments. I can only assume you think you are super intelligent and witty. I have an idea for you – it might be time for you to take a step back, calm down and take a break from hurling insults around, then come back later when you feel in a more constructive mood. wjematherbigissue 17:30, 19 September 2009 (UTC)[reply]
  • Oh… relax. First of all, I am calm. Secondly, you’re the one who appears to be all worked up and needs to calm down. Thirdly, we’re just talking about how to properly format dates; it’s not the end of the world. Fourthly, I have insulted no one here and no one has cast aspersions upon you, such as “Hab SoSlI' Quch!”. Debate, by definition, necessarily entails opposing the positions and ideas of others. Greg L (talk) 2009-09-19T1741 ;·)
Yes Greg L, you are in a habit of constantly insulting everyone who dares to disagree with your opinion. Furthermore you instantly brush aside any argument brought up against your personal preferences. That you do not recognise that yourself makes doubtful of your maturity. It would lead to better quality of the discussions if you would just react factually to arguments. −Woodstone (talk) 18:25, 19 September 2009 (UTC)[reply]
  • Woodstone, you confuse “disagreeing with you” as equating to “my lacking maturity”. Please stick to the issues please and don’t make personal attacks. Sometimes, there are a wide variety of ideas that people have, such as “communism vs. capitalism” and editors get all wound up where they equate criticism of the “cause” with criticism of “themselves.” Please try to differentiate between the two.

    Now, you wrote above I cannot possibly see anything wrong with all-numeric dates in the practically unambiguous from [sic] of 2009-09-17 and strongly oppose banning it. All portions of that position are demonstrably false. As is clearly explained above, all-numeric dates like “2009‑11‑09” are inherently ambiguous. Moreover, they look poor. For these, and probably still other reasons, no English-language encyclopedia uses them; it is not proper journalistic practice. If you want Wikipedia to diverge from standard encyclopedic practices, you’ll need to come up with a really compelling reason for doing so. Ain’t seen one out of you so far. Greg L (talk) 18:49, 19 September 2009 (UTC)[reply]

  • The objection "they look poor" is purely subjective. In tables I find them quite pleasing, because of the objective fact that their elements are in vertical alignment.
  • Dates like 2009-09-19 cannot be reasonably interpreted as being in YDM order. That order is practically never used anywhere. Can you show a body of occurrences that are not YMD?
  • Why is there any need to proceed to the heavyhanded action of a ban of a specific form that does not create any problems?
  • Can you show to a large body of occurrences of the proposed form of 2009 Sep 19?
Woodstone (talk) 20:24, 19 September 2009 (UTC)[reply]
(edit conflict x 2)
  1. After 9/11 (and 7/7, 7/11 and 3/11 alias el 11 M), no one can be entirely sure what order an all-numeric date is in.
  2. It's so unfamiliar to many people that many don't even recognize at first glance that 2001-09-11 is even a date.
  3. I'm sure that non-techies who've been writing 11/7 for July 11th all their lives don't effortlessly and subconsciously switch gears to realize that 1690-12-07 isn't July 12th but December 7th.
  4. I don't see 2009 Sept. 19 very often in the body of a text, but it is sometimes used in chronologies. —— Shakescene (talk) 21:10, 19 September 2009 (UTC)[reply]
  • You’re beating around the bush, Woodstone. Whether or not you understand or agree with the manuals of style and practices of all professionally produced English-language encyclopedias has no bearing here. Nor do your arguments for how your all-numeric date format of choice is *logical* and *gloriously unambiguous*.

    The fact is, no proper English-language publication of any sort uses all-numeric dates. As I said above, if you want Wikipedia to diverge from standard encyclopedic practices, you’ll need to come up with a really compelling reason for doing so.

    Does your argument that Wikipedia should flout these well-established practices amount to nothing more than “you like-ta”? Do you think all-numeric dates are exceedingly modern—even futuristic? Do you believe what some I.P. editor once wrote (fantasized) on ISO 8601? You know, that bit about how ISO 8601 “applies to all written communications … [even] hand written … when communicating … even privately.” Are you seriously asking us to believe that people are being “old-fashioned” when the write a handwritten note to their mother that spells out the name of a month?

    Let me know when the rest of the world starts writing notes like this to their mother:

Mom,

I went to Brad’s house to play with his Star Wars collection. Be back at 2009-09-19T1741.

The practice memorialized in ISO 8601 is fine for airplane tickets transmitted over the Internet. No one here is holding their breath for the day most people observe practices like this in their day-to-day activities. Have you seen this practice lately in any nice magazines? How about your local newspaper? How about any encyclopedias like Encyclopedia Britannica or World Book? Yeah, me neither. Yet here you are, promoting it for use on Wikipedia. Baffling. Greg L (talk) 20:58, 19 September 2009 (UTC)[reply]
A. Di M.'s 09:00 seems to be a step forward, although wordier than it needs to be. We could simplify it to "Avoid ambiguity." That would avoid 11/10/09, 12/11/1009, 12111009. It would even avoid 27 December 1701 unless the calendar was identified (as Gregorian, Julian, etc.) LeadSongDog come howl 20:20, 19 September 2009 (UTC)[reply]
I agree that A. Di M.'s post of 09:00, 19 September 2009 (UTC) is a satisfactory interim measure until some of the other issues reach consensus. --Jc3s5h (talk) 20:42, 19 September 2009 (UTC)[reply]
Concur; I also support A. Di M.'s proposal. Let's address one issue at a time instead of trying to fix the world's problems all at once. Dabomb87 (talk) 21:10, 19 September 2009 (UTC)[reply]

(Unindent) Woodstone asked "why is there any need to proceed to the heavyhanded action of a ban of a specific form that does not create any problems? (Emphasis added.) No specific form has been put forward. The various forms that could be used will create problems due to ambiguity. Writing "dates like 2009-11-09" leaves too much to the imagination and interpretation of editors. If something more specific were written, it would be well-neigh impossible to communicate it to readers. --Jc3s5h (talk) 20:47, 19 September 2009 (UTC)[reply]

  • If we are going to have an interim solution, then why the latter clause? Why not simply this:

Do not use date formats such as 03/04/2005, as they are ambiguous (it could refer to 3 April or to March 4).

Greg L (talk) 21:20, 19 September 2009 (UTC)[reply]
I consider it likely that someone will write an article that contains at least one day number greater than 12, and will use the 03/04/2005 format because in that particular article, assuming every editor follows the same convention, it isn't ambiguous. --Jc3s5h (talk) 21:37, 19 September 2009 (UTC)[reply]
For dates with year last, the MOS has said for a long time not to use numeric months. That is a wise measure to avoid ambiguity. Here we are only discussing dates with year first. In that case the order of YMD is the only one widely used. A quick Google for "2001-09-11" yields 10 million hits, whereas "2001 Sep 11" has only 200,000. Of course many of the hits are not even dates, but nevertheless it is indicative. Banning the most frequently used form does not make sense. Before doing that, more evidence on the relative frequency of use of the two forms in question is needed. −Woodstone (talk) 22:09, 19 September 2009 (UTC)[reply]
To Woodstone,
  • We can get elements in vertical alignment easy enough using three-letter abbreviations by including leading zeros or, with the international style, by left alignment.
  • Maybe dates like 2009-09-19 cannot be reasonably interpreted as being in YDM order but we should not assume people to read in what we might think of as a reasonable way (yes, this is serious).
  • "Why is there any need to proceed to the heavyhanded action of a ban of a specific form that does not create any problems?" There is none; YYYY-MM-DD is no such form.
  • "Can you show to a large body of occurrences of the proposed form of 2009 Sep 19?" No, a fine compromise it would be between the day-monthers and the month-dayers, only it's just not used in English ... put it in a sentence and feel how it reads. This one can be rejected.
Who's talking "2001 Sep 11" vs "2001-09-11"? Where the discussion is leading is in the direction of depreciating both. JIMp talk·cont 22:21, 19 September 2009 (UTC)[reply]

From above by Greg L: "The fact is, no proper English-language publication of any sort uses all-numeric dates". This is simply nonsense. Use of dates written like 9/11/2001 is very common, both in running text, and in isolated places, like headers of articles or in tables. Wikipedia is rightly deviating from that practice, because its international readership would easily be led to mistaken interpretations. However, outside of running text, in some cases a more condensed form is prefarable. For that purpose the form "2001-09-11" is the most suitable, because of its unambiguity and international recognition. And, by the way, vertical alignment cannot be achieved with textual months in the variable size fonts, now almost universally seen, even on computers. −Woodstone (talk) 22:51, 19 September 2009 (UTC)[reply]

The all-numeric year-month-day form is ambiguous. The fact that Woodstone cannot understand this this after repeated hints proves that not only it is it unfit for use in Wikipedia, but that it is impossible to rehabilitate it. --Jc3s5h (talk) 23:00, 19 September 2009 (UTC)[reply]
  • Nonsense? OK, Woodstone. Show me where any English-language encyclopedia uses all-numeric dates. Where? Only Wikipedia; that’s where. And that practice will eventually be deprecated. Watch; it’s days are numbered and you’re riding the loosing horse.

    As for your Wikipedia is rightly deviating from that practice, because its international readership would easily be led to mistaken interpretations. What an absurd thing to write! No international readership could possibly be confused by either November 9, 2002 or 9 November 2002. Conversely, the very thing your are promoting, all-numeric dates, are precisely the very thing that can cause confusion. Why? Simply because most people in their daily lives write these dates in some parts of the world as 9‑11‑2002 and still others 11‑9‑2002. Then there is this idiotic practice that you’re promoting because it is a *standard* (big whoop, it was never intended for use outside of stuff like airline tickets) that very few people anywhere outside of Star Trek conventions (and Wikipedia editors who have zero formal training in journalism) ever use: 2002‑11‑9, which is particularly confusing to European readers.

    As for your tiresome refrain about “international” readerships, are you even reading what you’re writing? Do you think Encyclopedia Britannica is only read by Americans and Britons?.

    It simply boils down to the fact that we have yet another “IEC prefix” crowd that is absolutely convinced of the superiority of a new *standard* and feel Wikipedia should be hijacked so we Can take the lead and show the world the path to a brighter and more logical future by adopting and misconstruing every *standard* ever proposed.©™® Uhm… no. As we learned from the IEC prefix experience, Wikipedia simply follows the way the real world works and never tries to promote change by adopting practices that are used only by Trekies, computer programmers, and a handful of Wikipedia editors. If it isn’t in other manuals of style, it’s probably a ratty idea.

    I think I’m gonna start an RfC to institute a rule that the only people who can edit MOS and MOSNUM are people who A) have journalism degrees, and B) have multiple resource books and “real” manuals of style such as Chicago Manual of Style and the AP Manual of Style. Then inane suggestions will hopefully evaporate, such as suggestions that Wikipedia is *uniquely* read by international readers (but Encyclopedia Britannica is not) and this is somehow a reason to engage in confusing practices that flout Technical Writing 101 and introduce confusion rather than reduce it (and looks like crap to boot). If adopted, I’d be eliminated from contributing, but so too would about 99% of the people who do drive-by shootings on MOS and MOSNUM because they’re out to show the world how things *oughta* be done. I’d welcome that. My older brother has an advanced journalism degree and taught college-level journalism. Under this proposal, he could contribute to MOS and MOSNUM. But then, he’s too damned smart to waste his time here. Greg L (talk) 02:23, 20 September 2009 (UTC)[reply]

I don't think anyone is suggesting that numeric dates be used in the body of an article, but I agree with Woodstone, they are used extensively in the wider world (just perhaps not Greg L's tiny part of it), and I do think they are apporopriate in certain circumstances such as in citations.
Further note to GregL – Please try to keep to the subject in hand and avoid further incivility. I think we have all had enough of your ranting. (It would also help if you simply indented your contributions without bullets as per WP:TP) wjematherbigissue 09:22, 20 September 2009 (UTC)[reply]
  • I count only one rant, above, and it was by you after having totally flipped your lid. As for allegations of incivility, I count only one instance, above, and that was by Woodstone where he accused me of being immature. As for your accusing me of incivility, that is the tiresome cheap-shot used by some Wikipedians when trying to put on an appearance of seizing the moral high road after their arguments have been proven to not hold water. Don’t presume you can hide behind the apron strings of false charges of incivility and just stick to debating the issues for once. I haven’t seen one logical argument out of you yet. Greg L (talk) 19:24, 20 September 2009 (UTC)[reply]
Woodstone did question your level of maturity, which is fair enough given the methods you employ when trying to make a point. Your number one tactic seems to be questioning the intelligence of others should their opinion differ from your own. You unnecessarily (and often inexplicably) embolden, italicise or underline words and phrases, and you do rant rather than express yourself in a clear and concise manner. It is perhaps simply naive of you to think people are not watching the discussion unfold before offering their opinion, but berating them for joining a discussion late in the day is uncivil, as are your thinly veiled accusations that fellow editors are somehow stupid or illiterate. Finally, this is not a place for debate, it is the place for civilised discussion with the aim of reaching a consensus one way or the other, a subtle but importance difference. wjematherbigissue 20:06, 20 September 2009 (UTC)[reply]
Most of the above comments by Greg L completely miss the point of what I had stated above. Greg L said that "no proper English-language publication of any sort uses all-numeric dates". Indeed that is untrue, as the use of dates like 9/11/2001 (USA) or 11/9/2001 (elsewhere) are very common. However WP has rightly agreed to deviate from this practice (i.e. the said all numeric forms) and always spell out the month names in running text. In my view and as proposed by others this should be extended to all cases where the year comes last. However that leaves cases where a more condensed form is preferable, such as in isolated places (headers, refs, tables). That is where the numeric form with year first comes in. As far as my observation of the real world goes, I never see cases where 2001-09-11 would be in November. −Woodstone (talk) 09:48, 20 September 2009 (UTC)[reply]
9/11 is a special case. In the UK at least, "9/11" and "9/11/2001" do not refer to the same date. People will recognise 2001-09-11 more easily simply because "9/11" is generally understood - but they may well interpret 2001-11-09 as the same date.
If you were to pick a more arbitrary date, it is far less easily understood. Even knowing the fact that YYYY-DD-MM is not really used, my first reading of 1776-07-04 would be 7 April 1776, not 4 July 1776. My first reading of 1605-11-05 would put Guy Fawkes Night in May. I've used this format in the past on Wiki (to induce autoformatting before it was deprecated) and I know that it's technically unambiguous, but it is still open to misinterpretation and I still misinterpret it on the first look. How can we expect readers who are unfamiliar with the YYYY-MM-DD standard to understand it if those that are familiar with it misinterpret it?
We don't want our readers to have to puzzle over dates, we want it to be clear first time - and the only way to do that is by not generally accepting all-numerical dates. Pfainuk talk 11:26, 20 September 2009 (UTC)[reply]
When I read Pfainuk's claim that Guy Fawkes Night was 1605-11-05 I was confused. Since I live in the USA, I had a general notion that Guy Fawkes Night was in the autumn, but didn't know quite when. Thus, I was unable to guess whether Pfainuk had given the date in the Julian calendar, since that was the calendar in force in London in 1605, or whether he and converted it to Gregorian, as required by ISO 8601. Of course, neither Pfainuk nor Wikipedia makes it clear whether ISO 8601 applies to dates in that format written in Wikipedia.
So I when to British History Online and found a transcript of the House of Commons Journal for 5 November 1605, which contained this passage:
Gunpowder Plot.
This last Night the Upper House of Parliament was searched by Sir Tho. Knevett; and one Johnson, Servant to Mr. Thomas Percye, was there apprehended; who had placed Thirty-six Barrels of Gunpowder in the Vault under the House, with a Purpose to blow King, and the whole Company, when they should there assemble.
Afterwards divers other Gentlemen were discovered to be of the Plot.
From: 'House of Commons Journal Volume 1: 05 November 1605', Journal of the House of Commons: volume 1: 1547-1629 (1802), pp. 256.
Unambiguous my ass. --Jc3s5h (talk) 15:10, 20 September 2009 (UTC)[reply]

Okay, Woodstone, yes, you're right; dates with three-letter abbreviations won't align (without some fancy adjustments). I wasn't thinking about the variable width of letters in the font used here. Chalk that up as an advantage of YYYY-MM-DD. Weighed against the disadvantages of YYYY-MM-DD, though, alignment hardly counts for much (but if we really must have it, I'll write us a template to align dates with three-letter abbreviations).

How could people think YYYY-NN-NN dates might possibly be YYYY-DD-MM? It defies all logic. This format is never used. It makes no sense ... right? Nonetheless people do make this mistake. That's enough, we don't need to fathom why. The format is unfamiliar.

Wjemather thinks YYYY-MM-DD dates "are apporopriate in certain circumstances such as in citations". Why? What is so special about citations that we have to use a different format than that used in the rest of the article? I've never been able to get this one. We see it all over the place, though. No, the only theory I can come up with is that people have just grown used to seeing this in citations because it was once the required input format for the citation templates. The format is unfamiliar & ambiguous, the only circumstances on WP where it's appropriate is hidden from view. JIMp talk·cont 16:07, 20 September 2009 (UTC)[reply]

Woodstone says of YYYY-MM-DD, "The objection "they look poor" is purely subjective. In tables I find them quite pleasing, because of the objective fact that their elements are in vertical alignment". Leaving aside whether they look poor or pleasing, if we are talking about tables, haven't we already agreed that that is the one case where they may be used if necessary for space (narrow columns) reasons? And nobody has suggested that it be used in sentences in the body of the article. So the dispute is only about whether they may be used in footnotes. I say they should not, because however unambiguous some may think that format, others here who say they are unfamiliar with YYYY-MM-DD have said they could not guess which figure is the day and which the month; and because, even for many of us who know which way round it is, one still has to stop and think about it. In my case, I came across this style first in computer databases and I do know what it means, but I still find it interrupts my train of thought while I make a conscious effort to decipher it. It should stay in computer databases; there is absolutely no need for it in encyclopaedia footnotes, where there is always room to write out the month in words. Alarics (talk) 18:40, 20 September 2009 (UTC)[reply]
  • Well done, Jimp and Alarics. Both; succinct and clear.

    Woodstone: Let’s attend Real World 101 here for a moment and also get into Woodstone’s mind. Let’s hook up the ol’ EEG to his brain…

    1. YYYY-MM-DD is logical. Fine; I agree with that 100%.
    2. People in their daily lives seldom use YYYY-MM-DD when they write, type, or speak of dates. Would you agree with this statement?
    3. People in their daily lives are seldom exposed to YYYY-MM-DD on their televisions, in newspaper articles, in magazines, and certainly not in Encyclopedia Britannica nor in World Book. In fact, the publication date in the upper left-hand or right-hand corner on the covers of most periodicals spells out the name of the month. Would you agree with these statements?
    4. The goal of all technical writing is to communicate with minimal confusion and to write in a way that is most natural and fluid and produces the fewest (*!*) subconscious interruptions in the train of thought. Would you agree with this statement?
    5. The expression November 11, 2002 can not possibly be confused with some other date. Would you agree with this statement?
    6. The expression 11 November 2002 can not possibly be confused with some other date. Would you agree with this statement? (Note that, though I am an American, this is the format I use when I am authoring general-science articles that are not closely associated with the United States or its territories.)
    7. Dates should be communicated in print in the most natural and unambiguous way possible. Would you agree with this statement?
    8. Encyclopedia Britannica (which is a British publication) is often read internationally and is found in other English-speaking countries—even at the library in Spokane, Washington from which Greg L hails; that is, it is an *international* publication. In fact, it can probably be found in any decent library in Europe. Would you agree with these statements?
    9. Few Wikipedians offering their 2¢ here have advanced degrees in journalism but nevertheless enjoy contributing to MOS and MOSNUM. Would you agree with this statement?
    10. Conjecture: Because of points 1, 2, 3, and 5, 6, 7, and 8 above; maybe the objective of point #4 above (writing naturally and clearly), underlies whey the manuals of styles used by professional copy editors at all quality publications throughout the English-speaking world call for writing out the name of the month in dates and also typically call for using short-form months in parentheticals and citations. What do you think about this conjecture? Could it have some validity?
    11. Because of point 9, above, we would be well advised to follow the practices of professionally produced publications. Would you agree with this statement?
Please respond to each of the above questions so we can identify the crucial point (or points) that cause you to reach a conclusion that varies so much from that of the others here. Once we have identified the key assertions with which you disagree, we can work towards gathering more data in hope of uncovering the real facts. Greg L (talk) 19:03, 20 September 2009 (UTC)[reply]
I agree fully with statements 1, 5, 6, 8, 9, 10 and 11 (in 5 and 6 the 11-11 is not ambiguous either, but that aside). I do not agree with 2 and 3, since these forms are quite common in international business communication, but also web pages and magazines use these forms, especially in isolated positions. A quick Google finds for example this and this. That leaves 4 and 7, with which I agree, but we may not mean the same by "most natural" or "fluid". In circumstances where quick comparison (ordering) between dates is of importance to the reader, in my view the form yyyy-mm-dd is more natural and flowing. This especially applies in tables, where the vertical alignment also helps, but also in references, where the order carries valuable information. As for 10, do those guides advise year first? −Woodstone (talk) 19:54, 20 September 2009 (UTC)[reply]
  • Well, good. You agree that writing out the months is absolutely unambiguous. You also wrote, further above, that YYYY-MM-DD is “practically unambiguous.” That equivocation (wiggle room) is tacit admission that all-numeric dates of any form must necessarily cause some confusion to some readers because of the widely varying day-to-day customs throughout the world; this is just too much common sense.

    As for your …in my view the form yyyy-mm-dd is more natural and flowing, the general consensus here is that it is certainly not and your achievement of providing links to web sites that use all-numeric dates is utterly irrelevant to this discussion.

    This should be the end of it. As with the IEC prefix debate, there was one editor who absolutely would not agree that “mebibyte” had no place on Wikipedia since it was *the future*. He ended up just falling on his sword and left Wikipedia. A “general consensus” on Wikipedia does not mean that 100% of editors are in full agreement and it never did. I would hope, Woodstone, that you will just realize what’s in the cards here for all-numeric dates on Wikipedia. No professionally produced, English-language encyclopedia uses them and there is no compelling reason in the world for Wikipedia to do otherwise. Greg L (talk) 20:17, 20 September 2009 (UTC)[reply]

Encyclopedia Britannica has been published in the United States since 1901, and currently has its headquarters in Chicago, Illinois. Just thought I'd mention it.RockyMtnGuy (talk) 19:25, 20 September 2009 (UTC)[reply]
Indeed, they have offices throughout the world. Editorially, the set is authored—as I recall—using British-English. When you buy the 2008 edition, you are buying “Britannica Encyclopaedia.” Am I wrong about that? I guess I don’t mind wadding into this minutia; I ought to know more about what I intend to buy some day soon. Greg L (talk) 19:40, 20 September 2009 (UTC)[reply]
Britannica is sometimes sniffed at here in the UK for no longer being properly British, despite its name. True, like much else, it has arguably been taken over, if not by American cultural imperialism (as some would allege), at least by American editors. But still, it is in many ways a good representative of what still unites the English-speaking world, and everything Greg L says is correct. -- Alarics (talk) 19:50, 20 September 2009 (UTC)[reply]
  • Thanks, Alarics. I didn’t know you were from England. Indeed, that doesn’t surprise me that EB is getting Americanized. The U.S.-dialect English dominates on the Internet so it is natural that certain Britishisms like “connexion” and “kilogramme” fall victim to the inexorable “yankification.” I wouldn’t be the least bit surprised if that preceding statement is poo-poohed for factual shortcomings; I am not expert on British-dialect English and what’s “in” and what’s “out.” But, you get the idea. Greg L (talk) 20:01, 20 September 2009 (UTC)[reply]
  • (Expanding more completely on my last post) It has one of its offices in Chicago. Indeed, they have offices throughout the world, including India, Israel, and Korea. Editorially, the set is authored—as I recall—using British-English and this has long lead me to conclude that it editorially hails from its offices at Mill Street, London. When one buys the 2008 edition, one buys what is titled “Britannica Encyclopaedia.” Am I wrong about that? My assumption is that the version that is “published” in Chicago differs only on the first few pages just past the fly leaf; editorially, they are all largely the same—regardless of where they are published. I guess I don’t mind wadding into this minutia; I ought to know more about what I intend to buy some day soon. Greg L (talk) 19:40, 20 September 2009 (UTC)[reply]
Getting back to the discussion at hand, the preferences of Britannica, or any other publication, have no bearing on what happens on Wikipedia. What matters is what editors actually do, and MOS should take more account of that rather than trying to impose whatever the relatively few people who contribute here would prefer to do. wjematherbigissue 20:10, 20 September 2009 (UTC)[reply]
  • Absurd. Contributing editors frequently write falsehoods in Wikipedia articles, but we don’t allow falsehoods to persist simply because that’s “what editors actually do.” Editors frequently use U.S. customary units of measure in science articles, but those are soon corrected because we have guidelines on MOSNUM that say otherwise. You are trying to place the cart before the horse. Just pardon me all over the place for suspecting that you fully understand that if our guideline prescribes the practices observed by other English-language encyclopedias, instances of YYYY-MM-DD will be properly converted to a readable form and you don’t want that to happen. Just because YYYY-MM-DD is *logical* has no bearing here. It is not frequently used by readers and looks poor, which is why copy editors who know better don’t use it. Greg L (talk) 20:25, 20 September 2009 (UTC)[reply]
Don't be obtuse. As you point out, MOS is nothing more than a guideline, and if if differs greatly from what a vast number of editors actually do, then it will be ignored, precipitating edit wars. As such, MOS absolutely should take more account of the practices of the majority of article editors. YYYY-MM-DD is widely used, perfectly readable, does not look poor, and to my mind perfectly acceptable for a range of uses, including citations. wjematherbigissue 20:40, 20 September 2009 (UTC)[reply]
  • I find your arguments, wjemather, to be unsupported by the facts of reality. Your arguments are circuitous and strike me as being illogical. Moreover, I have grown tired of being on the receiving end of incivility by your impugning my maturity.

    It is clear that you have strong convictions about how it is you edit and nothing will ever change your mind. This is only about adhering to style guidelines that other encyclopedias use but you behave as if it is the end of the world.

    It is clearly pointless for me—and probably anyone else here—to further debate you. I will leave it to others to try to deal with you. There is ample electronic white-space, below for you to get in the last word as I will no longer deal with you. Goodbye and happy editing. Greg L (talk) 20:54, 20 September 2009 (UTC)[reply]

wjemather, you say that "YYYY-MM-DD is widely used, perfectly readable..." But it's not widely used in real publications (how many can you show us as examples?), and it's not perfectly readable - well, perfectly readable by machines, which is what it was designed for, but not by humans. Our target audience at WP is human beings, not computers. As we have seen in the discussion above, some people do find it ambiguous. And as I keep saying, even some of us who do know what it means still find that we have to stop and mentally 'flip it over' to decipher it -- so it is an obstacle to understanding. Were there some overriding reason that made it necessary in spite of all that, that might be worth considering. But there isn't. It simply isn't ever necessary, because there is always room enough in a footnote to spell out the month in words, which is instantly clear to everybody. -- Alarics (talk) 21:05, 20 September 2009 (UTC)[reply]
If we're considering what is done on WP, we'd best spare a thought as to why. YYYY-MM-DD is not that much used on WP outside sort tables & cite templates. In the former case YYYY-MM-DD is unnecessary & in the latter it's a product of a depreciated practice. JIMp talk·cont 21:50, 20 September 2009 (UTC)[reply]

I agree. It is mainly footnotes that are still at issue. Most of us think that YYYY-MM-DD is never necessary in citation footnotes, and should therefore be avoided because it can be an obstacle to understanding. A minority disagree, and think we should say that it can be used in footnotes. Can we bring Tony back in to suggest what should happen next? I will go along with whatever he recommends. -- Alarics (talk) 11:59, 21 September 2009 (UTC)[reply]

I like the sound of the discussion here about eliminating ambiguous date formats such as 03/04/2005. Now that date autoformatting is gone, and citation templates now no longer covert ISO dates into dd mmm yyyy or mmm ddd yyyy, so the reference section is often a messy mix of formats. I think we should simplify the section #Format consistency to read:

Dates in article body text and in article references should all have the same format

I also think the exemption for tables and infoboxes can still apply. Ohconfucius (talk) 12:23, 22 September 2009 (UTC)[reply]

I myself would expunge dd mm yyyy YYYY MM DD completely, from main text, tables and reference lists. If it's a question of deprecating its use in ref lists, it might be done through the template pages, just as date autoformatting was dispensed with in those templates. But VP and Centralized discussion would need to be invoked, since I suspect a number of editors would object strongly. Tony (talk) 12:57, 22 September 2009 (UTC)[reply]
I also strongly oppose using ISO 8601 and other notations like it with other separators (e.g. 2024/08/15). I have two reasons. If I see 2000-10-08, I anyway have to translate this for myself into "the 8th of October 2000". And because it is not clear from the format whether it should be "October 8th" or "August 10th", and this is a possible source of confusion. Debresser

Status quo is acceptable. "Slash dates" are an abomination, everyone agrees, we will never get agreement on dmy vs mdy, and Pseudo ISO are good for tables and lists for a number of reasons apart from dynamic sorting. Since we suggest never using pseudo-ISO for dates before 1583 the "ZOMG" scenario "what if someone puts the date 83-12-25, out readers will have brain failure!" doesn't arise. If we were writing 20091225 I might agree that it presents readability problems... Rich Farmbrough, 14:03, 22 September 2009 (UTC).[reply]

No, the status quo isn't acceptable, because it allows people to think that YYYY-MM-DD is OK in citation footnotes. Nobody is suggesting "slash dates", so that is a red herring. So is "we will never get agreement on dmy vs mdy" -- nobody is proposing making people choose one or the other of these, when the month is written out in full. The discussion has already narrowed down to whether or not we can explicitly deprecate YYYY-MM-DD in citation footnotes, so it would be very helpful if people contributing to this debate would confine themselves to that, and not confuse matters by dragging back into it questions that have been settled or which were never at issue in the first place.
Rich Farmbrough says that "pseudo ISO", which I take to mean YYYY-MM-DD, "is good for tables and lists". That is fine, as long as we agree that lists don't include references and footnotes. The issue before us is: in addition to deprecating YYYY-MM-DD in running text, which we already do, can we also deprecate it in footnotes. That's all. -- Alarics (talk) 08:11, 23 September 2009 (UTC)[reply]
I'm not sure that that is all. The proposals put forth by Greg & me call for the depreciation of YYYY-MM-DD altogether. It's not good for tables and lists, it's not good for displaying anywhere on WP. JIMp talk·cont 08:50, 23 September 2009 (UTC)[reply]
Personally I would agree with that, but I thought we were further away from consensus on tables, and that if we separate out the question on which a clear majority here seem to be agreed -- the deprecation of YYYY-MM-DD in citation footnotes -- we could make progress on that at least, and argue out the question of tables later. It is, I'm pretty sure, in footnotes that YYYY-MM-DD appears by far the most often (for the more-or-less accidental reason that we've discussed, to do with templates and date delinking), so that is surely the most pressing issue. -- Alarics (talk) 11:32, 23 September 2009 (UTC)[reply]
True, it seems that there is no real opposition here to ridding footnote & refs of YYYY-MM-DD but I still believe that the arguments against having YYYY-MM-DD at all are stronger than those for allowing them in tables. Rich Farmbrough, for example, states that they "are good for tables and lists for a number of reasons apart from dynamic sorting" but hasn't listed any yet. Woodstone notes that they align, but if alignment is a concern, there are ways of getting dates with three-letter abbreviations to do so. What's YYYY-MM-DD got left going for it? Some just like it. What's it got against? It's unfamiliar thus many just don't get it & of those who do I reckon most will be translating it into named-month form in their heads. It's time to get rid of it altogether & the consensus to do just that is decent. JIMp talk·cont 14:14, 23 September 2009 (UTC)[reply]
ISO-format dates have their uses and purposes. Ban them from the main text all you want, along with all other numeric formats, but they should be allowed in tables and in other special case. Contrary to what Greg L and some others says, 2009-09-06 is unambiguously recognized as meaning "6 September 2009" everywhere on the globe. The only valid argument to ban it from text is that "Jim was born on 6 September 2009" is more readable and flows more naturally in prose than "Jim was born on 2009-09-06". A total ban on ISO-format dates is going too far, because the perceived problems of allowing them some of the time are completely blow out of proportion. They won't be in prose, they won't be in references, and we suggest the "12 Sep 2005" or "12 Sept. 2005" in tables as an alternative to "12 September 2005", so even in tables the ISO dates won't see much use. But they should be allowed. Headbomb {ταλκκοντριβς – WP Physics} 14:45, 23 September 2009 (UTC)[reply]
Why should they be allowed? What kind of tables & other special cases should they be allowed in? Why is a total ban going too far? What are the uses and purposes of YYYY-MM-DD? Sure it's unambiguous & understood by people everywhere iff the person gets it (and may don't). Where on WP do we ever have a situation where writing the month out in full or as an abbreviation won't do? JIMp talk·cont 15:13, 23 September 2009 (UTC)[reply]

Headbomb, you can't say "2009-09-06 is unambiguously recognized as meaning "6 September 2009" everywhere on the globe" when we have had people saying on this very page that they didn't recognise any such thing. If there are WP editors who aren't sure what it means, there must be zillions of readers for whom that is even more true. -- Alarics (talk) 16:24, 23 September 2009 (UTC)[reply]

I maintain my position that the ISO has contaminated the YYYY-MM-DD format beyond repair and it should not be used in an uncontrolled environment such as Wikipedia. For those who believe otherwise, I put the following questions:

  • Should we allow the ISO 8601:2004 standard, or some unspecified YYYY-MM-DD format?
  • What statement should we require in every article that contains that format, explaining the format?
  • What kind of articles should we allow the format in?

(By "require" and "allow" I mean that the MOSNUM encourages every editor to edit any article to avoid ambiguous or unexplained use of the format.) --Jc3s5h (talk) 16:28, 23 September 2009 (UTC)[reply]

There are probably countless WP readers who have a misconception of what a light-year is, but that does not make it ambiguous. YYYY-MM-DD is an internationally recognised standard that is fundamentally unambiguous, and some lack of understanding does not change that. I can see no compelling argument for the format's depreciation from use in lists, tables or footnotes, and in any case, as Tony suggests above, a much wider audience would be needed to warrant such drastic action given it's current widespread use. wjematherbigissue 17:00, 23 September 2009 (UTC)[reply]
ISO 8601 is not a law, it is a standard by a private organization that anyone is free to accept or ignore. Wikipedia has not adopted the standard, therefore it is ambiguous about whether a date in the format YYYY-MM-DD is governed by that standard or not. Indeed, the reason it is ambiguous is that people like yourself just assume it applies even though no formal adoption has occurred. In any community of people familiar with the standards process, the lack of formal adoption would be considered proof that the standard does not govern anything in Wikipedia. And if you think there can be no actual confusion about what date is intended, then you have not read the standard. --Jc3s5h (talk) 17:08, 23 September 2009 (UTC)[reply]
I agree that whatever ISO or any other outside body states is irrelevant when it comes to what is used on WP. However, this is an unambiguous standard that is used widely inside and outside of WP, and while it may not be preferred, I see no reason to abolish it's use. wjematherbigissue 18:16, 23 September 2009 (UTC)[reply]
Wikipedia does not use ISO 8601 because we have not formally adopted it. We have a general understanding that for years >= 1000, a date like 2009-09-23 should be read as September 23, 2009, but there are many other points on which there is no agreement, and therefore dates in that format are ambiguous. For example, if I were writing an astronomy article in which I needed to use the Julian calendar, could I write 2009-09-23 when refering to the Julian date September 23, 2009? --Jc3s5h (talk) 18:28, 23 September 2009 (UTC)[reply]
As far as I am aware WP does not need to formally adopt standards before using them, but if it does please show me the relevant policy or guideline. As stated previously, incorrect use due to lack of understanding does not equal ambiguity. wjematherbigissue 18:42, 23 September 2009 (UTC)[reply]

(unindent)Then you have no idea how standards work. The only formal standards that are in effect in the absence of a specific adoption by a publication are those that are imposed by law. ISO 8601 is not a law. Some Wikipedia editors might think they are using the ISO 8601 format when they write dates like 2009-09-23, but they are mistaken.

Of course, one could adopt the standard for a single article by explicitly stating in the article this had been done, but I've never seen an article with such a statement. --Jc3s5h (talk) 18:55, 23 September 2009 (UTC)[reply]

I do not believe you to be a qualified arbiter of what I do and do not understand, so would rather you kept your arguments to subject in hand. Wikipedia editors employ many standards that are not prescribed by law. I have no idea where you are trying to go with this one. wjematherbigissue 19:15, 23 September 2009 (UTC)[reply]
What I'm getting at is that writing "today is 2009-09-23" does not mean the date is expressed in the ISO 8601:2004 standard. Maybe it is written in an earlier version of the standard. Maybe it is written in an informal notation that cropped up before the first ISO 8601 standard was invented. There is no way to tell just by looking at the date. In the absence of adoption, within the article text, or by Wikipedia as a whole, of the standard, there is no way to know how to extend the usage to less obvious cases. If some other editor extended the remark to "today is 2009-09-23, the anniversary of the birth of Caesar Augustus, -62-09-23[4]." there is no criteria to decide if the date is written properly or not, nor is there any criteria to decide what calendar the editor had in mind (except by referring to the source). --Jc3s5h (talk) 19:33, 23 September 2009 (UTC)[reply]
How is "2009-09-23" any more ambiguous than "23 September 2009"? It is just as ambiguous as that even if it isn't understood to comply with ISO 8601 (and less ambiguous if it is, but ...). (BTW, my two cents: I'd agree recommending against it and for AP-style month abbreviations in footnotes and parentheses — although I'd rather hear more opinions (VP, CENT, etc.) before that; and, like Headbomb, I don't see the point of discouraging it in tables, although I would allow three-letter month abbreviations too.) --___A. di M. 20:00, 23 September 2009 (UTC)[reply]
The format's use within prose is not the subject of this discussion. That has long since been dealt with. What we are are discussing is it's use within lists, tables and footnotes, where it is clear and unambiguous. wjematherbigissue 19:54, 23 September 2009 (UTC)[reply]

(unindent) There are no criteria to decide if the dates in the following table are written correctly. This table is based on a New York Times article.

Date Event
1952-09-23 Richard Nixon's "Checkers" speech
-62-09-23 Caesar Augustus born in Rome

--Jc3s5h (talk) 20:39, 23 September 2009 (UTC)[reply]

  • Wjemather: Please stop with the mantra about how 2009-11-09 is “unambiguous”; no one is fooled by endlessly chanting it. As YYYY-MM-DD isn’t generally used in daily life on business correspondence, magazine publication dates, and notes to Mum, it is therefore unfamiliar to many readers. Accordingly “ambiguity” (or lack thereof) for most readers depends 100% on parsing through the number stream to divine the likely logic and order of its terms. The numbers 11‑9‑2009, 9‑11‑2009, 2009‑11‑09 are all inherently ambiguous unless one has foreknowledge of the convention being used. That YYYY‑MM‑DD is a “standard” does not make it any clearer what is meant than does “mebibyte”, which is also a “standard” but is seldom used in real life and is therefore also unfamiliar and needlessly confusing to readers.

    The only method that is abundantly clear and unambiguous is “November 11, 2009” and 11 November 2009. Now those are unambiguous, which is probably why the English-language, internationally circulated encyclopedia known as Encyclopedia Britannica doesn’t use all-numeric dates for anything in its publication.

    Having said all that, I’d go along with allowing its use in tables only as long as the header contains a parenthetical legend, such as Date Inducted Into Hall of Fame (dates are Year-month-day). And even that is a darn big compromise given that three-letter monthly abbreviations fit just as nicely in tables as your cursed all-numeric date method. Greg L (talk) 20:45, 23 September 2009 (UTC)[reply]

I am sure that I don't need to tell you that no written date is (entirely) unambiguous without specifying what calendar is being used. Both day-first and month-first formats are ambiguous because of widespread use of the latter, predominantly in the United States. However YYYY-MM-DD suffers from no such problems and, by definition, should always be in the (proleptic) Gregorian calendar, hence it is unambiguous. wjematherbigissue 21:16, 23 September 2009 (UTC)[reply]
FWIW I just read that date Greg L gave as 11 September 2009. It didn't occur to me that it wasn't 11 September until I got to the bit about 9 November written in words. YYYY-DD-MM may never be used in practice, but any all-number date is still sufficiently ambiguous to those who don't know that it's supposed to be YYYY-MM-DD (indeed, in my case, those who do know that) that it's undesirable. If there's a problem with the light-year we can link to light year. Will we be linking every article that uses these dates to ISO 8601?
You say it should by definition always be in the (proleptic) Gregorian calendar. This is doesn't make any practical sense. In my cases will be counterintuitive and will go against what sources say. No-one would say that the Gunpowder plot was 14 November 1605 (as per the Gregorian calendar) - cultural memory tells us it was the fifth - so how does it make sense to say that it was 1605-11-14? Surely at any such usage, we would need to clarify that 1605-11-14 is the same thing as 5 November 1605 or else expect to have to revert back from the Julian calendar to the Gregorian repeatedly. It's likely to be similar with most dates under the Julian calendar. Editors aren't going to run the conversion every time and readers aren't going to want to have to run the conversion every time. And why should they? Pfainuk talk 21:37, 23 September 2009 (UTC)[reply]
Mixing calendars in the same table without a clear explanation of what's going on is not a good idea regardless of the way dates are written. A table such as
Name Date of death
William Shakespeare 23 April 1616
Miguel de Cervantes 23 April 1616

 ::::::::doesn't stop being misleading just because "April" is spelt out. (Then, if the problem is that some people believe all YYYY-MM-DD dates to be ISO 8601, then the current wording discouraging its use for pre-1583 and non-Gregorian dates already solves it.) --___A. di M. 09:42, 24 September 2009 (UTC)[reply]

Oh sure, but I was specifically rebutting Wjemather's claim that YYYY-MM-DD dates are unambiguous because, by definition, they use the (proleptic) Gregorian calendar. On the contrary, YYYY-MM-DD is - as you note - at least as ambiguous as spelt out dates in this regard because it's not clear whether the writer is following the ISO standard or not.
We say that we shouldn't use it for dates before 1583 and non-Gregorian dates. That doesn't make it less ambiguous than writing the date out in full unless we expect readers to search out WP:MOSNUM to find out our conventions. FWIW my example of 1605-11-14 is acceptable according to those conventions - it's in the Gregorian calendar and it's after 1583. It's just that the Gregorian date isn't the one that went down in history. Pfainuk talk 18:00, 24 September 2009 (UTC)[reply]

(unindent) I believe Wjemather's claim that "YYYY-MM-DD suffers from no such problems and, by definition, should always be in the (proleptic) Gregorian calendar" is false. Please provide a citation from a book that addresses the entire English language (such as a dictionary, style guide, or grammar book) supporting this claim. Citations from standards are useless, since standards only apply to those who explicitly choose to adopt them, or when the standard is adopted by law.

Alternatively, propose on Village Pump that Wikipedia declare a policy that all numeric dates must adhere to ISO 8601:2004 and see how far you get. --Jc3s5h (talk) 22:19, 23 September 2009 (UTC)[reply]

wjemather says: "YYYY-MM-DD is an internationally recognised standard that is fundamentally unambiguous". The fact that it is an international standard is neither here nor there: it is meant to be read by computers, not humans. The assertion that it is unambiguous is simply not true, as has already been extensively demonstrated by various contributors further up this page. -- Alarics (talk) 22:43, 23 September 2009 (UTC)[reply]
wjemather also says: "Incorrect use due to lack of understanding does not equal ambiguity". That is absurd. If something isn't understood because it has more than one possible meaning, it's ambiguous. That's what "ambiguous" means. -- Alarics (talk) 22:46, 23 September 2009 (UTC)[reply]
A. di M. asks: "How is '2009-09-23' any more ambiguous than '23 September 2009'?" Answer: when you write the month out as a word, there is no room for doubt about which is the month and which is the day. With any all-numeric format, such as '2009-09-10', it's not clear which figure represents the day and which the month. '2009-09-23' is unambiguous only because there isn't a 23rd month, but the reader shouldn't be forced to stop and work that out, and a formula that works only for a day higher than 12 is not going to be consistent. -- Alarics (talk) 22:53, 23 September 2009 (UTC)[reply]
Has anybody ever used a date such as 2005-05-11 anywhere to mean "5 November 2005"? If not, claiming that 2005-05-11 is ambiguous because it might in principle mean "5 November 2005" (even if it never does) is akin to claiming that physician is ambiguous because it might in principle mean "physicist" (by analogy with mathematician, statistician, etc.), even if it never does. Also, YYYY-MM-DD is much more common in the real world than some believe: for example, the program which came with my Internet key in the "Statistics" screen has a line reading "Time Last Reset:2009-09-04 19:55:40" (note that this is not ISO 8601, which would require a T insead of the space; in particular, I have never seen the ISO format with a T for dates intended to be human-readable); many digital watches use YYYY-MM-DD, which is the customary format in China and Japan where most such watches are made, or close variations thereof (for example, mine says "09 9-24"). When I was about 10 and discovered that dates in my father's Japan-made digital diary had the year first, I immediately correctly guessed that it was followed by the month and then the day and just thought: "Well, so that's what they do in Japan. Makes perfect sense, because first you write the millennium, then the century, then the decade, and so on in the "right" order for sorting." And anyway, since what I and Headbomb would like is just to allow it in tables, there's nothing preventing you from adding a legend to the column header (like this or this), just in case the reader not only has never seen that format but also can't figure out which format we are using if we want the table to automatically sort correctly. --___A. di M. 09:42, 24 September 2009 (UTC)[reply]
  • Some of wjemather’s arguments, above, appear to be utter nonsense (‘November 9, 2009’ is ambiguous “without specifying what calendar is being used”). To me, this is nothing but obfuscation and isn’t even worth rebutting. It’s obvious to me his mind is set and no rational argument will change his mind. I’ve seen this sort of thing before.

    How say we just start one of those table-style RfCs (last used on IEC prefixes) where we all just register our opinion on some wording. If I’m reading A. di M.’s recent post correctly, I see he is now supportive of simply using A.P. months for parentheticals and three-letter abbreviations for tables. Why don’t we then have an up/down RfC (or, as wjemather might claim, “a !vote”) on Second pink‑div, above? Greg L (talk) 23:51, 23 September 2009 (UTC)[reply]

I was merely providing a rebuttal to your assertion that written dates are unambiguous. Am I suggesting that the calendar in use should be noted every time a date is used? Of course not, because it is unnecessary. Nor am I suggesting that ISO 8601 become the de-facto standard for writing out dates on Wikipedia, because that would be ridiculous. Do I think YYYY-MM-DD should be used across the board in tables, lists and footnotes? No, because it would not be appropriate. Do I think MOSNUM should legislate against it's use? No, because it is a useful concise format. Hope that makes everything clear for you. (P.S. Greg, your claim that I am obfuscating is again leaning towards incivility. Please assume good faith. Thanks.) wjematherbigissue 07:20, 24 September 2009 (UTC)[reply]
I support AP months for parentheticals, but I support allowing both three-letter abbreviations and YYYY-MM-DD dates in tables. --___A. di M. 09:45, 24 September 2009 (UTC)[reply]
wjemather says that YYYY-MM-DD "is a useful concise format". Useful in what circumstances, exactly? Will you agree that there is never a need for it in footnotes? What do you propose to do about the fact, clearly demonstrated repeatedly in the long discussion above, that some people don't know what it means? Why advocate the use of a formula which, even for some of those who do know what it means, is an obstacle to understanding, because they have to stop and "flip it over" in their heads? -- Alarics (talk) 09:49, 24 September 2009 (UTC)[reply]
Look at a table such as this one. Even if one happened to miss the legend in the table header, it's quite obvious that dates are sorted chronologically and thus 2009-04-06 is the day after 2009-04-05. I think one has to be very distracted to think, even momentarily, that it is the 4th of June. --___A. di M. 10:28, 24 September 2009 (UTC)[reply]
Yes, but one still has to stop and think about it. Here is the same table with abbreviated months in words. I think it looks just as "neat and tidy" and is easier to understand:
Date
and time (UTC)
Time
(local)
Lat. Long. Depth Mag.
30 Mar 2009 13:38:39.3 15:38:39.3 42.33° N 13.35° E 2 km (1 mi) 4.4 (Mw)
05 Apr 2009 20:48:56.4 22:48:56.4 42.36° N 13.37° E 2 km (1 mi) 4.0 (ML)
06 Apr 2009 01:32:41.4 03:32:41.4 42.38° N 13.32° E 2 km (1 mi) 6.3 (Mw)
06 Apr 2009 02:27:48.2 04:27:48.2 42.37° N 13.23° E 2 km (1 mi) 4.3 (mb)
06 Apr 2009 02:37:05.3 04:37:05.3 42.41° N 13.32° E 2 km (1 mi) 5.1 (Mw)
06 Apr 2009 03:56:48.1 05:56:48.1 42.38° N 13.34° E 10 km (6 mi) 4.5 (mb)
06 Apr 2009 07:17:16.1 09:17:16.1 42.47° N 13.40° E 30 km (19 mi) 4.4 (mb)
06 Apr 2009 16:38:10.7 18:38:10.7 42.38° N 13.32° E 2 km (1 mi) 4.4 (Mw)
06 Apr 2009 23:15:37.7 01:15:37.7 42.48° N 13.41° E 2 km (1 mi) 5.1 (Mw)
07 Apr 2009 09:26:30.7 11:26:30.7 42.31° N 13.35° E 10 km (6 mi) 5.0 (Mw)
07 Apr 2009 17:47:38.3 19:47:38.3 42.30° N 13.40° E 13 km (8 mi) 5.6 (Mw)
07 Apr 2009 21:34:30.9 23:34:30.9 42.34° N 13.37° E 2 km (1 mi) 4.5 (mb)
08 Apr 2009 04:27:42.5 06:27:42.5 42.30° N 13.43° E 2 km (1 mi) 4.0 (ML)
08 Apr 2009 22:56:51.0 00:56:51.0 42.55° N 13.34° E 2 km (1 mi) 4.1 (Mw)
09 Apr 2009 00:53:00.6 02:53:00.6 42.53° N 13.39° E 2 km (1 mi) 5.4 (Mw)
09 Apr 2009 03:14:52.7 05:14:52.7 42.35° N 13.46° E 2 km (1 mi) 4.3 (mb)
09 Apr 2009 04:32:46.0 06:32:46.0 42.45° N 13.39° E 2 km (1 mi) 4.3 (mb)
09 Apr 2009 04:43:12.3 06:43:12.3 42.52° N 13.34° E 10 km (6 mi) 4.0 (ML)
09 Apr 2009 13:19:35.8 15:19:35.8 42.33° N 13.23° E 40 km (25 mi) 4.0 (ML)
09 Apr 2009 19:38:17.4 21:38:17.4 42.52° N 13.35° E 2 km (1 mi) 5.2 (Mw)
10 Apr 2009 03:22:23.6 05:22:23.6 42.49° N 13.42° E 2 km (1 mi) 4.0 (mb)
13 Apr 2009 21:14:25.7 23:14:25.7 42.55° N 13.42° E 2 km (1 mi) 5.1 (Mw)
14 Apr 2009 20:17:28.9 22:17:28.9 42.55° N 13.23° E 10 km (6 mi) 4.0 (ML)
15 Apr 2009 22:53:08.7 00:53:08.7 42.54° N 13.28° E 2 km (1 mi) 4.0 (ML)
23 Apr 2009 15:14:10.6 17:14:10.6 42.22° N 13.44° E 10 km (6 mi) 4.0 (ML)
23 Apr 2009 21:49:01.0 23:49:01.0 42.24° N 13.48° E 2 km (1 mi) 4.3 (Mw)
22 Jun 2009 20:58:40.3 22:58:40.3 42.44° N 13.29° E 2 km (1 mi) 4.7 (Mw)
03 Jul 2009 11:03:09.0 13:03:09.0 42.38° N 13.32° E 2 km (1 mi) 4.1 (ML)

-- Alarics (talk) 16:34, 24 September 2009 (UTC)[reply]

(edit conflict)

Son of "What the…?"

Ah… splendid. Some real-world examples. Yes; the cited example is nothing but a sea of data that isn’t intended to instantly communicate a particular thought. It is a table of particular events and attributes that one must inspect and carefully parse if they want to extract anything meaningful. And if ISO / BIPM / IACUC / UFOP-formatted dates were limited to stuff tables this, I could be a peace.

But let’s examine for a moment, whether doing this practice actually best serves the interests of our readers, or if it is nothing more than an method of what best appeals to our inner Jonny Quests. Let’s say that there is a particular whopper of an earthquake that occurred in June that knocked down a childrens’ hospital. Quick… go find it. Ready… set… GO.

Date (YYYY-MM-DD)
and time (UTC)
Time
(local)
Lat. Long. Depth Mag.
2009-03-30 13:38:39.3 15:38:39.3 42.33° N 13.35° E 2 km (1 mi) 4.4 (Mw)
2009-04-07 17:47:38.3 19:47:38.3 42.30° N 13.40° E 13 km (8 mi) 5.6 (Mw)
2009-04-07 21:34:30.9 23:34:30.9 42.34° N 13.37° E 2 km (1 mi) 4.5 (mb)
2009-04-08 04:27:42.5 06:27:42.5 42.30° N 13.43° E 2 km (1 mi) 4.0 (ML)
2009-04-15 22:53:08.7 00:53:08.7 42.54° N 13.28° E 2 km (1 mi) 4.0 (ML)
2009-04-23 15:14:10.6 17:14:10.6 42.22° N 13.44° E 10 km (6 mi) 4.0 (ML)
2009-04-23 21:49:01.0 23:49:01.0 42.24° N 13.48° E 2 km (1 mi) 4.3 (Mw)
2009-06-22 20:58:40.3 22:58:40.3 42.44° N 13.29° E 2 km (1 mi) 4.7 (Mw)
2009-07-03 11:03:09.0 13:03:09.0 42.38° N 13.32° E 2 km (1 mi) 4.1 (ML)


Date and
time (UTC)
Time
(local)
Lat. Long. Depth Mag.
30 Feb 2009 13:38:39.3 15:38:39.3 42.33° N 13.35° E 2 km (1 mi) 4.4 (Mw)
7 Apr 2009 17:47:38.3 19:47:38.3 42.30° N 13.40° E 13 km (8 mi) 5.6 (Mw)
7 Apr 2009 21:34:30.9 23:34:30.9 42.34° N 13.37° E 2 km (1 mi) 4.5 (mb)
8 Apr 2009 04:27:42.5 06:27:42.5 42.30° N 13.43° E 2 km (1 mi) 4.0 (ML)
15 Apr 2009 22:53:08.7 00:53:08.7 42.54° N 13.28° E 2 km (1 mi) 4.0 (ML)
23 Apr 2009 15:14:10.6 17:14:10.6 42.22° N 13.44° E 10 km (6 mi) 4.0 (ML)
23 Apr 2009 21:49:01.0 23:49:01.0 42.24° N 13.48° E 2 km (1 mi) 4.3 (Mw)
22 Jun 2009 20:58:40.3 22:58:40.3 42.44° N 13.29° E 2 km (1 mi) 4.7 (Mw)
3 Jul 2009 11:03:09.0 13:03:09.0 42.38° N 13.32° E 2 km (1 mi) 4.1 (ML)

I see that the table with the abbreviated form takes up several pixels more. That, of course, is a meaningless difference in an all-digital, adjustable-everything, electronic encyclopedia. The advantages as far as readability when readers are interested in a particular earthquake? Priceless.

When I was doing mechanical engineering at a fuel cell company and these young engineers would get lazy and let their CAD programs automatically dimension an entire print, I used to call the resulting output “data ralphs.” Any good encyclopedia, rather than take a USGS data-ralph and publish it raw, would properly spend a moment and clean up that which can be cleaned up to make it easier for readers to deal with. Greg L (talk) 16:37, 24 September 2009 (UTC)[reply]


  • Jeez that was fast, Alarics! I note you wrote Yes, but one still has to stop and think about it. Do I assume correctly that you were rebutting A. di M. and not me? Yours and mine differ only in that my example hides the unused preceding zeros on the day and I simply right-justified that column.

    I agree that your method too is perfectly fine. You and I think alike. There is no reason in the world to not massage the dates to human-readable form; particularly where the first column of dates is the chronological index organizing the data.

    Technical writing is about communicating clearly and easily, not about appealing to a few editors’ notion of what makes sense because this-n-that date format is “unambiguous since one doesn’t need to specify whether or not the date is given in the Gregorian calendar system”. Some things, like how modern dates always use the Gregorian calendar, are a given and no one but a few Wikipedia editors who are busy promoting their favorite all-numeric date format ever question such things. I prefer common sense technical-writing practices, myself. Greg L (talk) 16:48, 24 September 2009 (UTC)[reply]

Yes, I was responding to A. di M. I've shuffled the posts round so that that is clear. You and I had exactly the same idea almost simultaneously. Of course your version is as good as mine if not better. Either way, it doesn't prove that YYYY-MM-DD is never necessary in tables, but it does show that the example of where it is essential has not yet been found. -- Alarics (talk) 18:40, 24 September 2009 (UTC)[reply]

Summary of the present state of play on YYYY-MM-DD in footnotes (now superseded -- see next subsection)

Analysing all the comments made in the past few weeks (including those now archived at Wikipedia talk:Manual of Style (dates and numbers)/Archive 125, there appear to be broadly three main strands of opinion:

(A) In favour of YYYY-MM-DD in footnotes and tables. Cavrdg, Darxus, Denimadept, LeadSongDog, Offliner, RockyMtnGuy, TheFeds[See below. TheFeds], wjemather. Total: 7 editors.

(B) Prepared to see YYYY-MM-DD in some tables, but not in footnotes. A. di M., Headbomb, HWV258, Ohconfucius, Rich Farmbrough, Septentrionalis, Sssoul, Woodstone. Total: 8 editors.

(C) Opposed to YYYY-MM-DD anywhere. Alarics, Dabomb87, Debresser, Greg L, gu1dry, Jc3s5h, Jimp, Pfainuk, Shakescene, Tony1, VMAsNYC. Total: 11 editors.

So, adding (B) and (C) together, we have 19 editors who oppose the use of YYYY-MM-DD in footnotes, against 8 who are in favour of it. Does that constitute a consensus on that particular point? If so, can we move forward with that, and leave the other, more contentious issues to one side? -- Alarics (talk) 19:07, 25 September 2009 (UTC) [reply]

I have added myself to the C strand, even though I haven't voiced my opinion in the discussion at hand. ɠu¹ɖяy¤ • ¢  19:20, 25 September 2009 (UTC)[reply]
  • Thanks for wading through the edit history and tallying up the totals. It’s more than just the editor count though, gu1dry. One also looks at the consistency of the arguments on both sides and considers the logical ramifications of it all.

    It seems to me that many of those who oppose total deprecation of the YYYY-MM-DD make assertions that the form is unambiguous, whereas “9 November, 2009” is ambiguous (citing at times, that this is because it somehow doesn’t specify whether it is based on the modern Gregorian calender). Just because absurd arguments can be advanced, doesn’t mean they carry the same weight as common-sense ones.

    Another argument is that is endlessly repeated is that YYYY-MM-DD mustn’t be deprecated because it works well in tables and footnotes. But, since “09 Nov 2009” and/or “9 Nov 2009” also work, that argument carries no weight either.

    One simply must include an evaluation of the total weight of the logical shortcomings and strengths on both sides of the issue because some editors will endlessly make assertions that make no logical sense for no other reason that they like the way they do their edits and don’t want to change or have someone later change their work. Others (though they will seldom admit it) believe that their particular practice might gain traction with the world if it is used here. But, as was amply demonstrated with Wikipedia’s three-year-long trial with terminology like “kibibyte” and “mebibyte” (which to this day, my spell-checker still flags), stupid technical writing practices don’t become wise technical writing practices that the world starts adopting simply because they appear on Wikipedia.

    The final straw that breaks the camel’s back here, IMO, is that some editors cite how Wikipedia is an *international* English-language encyclopedia. But then, so too is Encyclopedia Britannica. Frankly, I think it is wisest to follow the practices of E.B., which always writes out the name of the month and never uses all-numeric dates. Why? Well, E.B. is inhabited by professional copy editors who invariably posses advanced journalism degrees. I therefore place greater credence in the opinion of those editors on this subject than I do with some of the all-volunteer editors who inhabit Wikipedia. Greg L (talk) 21:19, 25 September 2009 (UTC)[reply]

Since Britannica keeps coming up as the example to follow, I'll note that they too use descending significance all-numeric dates on their Japanese and Korean websites. (Even those of us who read neither language can still see that much.) Again, that rationale is not based on WP being international but rather upon it being multilingual. We don't help matters by ignoring the "other" 11/14 of WP and pretending it is an English-only enterprise.LeadSongDog come howl 21:45, 25 September 2009 (UTC)[reply]
I find this argument amusingly bizarre. We aren't writing in Japanese or Korean, we're writing in English - this being the MOS of the English Wikipedia. Other language editions are free to write their MOS's based on the customs of their languages. They don't have to worry about the norms of written English and we don't have to worry about the norms of written Japanese or Korean.
But let's look at these more closely for a minute with half an eye on the article Japanese calendar (I'm using Japanese because it shows up better on my browser - I don't speak the language). They don't write "2009-09-25", they write "2009年9月25日". If you consider that 年 means "year", 月 means "month" and 日 means "day", and that Japanese has no way of writing "September", other than "9月" and the equivalent with a Japanese numeral, "九月", it becomes clear that, far from being an all-numeric date, "2009年9月25日" actually means something to the effect of "Year 2009, 9th month, 25th day", or "Year 2009, September, 25th day".
So, even if your argument that we should adopt other languages' dating systems on the English Wikipedia had merit - and it does not - the examples you cite are not the all-numerical system you suggest they are. As it is, it is surely obvious that English is not Japanese, and that Japanese-language norms should not be expected to apply on an English-language encyclopædia. Pfainuk talk 23:01, 25 September 2009 (UTC)[reply]
Greg, it goes without saying that a crude headcount doesn't reflect the quality of the arguments one way or the other. I was just trying to draw things together in the hope that we could maybe make some progress without reopening all the arguments again. Simply on a headcount alone, we have 19 editors who oppose the use of YYYY-MM-DD in footnotes, against 8 who are in favour of it. What I am asking is, does that constitute a consensus on that particular point? If so, can we move forward with that, and leave the other, more contentious issues to one side? -- Alarics (talk) 21:35, 25 September 2009 (UTC)[reply]
  • Wow! Quoting LeadSongDog: Again, that rationale is not based on WP being international but rather upon it being multilingual. We don't help matters by ignoring the "other" 11/14 of WP and pretending it is an English-only enterprise. What? What?!? I endorse what Pfainuk said in his first paragraph.

    Earth calling LSD: This is en.Wikipedia. It is written and optimized for readers for whom English is their first language. As for those readers for whom English is their second language we’ve got Wikipedias in 271 other languages, all optimized for each language and/or country with their own numbering systems, alphabets, everything. In short: Being that this the English-language version of Wikipedia, we’ll be sticking to the manuals of styles suitable for English—thank you very much—and won’t be running off on some home-baked tangent that flouts common sense on the pretense that you can do a five-minute Google search and find an African tribe that keeps track of dates by counting the scars they carve into their bodies. So…

    Just pardon me all over the place for treating en.Wikipedia as an “English-only enterprise.” I’m much obliged for your assistance in proving my point regarding how “one also looks at the consistency of the arguments on both sides and considers the logical ramifications of it all.” Greg L (talk) 00:14, 26 September 2009 (UTC)[reply]

Alarics, "In favour of YYYY-MM-DD in footnotes and tables" is not quite my position. I'm in favour of using a shortened date format in space-limited areas of tables, references and template output. But although I don't personally mind YYYY-MM-DD or find it ambiguous, I'm receptive to the idea of a 5 Dec 2009/Dec. 5, 2009 format as a standard short form, because it is certainly unambiguous.
From the now-archived thread, I proposed two versions of a guideline, one using YYYY-MM-DD—but not ISO 8601—and one using abbreviated month names. After other editors felt there was still too much potential confusion because of ISO 8601's requirements for Gregorian-only dates, I declined to continue with the YYYY-MM-DD version. My revised (green) proposal from September 16th, and comment the next day clarifies this.
So, more accurately, I'm neutral with regard to YYYY-MM-DD outside of prose (especially given others' concerns on confusion with ISO 8601), but in favour of unambiguous short dates in space-limited areas outside of prose (which includes reference footnotes). (Accordingly, I'm striking my name from your list.) I oppose YYYY-MM-DD within prose, which was a separate question not directly addressed by your tally.
Nevertheless, any proposal on date formatting in citations ought to be discussed over on the talk pages where people discuss citation styles, before we go ahead with it. TheFeds 00:28, 26 September 2009 (UTC)[reply]
Lies, damn lies and statistics. Disregarding the fact that assumptions are being made on how everyone would vote (if indeed it was a vote), that would be 16 against 11 (12 with gu1dry) in favour of not depreciating the use of YYYY-MM-DD.

In response to Greg's points:

  • The fact that other formats work just as well is no reason to depreciate YYYY-MM-DD.
  • Encyclopædia Britannica has no authority here.
  • I would much rather trust the consensus of the many on WP than the view of an arbitrary individual, even one with a degree in journalism (advanced or otherwise).
I can see no consensus for a change in any direction, and I think it is quite clear that for this to go any further, a wider audience is certainly required. wjematherbigissue 00:31, 26 September 2009 (UTC)[reply]

←outdent (and ignoring wjemather’ rant)

Oh, and quoting LeadSongDog again: Since Britannica keeps coming up as the example to follow, I'll note that they too use descending significance all-numeric dates on their Japanese and Korean websites. Have you not heard of Google “Language tools”? I have. Here’s the English-language translation of the Japanese version of Encyclopedia Britannica. Note that they spell out the months: August 11, 2009; May 14, 2009 ; and another instance of May 14, 2009. Are you trying to help your cause or hurt it? Anyway…

I think we can limit our discussion to Encyclopedia Britannica’s *English-language* practices, can’t we? And, more to the point, I’d like to see you or anyone else advance a plausible sounding argument as to why the English-language version of Wikipedia (which is read internationally) has a compelling need to depart from standard encyclopedic practices observed by World Book and Encyclopedia Britannica both of which can also be found in libraries and homes (*sound of blair trumpets*) “INTERNATIONALLY”. The same goes for the Associated Press manual of style, which is observed by some 99% of the English-language newspapers published throughout the international community. Greg L (talk) 00:36, 26 September 2009 (UTC)[reply]

Well count me as being OK with A. Vegaswikian (talk) 03:05, 26 September 2009 (UTC)[reply]
wjemather accuses me of "lies, damned lies and statistics" as though I were somehow twisting the facts. (That seems to be an accusation of bad faith, which is against the rules.) No, I was trying as objectively as I could to see what there might be a consensus for, precisely so that we could take the issue to the "wider audience" that he/she wants. Unfortunately people have started going round all the arguments again. I think all the arguments have been thoroughly aired. I'll try once more .... -- Alarics (talk) 06:21, 26 September 2009 (UTC)[reply]
TheFeds says "I oppose YYYY-MM-DD within prose, which was a separate question not directly addressed by your tally". Yes, I didn't address that in my tally because I think pretty well everybody opposes it within prose. In any case, the present MOSNUM already says not to use any numerical date format in prose. That, therefore, is not what is at issue. What is still at issue is the use of YYYY-MM-DD in (a) footnotes and (b) tables. -- Alarics (talk) 06:33, 26 September 2009 (UTC)[reply]
TheFeds also says "I am in favour of unambiguous short dates in space-limited areas outside of prose (which includes reference footnotes)". Why do you say reference footnotes are space-limited? A YYYY-MM-DD date takes up 10 characters. A "26 Sep 2009" date takes up 11 characters. The longest possible fully-written-out date (xx September xxxx) takes up 17 characters. When are we ever so pushed for space in a footnote that saving at most 7 characters is going to be an issue? -- Alarics (talk) 06:46, 26 September 2009 (UTC)[reply]
Sorry Alarics, I was accusing you of nothing, merely pointing out it is equally possible to derive the precise opposite conclusion from the one you put forward. Maybe I should have linked the phrase for you: Lies, damned lies, and statistics. wjematherbigissue 07:57, 26 September 2009 (UTC)[reply]
No, it's not "equally possible to derive the precise opposite conclusion". What you mean is, there is a majority against deprecating YYYY-MM-DD altogether (A plus B). I am agreeing about that, but pointing out that there is a majority in favour of deprecating YYYY-MM-DD in footnotes (B plus C). These are not "precise opposites"; they are not opposites at all; they are two different things. Can you not see that I am ageeing with you that there is no consensus for the former, but saying that there could be a basis for a consensus on the latter? BTW I am familiar with the quotation to which you allude. What it means is that "you can prove anything with statistics". It isn't true, if you analyse them properly. With these "statistics", I can't prove there is unanimity against YYYY-MM-DD, or even a consensus against it, and you can't prove that there isn't a consensus for deprecating YYYY-MM-DD in footnotes. -- Alarics (talk) 08:33, 26 September 2009 (UTC)[reply]
Thanks, of course I meant different, not opposite. (I'll be awake soon, hopefully) wjematherbigissue 08:53, 26 September 2009 (UTC)[reply]
Regarding Google's translation of the Japanese Britannica: So what? It's Google which translated that, not Britannica; and translating 8月 as August is perfectly reasonable, considering that Japanese has no month names and English does. That's quite irrelevant. Regarding "As for those readers for whom English is their second language we’ve got Wikipedias in 271 other languages": well, have you seen in what state are those other 271 Wikipedias? The English Wikipedia is by far the largest one, having three times the number of articles the second-largest (German) one; and English is by far the most commonly taught second language in the world. Why on Earth would an Icelander prefer to read the Icelandic Wikipedia, when it has less than one hundredth the number of articles the English Wikipedia has, and almost all literate Icelanders can read English? C'mon, even I, a native Italian speaker, prefer to read the English Wikipedia, and the Italian one is the sixth-largest. (Anyway, I don't understand what's the relevance of that. A randomly-choosen natively English-speaking reader of en.wiki is no more and no less likely than a randomly-choosen non-natively English-speaking one to understand "2009-07-05", and no more and no less likely to understand "5 July 2009". But I do think we should avoid usage which is unnecessarily confusing to non-native readers: once I found something like "the angular velocity vector is ... in the direction of the rotation axis"; now, in some languages the word-by-word translation of "in the direction of" means "towards", so that a native speaker of such a language might think of a vector perpendicular to the one we're talking about; so I replaced it with "parallel to", which is clearer to non-native speakers and no less clear to native ones. I just don't happen to believe that either "5 July 2009" or "2009-07-05" falls in this category.)

--___A. di M. 12:07, 26 September 2009 (UTC)[reply]

You say you don't believe it falls into that category, and yet we've had at least two people on this very page who said they found YYYY-MM-DD not merely "unnecessarily confusing", as you put it, but positively incomprehensible. Are you saying you don't believe them? -- Alarics (talk) 12:55, 26 September 2009 (UTC)[reply]
I meant that whether one finds "YYYY-MM-DD" confusing or not has nothing to do with whether they speak English as a first or a second language, so neither "Wikipedia is a multilingual encyclopedia" nor "but WP:MOSNUM only apply to the English Wikipedia, which is mainly read by native English speakers" is a valid argument either in favour or against YYYY-MM-DD. (The only reason I can think of why that would be relevant is that images are hosted at Commons which is shared by all Wikipedias, so, if for some reason there were a full date in an image, it'd make sense to write it in YYYY-MM-DD. But we're not talking about images.) --___A. di M. 13:31, 26 September 2009 (UTC)[reply]
As Alarics writes, the cite templates used to require YYYY-MM-DD input (following the idea that it would be autoformatted), now they give this straight back. This created the impression that dates in footnotes are supposed to be in this format.
It should not be a simple head count. The strength of the arguments must be taken into account. The argument from multilinguality, for example, is absurd. This is the English Wikipedia; it's written in English; ESL people come here because they can read English; let's write in English. JIMp talk·cont 13:37, 26 September 2009 (UTC)[reply]
  • Jeez Jimp. Common sense arguments that are succinct! Is that allowed here? Yes, it’s this simple.

    Perhaps the practice of “deprecating” the YYYY-MM-DD” form shouldn’t happen because there are editors here who will always think they know better than professionals and get panicked whenever threatened with the prospect of no longer being permitted to do something they “like-ta” do. Isn’t that what en.Wikipedia is for(?): to provide a venue where editors who no advanced training in journalism and technical writing try to advance reasons for not looking towards the manuals of style produced by the professionals because they’ve *got it all figured out* and know better than the pros?

    Arguments from some of the above editors are predicated on the false premise that en.Wikipedia presents some sort of unique circumstance and they are applying their amazing powers of astute observation and unflagging logic to deal with the situation. While no-doubt good for their sense of self-esteem, their arguments are illogical and/or unfounded. Many of these absurd arguments are predicated on the earth-shaking realization that some of en.Wikipedia’s readership speaks English as a second language. All these arguments are 100%, utter and absolute nonsense and have no bearing on the discussion since all the top English-language newspapers, magazines, and print encyclopedias also have a vast readership for whom English is their second language. Does that surprise anyone here?

    Arguments that some of these readers for whom English is their second language read the English-language version of Wikipedia because it is more comprehensive, and this somehow constitutes a reason for us to depart from standard English-language rules of technical writing style are similarly utter and complete nonsense. Why? For many of the world’s languages, their print encyclopedias also suck in comparison to things like en.Wikipedia and Encyclopedia Britannica (or, in many cases, don’t even exist. At least those who speak Esperanto have eo.Wikipedia).

    So, while “deprecation” might be too strong, it would be nice if we didn’t end up completely turning our backs on Technical Writing 101 common sense and *promote* the practice of using three-letter abbreviations for months in tables—as shown in Son of, above. It’s clear to anyone with the common sense that God gave a goose that dates with months written out are easier to read and look better than a sea of numbers in a format that no one in real life uses outside of USGS “data‑ralphs” and attendance forms at Star Trek conventions. Does that much surprise anyone? Or is the electronic white-space provided below going to be used for someone to spout about how 2009-04-07 17:47:38.3 “reads real purdy” and ought to spread like wildfire across the land? Greg L (talk) 16:03, 26 September 2009 (UTC)[reply]

Apparently God gave an awful lot of people less sense than a goose. However, let me tell you the REAL reason for the popularity of the YYYY-MM-DD format. People are sitting at their computer writing a document, and they wonder, "What date format should I use?". So they go to Google, type in "international standard date format", and hit enter (according to Google, 104,000,000 people have done this). And what is the first hit that comes up? Why it's the Wikipedia article ISO 8601, of course! So then you have 104,000,001 people using YYYY-MM-DD. Greg L's experience may vary from this.RockyMtnGuy (talk) 16:55, 26 September 2009 (UTC)[reply]
Wikipedia can't use ISO 8601 for all the dates we need to write about (without being liars). There is a consensus against using it in running text. There may very well be a consensus against using it in footnotes. So how much benefit would the people with a marginal ability to read English get from having ISO 8601 only in tables (and only in articles about events in the last four centuries or so)? --Jc3s5h (talk) 17:18, 26 September 2009 (UTC)[reply]
It's not exclusively people with a marginal ability to read English that use YYYY-MM-DD (and frankly, many people who learned English as a second language speak it better than many people who learned it as a first language) - it's mostly technophiles. There are a lot of technophiles around, particularly here on Wikipedia, and not very many footnotes or tables reference dates prior to 1582-10-15. Really, they don't. RockyMtnGuy (talk) 17:42, 26 September 2009 (UTC)[reply]
RockyMtnGuy, you wrote "not very many footnotes or tables reference dates prior to 1582-10-15". Unless your memory is hazy, this would indicate that you have not read the standard. Have you? --Jc3s5h (talk) 17:58, 26 September 2009 (UTC)[reply]
  • RockyMtnGuy. So… you’re saying ISO 8601 is an “international date format.” So what?!? The technical-writing world doesn’t give a dump. BIPM is an international standard body that prescribes how to communicate unambiguously across international boundaries and between different languages. They prescribe that we write “75 %” (note the space between the value and the percent sign) and not “75%”. Why are you not insisting we “technophiles” adhere to that “international standard” (*sound of female oratorio from heaven delivered in C-sharp*)? (Please excuse my grunts as I get off my knees. I was kneeling to RockyMtnGuy, who now postures himself as the leader of those who embrace technology and The Scientific Way©™®).

    Seriously; I insist that you answer that question about the percent sign before you shovel more of your metric ton of weapons-grade bullonium that is all founded on the false premiss that Wikipedia is somehow unique in its being looked to by non-native English speakers; It isn’t. Greg L (talk) 19:29, 26 September 2009 (UTC)[reply]

RockyMtnGuy has now made an interesting admission: it is technophiles who like YYYY-MM-DD. It is obviously true that they are over-represented among WP editors. All the more reason why they should take care to avoid geekspeak when writing for WP, which is aimed at a general audience, many or most of whom are not technophiles. -- Alarics (talk) 19:36, 26 September 2009 (UTC)[reply]
IMO this is a very important point. In the UK - and I assume most other English-speaking countries, YYYY-MM-DD is very rarely encountered outside a computer context. On the rare occasion you do see it in RL, it'll almost always be intended to be computer-readable more than human-readable.
Someone mentioned airline tickets before. Turns out I have an old (paper) airline ticket here, and it uses two date formats - 08AUG07 and 22SEP. The former refers to 8 August 2007, not 7 August 2008. They may have started using ISO format in the last two years, though it's all gone electronic anyway, so a date in that format may not need to be made human-readable.
As such, I endorse Alarics' comment. This is a systematic bias issue, and we should be writing for a general audience, not a technically-minded one. Pfainuk talk 15:23, 27 September 2009 (UTC)[reply]
History lesson: The cite xxx templates wikilinked the dates and the documentation recommended using the ISO date format. Linking the dates formatted them for users who were logged in and had a preference set. When refTools was implemented, it followed suit. Around August 2008, there was some consensus to remove the date linking, and this was very quickly done. Unfortunately, there was no work to update dates in footnotes that were left in all sorts of formats. Much of the cite template documentation still showed ISO dates until a month or so ago. And refTools still uses ISO dates. ---— Gadget850 (Ed) talk 23:15, 26 September 2009 (UTC)[reply]
  • Thanks for the history lesson, Gadget850. That helps explain why the blight of all-numeric dates has encroached (cockroached) as far as it has. Hopefully, we can keep the practice tightly corralled and stomp each cockroach as it is encountered. I volunteer to start first with that USGS data-ralph; there is no reason in the world that three-letter abbreviations should not be used there and there is every ‘readability’ reason in the world they should be used there. Greg L (talk) 00:25, 27 September 2009 (UTC)[reply]
I could find links to the discussions, but there were a number of them spread across lots of pages. I consider that the mere presence of so many ISO dates should not present a consensus for their use. The lack of fixes to then current articles and the continued lack of updates to documentation and tools has caused the format to proliferate. There are some tools that will help: User:Remember the dot/ISO date format unifier.jsworks quite well. ---— Gadget850 (Ed) talk 00:53, 27 September 2009 (UTC)[reply]

Comment. When recommendation are truly absurd, people just ignore them. Once upon a time, MOSNUM said: "Very large numbers may be divided up by commas every three places (e.g.: 2,900,000), starting from the decimal separator in both directions [emphasis added]." That'd mean one should write the number of square metres in an acre as 4,046.856,422,4. Of course, I've never seen such a format, on Wikipedia or elsewhere. I think I have seen other example of obviously silly rules which were just ignored, though I can't recall any one right now. If people are not treating the suggestion to use YYYY-MM-DD in "long lists and tables" the same way as they were treating the suggestion to use commas after the point, that means that they consider it less absurd. --___A. di M. 10:03, 27 September 2009 (UTC)[reply]

I fully understand your point, A. di M. Unwise MOSNUM advise that flouts common sense is seldom followed. However, MOSNUM is often used as a battle ground by editors who think they will Lead the World To A Brighter New Future By Leading By Example©™®. Now… you know this to be true. The IEC prefixes, where “mebibyte” (MiB) and “kibibyte” (KiB) were “allowed” according to MOSNUM, lead to just one single editor running about changing hundreds of computer articles overnight. Thereafter, those (somewhat less motivated) like-minded editors—including one admin—blocked anyone from reverting the articles. This group too spouted about how the IEC prefixes were an <profound awe>international standard</profound awe> that had been washed in unicorn tears and anointed with holy oil from the technology gods. Never mind that the entire computer industry as well as the computer magazine industry as well as all encyclopedias didn’t adopt the IEC prefixes, Wikipedia was going to use terminology that was unfamiliar to readers because (“they’ll learn it easily enough,“ “it’s an *international standard,” “we are electronic and have links,” “it’s logical and everyone can figure out what it means,” etc.).

Similarly, there appears to be an editor who was logging out to do I.P. edits on the ISO 8601 article to make it say that the standard was intended to apply to “internal, personal, hand-written notes (“Mom, I’ll be home by 2009-11-09T11:20 after the Star Trek convention lets out”). Such highly *motivated* editors can be exceedingly difficult to revert and the work of a single editor can spread like lung cancer across Wikipedia.

The common theme between the IEC prefix cabal and those who promote “2009-11-09T11:20” for use on Wikipedia is that they are perfectly willing to ignore the common-sense principles of clear technical writing and don’t care what practice is common in the real-world; they are *believers in the cause* and think our use of the practice here will lead to more general adoption in the real world. After three long years confusing readers and making Wikipedia’s computer-related articles look like they had been authored by 15-year-old fools, our experiment with the IEC prefixes proved that this mindset was nothing more than wishful thinking of those who don’t understand the fundamental principles of how to write clear, encyclopedic prose. So…

Though a practice may be stupid and you think few will follow stupid advise on MOSNUM (you might well be right), having any unwise practice sanctified on MOSNUM is just that: unwise. Why? Because, though not too many may follow it, all it takes is a handful of editors to make a lot of crappy looking stuff on Wikipedia; all they have to do is point to MOSNUM to say it is officially sanctified and that the practice has been blessed by the ISO gods. Greg L (talk) 16:38, 27 September 2009 (UTC)[reply]

Don't forget that many, if not most, editors aren't constantly (or probably in many cases ever) consulting MOSNUM or the documentation for citation templates to see what they should do. They just do what they see other people doing. But, A. di M., I'm not sure that I get your point here. The issue with the bit about "long lists and tables" is whether or not footnotes are included in "long lists". I don't think it was ever the intention that they are to be so regarded. -- Alarics (talk) 10:25, 27 September 2009 (UTC)[reply]
My point was that if it were that absurd to use YYYY-MM-DD in footnotes, no-one would have ever done that, regardless of what the MOS say, just like no-one ever wrote "0.453,592,37" for the number of kilograms in a pound, in spite of the fact that the MOS used to explicitly allow that. (I'm not saying that using YYYY-MM-DD in footnotes is good; I'm just saying that it isn't the worst thing in the world, unlike some people here seem to believe.) --___A. di M. 22:28, 27 September 2009 (UTC)[reply]
Indeed. I agree; there are gradations of technical-writing faux pas. Just like criminal cases, using “2009-03-09T19:30” in a table certainly isn’t first-degree technical writing murder; just criminally negligent technical-writing assault. A friend should have interceded to prevent the offender from getting behind the keyboard. The friend could have prevented the accident by properly writing the much easier-to-read, natural, and unambiguous “Mar 9, 2009, 7:30 PM” and thus saved the poor article from a life in a wheelchair. Greg L (talk) 01:05, 28 September 2009 (UTC)[reply]

Revised summary of the present state of play on YYYY-MM-DD in footnotes

Analysing all the comments made in the past few weeks (including those now archived at Wikipedia talk:Manual of Style (dates and numbers)/Archive 125, there appear to be broadly three main strands of opinion (this is necessarily a crude measure, but it gives a rough idea of the weight of views):

(A) In favour of YYYY-MM-DD in footnotes and tables. Cavrdg, Darxus, Denimadept, LeadSongDog, Offliner, RockyMtnGuy, Vegaswikian, wjemather, Woodstone. Total: 8 9 editors.

(B) Prepared to see YYYY-MM-DD in some tables, but not in footnotes. A. di M., Headbomb, HWV258, Ohconfucius, Rich Farmbrough, Septentrionalis, Sssoul[see below], Woodstone[see above]. Total: 8 7 6 editors.

(C) Opposed to YYYY-MM-DD anywhere. Alarics, Dabomb87, Debresser, Greg L, gu1dry, Jc3s5h, Jimp, Pfainuk, Redrose64, Shakescene, Tony1, VMAsNYC. Total: 11 12 editors.

Clearly, there is no consensus for deprecating YYYY-MM-DD altogether. But, adding (B) and (C) together, we have 19 18 17 18 editors who oppose the use of YYYY-MM-DD in footnotes, against 8 9 who are in favour of it. Does that constitute a consensus on that particular point? If so, can we move forward with that, and leave the other, more contentious issues to one side? I would like to get agreement on just this narrow question -- YYYY-MM-DD in footnotes -- without going over all the arguments again. I'd be grateful if any further discussion beyond this point is about the practicalities of taking the matter forward, not on the substantive issue. If people really want to carry on going over the arguments again on the substantive issue, perhaps they could do so above this subsection. -- Alarics (talk) 19:07, 25 September 2009 (UTC)[reply]

sorry to revise your revision, but i was in the process of removing myself above when you made your revision. in fact if i have to see YYYY-MM-DD anywhere, i'd rather see it in reference footnotes than in tables. my own preference is to use three-letter month abbreviations in space-limited areas, and full dates or three-letter abbreviations in footnotes, but my main view at this point is that there needs to be wider discussion before deprecating YYYY-MM-DD outside of prose. (Alarics didn't misrepresent my view – i simply neglected to finetune it as the discussion got windy.) Sssoul (talk) 06:49, 26 September 2009 (UTC)[reply]
Yes, there needs to be wider discussion, indeed. That is why I am trying to get agreement here on one specific question to be put to that wider discussion. From the debate up to this point, it seems clear that we are not going to get a consensus on deprecating YYYY-MM-DD altogether. The only specific question on which we appear likely to get a consensus is: Can we deprecate YYYY-MM-DD in footnotes? I want us to put just that narrow question to a wider discussion, and, if people agree with me, to work out in practical terms how we do that. -- Alarics (talk) 07:11, 26 September 2009 (UTC)[reply]
thanks for clarifying that, Alarics - it wasn't clear that "Does that constitute a consensus on that particular point? If so, can we move forward with that" meant "can we present this particular point to a wider audience". yes, i support doing that. Sssoul (talk) 07:46, 26 September 2009 (UTC)[reply]

A real-world sample. I did not participate in the above discussion, but (for other reasons, having to do with HTML conformance of citations) I happen to have been reviewing the ten articles most recently nominated for Featured Article status. These are articles that reflect recent activity in article improvement, and by and large they are in pretty good shape (though obviously not featured yet). Of these ten articles, six use YYYY-MM-DD dates in footnotes, and four do not. The six that use YYYY-MM-DD are Well Dunn, Trump International Hotel and Tower (Chicago), Sydney Riot of 1879, Anarchy Online, Ethan Hawke, and John Tavares (ice hockey). The four that do not use YYYY-MM-DD, along with the styles they use in parentheses, are Neverwinter Nights 2: Mysteries of Westgate ("September 24, 2009"), Tiananmen Square self-immolation incident ("4 October 2007"), Bramall Hall ("12 September 2009"), and 1982 British Army Gazelle friendly fire incident ("19 November 2008"). Admittedly this is a small sample, but it was chosen sort-of-at-random from pretty-good recent articles. In this sample of recent articles, YYYY-MM-DD style is used in footnotes by more than half the articles, and it's used by twice as many articles as the next most-popular date style. I therefore suggest that the real-world consensus (as opposed to the consensus on this page) is strongly in favor of allowing YYYY-MM-DD in footnotes, though there is obviously not a consensus in requiring YYYY-MM-DD. Eubulides (talk) 08:54, 26 September 2009 (UTC)[reply]

Two tests which I made a few weeks ago gave similar results: among the FA on the Main Page of that day and the three previous days, two had YYYY-MM-DD, one had spelt-out months, and one had no full date in footnotes at all; among twenty-odd articles I got to through "Random article", five had YYYY-MM-DD, five had month names, and all the others had no full date in the footnotes. BTW, what about having a centralized discussion, advertised on the Village Pumps, WT:MOS, here, and maybe even on a watchlist notice? I agree there's no reason to use YYYY-MM-DD in footnotes, but if we have to make such a large-scale change, we'd better notify as many people as practical before changing the MOS and having bots seeking and destroying YYYY-MM-DD dates in footnotes all over Wikipedia. Hasn't this taught anyone anything? --___A. di M. 10:13, 26 September 2009 (UTC)[reply]
Even if such a change were made, you would propose implementing it using a bot, but given the various written formats used in different articles is that even possible to do accurately in order to maintain consistency in compliance with MOSNUM? wjematherbigissue 10:30, 26 September 2009 (UTC)[reply]
I have no opinion on how to implement that (by "we should do A before doing B" I actually meant "we should not do B before doing A); but I don't think it would be impossible to for a bot to determine whether dates like "26 September 2009" or "September 26, 2009" occur more often, and use that format to replace YYYY-MM-DD. --___A. di M. 12:20, 26 September 2009 (UTC)[reply]
No, it should NOT be done with a bot. There are cases where YYYY-MM-DD is part of the URL of an external link (some newspapers structure their URLs that way) and obviously those have to stay. I use Lightmouse's script, which allows you (among other things) to convert them either to DMY or to MDY, according to the subject of the article or the existing predominant style in the article, but you have to manually check the output.
Eubulides and A. di M. both note that YYYY-MM-DD occurs a lot in footnotes at present. But we know that already. That doesn't prove any positive or conscious consensus in favour of it, only that people think it is what they are supposed to do. In many cases it may result from the use of citation templates in which such a date is already entered by default. It hasn't yet been explained to these people why it's unsatisfactory. When I change YYYY-MM-DD in footnotes to a proper date, which I always do when editing an article for some other reason, nobody ever complains. -- Alarics (talk) 13:09, 26 September 2009 (UTC)[reply]
  • Pls feel free to move this comment to elsewhere if I've dropped it in the wrong place. I think the popularity of the YYYY-MM-DD format is overstated above. First, I've run into at least one bot repeatedly (and perhaps more than one) that have been energetically changing references from other date formats to the YYYY-MM-DD format (despite the fact that, arguably, the YYYY-MM-DD format has always been forbidden by the MOS). I've not run into any bots that I can recall that are changing the YYYY-MM-DD date formats to other date formats. Thus an active bot (e.g., the one by our most active editor, Richard F ... , has been changing articles where editors chose a style other than YYYY-MM-DD to that format -- his bot User:SmackBot has made over 2.4 million edits) would tend to severely skew the above readings of how "popular" that format is on Wikipedia. I've alerted the editor who created that bot of the discussion here, so that he can contribute (or simply follow) -- as he prefers.
Google searches yield decidely different results (as shown below). I would submit that the YYYY-xx-xx is as confusing to the masses (who, like me as of a month ago, had no idea that there is no YYYY-DD-MM format) as is the MM/DD/YYYY format, and that format is obviously far less common (as demonstrated below).
  1. "1/1/09" appears 91.9 million and 6,340 times in googles web and news searches.
  2. "Jan. 1, 2009" appears 43.7 million and 177 times.
  3. "January 1, 2009" appears 20.5 million and 111,000 times.
  4. 2009-01-01 appears 15.5 million times in a google search (note: no doubt some percentage of these are the Wiki articles with the dates revised by bots, as discussed above), and 685 times.
  5. "01/01/2009" appears 13 million and 1,840 times.
  6. 1 January 2009" appears 11.5 million and 2,870 times.
  7. "01/01/09" appears 5.9 million and 537 times.
Thus, day/month/year and month/day/year formats (which people are so quick to eradicate) in the above sample show up 110.8 million times, months written out show up 75.2 million times, and the YYYY-MM-DD format shows up 15.5 million times (and it would appear that some percentage of that may be in Wikipedia articles, changed by a bot from a prior different format). This effect is even more dramatic in news articles. (note: "1 Jan. 2009" yields many false positives, as where the phrases issue, volume, and the like precede the "Jan.", but probably account for tens of millions of references as well).
I think that the popularity of the YYYY-MM-DD format is therefore exagerated above, and even more firmly than before think its use should be eradicated.
I would add that since we ban YYYY-MM-DD from the text of the article, banning it from footnotes (still) would have the benefit of opening up the possiblity of greater conformity between the date format style of the article text and of the references. This would seem to be in keeping with the general Wikipedia preference for conformity of format where possible. [Note: I was formerly known as VMAsNYC (so pls don't double-count me].----Epeefleche (talk) 09:22, 27 September 2009 (UTC)[reply]
A. di M. suggests we organise a centralised discussion. That is just the sort of thing I am aiming for. It should be on the narrow question of deprecating YYYY-MM-DD in footnotes. Does anyone know how to organise this? I have no experience of this kind of procedural thing. -- Alarics (talk) 13:18, 26 September 2009 (UTC)[reply]

[PLEASE don't add further comments here on the substantive issue; they go in the previous subsection. I meant THIS subsection to be about the procedural issue of what do we do now.] -- Alarics (talk) 19:32, 26 September 2009 (UTC)[reply]

I think that based on this discussion we may remove any advise to use the YYYY-MM-DD or ISO 8601 (or whatever else looks like it) whereever we find it. With exeption of what it says here on the project page "YYYY-MM-DD style dates (1976-05-31) are uncommon in English prose, and should not be used within sentences. However, they may be useful in long lists and tables for conciseness." That would be a good start and seems uncontroversial for all points of view. Debresser (talk) 21:27, 26 September 2009 (UTC)[reply]

Yes, but then we need to spell out that "long lists" doesn't include footnotes. -- Alarics (talk) 08:13, 27 September 2009 (UTC)[reply]
Related discussion: Wikipedia:Village pump (policy)#accessdate format. ---— Gadget850 (Ed) talk 00:56, 27 September 2009 (UTC)[reply]
Epeefleche, are you quite sure that SmackBot is converting dates in footnotes to YYYY-MM-DD? Can you show examples? If that is true, it must be stopped from doing so immediately. But I can't find any reference to that on the SmackBot page, and on the basis of earlier discussion I had Rich F. down as supporting YYYY-MM-DD in tables but not in footnotes. -- Alarics (talk) 08:18, 27 September 2009 (UTC)[reply]
I would have to do some hunting to find it, but believe I saw it make that change as recently as the last 48 yours. I've left him a note. Tx.--Epeefleche (talk) 09:24, 27 September 2009 (UTC)[reply]
No you didn't. I have never written the regexs to do that. XX/XX/XXXX to full dates in many places, hacked pseudo-ISO to full dates in certain long articles (but never stored the code), linked dates, back when that was what we did, and unlinked. SmackBot has a mandate to de-link days of the week and months. That's about it. It is true I am in mildly supportive of them in access dates (but not elsewhere in footnotes/urls/cites/references) , I would be even more supportive of not displaying access-dates at all - they are really only relevant when the cite fails in some way. Rich Farmbrough, 11:39, 27 September 2009 (UTC).[reply]
I've left an example of the sort that I was referring to (as recent as this month) at [5].--Epeefleche (talk) 02:38, 28 September 2009 (UTC)[reply]

Note: the Google counts above double counts 12/31/08 and 31/12/08 . Note also that Google is too smart. On the first page of 01/01/09 we find "Coney Island Polar Bear Plunge 1-1-09 Philip Kiracofe Video". Rich Farmbrough, 11:39, 27 September 2009 (UTC).[reply]

I agree that ISO dates, unless talking specifically about the date format itself, should be avoid in prose and tables, with 3 or 4 letter abbreviations used on months to save space. I also do agree that at the end of the day, an article should avoid ISO dates in footnotes, but I will note that as a writer that is frequently adding references, the ISO date is a much more favorable way of getting the date information into the article instead of either normal MD,Y or DMY formats. As long as there are tools that can be used at the end of the day to convert ISO to either format as appropriate in refs, I don't recommend depreciating all use of ISO, but instead recommending that reflists should avoid ISO (with links to such tools) in the long run, but definitely blocking ISO (except as needed) from the article body itself. --MASEM (t) 13:36, 27 September 2009 (UTC)[reply]
And obviously, the ISO avoidance in the body should be only in the displayed text. ISO is very helpful in {{sort}} and other such backend templates. --MASEM (t) 13:41, 27 September 2009 (UTC)[reply]
I don't understand why you say "ISO date is a much more favorable way of getting the date information into the article instead of either normal MD,Y or DMY formats". In what way more favourable? It would be much better if people wouldn't put them there in the first place than to rely on somebody coming along and changing them later. -- Alarics (talk) 13:44, 27 September 2009 (UTC)[reply]

Responding to Debresser's point above: No, the "However, they may be useful in long lists and tables for conciseness." bit is not uncontroversial. A number of us are arguing that YYYY-MM-DD are not useful on WP at all and that the difference in conciseness between them & three-letter dates is insignificant. JIMp talk·cont 15:53, 27 September 2009 (UTC)[reply]

The only person that I ever met who used YYYY-MM-DD (outside of WP) was my father, and it took me less than twelve years to realise that he wasn't right about everything --Redrose64 (talk) 17:18, 27 September 2009 (UTC)[reply]

Fathers aside, YYYY-MM-DD and YYYY-MMM-DD are both widely used in Canada, particularly on government documents, both geeky and non-geeky. Canada also uses DMY & MDY (each in at least 3 forms), and all checks must now indicate which style is being used--JimWae (talk) 20:19, 27 September 2009 (UTC)[reply]

Such is true. The standard Canadian government date format is YYYY-MM-DD, and many Canadian companies use it as well. Where they spell out the month in English, some Canadians use 2009 September 27, some use 27 September 2009, and some use September 27, 2009. The French Canadians do the same thing in French. I am treasurer for a Canadian nonprofit organization, and I have a stack of cheques (sic) from our members here. Since all cheques in Canada must have a machine readable date now, the date formats they use are YYYYMMDD, DDMMYYYY, and MMDDYYYY. The most common date format is YYYYMMDD. Most of the cheques are printed in English, many are printed in French, and the odd one is filled out in Japanese or Chinese.RockyMtnGuy (talk) 22:56, 27 September 2009 (UTC)[reply]
There you are, you see: "all cheques in Canada must have a machine readable date". But we're not writing cheques for a machine to read, we're writing an encyclopaedia for humans to read. -- Alarics (talk) 23:13, 27 September 2009 (UTC)[reply]
Alarics, regarding "we're not writing cheques for a machine to read", I think you misunderstood. All three of the formats RockyMtnGuy listed are intended to be machine-readable. He's saying that YYYYMMDD is most common on Canadian cheques, and not commenting on the relative readability by machines or humans. TheFeds 04:06, 28 September 2009 (UTC)[reply]
  • IMHO Alarics has a point here, in that article dates and check dates have different audiences. Broadening out from "checks" to "what appears on the internet", and from "Canada" to "all google-able hits", from the numbers I set forth above (which may need some honing, per the above comment, but even still would appear to overwhelmingly make this point ... ) the YYYY-MM-DD format appears to be in a distinct minority in terms of date formats on the internet. And that is even the result I reached conducting a search for a very recent date (January 1, 2009); if we were to run the same test looking at a date from many years ago, I would expect the results to be even more stark.
If some of the newer commentators have views that they would like to have reflected in the vote summary above at the beginning of this section, please feel free to so indicate (if you feel you haven't done so sufficiently already).--Epeefleche (talk) 05:54, 28 September 2009 (UTC)[reply]
I've come down in favour of (C) but not hard and fast. This all reminds me of a situation I was in some fifteen years ago.
My employers at the time (a firm of database specialists) were engaged by another firm (a manufacturer of motor car spare parts) to produce a database of all their products, including their suitability for various cars made over twenty years or so. One of the search criteria was to be the vehicle manufacturing date. The spare part manufacturer wanted this to be entered and displayed in DD-MMM-YY form; this we were happy with. What we were not happy with was their insistence that the date also be stored in the database as a 9-character string, their reason being "that is how the management have decided that dates must be shown". We simply could not persuade them that the storage format and display format for date-type values could be different, not even by practical demonstration with sorted files; nor could we persuade them of the folly of two-digit years (this was in 1994). Without telling them, we created two fields in the database, one being the 9-char string that they insisted upon, and the other being an integer (count of days since a certain defined moment) to hold the internal form for sorting. When they discovered the extra field, they insisted on its removal. I left the firm well before 01-JAN-00.
So, I have experience that this sort of thing can drag on for years. My preferred solution is as follows.
  1. Where dates do not need to be parsed (by a bot, whatever), use the normal form for the article; if unclear, one of the forms preferred long-term by existing MOS guidelines for the main text
  2. Where dates do need to be parsed, primarily in sortable tables, use the same as above but wrap it inside {{dts}}
I'm not sure if everybody's read it up, but Template:Dts/doc implies that {{dts|2009|September|28}}, {{dts|2009-09-28}}, {{dts|September 28, 2009}} and {{dts|28 September 2009}} are all valid and give identical behaviour when sorted. Therefore, should it be necessary for |accessdate= to be parsable (and I've yet to see a reason for requiring that), the same code as used by {{dts}} to derive <span style="display:none">2009-09-28</span> could be utilised. Or there's {{Start date}}. The point is, that forcing the |accessdate= to appear in different format to all the other dates is jarring. --Redrose64 (talk) 10:51, 28 September 2009 (UTC)[reply]

I think it infinitely clear that the professional editors in the editorial rooms of fine encyclopedias, when they are pondering how best to communicate dates to readers, don’t ask “well, what computer-readable, all-numeric format is used on Canadian bank checks?” So… Have we developed a consensus to use machine-readable date formats only where machines (Wikipedia’s servers) need to understand dates, and to ensure dates are rendered in human-readable form for the humans? You know, where…

  1. In main-body prose, we write the month’s name out in full: “On 7 April 1795, the gram was decreed in France to be equal to…”.
  2. For citations, we use A.P. short-form: “(Science News, Vol. 172, Oct. 17, 2007)”.
  3. For tables, we use fixed, three-letter abbreviations and we modify USGS data-ralphs so the temporal column reads “Mar 9, 2009, 7:30PM” instead of “ “2009-03-09T19:30”. They’re both two-fingers wide on my screen and the first example is much easier to read.

None of this is technical-writing rocket science. Why is so much discussion transpiring on an issue that is so easily solved? Greg L (talk) 19:46, 28 September 2009 (UTC)[reply]

C'mon...

Do you agree to add the following:

  • Do not use date formats such as 03/04/2005, as they are ambiguous (it could refer to 3 April or to March 4). For consistency, do not use such formats even if the day number is greater than 12.

after the fourth bullet ("Yearless dates ..." in Wikipedia:Manual of Style (dates and numbers)/Datestempprotectedsection? If no-one disagree in 24 hours, I'll post an {{editrequested}}. (Please do not use this section to discuss any other issue, no matter how close it is to this one; that would defeat the purpose why I'm writing this in the first place. --___A. di M. 20:42, 20 September 2009 (UTC)[reply]

  • I assume this was posted by A di M?

    Propose:

Do not use all-numeric date formats such as 03/04/2005, as they are ambiguous (the example could refer to 3 April or to March 4). For consistency, do not use such formats even if the day number is greater than 12.

Support It’s a good first step towards purging MOSNUM of the last of the silly practices that no other quality, internationally distributed, English-language encyclopedia uses. Greg L (talk) 20:41, 20 September 2009 (UTC)[reply]
Yes, I can live with that, as far as it goes. Better I think would be "Do not use numerical date format such as .... " However, it doesn't address the main problem, which is YYYY-MM-DD. I don't get the impression that many people are writing 03/04/2005, but perhaps it crops up in articles that I don't look at. Alarics (talk) 20:52, 20 September 2009 (UTC)[reply]
Didn't ya get the point? All this talk about numeric format started when a editor reverted an article back to MM/DD/YYYY, noting that MOSNUM says "it is inappropriate for an editor to change an article from one [acceptable style] to the other without substantial reason" and doesn't say that MM/DD/YYYY is not an acceptable style. Everyone else agreed that MM/DD/YYYY is not an acceptable style, and that this should be explicitly stated to MOSNUM; but, since somehow the discussion widened to YYYY-MM-DD, AP abbreviations, yadda yadda yadda, on which there's no strong consensus for anything, the simple suggestion at the top of this section, to which no-one disagrees, was not implemented. --___A. di M. 21:07, 20 September 2009 (UTC)[reply]
Yes, by all means go ahead with that limited change, for what it's worth. Alarics (talk) 21:09, 20 September 2009 (UTC)[reply]
BTW, I don't agree that we have "no strong consensus on anything" as far as YYYY-MM-DD is concerned. By my calculations, in the whole of the above discussion, we have about twice as many users against YYYY-MM-DD as in favour of it. Alarics (talk) 21:12, 20 September 2009 (UTC)[reply]
Usually "consensus" on WP means about 75% (even if raw numbers aren't supposed to matter). Maybe there's consensus against YYYY-MM-DD, maybe not, but the point is that there's overwhelming consensus against MM/DD/YYYY and DD/MM/YYYY which was not implemented due to discussions about YYYY-MM-DD. --___A. di M. 21:16, 20 September 2009 (UTC)[reply]
  • A. di M., you have my support on anything you propose that makes progress along these lines. Anything that brings Wikipedia closer to standard encyclopedic practice is better than nothing. Greg L (talk) 04:25, 21 September 2009 (UTC)[reply]

(outdent) I would suggest something more along the lines of this, so it follows more cleanly from the preceding bullet point:

Other all numeric date formats, such as 03/04/2005, should be avoided since they are often ambiguous in that the first number could translate to either the day or the month (the example given could refer to 3 April or March 4).

I think it is unnecessary to further clarify with regard to days greater than 12. wjematherbigissue 21:54, 20 September 2009 (UTC)[reply]

go for it, A di M - and please do include the wording about days greater than 12, because (as noted way earlier) otherwise some literal-minded editor will understand that it's good to use 18/01/2010. Sssoul (talk) 06:19, 21 September 2009 (UTC)[reply]
I can't "go for it" myself, as the section is protected (as a result of the Great Date Delinking War) and I'm not an admin. I'll post an editrequest on its talk page, though. --___A. di M. 09:52, 21 September 2009 (UTC)[reply]
smile: ahh, another literal-minded sort! i meant "go for the editrequest". Sssoul (talk) 10:04, 21 September 2009 (UTC)[reply]
I thought of making a parallel change to the "Manual of Style", but all-numeric dates that start with day or month are uncommon enough in Wikipedia that I think we can leave that detail to MOSNUM. --Jc3s5h (talk) 04:33, 22 September 2009 (UTC)[reply]

Summary done

See WT:Manual of Style#Summary done. --___A. di M. 22:55, 20 September 2009 (UTC)[reply]

Torque measurement standardization

I'm trying to help expand {{Convert}} & it's standardization of the abbreviations used. We have come to a wall with the torque measurements. As of right now the kilogramforce-meters to Newton meters & foot-poundforce via {{convert|xx|kgm|Nm lb.ft}} as 10 kilogram metres (98 N⋅m; 72 lb⋅ft). Well as of right now we were working on adding Nm to kgm & ft-lb & ft-lb to kgm & Nm, but we have hit a snag of disagreement & we have agreed that we need the MoS communities opinion on this matter. I say we should use kgm for kilogramforce-meters & Jimp says we should use kgfm. I say we should use ft-lb for foot-poundforce & Jimp says we should use ft-lbf. Also I say we should use Nm for Newton meters & Jimp says we should use N.m. The wiki article for Kilogram-force it states for torque it is "meter-kilogram" & the Torque article has it listed as "meter-kilograms-force" or "kilogrammeter". So thoughts? ɠu¹ɖяy¤ • ¢  21:40, 21 September 2009 (UTC)[reply]

  • Holy smokes will this get complex. This issue falls right smack in the middle of my new catchphrase: “Well… when you dig down into the details, it’s not all that simple.” Alright. I am an ME and know my way around this subject rather well. The only proper SI unit in science-related articles is the newton‑meter. The newton (and its multiples and submultiples) is the only proper SI unit of force and the meter (and its multiples and submultiples) is the only proper SI unit for the moment arm. But, there are a number of very important caveats:

    Different disciplines have widely different practices. For instance, the cubic centimeter is an old CGS unit for volume. Nevertheless, the long-standing practice with Japanese motorcycles has been—and still is—to use “cc” for engine displacements. Accordingly, Wikipedia follows real-world practices rather than try promote the adoption of the rule of SI via example (which doesn’t work anyway). So, on the subject of antiquated practices, torque wrenches from ten or twenty years ago will often be calibrated in kg‑f‑meters, which was a common torque unit for Japanese-built automobiles; perhaps it still might be, I don’t know. IMO, an article for instance, on the Ford 351 Cleveland engine, which is sold all over the United States (and not so much elsewhere) ought to use ft-lbs as the primary unit of measure and provide a parenthetical conversion to N‑m. Similarly, if the the subject is about a particular Japanese car where the manufacturer still uses kg‑f‑meters, then that is what I would go with. Where there is no consistent industry practice, I would generally use the proper SI unit (newton‑meter). As a final caveat, if the subject pertains to a subject that is about or is closely related to the United States, one should consider using U.S. customary units throughout (including ft‑lbs for torques).

    Many Wikipedians, who are prolific and jump from article to article find this practice of using different units in different articles to be disconcerting. They feel that there should be project-wide consistency. However, the practice using the units of measure that are very common to a particular discipline (with parenthetical conversions to a suitable unit) best serves the interests of our readers (which is why we’re really all here). The purpose of any encyclopedia is to educate readers on a subject and properly prepare them for any future studies they may pursue on the subject. We do our readers no service whatsoever if, in the subject of gravimetry, we mention gravity gradients of “3.1×10−6 s–2” (that unit is pronounced “reciprocal seconds squared”) when virtually all text books on the subject use “3.1 µGal/cm” (pronounced “microgal per centimeter”).

    In a nutshell, try to stick to the rule of SI unless an industry practice is rather consistently otherwise or if the subject matter is about or strongly associated with the United States.

    That’s my 2¢. Now for “unit-of-measure jihad” and suicide bombers from *standards organizations*… (*wheeeee*) Greg L (talk) 22:18, 21 September 2009 (UTC)[reply]

    We're not debating on which unit to use but which abbreviation for torque measurements to use. So your essay is not truly relevant to current issue we are debating. Just a side note, the purpose of Template:Convert is convert units so people don't have to manually do for the wide range of patrons of Wikipedia. ɠu¹ɖяy¤ • ¢  22:27, 21 September 2009 (UTC)[reply]
  • Oh, well… just pardon me all over the place for the “essay.” You’re welcome.

    In that case, as to the exact way to write out these units of measure (such as someone’s suggested “foot-poundforce”), I would dispense with arguments over “what technically makes scientific sense and mustn’t be confused with units of energy” and would certainly jettison weird-looking examples like that subscripted form. We’re not doing anyone a favor by pretending to change how the world works. Moreover, such efforts to change the world will fail anyway; Wikipedia is pretty darn good at spreading misinformation, not in changing the very way people communicate. Technical writing works best when the writing techniques being used to convey ideas don’t call attention to themselves. If there is a sound reason to depart from the rule of SI, I would just use what is most typically used in real-world literature on the subject.

    Either that, or do whatever the hell you want. Some of the suggested units up there look retarded to me. I now have a sense that you weren’t so much looking for advise as were simply inviting a pile-on against those who would disagree with you. No help here; just go bicker amongst yourselves. And you and the others might try to use common sense for once and not needlessly confuse readers or call attention to one’s writing style. That beats endless arguing in an effort to prove who’s right.©™® Greg L (talk) 22:46, 21 September 2009 (UTC)[reply]

I wasn't trying to be rude, but you went into a complete tangent into something is not even trying to be discussed. We are not disputing the terminology but the abbreviation, which something you still haven't addressed you stance on. ɠu¹ɖяy¤ • ¢  22:58, 21 September 2009 (UTC)[reply]
  • I wasn't trying to be rude. Oh, I’m sure that was an “oopsy”; rudeness comes easy. We are not disputing the terminology but the abbreviation: yeah, you explained that above; ergo my previous response. [How to abbreviate is] something you still haven't addressed you stance on. Beyond the few nuggets I provided above? My views there are clear enough for those willing to read and stop pounding their keyboard. Indeed, I’m done. Sit back and see if someone else here volunteers to bang their damned head against a wall with editors who won’t crack open books and follow common practices because they’re out to change the world. Goodbye and happy editing. Greg L (talk) 23:12, 21 September 2009 (UTC)[reply]
No you have not addressed you thoughts on ABBREVIATIONS of the common torque measurements. You continued to provide information that did not assist in the discussion at hand, but a discussion that does not exist. We are not discussion which torque measurement to use, which is all you have addressed. ɠu¹ɖяy¤ • ¢  23:35, 21 September 2009 (UTC)[reply]

Jimp is correct in that the standard abbreviation for newton-metre is N·m (note use of a half-high dot). Otherwise it may be confused with nm for nanometre or mN for millinewton. The problem with the foot-pound and kilogram-metre is that neither the pound or the kilogram are units of force, so it's not clear how to abbreviate pound (force) and kilogram (force) in some kind of internationally standardized way. You could come up with some local standard, but someone from some other country would always disagree. I'll have to research that issue.RockyMtnGuy (talk) 00:55, 22 September 2009 (UTC)[reply]

The {{Convert}} template is used to support Wikipedia articles. The only reason for Wikipedia articles to contain non-standard torque units such as kilogram-force meter would be in a direct quote, or if there is some specialized field that still uses it (which I doubt). The conversion, which is abbreviated and goes in parenthesis, would be to a standard unit. I can see a need to convert from kilogram-force meter but no reason to convert to that unit. So, I don't think any abbreviation is needed. --Jc3s5h (talk) 01:34, 22 September 2009 (UTC)[reply]
  • Jc3s5h, I was jumped on for touching upon the subject of “choice of units.” The issue that has these editors at each others’ throats is how to denote the unit symbols, and it appears there is a crowd chanting “Let’s Change the World” over there.

    Yes, Jimp is correct on the proper way to write the unit symbol for the newton-meter. As for unit symbols like foot·pound (ft·lb) “house solutions“ and “local standards” like “foot-poundforce” are just that: local standards that are not generally found in the real world. Such *Wikipediaisms* are nothing more than just more grist for, as one editor wrote, above, people to “chuckle good-naturedly” at our “foibles.”

    Just because a practice that is common in the world has technical or logical shortcomings when one scrutinizes it doesn’t mean that we need super editors to come to the rescue and right every wrong with the technical-writing world. When General Motors specifies a torque of 75 ft·lb, and since torque is, by definition a force moment, it can quite reasonably be assumed that “force suffix” is implied and the unit really means pound-force or kilogram-force. I find that much preferable to (once again) pretending we’re going to show the world how things ought to be done. The expression “75 ft·lb” in the context of torque confuses no one; the expression “75 foot-poundforce” would just make Wikipedia once again look like it’s been infested by space-cadets.

    Once again, I would suggest we look to other encyclopedias and other professional publications for guidance here rather than try to set the world on fire by misapplying our *amazing powers of physics acumen* and trying to invent new and better ways to write common things. Greg L (talk) 01:52, 22 September 2009 (UTC)[reply]

See once you actually point your POV of the actual subject on hand I have something to properly rebuttal about. Yes I agree that foot-poundforce should be abbreviated as ft-lb, this is what I proposed in the original decision on Template:Convert, but Jimp is the one that thinks it needs the force in the abbreviation, when it isn't needed. No one is at other people throats, have you looked at Template talk:Convert? It's just is helpful to rant on into a tangent about that something doesn't help the discussion. ɠu¹ɖяy¤ • ¢  02:03, 22 September 2009 (UTC)[reply]
I'd use either "kgf·m" or "kgf·m". It should be less confusing if the handful of articles using this unit stick to the idea of using the kilogram symbol to represent the kilogram. I'd prefer to extend that to the pound too but foot-pounds are a more widely used and understood unit. JIMp talk·cont 03:01, 22 September 2009 (UTC)[reply]
I'd would agree that you should use "kgf·m" for kilogram (force) metre and also suggest that you use "ft·lbf" for foot-pound (force). This is purely in the interest of avoiding ambiguity, which is a huge problem in international documents. And of course "N·m" is the officially recognized abbreviation for the standard SI unit, the newton metre.RockyMtnGuy (talk) 03:38, 22 September 2009 (UTC)[reply]
The handful of articles using kilogram-force meter would be using it as a primary unit, which would be spelled out; there would be no need for an abbreviation. However, if an abbreviation were needed, NIST Special Publication 811 suggests "kgf · m" (page 65). --Jc3s5h (talk) 03:42, 22 September 2009 (UTC)[reply]
  • So then, N·m, kgf·m, and lb·ft? Here I am going against my own mantra about “follow real-world practices” and I got a hunch “ft·lb” dominates torque usage in the U.S. when writing the unit. It is overwhelming the order when verbally mentioning torque in the U.S. Regardless, it would confuse no one if it was “lb·ft”, which has the virtue of being properly distinct from the unit of energy and semi-scientific at that. I’ve always had a ‘problem’ with that mix-up and see no legitimate reason to make barbarian units even more barbaric. Greg L (talk) 04:02, 22 September 2009 (UTC)[reply]
I agree with N·m for Newton meters but for the wiki attribute on Template:Convert, I believe to make things easier it should be Nm; example: {{convert|32|Nm|kgm ft-lb}}. I prefer Kg·m, but whatever on that one. But still make formatting/typing easier I think the wiki attribute should be kgm. As for lb-ft vs. ft-lb, in the US ft-lb (or ft. lb) is more commonly used. ɠu¹ɖяy¤ • ¢  05:43, 22 September 2009 (UTC)[reply]
In my experience the more common forms are foot-pound (or ft-lb) and kilogram-meter (or kg-m), with a dash instead of a middot. Using the middot seems to be a mix between SI practices with non-SI units. Having the dash attracts attention to the fact that it is a non-standard expression. That the pound(force) and kilogram(force) are meant may then be left implicit in the measure described and the N·m. −Woodstone (talk) 08:03, 22 September 2009 (UTC)[reply]
  • I agree with you, Woodstone, regarding the hyphen. That’s a really good point. As an American, I was never confused when I first encountered the middot but always thought it a “genteel” form used by BIPM-types when they write “Be sure to not do this in your nickers, and then take your spanner wrench and tighten to 10 to 12 kg·m (72–87 lb·ft)”. Since torques in pound‑feet are pretty much an “American thing”, it would look more natural to write the unit symbol with a hyphen: “lb‑ft”, which is the most common practice in America.

    Note that I am using the non-breaking hyphen ({{nbhyph}}) for this unit symbol. A template should either be slapping a no-wrap around “lb‑ft” or it should use a non-breaking hyphen.

    Note also, Woodstone, that you reverted to the exceedingly common practice of referring to the torque as “foot‑lb”, but that form properly refers to the unit of energy that has a magnitude of ~1.3558 joules. Nowadays, it is not uncommon to hear commercials with Mike Rowe’s baritone voiceover on Ford commercials talking about big, masculine diesel torques of “410 pound‑feet of torque”. Certainly, no one in America will be ‘confused’ by “410 lb‑ft”. And, in my opinion, using this form will not unduly distract or draw attention to the writing style when trying to communicate ideas.

    Besides the fact that putting the length of moment arm last is more scientifically valid, it is also in conformance with other units like the N·m and kgf·m, which also have their moment arms last. Thus, this should appeal to those editors here who like project-wide consistency.

    Does everyone agree then, that it would be best to write them N·m, kgf·m, and lb‑ft ? Greg L (talk) 16:54, 22 September 2009 (UTC)[reply]

(outdent) A quick run at the search box with "kgf-m" gets 262 hits, while "N-m" gets 333 thousand. Why would we want {{convert}} to output this obscure form? LeadSongDog come howl 16:19, 22 September 2009 (UTC)[reply]
  • Because it is an archaic unit of measure that won’t often be found on the relatively modern Internet. There should be little need for it but I don’t see the harm of providing it in a template. There may be an article, for instance, about some old Ferrari and its owner manual and all its aftermarket shop manuals use “kg-m”. If this were the case, it would be perfectly appropriate to use “kgf·m” in that Wikipedia article. How and where to “use” the unit isn’t being discussed here; just getting the unit down correctly in a template. Greg L (talk) 16:54, 22 September 2009 (UTC)[reply]
I still prefer kg·m over kgf·m but I can accept it, especially for Gsearch of "kgf-m torque" & "kg-m torque" generate only a 5k different in results. ɠu¹ɖяy¤ • ¢  17:26, 22 September 2009 (UTC)[reply]
To clarify, those figures I gave were for English wikipedia articlespace, not the internet at large. Google gives much larger numbers with a less overwhelming ratio of hits. No objection to having it output when explicitly requested, as in {{convert|10|lb-f|kgf-m}}, but would oppose kgf-m the default output for {{convert|10|lb-f}}. The default output should remain N-m or the middot equivalent.LeadSongDog come howl 18:23, 22 September 2009 (UTC)[reply]
  • I see… I didn’t understand your point the first time around. You were not speaking to the issue of the form of the “kgf·m” unit symbol but were addressing how it should not be the converted-to value. Certainly; that makes perfect sense to me. Was anyone proposing otherwise? Conversions should generally be to N·m. It is the modern SI unit for torque and the unit symbol form shown is as modern and kosher as it goes and certainly doesn’t distract. Greg L (talk) 18:29, 22 September 2009 (UTC)[reply]
  • P.S. Well, let me back up here. There still might be industries, fields of endeavor, disciplines that even today typically use “kgf·m” as a primary unit. If that is the case (big “if”), then the {convert} template should support a “convert-to” unit of measure of “kgf·m”. Perhaps the best way to address this is to simply provide some usage guidance in the template documentation advising that, generally, N·m should be the convert-to value unless there is good reason to do otherwise. I don’t at this point see that it would be wise to de-feature the template so it isn’t capable of certain things.

    If, it is your intention here to be addressing what is strictly the “default” behavior, then—by all means—I agree with you 100%; converting to N·m should clearly be the default setting. Greg L (talk) 18:43, 22 September 2009 (UTC)[reply]

Agree that N·m should be the default and preferred "to"-unit. But as explicitly requested unit I would prefer to write kg-m (no explicit "force", but with dash to avoid confusion with the wrong dimensioned kg times meter) and similarly lb-ft. −Woodstone (talk) 19:51, 22 September 2009 (UTC)[reply]

  • Personally, I agree with you 100%, Woodstone. I have been in “compromise mode” here because of the perception that kg‑m is *unscientific and incorrect*. Technically, it is. To me, the issue comes down to these two questions:
  1. Is “kg‑m” (without the “f” suffix to denote force) far and away the most common form in the real world(?), and…
  2. Could writing “kg‑m” in the context of torques confuse our readership?
Well… I think the answer to question #2 flows from the answer to question #1; if (big “if”) the form “kg‑m” is far and away the most common way to write the unit of measure in the real world, then, IMO, that is practice Wikipedias should follow and the answer to #2 would have to be “obviously, “kg‑m” confuses no one.” The distinction of adding the “f” suffix would really only be necessary in a physics article where mass and forces are being bandied about. But for general use for a general-interest readership where we’re writing about how much Ferrari wheels were tightened onto a hub, whatever practice is most common in the real world is just fine.
As anyone who knows me from my writings, the way of addressing the issue is squarely in line with my SOP. It would be interesting however, to see if the implied “unit of mass on the end of a moment arm” (which technically makes no sense) has physics purists here fainting dead away. I propose we have some “Google search” arm wrestling here and find out what the facts are as to common usage before we go further with this. Anyone want to volunteer?
BTW, I just dragged out my gazillion-year-old Craftsman torque wrench. It reads in “METER KILOGRAMS” AND “FOOT POUNDS”. We’ve got to all bear in mind that the torque-measuring world has been all over the map in the past and that practices are slowly getting more in line with what the physics world does. I’m beginning to think that—once again—there is no single right way©™® that works best in all circumstances. This notion (that there is only one way to do things and that we should have project-wide consistency) has resulted in really shortsighted and unwise MOSNUM guidelines that flout common sense when it comes to writing clearly and without confusion. What is perfectly suitable (clear and glass and very natural) for an article about nuts and bolts would be truly horrifying in an article about kinetics and physics (masses and forces, etc.). For instance, I’d never use “kg‑m” in Kilogram or some other article that discusses mass or is drawing a distinction between the properties of mass and force. And our Torque article likely needs to remain pure as the driven snow as to properly using units.
Perhaps, the very nature of trying to address this in a {convert} template dooms us to have these debates. Templates by their very nature tend to be an instrument that enforces project-wide consistency but project-wide consistency is not always best and editors who specialize in certain fields get rightly pissed when someone who knows nothing about the field ram-rods over the article with a new whiz-bang template. I had a premonition when I started out my first post on this thread that this discussion was going to end up with a metric ton of “Well… when you dig down into the details, it’s not all that simple.” Any thoughts? Greg L (talk) 20:36, 22 September 2009 (UTC)[reply]
To assist in the answering of question #1, a Gsearch for "kg-m torque" generates: 865,000; "kgf-m torque" generates: 154,000; "m-kg toque" generates: 763,000. So by these numbers, kg-m is the clear winner for commonality. I still think ft-lb is more common that lb-ft too. ɠu¹ɖяy¤ • ¢  20:30, 22 September 2009 (UTC)[reply]
  • I don’t think a universal {convert} template will work here, Gu1dry. What is scientifically pure and entirely suitable for our Torque article will look like the rod up its ass has a rod up its ass in an article like Bolt. A convert template that offers the sort of flexibility required for all uses everywhere on Wikipedia would, IMO, need to provision for several different styles of unit symbols and provide lots of guidance to editors instructing them on best practices. Would you agree? Are you thinking this {convert} template might be directed only to the “industrial” crowd and not for physics? Greg L (talk) 20:36, 22 September 2009 (UTC)[reply]
There is a guideline for convert, it's on the main Template:Convert page. From my PoV the main usage for the torque conversion within {{convert}} is for vehicles or more specifically engines within said vehicles. And from this concussion this is directed more towards industrial usages than physic usages. For example, I'm more comfortable with ft-lb, it's what I have used for years & it's what I understand the most due to my mechanical tinkering background with cars with US standard listings & with the help convert template, vehicles can use the {{convert}} to convert torque measurements so anyone can understand the torque measurement in which ever background they come from. ɠu¹ɖяy¤ • ¢  20:48, 22 September 2009 (UTC)[reply]

The template is not meant only for science articles. Only a few articles use this obsolete unit. The template is currently flexible enough to allow the option of "kilogram-metres" and no "f" in the abbreviation.

Changing the default outputs for torque units is a different question. Having them include kilogram (force)-metres would be a bad idea but there's no such proposal at template talk:convert. JIMp talk·cont 20:59, 22 September 2009 (UTC)[reply]

(outdent)

  • Then I think that to get buy-in from purists, gu1dry, the challenge is to make it clear in the documentation what exactly the intended use for the template is. The documentation needs to be very explicit that the unit symbols follow the most common, industry-wide vernacular for industrial-type disciplines, which is not suitable for physics and other scientific uses. I have every confidence that you, gu1dry, are planning on doing the right thing for the intended use. The only remaining challenge is to ensure that this “intended use” and its attendant limitations is very clearly spelled out so editors like Jimp don’t fear the prospect of watching as highly-technical articles get mucked up as less-informed editors skate on through giving them “the {convert} treatment.” When limited to the uses you envision, what you are making seems sensible; will make editors’ lives easier; and will produce natural looking, familiar units of measure that don’t cause confusion and don’t draw attention to the writing style as information is being conveyed.

    I see that you, Jimp, are suggesting that the template is also suitable for science-related articles. If so, then the challenge is to get all the *truly proper* forms in as well as the *real-world industrial* forms and to provide succinct and clear guidance on how to use the template. Greg L (talk) 21:14, 22 September 2009 (UTC)[reply]

It currently supports both. ɠu¹ɖяy has been putting Template:Convert/list of units/torque together. JIMp talk·cont 21:28, 22 September 2009 (UTC)[reply]

So which abbreviations have we come to a consensus to & which approach should we take on this exactly, because I'm not completely clear on the current stance we are at. ɠu¹ɖяy¤ • ¢  21:33, 22 September 2009 (UTC)[reply]

I don't think we have consensus on whether to allow "kilogram-metres" and "kg·m" in articles or not. Of course "kilogram force-metres" and "kgf·m"/"kgf·m" should be allowed and how to use them in the template should be documented on the template doc page. JIMp talk·cont 21:45, 22 September 2009 (UTC)[reply]
  • I don’t have the time to get myself involved in the minutia. Sorry I can’t help you more. I encourage you, Jimp, to be more inclusive and less proscriptive. First off, I’m (half) on your side; we can’t have non-scientific units of measure in science articles. But I also entirely agree with gu1dry, that we can’t have awkward looking prose for industrial-related articles.

    This isn’t even always a “this vs. that” issue; there are shades of gray. Whereas “ft‑lb” might be particularly suitable for automotive and industrial, purposes, if one were discussing motor torques on ski lifts, “lb‑ft” may be more appropriate. In an article on the polar moment of inertia of the Saturn V moon rocket, a torque of “lbf·ft” or something like that might be more appropriate.

    I can certainly tell you from having horsed around on 250 kV Mitsubishi circuit breakers that are as big as a VW van (and Hitachi and Siemens, etc.) that there are a wide variety of practices with lots of units of measure. These practices apply also to pressures in a fashion that—once again—drags the kilogram into units of measure where it is employed as a unit of force. You can find “kg/sq cm”, “kg‑f/cm2, and all sorts of things you would find to be abomination unto the eyes of the technology gods. We need to provision for lots of stuff because we can’t become instant experts in every niche discipline by sitting on our butts performing Google searches to prove this point or that. Greg L (talk) 22:11, 22 September 2009 (UTC)[reply]

Then I will propose this, I will break the torque table down into two categories, "Industrial" & "Scientific". Industrial will use ft-lb, kg-m & N·m, while Scientific will use ft-lbf, kgf-m & N·m. I will set it up where it will be different, yet still easy to use. ɠu¹ɖяy¤ • ¢  22:21, 22 September 2009 (UTC)[reply]

  • Not exactly. For scientific, the moment arm needs to always go second—otherwise you are making units of energy. I don’t know what’s best as far as middots and other details. To me, frankly, the subscripted f looks awkward and I wonder just how common that is. I propose you both think hard about getting a simple “f” or “‑f” in there. I would think that for scientific, the following: “kg‑f·m”, “lb‑f·ft”, and “N·m”. These three appear “least striking” to me; something on that theme, anyway. Greg L (talk) 22:31, 22 September 2009 (UTC)[reply]
I'm not really sure about scientific standards, so I'm completely open to suggestions for how to implement the force abbreviation into the mix. Once everything is agreed upon, I will draw up the standardization of torque measurements on both sides for Template:Convert & then I will allow Jimp to code, since I don't completely under the code with {{convert}}. ɠu¹ɖяy¤ • ¢  22:49, 22 September 2009 (UTC)[reply]
Template:Convert/list of units/torque Thoughts? ɠu¹ɖяy¤ • ¢  23:36, 22 September 2009 (UTC)[reply]
  • For non-scientific, I think what you have there is fine. For scientific, having “lbf” looks like there’s an “elbfph” unit of some sort out there. I personally think “kg‑f·m”, “lb‑f·ft” look best because there is lots and lots of real-world usage where a “dash-f” suffix is applied to kilogram and pound to denote that it is a unit of force due to said unit of mass being accelerated at one standard gravity. To me, these two examples I just provided look very un-noteworthy and don’t call attention to themselves, while at the same time, being 100% technically correct. I’ve revised the Template per my suggestion. Revert if you like. Greg L (talk) 00:32, 23 September 2009 (UTC)[reply]
The U.S. National Institute of Standards and Technology uses "lbf·ft" and "kgf·m" because these are unambiguous. The dot is used because it implies multiplication. They do not recommend using a hyphen - it would imply subtraction. I suggested using a subscript "f" rather than normal size because it is not a unit but a qualifier, but that is a matter of aesthetics. The trouble with "real-world usage" is that there seem to be a lot of different "real worlds", at least here on Wikipedia.RockyMtnGuy (talk) 01:29, 23 September 2009 (UTC)[reply]
  • You raise excellent points, RockyMtnGuy, and I disagree with none of it. The “industrial” versions are following most-common, real-world practices. If we are to have perfectly logical “scientific” versions, we best start with the NIST as our beginning point and stick with it unless someone can advance a good reason to depart from their guidance. Accordingly, I have revised the proposed template per your counsel. I haven’t touched the “combinations” section, as it has become a bit too convoluted for me to parse what all is going on there and what the intent is. Greg L (talk) 19:53, 23 September 2009 (UTC)[reply]
I have upgrade the table for the uniformity & issues within the text. If this is the final, I will update the short list. ɠu¹ɖяy¤ • ¢  20:44, 23 September 2009 (UTC)[reply]
I disagree that "it is not a unit but a qualifier". A kilogram-force is a different unit from a kilogram. A pound-force is a different unit from a pound-mass. There is no comparison to terms like "MWe" and "MWth" which (however much CIPM may frown upon them) use subscripts to qualify which kind of power is being described, but measure the power in exactly the same units. --Jc3s5h (talk) 02:02, 23 September 2009 (UTC)[reply]
How about we just use a small "f" instead of a subscript "f", due to a subscript "f" just looks out of place? ɠu¹ɖяy¤ • ¢  03:29, 23 September 2009 (UTC)[reply]

BTW: Why is our article on the “foot-pound” unit of energy titled Foot-pound force? Talk about misleading. What they mean is “Foot·pound-force (unit of energy)”. But that title has the connotation of “Foot-pound (force).” Not wise, IMO. I’d suggest simply “Foot-pound (energy)” and provide some redirects.

And, no, gu1dry, you don’t want to be linking to that one, regardless of whether someone fixes that title. It appears Wikipedia might not have a dedicated article on the unit of torque that would be titled something like “Pound-foot (torque)” Greg L (talk) 00:51, 23 September 2009 (UTC)[reply]

The article addresses foot-pounds as a form measurement for torque. So I'm not complete sure as to why it shouldn't be linked to. ɠu¹ɖяy¤ • ¢  01:11, 23 September 2009 (UTC)[reply]
  • Yes, I see that now. Sure; linking to that is better than nothing, I suppose. The article used to be primarily about the unit of energy and someone expanded it somewhere along the line with that bit about it also being a unit of torque. Really, we need to get these units separated into their own articles and properly titled. They would be “Foot-pound (energy)” and a separate article titled “Pound-foot (torque)”; not some hybrid, that essentially means “Foot-pound force (whatever unit of measure I.P. editors want it to be because it says so on my torque wrench I got from Harbor Freight Tools)”. Greg L (talk) 01:39, 23 September 2009 (UTC)[reply]
Articles have been separated; Foot-pound (energy) & Pound-foot (torque). ɠu¹ɖяy¤ • ¢  03:14, 23 September 2009 (UTC)[reply]
I added some top notes and other tweaks, including stub tags, to the separated articles. I would not normally support separation of such a short article on closely-related topics. However, I can see the argument that it makes them easier to understand, and it is certainly an easier platform for future expansion of the topics, as a writer wouldn't be continually disentangling the two measures. Great idea to link them both from the {{Convert}} template. --Hroðulf (or Hrothulf) (Talk) 11:07, 23 September 2009 (UTC)[reply]
Would it not be more straightforward to replace the redirect Foot-pound_force with a disambiguation page? Certainly the talk page redirects are a recipe for confusion.LeadSongDog come howl 15:37, 23 September 2009 (UTC)[reply]
Thank you to you all, Gu1dry, Hrothulf, and LeadSongDog. Greg L (talk) 19:40, 23 September 2009 (UTC)[reply]
  • Gu1dry, does “code” mean that someone would type that to get an output, or just chose it by clicking on selections from a list? I ask because the middot isn’t something that is easy to type. Greg L (talk) 21:09, 23 September 2009 (UTC)[reply]
Yes the code is what some types to get the output, for example: {{convert|45|mi|km}} (the bold is the code) would generate 45 miles (72 km). So you think for the code it should be a hyphen instead of a middot? ɠu¹ɖяy¤ • ¢  21:22, 23 September 2009 (UTC)[reply]
  • Certainly, yes. The code needs to be easily typed from a keyboard. Accordingly, simple hyphens (rather than a middot) is fine. And, from what I can see, there is no need for two codes for the newton-meter since both the industrial and scientific forms are identical. I would just code the one and only form for newton-meter as n‑m. Greg L (talk) 00:01, 24 September 2009 (UTC)[reply]
Newton meters needs to be coded twice, due to their measurement counterparts (kilogramforce-meters & foot-pound/pound-foot). ɠu¹ɖяy¤ • ¢  00:06, 24 September 2009 (UTC)[reply]
  • gu1dry, per RockyMtnGuy's post of 01:29, 23 September 2009 (UTC) and my response of 19:53, 23 September 2009, and (seemingly) your buy-in per your 20:44, 23 September 2009 post, we concluded that best practice on the scientific forms was to observe the NIST’s recommended form of a no-dash regular “f” and the use of a middot, not a hyphen. I see your reversion of my recent edit and understand now about the “code combinations”. But doesn’t the “abbreviations” need to be using the middot? Isn’t that showing what the output will be? Greg L (talk) 04:40, 24 September 2009 (UTC)[reply]
  • BTW, if I understand your intention for the column “abbreviation”, the proper term is “unit symbol”, which I’ve taken the liberty of correcting. I hope you don’t mind. Greg L (talk) 04:47, 24 September 2009 (UTC)[reply]
I have no problem with your liberty of correcting the table, but I corrected on of the headings to conform with the rest of the table/list. ɠu¹ɖяy¤ • ¢  05:08, 24 September 2009 (UTC)[reply]
  • I’m not going to change the column heading “abbreviation”. As I now understand it, you changed it back to “abbreviation” because there is some other area of Wikipedia to which you are trying to conform. Please let the template authors (or whoever/whatever they are), know that unit symbols are not “ abbreviations.”

    Here’s the terminology:

  1. Measures are things like volume, length, temperature, and mass.
  2. Units of measure are liter, meter, degree Celsius, the kelvin, ohm, pound, and kilogram
  3. Unit symbols are l (or L) for the liter, m for meter, °C for degree Celsius, K for kelvin, Ω for ohm, lb for pound, and kg for kilogram.
In the metrology world, unit symbols are not called “abbrevations” because they aren’t abbreviations. The symbol Ω is not an abbreviation for ohm, nor is lb an abbreviation for pound. Certainly, “pnd” could be called an abbreviation for pound, however, all these symbols are just that: symbols, even if °C has a “C” in it and appears to be an ultra-abbreviation for “Celsius.”
Please pass this along so we don’t have lots of templates misleading editors about basic terminology. When they get all that stuff in order, then maybe you can correct the “torque” template too. Greg L (talk) 17:18, 24 September 2009 (UTC)[reply]
All of it is right here: Template:Convert/list of units ɠu¹ɖяy¤ • ¢  19:04, 24 September 2009 (UTC)[reply]

Let's end the MoS/MOSNUM duplication

There appears to be widespread but vague sentiment against the duplication of scope in the two style guides, because it's a recipe for contradictions to develop, and fragments dialogue about the overlapping part of the scope.

Again, I put it to you that MOSNUM should deal with specialised guidance alone, in these areas:

  • Uncalibrated (bce) radiocarbon dates
  • Some of the calendar section (?)
  • Time zones (if retained at all)
  • Delimiting (but a short summary to be inserted into MoS)
  • Natural numbers
  • Repeating decimals
  • Non-base-10 notations
  • Scientific notation, engineering notation, and uncertainty (but a short summary in MoS)
  • Avoiding ambiguities (it's already in shortened form in MoS)
  • Most of "Units and symbols often written incorrectly"
  • Quantities of bytes and bits
  • Adopting suggestions from standards bodies
  • The table from "Common mathematical symbols" (?unsure)
  • Geographical coordinates

I intend to create a draft of this. Tony (talk) 08:48, 23 September 2009 (UTC)[reply]

I oppose, on the grounds that some statements can only be understood in the context of surrounding statements. If the surrounding statements are on a different page, they will have to be repeated. This will create an uneven degree of repetition in MOSNUM, which will create confusion. --Jc3s5h (talk) 16:31, 23 September 2009 (UTC)[reply]
  • Support What Tony proposes makes perfect sense. There is no reason in the world for those portions of any manual of style that deal with the fundamentals of dates and numbers to be separated out. Putting the highly specialized stuff in their own sub-sections make sense to me. We should take a closer look at this. I think Tony has done a fabulous job of making the essentials of dates and numbers very succinct. Greg L (talk) 19:56, 23 September 2009 (UTC)[reply]
Oppose. MOSNUM should be a complete guide. In addition, as stated by Jc3s5h, duplication will often be required to contextualise the specifics, which would lead to a somewhat disjointed guide. What is needed is better synchronisation between the two guidelines. wjematherbigissue 20:02, 23 September 2009 (UTC)[reply]

I agree that there's too much duplication, but removing all of it would have the problems which Jc3s5h and Wjemather described. If a section is in MOSNUM, then MOS should have only a short summary of it, addressing only the aspects of it which one needs to look up more often, and possibly should have a clear indication of what is a summary and what is the "master" section: for example

<-- This section is a summary of [[WP:MOSNUM#Currencies]]; make sure that any edit to this section represents the section on WP:MOSNUM faithfully. If you want to change the actual content of the guideline, discuss it at WT:MOSNUM. -->

at MOS, and

<-- [[WP:MOS#Currencies]] is a summary of this section. When making significant edits to this section, please update the summary at WP:MOS accordingly. -->

at MOSNUM. (Now there's such a comment at the top of MOSNUM, but it should be put at the top of every section having a summary at MOS, so that people editing single sections will read it as well. Also, the "summaries" at MOS should be much shorter than they are; here's my take.) --___A. di M. 00:10, 24 September 2009 (UTC)[reply]

Nothing wrong with duplication, only with conflict. Rich Farmbrough, 11:24, 27 September 2009 (UTC).[reply]