Wikipedia talk:Manual of Style/Dates and numbers/Archive 126

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 120

←

Archive 124

→

New-look Manual of Style

A few weeks ago there was extensive discussion on FAC talk about the vast size, complexity and instability of the Manual of Style. On reviewing the text of the MoS, I agree that the Manual is much larger than necessary to cover the areas it does: about 20 thousand words. In particular:

it is often wordy;
it provides more examples than necessary;
it lectures around some of its points in a way that is not strictly necessary;
it is a little repetitive and disorganised.

As a service to featured-content nominators and reviewers, and editors at larger, I've created a new, user-friendly version of the MoS that is only 40% of the size of the full version. There are no intended changes in substantive meaning. The new version has the following features:

brevity and directness of language, including the default use of active voice and contractives;
new inline headings for every point, for ease of navigation;
the removal of highly specialised points about numbers and dates, which are treated by MOSNUM;
the removal of a few other sections that appear to be on the fringe, including Blason;
the addition of a Currency section, summarised from MOSNUM.
improvements in structural organisation;
the use of links by asterisk, to reduce clutter.

Any changes to the full MoS as reflected in the new version will be notified, at the start of each month. Your feedback is welcome on the talk page.Tony (talk) 03:04, 16 September 2009 (UTC)

WP:OTHERDATE

Please abide by consensus

Jc3s5h, your edits were contrary to the results of the RfC you yourself conducted here on Archive 123. The {val} template was the result of very lenghty, months-long discussions by very many editors on both WT:MOS and WT:MOSNUM.

{Val} (originally known as “Delimitnum”) had its functionality described here in WT:MOSNUM Archive 94…

…it was extensively discussed and voted upon here in WT:MOSNUM Archive 94…

…and was well received here on WT:MOS Archive 97…

…where its functionality was tweaked to achieve a compromise solution that made everyone happy on an issue regarding the look of scientific notation.

Then a number of developers and template authors worked on it.

Please don’t presume that you can come along and change it without a proper consensus. Greg L (talk) 17:17, 18 August 2009 (UTC)

Greg L misinterprets the results of the RFC. While the Val template is generally acceptable in that it can be altered to accommodate almost any format for which there is consensus, Greg L is the only one who considers the commas-left, thin-spaces-right format to be the best choice. A few others considered it acceptable but not superior to other choices. The outcome of the discussion was to avoid the commas-left, thin-spaces-right format. Val should be modified accordingly.

I also call upon Greg L to abide by the argument he has often made with respect to binary prefixes (that is, follow external consensus rather than advocate formats that have not achieved external acceptance, and choose a format that has at least limited acceptance outside of Wikipedia to a format that has no acceptance at all outside Wikipedia. --Jc3s5h (talk) 18:34, 18 August 2009 (UTC)

You must not have read the links I provided, above; they show widespread, overwhelming support for {val}. The consensus (not just me) on Wikipedia is that the techniques {val} uses for scientific notation and long strings is a good one that causes zero confusion. If you don’t like it, don’t use it. But please stop trying to delete mention of it or discourage its use. It serves a valuable purpose in technical articles. Greg L (talk) 18:44, 18 August 2009 (UTC)

Delimiting numbers

(no longer beating around the bush here): One source of periodic friction on MOSNUM is the delimiting of numbers. There are four or even five different ways of doing so. In Sweden, they teach school children three different methods (and two of them are “Swedish 1” and “Swedish 2”). To make a long story short: Wikipedia allows both British and American-dialect English (spelling) in its articles, so long as they are consistent within an article. However…
This practice of “your way / my way… it’s all just six of one / half a dozen of the other” doesn’t apply to numbers. Why? Wikipedia has gone through all this before many times, and new editors who come here don’t have the benefit of all that history and discussion. But it comes down to this: English-speaking Europeans are familiar and comfortable with a many different ways of delimiting numbers and the American style causes them no confusion whatsoever. Comma-delimiting might not be the most common practice for English-speaking Europeans, but they recognize what it means and fully understand the numbers. However, Americans are familiar with one and only one method; as a group, they have had no exposure whatsoever to other ways of delimiting numbers. So, especially for general-interest articles, in order to cause the least confusion, the American method of using commas to the left of the decimal point is to be used on Wikipedia. Scientific articles; particularly ones directed to a professional readership, are the only exception.
The argument that “Well, Wikipedia will just start using the Euro/BIPM method and dumb-ass Americans will simply learn” just doesn’t fly and it never will. Wikipedia doesn’t have that kind of influence; all that sort of attitude does is produce confusion. Our aborted attempt to push the world into the adoption of the IEC prefixes (kibibytes and KiB) amply demonstrated that. After three long years, the practice was no more well adopted throughout the world than before. All Wikipedia accomplished by letting itself by hijacked by a handful of editors who wanted to push the world into a new and brighter future with warp drive and membership in the United Federation of Planets™®© was to make our computer-related articles needlessly confusing. We follow the way the world works and can not presume to lead by example.
We can’t have MOSNUM subtly edited in a fashion that tacitly allows numbers in articles, other than science-related ones, to be delimited with thinspaces in place of commas to the left of the decimal point; it is unnecessarily confusing to too many readers. This is the way it has long been done and there has been no decision to change the practice.
As for delimiting with gaps to the right of the decimal point using {val} on high-precision numbers, particularly in engineering and scientific-related contexts where the distinction between numbers is important and the values actually have to be parsed and understood, that confuses absolutely no one—even “sheltered Americans”. A value like 1.6162523625×10⁻³⁵ meters is no more confusing than the decidedly non-SI-compliant, five-digit delimiting used for mathematical constants (particularly in tables of constants), such as 3.141592653589793238462643383279...; everyone instantly “gets” it. It is a much-appreciated and much-needed touch that makes long strings of digits much easier to parse. Moreover, its technique of using thinspaces to the right is the only possible method that could be employed to solve the problem of long strings without upsetting the apple cart; it was either do nothing (and have absurdly long strings that can’t easily be parsed) or utilize the only logical available technique. Greg L (talk) 18:28, 18 August 2009 (UTC)

My position is that using thin spaces to both the left and right of the decimal when an article contains one or more numbers with 5 digits to the right of the decimal is preferable to Wikipedia making up its own format. It also my position that the practice of using thin spaces to the right and commas to the left looks especially asinine in the case of a number like 4,046.8564224. I will not change my position unless a reputable external source, such as a major style guide, which supports the 4,046.8564224 format, is cited. --Jc3s5h (talk) 21:22, 18 August 2009 (UTC)

That’s perfectly fine, Jc3s5h. Don’t write it that way then. A number like 4046.8564224 is rare anyway. With that much precision, such numbers will often be in scientific articles where scientific notation might be more appropriate. Amongst all the above-cited discussions in the archives, there was another editor who felt as you do. We go with the consensus here on Wikipedia and the approval of {val} was (very) lopsided. The guideline advising editors that numbers like 1.6162523625 × 10⁻³⁵ meters are hard to parse and they should consider using 1.6162523625×10⁻³⁵ m is a sound one because it makes Wikipedia easier to read and understand. Greg L (talk) 21:44, 18 August 2009 (UTC)
- Thank you; as long as this is phrased so as to be clear that the answer to "I don't like 4,046.8564224" is "Don't use it then", not "MOS breach! MOS breach! shun this start-class article", a recommendation backed by a lopsided majority should be fine, and harmless. The present use of may be seems to achieve that, but I would value Jc3s5h's opinion. Septentrionalis PMAnderson 00:09, 19 August 2009 (UTC)

(unindent) When Pmanderson asks whether the present use of may be, I surmise he is asking about this section:

Numbers with more than four digits to the right of the decimal point, particularly those in engineering and science where distinctions between different values are important, may be separated (delimited) into groups using the {{val}} template, which uses character-positioning techniques rather than distinct characters to form groups. Per ISO convention (observed by the NIST and the BIPM), it is customary to not leave a single digit at the end, thus the last group comprises two, three, or four digits. Accordingly, the recommended progression on Wikipedia is as follows: 1.123, 1.1234, 1.12345, 1.123456, 1.1234567, 1.12345678, 1.123456789, etc. Note that {{val}} handles these grouping details automatically; e.g. {{val|1.1234567}} generates 1.1234567 (with a four-digit group at the end). The {{val}} template can parse no more than a total of 15 significant digits in the significand. For significands longer than this, editors should delimit high-precision values using the {{gaps}} template; e.g. {{gaps|1.234|567|890|123|45}} → 1.2345678901234567.

Let us set aside my objection to the 4046.8564224 format for the moment; whether my interpretation or Greg L's interpretation of consensus prevails will become apparent in due course. The present version of the guideline states, or at least strongly implies, that the Val template conforms to "ISO convention (observed by the NIST and the BIPM)", but the template at present does not conform to the ISO convention. Furthermore, every example in this section has exactly one digit to the left of the decimal, so the non-conformance is concealed.

This is a falsehood. I don't think it has been pointed out until now, so it is an innocent falsehood. But over time, as the falsehood becomes better understood among editors of this guideline, it could ripen into a lie. --Jc3s5h (talk) 00:28, 19 August 2009 (UTC)

If there is a question of fact (assertions of fact are generally undesirable on guideline pages, because it provokes exactly this sort of discussion), would both of you provide citations? Septentrionalis PMAnderson 00:34, 19 August 2009 (UTC)

Alternatively, can Jc3c5h propose a text which supports the use of {{val}} - commonly but not without exception - but does not make those claims of fact?
Is GregL willing to consider such a text? Septentrionalis PMAnderson 00:37, 19 August 2009 (UTC)

In response to Pmanderson's request for a citation, the BIPM brochure setting for the International System of Units states "for numbers with many digits the digits may be divided into groups of three by a thin space, in order to facilitate reading. Neither dots nor commas are inserted in the spaces between groups of three."

As for proposing a text supporting the use of {{val}}, I don't support that template at all until it is modified to not allow commas and thin spaces in the same number. (I have no objection to a version that provides a parameter to choose between the BIPM format and the customary American format.) --Jc3s5h (talk) 00:50, 19 August 2009 (UTC)

I see that citation does address how to handle 4 digits (make a single group of 4); but one issue between you is how to handle 8 digits. {{Val}} divides them IIUC 3, 3, and 2; what would you do, and can you cite it as ISO? Septentrionalis PMAnderson 01:14, 19 August 2009 (UTC)

Septentrionalis, I suspect you are missing the point. Looking at 8 digit numbers, 1234.678 is fine. The format 12345678 is fine if the article does not contain any numbers with 5 or more digits to the right of the decimal. The formats 12345678 and 0.12345768 should not appear in the same article. The formats 12345678 and 0.12345768 in the same article are fine. --Jc3s5h (talk) 01:29, 19 August 2009 (UTC)

Let me get this straight. Either commas or gaps, not both. That still leaves several possibilities to object to. Do you object to

The use of gaps and commas in the same article?
The use of gaps and spaces in the same number?
The claim that (which of the above?) is ISO?
All three?

Are you willing to let Greg use his preferred format, if you can use yours? Septentrionalis PMAnderson 01:41, 19 August 2009 (UTC)

My two cents: there's no problem if the lead of LHC reads "over 10,000 scientists and engineers" and a paragraph deep down inside it says, "At this energy the protons have a Lorentz factor of about 7500 and move at about 99.9999991% of the speed of light." They are different contexts: the former is something even my grandmother could read (if he spoke English), the latter is an advanced technical detail. But I'd prefer avoiding both styles in the same contexts: after all, contexts in which you want to use the traditional American style not to confuse American readers are very, very, very unlikely to contain any number with a large number of digits after the decimal point. (Personally, when I see a number with more than three significant figures I ask myself where the hell the last ones were taken from, and if I can find no answer, that confuses me much more than an unfamiliar format would.) These generally occur in scientific and engineering contexts, where using thinspaces is OK. Of course, these are generalizations and exceptions may occur. --___A. di M. 02:16, 19 August 2009 (UTC)

In response to the items questioned by Septentrionalis,

The use of gaps and commas in the same article? ~~Object~~ Neutral.
The use of gaps and spaces in the same number? ~~Strongly~~ Object
The claim that (which of the above?) is ISO? The claim that {{Val}} conforms to ISO/BIPM/NIST format is not compatible with the use of the comma as a separator at all. This wording will have to change if {{Val}} is capable of using commas as a separator.

I do not support the use of made-up formats when an acceptable format is already in use in non-Wikipedia publications. Gaps and spaces in the same number is certainly a made-up format. ~~Mixing numbers with commas and numbers with spaces in the same article is, in my view, also a made-up format, but I suppose others could argue to the contrary.~~ --Jc3s5h (talk) 02:09, 19 August 2009 (UTC)

Greg? The third bullet point above is a call for citation; please give one. I cannot help with this otherwise without proposing a compromise text, and I do not see one. If one of you bends to the breaking point, the other may see the result as marginally acceptable. Septentrionalis PMAnderson 02:14, 19 August 2009 (UTC)

Quoting Jc3s5h: The present version of the guideline states, or at least strongly implies, that the Val template conforms to "ISO convention (observed by the NIST and the BIPM)". Fact: It does (and says) no such thing. Read the text. It says as follows:

Per ISO convention (observed by the NIST and the BIPM), it is customary to not leave a single digit at the end, thus the last group comprises two, three, or four digits.

It’s 1.2345678, not 1.2345678. That’s what it says. That’s all it says.

Following the logic of Jc3s5h, if there are any numbers in an article that have the right hand side delimited (for clarity of parsing), then that gives him carte blanche freedom to use spaces to the left of the decimal point. Perhaps. But only if the article is on a scientific subject. There is no reason for this majorly-conflicted dilemma. It seems Jc3s5h rather wants to expand the Euro-style way of delimiting and is exploiting the existence of {val} to push this view. That would be a mistake if it’s the case. But, if it’s just a matter of WP:IDON'TLIKEIT, then don’t use it, because many others do like it.

Count the number of readers who are confused by the use of {val} on Kilogram. Zero. Zip. Count the number of readers who would be unnecessarily confused if we expanded the use of comma delimiting outside of the realm that it is currently limited to (science). How many American readers are going to be baffled if we started delimiting with thinspaces to the left of the decimal marker?? A metric butt load; that’s how many. It would be foolhardy to contemplate any such change. Like A. di M. wrote, above, …there's no problem if the lead of LHC reads "over 10,000 scientists and engineers" and a paragraph deep down inside it says, "At this energy the protons have a Lorentz factor of about 7500 and move at about 99.9999991% of the speed of light." Even his grandmother wouldn’t be confused.

And, Jc3s5h, don’t bother quoting how the BIPM says numbers ought to be delimited to the left of the decimal marker in documents for a world-wide audience. That isn’t the first advise from the BIPM that Wikipedia (and the rest of the world ignores) and it won’t be the last. Notably—perhaps very unfortunately—America ignores that advise. Perhaps you find that to be an unfortunate shame. I might agree with you. Perhaps you think we will Make the world a better place by leading by example.®™© No. That is not what Wikipedia can or should do. This flouting of standards applies to the IEC and many other standards bodies: sometimes proposals fly like a wet noodle. However, the good ones that solve a problem rapidly gain traction in the world. And when the rest of the world changes, Wikipedia will follow suit. Note also, en.Wikipedia is not intended to be read by all cultures throughout the world; just English-speaking ones (either first or second language). As I’ve patiently explained above, the rest of the English-speaking world “gets” the American-style way of delimting. However, Americans don’t “get” other ways of delimiting. Not… in… the… slightest. That’s why en.Wikipedia has adopted the comma to the left. Please accept that and stop seizing on {val} as a reason why thinspaces ought to be expanded. Greg L (talk) 03:07, 19 August 2009 (UTC)

The idea behind Wikipedia allowing the BIPM method of delimiting in its science-related articles was borne out of the fact that professional, peer-reviewed articles in science are typically written that way, as required by the manuals of style of the respective journals. They have an international audience and the journals try to make the papers as easy to digest for an extraordinarily wide, professional audience. The “science” exception has often been used as a window of opportunity to be exploited by some Wikipedians in an effort to expand the practice into just about anything (“well… water is a ‘sciency’ subject.”).
IMHO, the objective on Wikipedia should always, always be about writing in a way that is clearest and causes the least confusion. There are many distasteful practices that come with that philosophy, including using feet and inches and pounds in American-related articles like Boston Red Sox. Too often, editors want to do things a certain way because… well… editors simply like doing it that way and always have done it that way. It ends up being more about writing to please the Wikipedian rather than do what is best for the readership. Greg L (talk) 04:35, 19 August 2009 (UTC)

A break after the boxed sentence puts ISO and {{val}} into different and shorter paragraphs; that should remove any implication of connection where none is intended. Septentrionalis PMAnderson 00:59, 21 August 2009 (UTC)

I was trying to think of something that would remove (or at least greatly reduce) the implication without being too bulky. This is an elegant change. --Jc3s5h (talk) 01:05, 21 August 2009 (UTC)

Proposal

To resolve the issue I offer a two part proposal:

Part 1: {{Val}} is altered so that by default, it produces commas to the left and no separation to the right of the decimal point (customary American style). A parameter is added, BIPM=y or yes which produces thin space separators on both sides of the decimal point.

Part 2: The "Delimiting (groups of digits)" be altered to read as follows:

Numbers with five or more digits to the left of the decimal point; i.e. 10,000 or more, should be delimited (separated into groups so they can be easily parsed visually) using commas every three digits; e.g. 12,200 and 255,200 and 8,274,527 etc. Exception: articles containing numbers with five or more digits to the right of the decimal point, e.g. 3.141593 (as such articles should delimit numbers as for scientific articles—described below).

Numbers with four digits to the left of the decimal point may be delimited with a comma; that is, there were 1250 head of cattle and there were 1,250 head of cattle are both acceptable. The same exception as for five digits to the left of the decimal point applies.

Numbers are not delimited when they are part of mailing and shipping addresses, page numbers, and years with four or fewer digits. Years with five or more digits (e.g. 10,400 BC) shall use commas.

In scientific articles, particularly those directed to an expert readership, numbers may be delimited with thin spaces using the {{gaps}} template. Coding {{gaps|8|274|527}} produces 8274527 (note: the thin space character and its HTML entity, , do not render correctly on some browsers). Articles containing numbers with five or more digits to the left of the decimal point should delimit numbers with thin spaces.

The style of delimiting numbers should be consistent throughout an article.

Mathematical constants in math-oriented articles may be grouped into groups of five; e.g. 3.141592653589793238462643383279....

Numbers with more than four digits to the right of the decimal point, particularly those in engineering and science where distinctions between different values are important, may be separated (delimited) into groups using the {{val}} template, with the BIPM parameter set to "y" or "yes"; {{val}} uses character-positioning techniques rather than distinct characters to form groups. Per ISO convention (observed by the NIST and the BIPM), it is customary to not leave a single digit at the end, thus the last group comprises two, three, or four digits. Accordingly, the recommended progression on Wikipedia is as follows: 1.123, 1.1234, 1.12345, 1.123456, 1.1234567, 1.12345678, 1.123456789, etc. Note that {{val}} handles these grouping details automatically; e.g. {{val|1.1234567}} generates 1.1234567 (with a four-digit group at the end). The {{val}} template can parse no more than a total of 15 significant digits in the significand. For significands longer than this, editors should delimit high-precision values using the {{gaps}} template; e.g. {{gaps|1.234|567|890|123|45}} → 1.2345678901234567. Also note that when the BIPM parameter is omitted, {{val}} does not conform to the ISO/NIST/BIPM format; instead it uses the customary American format of grouping digits to the left of the decimal with commas, and not grouping digits to the right of the decimal.

--Jc3s5h (talk) 03:01, 19 August 2009 (UTC)

As I said above, there is well established reason why en.Wikipedia uses commas to delimit numbers to the left of the decimal point: it results in the least confusion in our readership. Please stop using {val} as an excuse to advocate that we diverge from this well-entrenched principle. If you don’t like {val}, don’t use it. It solves a legitimate problem when you have really long, hard-to-parse strings of numbers to the right of the decimal point. It is not a vehicle to be used to try to use Wikipedia to enlighten Americans to the One True Way that numbers really ought to be delimited. Greg L (talk) 03:12, 19 August 2009 (UTC)

I reject the claim, unsupported by any scientific survey or by adoption by any external publication, that commas to the left of the decimal point and thin spaces to the right are less confusing than a format that uses the grouping method, thin spaces, on both sides of the decimal. --Jc3s5h (talk) 03:17, 19 August 2009 (UTC)

Well, you clearly aren’t familiar with America, are you? How many methods of delimiting numbers do you think American school children are taught? Just one. In Sweden, they teach elementary kids three different techniques, including the American method. You are certainly free to choose to believe what you want to believe. Greg L (talk) 03:23, 19 August 2009 (UTC)
P.S. I’ve been to England, Scotland, Wales, Ireland, Antigua, Moroco, Spain, Monaco, France, Italy, Austria, and Hungary—and Canada, if you can count that as not being part of the U.S. ;-). Notwithstanding that I am American, I do all my engineering in hard metric. Have you been to the U.S.A? If so, how long? Because, as an engineer, I can assure you I have keen insight into what causes confusion in Americans. The current practices of Wikipedia were no accident. Greg L (talk) 03:42, 19 August 2009 (UTC)

I have found that the current edition of the U.S. Government Printing Office Style Manual, in rules 12.9e and 12.14, calls for the use of commas to the left of the decimal and ~~thin~~ spaces to the right. (Although the manual does not say "thin spaces", the spaces in their example look thin to me.) Therefore I withdraw my contention that this is a made-up format. This manual does not address the question of what to do when one number has 5 or more digits to the left of the decimal, and also 5 or more digits to the right of the decimal. In most cases this could be handled by putting the number in scientific notation. --Jc3s5h (talk) 04:31, 19 August 2009 (UTC)

Jeez! I didn’t know that. That was big of you. You did the homework and declared an “inconvenient truth” that I didn’t even know about. Damned big of you; I’ll remember that. Like the guideline says, editors may use {val}. If you think it is important for readers to be able to easily parse the digits to the right of the decimal point in a particular value, and if scientific notation doesn’t seem suitable for some reason, then use {val}. Otherwise, don’t. Cheers. I’m done for the evening. Greg L (talk) 04:43, 19 August 2009 (UTC)

I think that the proposed changes to {{val}} would be straightforward and reasonable.
As for the proposal, it's on the right track—but let me raise some issues. I think the current text is a bit cumbersome, in that it has a lot of exceptions and places where the text diverges into subcases. I think we can state the exceptions a little more clearly, and make them general in application.
There's also the question of whether to treat the U.S. and BIPM delimiting schemes as similarly-acceptable, or not. I don't buy the idea that Americans don't understand the BIPM format—any literate English speaker ought to be able to figure out the meaning of either the U.S. customary or BIPM formats (or for that matter the meaning of an undelimited number), with minimal effort. (And for subsequent occurances, zero effort.) It's not a significant issue of understanding at all—it is straightforwardly stylistic. And given that an English-speaking Canadian or European would probably default to the BIPM format, and would certainly understand it, it's not appropriate to direct those users to use an unfamiliar method despite the conventions of English-language style that are typically employed in their regions. (It's the same can of worms as telling them to spell it color instead of colour, or vice versa.)
It also follows that there needs to be an exception for special regional contexts that would be unintelligible to the majority of English speakers, but which are still in widespread use. (This particular exception could use further discussion, and might be relevant in so few cases as to be omitted, but I'll suggest something below anyway.) For example: English is a second language of hundreds of millions of Indians, Pakistanis and Bangladeshis, and they often use the Indian numbering system when communicating in English. For articles specifically about an Indian topic, if we're to be faithful to the idea of avoiding regional bias, we have to acknowledge that their method is widespread enough to consider in the MOS.
There's also the matter of splitting the technical details out into their own subsection. I think things were getting a bit convoluted with the mixing of implementation details with stylistic concerns, so I think that we should separate them from the main text.
So with that in mind, I've spliced portions of the various versions of this section (by Greg L, Jc3s5h and myself) together, and come up with this:

===Digit grouping===

In numbers with many digits, digit grouping symbols (inserted at intervals from the decimal point) are used to subdivide the number into easily readable groups. The acceptable digit grouping schemes are:
Commas every three digits to the left of the decimal point, and thin, non-breaking spaces every three digits to the right of the decimal point (e.g. 8,274,527 or 0.12345). This is traditional usage in many English-language contexts, and recommended by the U.S. Government Printing Office.

Thin, non-breaking spaces every three digits (e.g. 8274527 or 0.12345). This format is suggested in BIPM and NIST style guides for scientific and engineering works, and is in common use in interlanguage contexts.

Mathematical constants in math-oriented articles may be grouped into groups of five digits on both sides of the decimal point; e.g. 3.141592653589793238462643383279....

Other traditional digit grouping schemes, when relevant to the subject matter of the article; e.g. 82,74,527 in the Indian numbering system. (An explanation of the digit grouping scheme should be provided, typically by way of a link or brief summary. Also or instead, parenthetical conversions to another acceptable scheme may be used.)

The style of grouping digits within numbers should be consistent throughout an article.

When grouping digits by threes, and a number has exactly four digits on any side of the decimal separator, those digits may optionally be expressed as a group of four instead of three; e.g. both 9876 and 9,876 are acceptable.

Digits are not grouped when they are part of addresses, page numbers, and years with four or fewer digits. However, years with five or more digits (e.g. 10,400 BC) are delimited as any other large number.

====Technical implementation====
The {{gaps}} template uses CSS to output thin spaces (using the syntax {{gaps|8|274|527}}). Using HTML entities for this purpose (e.g. or  ) may cause rendering problems in some browsers, and should be avoided when practical.
The {{val}} template handles digit grouping automatically, in the American style (by default) or in the BIPM style (by using the BIPM=y parameter). In both cases, CSS is used to output the thin spaces. For example, {{val|1.1234567}} generates 1.1234567 (with a four-digit group at the end). The {{val}} template can parse no more than a total of 15 significant digits in the significand. For significands longer than this, editors should manually delimit values using the {{gaps}} template; e.g. {{gaps|1.234|567|890|123|45}} → 1.2345678901234567.

TheFeds 07:08, 19 August 2009 (UTC)

Good, except for a few points:

To address Greg's concerns about the "BIPM" system, you might consider to add something like In some major English-speaking countries, this format is unfamiliar most persons without advanced scientific or engineering education, so avoid using it in general-interest topics.
I'd replace "throughout an article" with "within a context": as I said above, the lead of LHC is a general-interest topic (as it made major appearances in the media last year), and so you'd want to use the "American" style; the sections about technical details are advanced scientific topics, and so you'd want to use the "BIPM" style. (Probably a better example than that could be found.) BTW, in the former type of contexts you'd seldom use numbers with more than three or four significant figures anyway (if you do, you're likely to be breaching the second bullet in "Large numbers"), ~~so issues of long strings of digits won't occur~~; and laymen are unlikely to want to read stuff in the latter type of contexts.
Don't see the point of making {{val}} use the "American" style by default. It is a template with facilities for scientific quantities and it is far more likely to be used for the mass or magnetic moment of the electron than for the population or GDP of the US: the latter type of numbers are normally hard-coded in articles without using templates. (BTW, look at the last example. I'm going to fix it in the actual MoS text where it's also found, but I don't generally edit other people's comments.) --___A. di M. 12:24, 19 August 2009 (UTC)

I hadn't read that the "American" style does include spaces after the point. Given that, the "long string of digits" issue is moot, so the grounds for replacing "throughout an article" with "within a context" are weaker than I believed: 99.9999991% conforms to the "American" style, too. --___A. di M. 15:07, 19 August 2009 (UTC)

(unindent) As one of the guys who take care of the {{val}} template, the sensible solution as far as the template is concerned is to leave the default behavior of {{val}} as-is, because otherwise you will screw up a million articles and remove the ease of using {{val}} in >90% of cases. Then for all those who hate gaps, or hate commas, two parameters can be added, |gaps=no (producing 1,232,345.0023234) and |commas=no (producing 1232345.0023234). You can then write exactly what you want, and you'll have the choice of picking whichever format is best suited for the article.Headbomb {^ταλκ_{κοντριβς} – WP Physics} 15:18, 19 August 2009 (UTC)

"Scientific articles; particularly ones directed to a professional readership, are the only exception."

... plus mathematical articles, articles about technology (computing, etc.), articles about measurement, etc.

I have to say that I've never really been a fan of the commas+gaps hybrid formatting that val uses. I'd rather have either gaps+gaps or commas+nogaps consistently throughout the article perhaps with a few exceptions based on context as mentioned above.

Rather than having the default behaviour of {{val}} produce 1,232,345.0023234, I'd have it produce 1232345.0023234 but that's my preference & would probably not be what many would consider appropriate in many cases.

However, I'd be happy with the suggestion by Headbomb. Between three and four thousand pages use the template, many maths/science/technology related, many not. It wouldn't be impossible to send a bot round adding |gaps=no and |commas=no where appropriate.

On the other hand, instead of a hybrid format that happens to turn out perfectly acceptable in 90 or so percent of cases (i.e. not too many numbers on WP are both greater than a thousand and have more than four digits after the decimal point), we might consider a hybrid default. For example, the template could produce gaps+gaps if there are more than four digits after a decimal point and commas+nogaps otherwise. That shouldn't screw up a million articles and it might even make the template a fraction easier to use. JIMp_talk·cont 20:49, 19 August 2009 (UTC)

That’s what {gaps} is for. Nothing is broken. This “dump on {val}” thing was just a vehicle to promote the point of view of an editor who wants to use gaps left and right—perhaps even outside the strict field of science. Now I see “engineering” being proposed to add into the mix, which is most unwise and unnecessary. And Jimp just described it as “maths/science/technology”—almost like “smart-like articles.” We often get that on Wikipedia—encroachment because it makes editors happy because they can edit in a fashion they are accustomed to in their country; the practice seems truly “right” in some way to them. That’s fine with dialect/spelling. It is a can of worms with numbers for the reasons I’ve stated above and unnecessarily creates confusion in our readership. The exception of using thinspaces to the left of the decimal marker is currently limited to “science” and needs to stay that way for good reason. Greg L (talk) 20:58, 19 August 2009 (UTC)

That's what I use {{gaps}} for but I'd rather use {{val}}. I'm not trying to water things down to "smart-like articles". Perhaps gaps is not appropriate for technology articles, I'm sure its not appropriate for all of them, it may be appropriate for some. I'm just suggesting that the scope is broader than just science articles. Here's a maths article using spaces both sides. It looks fine to me. JIMp_talk·cont 21:18, 19 August 2009 (UTC)

IMO, that math article ought to be conforming to the general rule of using commas to the left. Fortunately, it is an obscure enough of an article (only 700 hits per day). Was there ever a manual of style on Wikipedia saying that that math articles ought to to be delimiting numbers to the left of the decimal marker with gaps or did that article just happen that way? Just because there are math articles that have been done this way does not mean it is a wise idea. I can point to articles that have countless quantities of ending sentences with a preposition; that doesn’t mean we need to change WP:MOS. Greg L (talk) 21:30, 19 August 2009 (UTC)
- Go talk to WP:MOSMATH. But in context of the article, which depends on the contrast of long strings left and right of the decimal point, it seems a reasonable deviation for clarity. Septentrionalis PMAnderson 23:42, 19 August 2009 (UTC)

Actually that article is itself inconsistent, using sometimes commas and sometimes spaces. I'm going to fix it to all-commas before and all-spaces after, as I think it was intended for a lay readership. (I don't think they'll ever appear in the same number or even section, given the structure of the article.) --___A. di M. 18:11, 20 August 2009 (UTC)

Please change it to all gaps, which seems to predominate; that works better to my eye. Septentrionalis PMAnderson 18:30, 20 August 2009 (UTC)

To me it seems that the powers of ten immediately below the section headers mostly have spaces, but the actual examples mostly have commas. --___A. di M. 18:52, 20 August 2009 (UTC)

It looks to me like that double rule is exactly true, except for the scientific notation and one glitch at 1 000, which I fixed. Let's leave it alone -unless there are other glitches. The gaps in the headers are what is useful. Septentrionalis PMAnderson 19:24, 20 August 2009 (UTC)

It used normal space characters, which are too wide (at least with my font and in my eye), and it had a couple numbers with spaces within the actual lists, which I fixed until the 10^39 section. But there's another issue: the last sections have gargantuan exact integers, currently delimited with normal spaces. Using commas or {{gaps}} would blow up the line width, forcing horizontal scrollbars on any window of any reasonable width. --___A. di M. 10:48, 21 August 2009 (UTC)

I'll go along with TheFeds proposal, once one technical issue is ironed out. This bullet:

When grouping digits by threes, and a number has exactly four digits on any side of the decimal separator, those digits may optionally be expressed as a group of four instead of three; e.g. both 9876 and 9,876 are acceptable

is not compatible with the example 1.1234567 because the example has exactly seven digits to the right of the decimal, not four.

Also, the style implemented by {{Val}} should really be called the GPO (Government Printing Office) style, because the prevalent American style is to not group digits to the right of the decimal point. (The Chicago Manual of Style is one publicaton that advocates no separation to the right of the decimal outside the realm of science and technology). --Jc3s5h (talk) 22:36, 20 August 2009 (UTC)

And the Chicago Manual of Style probably gives the same guidance as the Associated Press’ Manual of Style; both wouldn’t delimit to the right for non-technical articles directed to a general-interest readership, now, would they? The {{val}} template probably isn’t a good fit for an article on Wham‑O’s Super Ball: Super Balls have amazing rebound kids! Yet it has a specific gravity of only 1.25864(16) g/ml (which is how much a fifth of a teaspoon of a Super Ball weighs). High-precision values will most frequently be found in technical articles, won’t they? The only noticeable legitimate exception that comes to my mind at the moment is high-precision numbers intended to impress, such as French scientists in 1799 measured the density of water to within 99.997495% of the currently accepted value. Wow!
The current guideline reads, in part, as follows:

“

Numbers with more than four digits to the right of the decimal point, particularly those in engineering and science where distinctions between different values are important…

”

The whole section seems clear enough to me—even for editors who are disinclined to bring much common sense to the party. It reflects what we ought to be doing in order to communicate without confusion, and, after A. di M. got through with it, seems to be capturing the all the known exceptions to the general rule. Greg L (talk) 03:57, 21 August 2009 (UTC)

Regarding the groups of four issue, recall that stemmed from an unclear recommendation from the BIPM manual. They said groups of four were the exception, but didn't explicitly provide for a group of four followed or preceded by a group of three on the same side of the decimal separator. (But gave examples in-text that seemed to support that style.) I don't think it's a huge deal, so I'd be fine with a revised version of that sentence. Do you want to suggest the wording? It would be good to consider whether a case like 9876543 is permissible or too ugly to let stand—contrast that with 9876543 (which is grouped 1/3/3 instead of 4/3). TheFeds 03:34, 21 August 2009 (UTC)

Are we having a “consensus of two”-thing going here again? This issue of number delimiting, as I wrote (abundantly) above, was thoroughly discussed by a very wide group of participants. Moreover, A. di M. and I got deep into the ISO and BIPM recommendations and sorted out—and documented—why things are being done that way. The current MOSNUM guidelines reflect proper practice and there is no good reason to diverge from the practice, notwithstanding your musings as to what sorts of alternative delimiting strikes you as “too ugly to let stand.” Greg L (talk) 03:59, 21 August 2009 (UTC)
The problem with what BIPM say w.r.t. numbers with seven digit after the point is that it differs from what it does. They say that you should use 0.1234567, but their examples use 0.1234567. As for ISO, their standards aren't available for free; a 2008 draft of ISO 80000-1 I found somewhere on the Web explicitly forbids 0.1234567 in favour of either 0.1234567 or no delimiting at all, but judging at this I think it hasn't been accepted. So we'd better ditch the question of what they say and think about what is better. The IUPAP Red Book clearly says "Instead of a single final digit, the last four digits may be grouped." (But above it has unclear wording which doesn't seem to allow delimitation with four digits as in 1987 or 0.1234.) In actual usage, 0.1234567 seems to be more common than 0.1234567 (even because it's not clear how you'd use the latter with two digits uncertainty as in 0.1234567(89)). So I'd keep the convention as it is, but I wouldn't call it "ISO convention" unless someone has access to ISO 31-0 and can confirm that they say that, and is willing to buy ISO 80000-1 when it's officially published to check if it continues saying that. Let's just drop "According to ISO convention (observed by the NIST and the BIPM)"; most people won't even actually care. Also, is "to within 99.997495%" supposed to mean "to within 0.002505%"? BTW, you could impress the reader by writing "99.9975%" or "0.0025%" as well, and neither would have more than five digits after the point. --___A. di M. 10:20, 21 August 2009 (UTC)

BTW, I'd support this:

A. di M.'s proposal

===Digit grouping===

In numbers with many digits, digit grouping symbols (inserted at intervals from the decimal point) are used to subdivide the number into easily readable groups. The acceptable digit grouping schemes are:
Commas every three digits ~~to the left of~~before the decimal point, and ~~thin, non-breaking spaces every three digits~~no delimiting ~~to the right of~~after the decimal point (e.g. 8,274,527 or ~~0.12345~~0.12345). This is traditional usage in many English-language contexts, and recommended by ~~the U.S. Government Printing Office~~The Chicago Manual of Style and the AP Stylebook for non-technical articles.

As above, but with thin, non-breaking spaces every three digits after the point (0.12345). This is recommended by by the United States Government Printing Office.
Usually there is no difference between the two styles above, because non-technical articles should avoid using excessively precise values: see the second point in § Large numbers, below.

Thin, non-breaking spaces every three digits (e.g. 8274527 or 0.12345). This format is suggested in BIPM and NIST style guides ~~for scientific and engineering works, and is in common use in~~and is in common use in scientific and engineering works and interlanguage contexts.
In some major English-speaking countries, this format is unfamiliar most persons without advanced scientific or engineering education, so avoid using it when discussing general-interest topics.

Mathematical constants in mathematics-oriented articles may be grouped into groups of five digits on both sides of the decimal point; e.g. 3.141592653589793238462643383279....

Other traditional digit grouping schemes, when relevant to the subject matter of the article; e.g. 82,74,527 in the Indian numbering system. (An explanation of the digit grouping scheme should be provided, typically by way of a link or brief summary. Also or instead, parenthetical conversions to another acceptable scheme may be used.)

The style of grouping digits within numbers should be consistent throughout an article.

When grouping digits by threes, and a number has exactly four digits on ~~any~~either side of the decimal separator, those digits may optionally be expressed as a group of four instead of three; e.g. both 9876 and 9,876 are acceptable. Additionally, after the decimal point a final group of four digits can be grouped together, e.g. 0.1234567 or 0.1234567. The latter style is more common, and is recommended on Wikipedia.

Digits are not grouped when they are part of addresses, page numbers, and years with four or fewer digits. However, years with five or more digits (e.g. ~~10,400 BC~~10,000 BC) are delimited as any other large number.

====Technical implementation====
The {{gaps}} template uses CSS to output thin spaces (using the syntax {{gaps|8|274|527}}). Using the thin space character or its HTML entities for this purpose (e.g. or  ) may cause rendering problems in some browsers, and should be avoided when practical.
The {{val}} template handles digit grouping ~~automatically, in the American style (by default) or in the BIPM style (by using the BIPM=y parameter)~~in the U.S. GPO style automatically. ~~In both cases,~~ CSS is used to output the thin spaces. For example, {{val|1.1234567}} generates 1.1234567 (with a four-digit group at the end). The {{val}} template can parse no more than a total of 15 significant digits in the significand. For significands longer than this, editors should manually delimit values using the {{gaps}} template; e.g. {{gaps|1.234|567|890|123|456}} → 1.234567890123456.

Differences from TheFeds' version are marked. --___A. di M. 11:15, 21 August 2009 (UTC)

"This format is suggested in BIPM and NIST style guides for scientific and engineering works" misrepresents the position expressed in the BIPM brochure (and the NIST brochure is, with minor variations, just a translation). The brochure states on page 133

The practice of grouping digits in this way is a matter of choice; it is not always followed in certain specialized applications such as engineering drawings, financial statements, and scripts to be read by a computer.

So as far as NIST and BIPM are concerned, the thin space format should be used for everything except "certain specialized applications". --Jc3s5h (talk) 12:16, 21 August 2009 (UTC)

Amended to reflect this. --___A. di M. 12:24, 21 August 2009 (UTC)

A. di M., thank you for stepping in here. Please insert, somewhere in your suggestion, something along the lines of this: “In technical articles such as engineering and science, where distinctions in the magnitude of numeric expressions are important, editors should consider using the {{Val}} template to delimit numbers that have many digits to the right of the decimal point in order to make them easier to parse.” Greg L (talk) 19:21, 21 August 2009 (UTC)

I strenuously object to the clear objective of the proposed verbiage that reads

Thin, non-breaking spaces every three digits (e.g. 8274527 or 0.12345). This format is suggested in BIPM and NIST style guides and is in common use in scientific and engineering works and interlanguage contexts.

The current wording, (“scientific articles, particularly those directed to an expert audience”) is the proper limit. The clear objective with that proposed wording is to expand the “Europeanizing” of Wikipedia’s numbering into anything remotely ‘technical’ in nature. Unlike dialect (spelling), delimiting with gaps to the left of the decimal point is far too confusing to American readers who are not taught any other methods of number delimiting. Conversely , the typical Swedish school child is taught three different ways to format numbers and are not in the least bit confused when they come across numbers with the American-style of delimiting.

I’ve made this point numerous times, above, and the best counter-argument I’ve yet to see is a demand to see scientific proof or studies showing that alternative numbering formats would be confusing to Americans. Commons sense does not need to be legislated. This is hopeless. This is simply nothing more than an attempt by some Europeans, who are absolutely convinced that their BIPM-endorsed, European way is superior (perhaps it is) and should be adopted here on Wikipedia and dumb ol’ Americans will learn it here, if nowhere else. These editors need to drop this agenda to change what has long worked here. Wikipedia is not to be exploited as a vehicle to promote change by educating Americans to conventions with which they are entirely unfamiliar. The current guidelines are fine.

And, a final note: Just because something is endorsed by the BIPM doesn’t mean it enjoys world-wide adoption. The BIPM wants 75% written 75 %, but Americans (and as far as I know, no one else) don’t do it that way so Wikipedia goes with the flow and ignores the BIPM so we don’t confuse people for God’s sake. Greg L (talk) 23:35, 21 August 2009 (UTC)

I have to say, having read this thread I am not at all persuaded by the BIPM-rules-all feeling that's about. What is being proposed here seems controversial and is unlikely to gain broad consensus. I see no reason to change the current guidelines, which have long been on MOSNUM and have served us well. Tony (talk) 00:12, 22 August 2009 (UTC)

As someone who has lived in France for many years, I am familiar with that convention. It appeared bizarre to me when I first arrived there. Now it is pointed out that this is also adopted in some scientific contexts. Before this is imposed on the unwitting WP public, I would point out that it is a convention I have never seen before in the Anglo-Saxon world. Being able to understand it is one thing, but to insist that this professional technical standard be adopted in any form in a general knowledge encyclopaedia is quite another. - BTW, the French also use the comma in place of the period as the decimal delimiter. Even if we were not to adopt this last 'quirk', it is unlikely to find widespread acceptance. Implementation is likely to meet with bewilderment, and be universally reverted to the comma delimiter which all English-speakers are familiar with. Ohconfucius (talk) 06:37, 22 August 2009 (UTC)

Regarding Greg's oft-repeated assertion that Americans would be confused by the BIPM style, let me also reiterate my feelings. I don't believe that someone with a working comprehension of written English would be so hopelessly confused by that format as to fail to comprehend the meaning after a short pause to think about it. To me, the worst reasonable case is that someone will assume that a previous editor neglected the commas.
To consider an analgous case, an American reading about a boot and a bonnet might picture articles of clothing, rather than car parts—yet we would not expect articles to generally defer to the American's preferred vocabulary, even though Britons are somewhat accustomed to American vocabulary (e.g. because of the pervasiveness of American culture and media in Britain, vs. the opposite), and would grudgingly understand "trunk" or "hood" in the context of an automobile. In fact, with numbers, at least there's a contextual clue to the meaning—the numerals are the same, after all. With "boot" vs. "trunk", we have to resort to things like linking the first occurrance, to avoid misunderstandings; the case of dialect is more, not less confusing than numbering style. Yet despite that slight inconvenience, the well-established principle is to accept such regional eccentricities as part of the language, and accomodate them in the interest of avoiding the imposition of one region's style over another. Just because the Swedes often understand either format—to recall Greg's example—does not mean that their preference ought to be be moot.
And let me just point out that I was not the one who demanded a study or scientific proof of the alleged incapacity of Americans to use other formats—I simply expressed my doubt. My common sense appraisal doesn't agree with Greg's, and I suspect that when it's nothing but assertions of common sense on either side, there's nothing in particular to refute. (And of course, repeating something doesn't make it true; neither argument is any stronger upon retelling.)
I've also got to take issue with the idea that Europeanization is the motive. ("This is simply nothing more than an attempt by some Europeans, who are absolutely convinced that their BIPM-endorsed, European way is superior (perhaps it is) and should be adopted here on Wikipedia and dumb ol’ Americans will learn it here, if nowhere else.") I doubt that it was an intentional strawman, but for the sake of keeping this discussion on track, let's drop the idea that there's any effort to force-feed Americans with foreign concepts, because there's no evidence that any editors presently commenting on this matter are attempting to engage in any such scheme.
To me, the convention used by the BIPM is a necessary inclusion in the MOS because it is the dominant English-lanugage usage in some regions—not just in science or engineering, but in any English-language usage. That's the way things tend to work in Continental Europe (and maybe that's why this "Europeanization" allegation arose), where several states and languages have their own incompatible digit grouping schemes, and where English is the de facto language of international commerce and collaboration. There is no ulterior motive: it's simply an acknowledgment of European English style. Consider the European Commission English Style Guide, which calls for BIPM-style digit grouping. That guide is "intended primarily for English-language authors and translators" and "serve[s] a wider readership as well" (speaking in terms of the EC and of EU institutions)
The fact that things like scientific journals and engineering handbooks have also adopted the BIPM convention is a secondary component of the issue—when we say "in common use in scientific and engineering works", that's just an acknowledgment that scientific usage of this convention is worldwide, versus the regional adoption of the convention for general use. If we wanted to capture that reasoning in detail, we could say that BIPM style is limited to topics in the fields of science and engineering, plus topics dealing with Continental Europe and other regions that enjoy significant adoption of that style.
But what's the point of being needlessly precise? It's much simpler to acknowledge that both the U.S. and the BIPM convention are in general use in large regions of the world, and each preferred by major fields of study (as evidenced by style manuals). On balance, the MOS is clearer by just allowing either one (though calling for consistency within an article), without complicating the issue with topic-related stipulations (and the consequent discussion of what belongs to which topic, or what dominates in which region). This is easier to understand, and easier to enforce—that's a useful thing, given the level of complexity of the MOS and Wikipedia policy in general. TheFeds 19:46, 22 August 2009 (UTC)

Quoting you, TheFeds: I don't believe that someone with a working comprehension of written English would be so hopelessly confused by that format as to fail to comprehend the meaning after a short pause to think about it. You might well be right. After a moment of looking at the unfamiliar-looking number, many—perhaps most—Americans would eventually figure it out. So what? Do you think that is the litmus test the Associated Press uses in judging what to put into their manual of style(?): whether readers, who are initially confused by the written word, will for the most part eventually figure it out??? The point of all technical writing is to write with the least confusion. Your arguments of how the BIPM recommended this ‘n’ that so their recommended method of delimiting numbers has been anointed with holy oil and ought to be adopted here is entirely beside the point.
Frankly, your arguments that we should follow whatever the BIPM says the world ought to do comes right out of the four-year-old playbook used by proponents of the IEC prefixes (see the B0–B16 archives, above). That whole stink (seventeen entire archives dedicated exclusively to that one fiasco) was because a small handful of editors banded together and decided to start using terms like “256 kibibyte (KiB)” instead of the “256 kilobyte (KB)” used by computer manufacturers and computer magazines throughout the rest of the planet. Then one of those editors ran around and changed hundreds of articles over a period of a few weeks and the group blocked anyone from reverting all those edits, citing “lack of consensus”. That this could have occurred that way, that such stupidity lasted for three years, and that it took three months of bickering to put an end to it speaks volumes to how broken MOSNUM can be at times. And all because it was a proposal by some vaunted standards organization. The end result(?): needles confusion in readers who had the misfortune for three long years to come here and read many of our computer articles. I’m sure there were a number of people read up on computers here on Wikipedia and then went into computer stores where they announced they were looking for a computer with “512 mebibytes of RAM.” They were no-doubt met with blank looks (at best) or snickers.
Quoting you again: To me, the convention used by the BIPM is a necessary inclusion in the MOS because it is the dominant English-lanugage usage in some regions. Yeah, I got that much. I figured that bit out in the first four seconds after seeing what you were trying to do. And, as I’ve explained, it unfortunately isn’t a two-way street. There are many ways the Europeans format numbers. In Sweden, the “Swedish1” technique (there’s yet another) is to write the population of America as “285.865.855” so why don’t we just go ahead and let articles here use that system too(?), right along with the BIPM method (which Swedish school children are also taught)? That’s a rhetorical question, please don’t answer it. The answer is because Swedish school children are also taught to recognize the American-style of delimiting numbers. In fact, Europeans by and large are not in the least bit confused when they encounter numbers with American-style delimiting. The trouble is that American’s know of only one way; they’ve been taught no other. Your argument that Americans’ confusion will be short-lived because *Wikipedia* will just teach them using an “oh… didn’t-cha know?”-fashion (and only the galactically clueless and retarded will be left in the dust) is wholly uncompelling.
With regard to how numbers are written here on Wikipedia, it doesn’t matter in the least what the proposal is or who proposed it. When the American style of delimiting numbers is no longer the dominant numbering format universally recognized throughout the English-speaking world, and when Americans have as much familiarity with alternative numbering styles (like “Swedish1” and “BIPM”) as Europeans do with the American style, then Wikipedia can change over. Wikipedia follows the way the world works and never, ever tries to promote change in the way the world works by presuming we can somehow lead by example. Wikipedia wisely decided to use American-style delimiting in our numbers so there is minimal confusion. Greg L (talk) 21:50, 22 August 2009 (UTC)

With regard to your first point, we're writing with a different set of rules than the AP (to use your example). They are free to insist that their writers use "truck" instead of "lorry", or group digits with commas rather than thin spaces, because they have no mandate to consider the issues summarized in WP:ENGVAR, and choose instead to cater to one region's preferences. Wikipedia is written for an international, English-reading audience. That means that we need to accept that occasionally, a user may encounter a term or convention from elsewhere, and be briefly confused. But this is not a critical flaw, because most readers don't just shut down at that point; they keep reading the sentence or paragraph. And the context generally makes clear what is meant, without loss of information. I submit that if we presented a number all alone in the BIPM format, there might be unacceptable confusion among Americans, but that if it was placed within prose or a table, the context would make the meaning accessible to all.
Let me stress that there is no implication of "teach[ing] them using an “oh… didn’t-cha know?”-fashion". Readers are free to assume that the formatting was a stylistic error, rather than another valid convention, and be none the wiser. The content of the article still gets across. (In other words, I am absolutely not advocating some sort of patronizing policy that would educate the savages of the world about Europe's genteel ways.)
My concern here that by mandating a convention that represents the preference of a subset of English speakers, we would imply that other accepted English-language usage is inappropriate. It would be like saying "because the British spelling of words like 'harbour' is recognized throughout the world"—despite the American spelling "harbor"—"this spelling convention is mandatory (unless quoting a source or explaining foreign usage)". Wikipedia has not gone this route, instead permitting either form.
Regarding your Swedish example, I assume that Swedish-1 and Swedish-2 are used in Swedish-language works? This being the English Wikipedia, one would expect them to use the style that is typically used in their region for writing in English. (Which is most probably the BIPM style.) If the Swedes don't use their native styles when writing in English, then there's no need to deal with them here.
When you say with certainty that "Wikipedia follows the way the world works and never, ever tries to promote change" by example, I think you're misinterpreting what's going on here. Maybe during the binary prefix debate, some editors advanced the idea of promoting IEC usage to the world. Nobody's said anything of the sort here. Furthermore, we usually follow bits and pieces of what influential parts of the world do, but only because consensus among editors often ends up settling upon that course of action. Sometimes that means following or ignoring a particular standard or widespread convention, but the key is that Wikipedia does what the editors agree upon. It's coincidence rather than design that consensus usually settles upon permitting what's popular in the world.
Lastly: you're definitely mischaracterizing my motives. I'm not waging some promotional campaign that serves to advance the interests of the BIPM, or Europe, or any other entity. Specifically, despite your assertion above, I have not stated or implied that "we should follow whatever the BIPM says the world ought to do". (I have previously stated that I tend to use the BIPM style in my outside work—which is immaterial to your allegation.) TheFeds 00:18, 23 August 2009 (UTC)

Quoting you: I am absolutely not advocating some sort of patronizing policy that would educate the savages of the world about Europe's genteel ways.) {{smiling, very amused emoticon}}. Perhaps you aren’t. But it seems you are mightily crossing your fingers that mixing things up here and allowing editors to use different types of numbering formatting if they feel like it won’t cause needless confusion with our readership. Better cross two fingers.
I’m an American engineer. I do all my design in hard metric. In fact, only a half hour ago, I was busy calibrating a celsius-only thermostat that I’m going to retrofit into my otherwise-gaugeless, Italian-made Rancilio espresso maker. The boiling point of distilled water was 97.8 °C at that moment (barometric pressure) at my altitude (about three meters above the sewer cover outside my house). I’m also installing a pressure gauge calibrated only in bar. I am as “BIPM” as they come for an American. However, as an engineer who has done far more than his share of technical writing (owners manuals, white papers, etc.), I am fully aware of what Americans know and don’t know technically. I am also keenly aware of how utterly stupid it is to needlessly confuse readers.
Here’s how to speed America’s adoption of all-things-BIPM (e.g., their SI (metric) system, their numbering system, etcetera): Just run for elected office while promising that if America adopts BIPM into their way of life, they’ll loose weight while they sleep and their taxes will go down due to less government waste. You’ll get into office. Moreover, you’d stay there; all you’d have to do is repeat the promise each election cycle; they’ll buy into your promise each time.
America is big and homogenous; a drive that would take you clean across the whole of Luxemburg won’t even get you across Harris County, Texas. This is a source of strength and weakness. For one thing, we can drive across Harris County and not require a pocket-full of plug adapters to plug our iPhones into the outlets in the next county (or state for that matter). We could design a big-ass airplane in the late 60s and not get all confused because Californians can’t speak French whereas Oregonians right next door can’t speak German. But this homogeneity also means that Americans would be surprised to get into an elevator on the ground floor and see that they are at floor “0”.
Indeed, Americans are certainly not as “genteel” and worldly as Europeans (that’s a friend of the guy who owns a tool & die shop I frequent); there’s this big-ass pond that shelters us from being exposed to other languages and other ways of doing things. Therefore, it’s a damned-seldom American indeed who is fluent in two or more languages and easily recognizes two—even three—ways that numbers can be delimited. Europeans “get” “285,564,125” in a nanosecond. The typical American would be needlessly confused by “285564125”. So, you Europeans have a leg up on Americans when it comes to understanding other cultures and practices.
Please take note of the following three expressions. The first is “A civilized man can convincingly imitate a barbarian, but a barbarian can not convincingly imitate a civilized man.” The second is “Never try to teach a pig to sing; you only waste your time and annoy the pig.” The third is “The goal of all technical writing is communicate with minimal confusion.” What you are proposing handily ignores all three. Greg L (talk) 03:52, 23 August 2009 (UTC)

Well, now that Greg and I have said plenty about our respective opinions, are there any comments from interested individuals? Did either of our statements change your opinions about the proposals? (Or did we bore you all with too many words?) TheFeds 03:15, 26 August 2009 (UTC)

…besides Greg L, A. di M., Tony, and Ohconfucius? Anyone else?… Anderson? Bueller? Greg L (talk) 03:48, 26 August 2009 (UTC)

I just want to clarify once again that I have no view on what takes place after the decimal place. However, Greg has demonstrated that trying to get a minority European notation system is just too far from wide acceptance. The use of commas as delimiters is pretty much universal – the comma separator is not only American, it's Canadian, British, Australian, Irish, South African, Singaporean - which should take care of about 95% of the native English-speaking population. As this is English Wikipedia, I think that just about makes the case for not embracing BIPM with even tepid reception. Ohconfucius (talk) 04:13, 26 August 2009 (UTC)

Well put and succinct. Thanks, Ohconfucius.
Those English-speaking Europeans who want to come to en.Wikipedia can, while they learn about the subject matter in our articles and brush up on their English-language skills, also get even more comfortable with the accompanying number delimiting technique whereby native speakers of English (U.K., America, Australia, and aothers) use commas to the left of the decimal point.
That is all part of the “experience” for many visitors to en.Wikipedia for whom English is their second language: immersing themselves in the culture, including such nuances as idioms. That approach is much more realistic (when in Rome, do as the Romans do) than assuming that Wikipedia can somehow change the way the English-speaking world works.
While it might be *pretty* to think that we wouldn’t be creating unnecessary confusion in our readership by using a wholly unfamiliar number formatting technique here, such a notion doesn’t seem grounded in reality. Nor is such a confusing change in the least bit necessary.
TheFeds, I ask you to drop the stick and back away from the horse carcass. This issue has been flogged to death and your persistence is becoming tedious. There is clearly not the remotest chance that a consensus might form for adopting the BIPM method of delimiting numbers for use on en.Wikipedia or expanding its mixed use beyond the confines within which it is currently limited. Far from it; it seems the general consensus is to leave things the way they are. Greg L (talk) 16:13, 26 August 2009 (UTC)

My persistence is becoming tedious? Aren't you the one responsible for 53 of the last hundred edits to this talk page?
Also, despite prior implementation and positive discussion of a similarly-worded edit to the MOS, you reverted it, and prompted this discussion in the first place. You can't just handwave away a discussion that you caused. How can you assert that "it seems the general consensus is to leave things the way they are", when the discussion on this point has largely been limited to you and I? If anything, the previous discussion about the MOS changes was more representative of consensus than our current conversation.
I'm receptive to your ideas, and have constructively disagreed, but you need to quit mis-stating my position regarding "chang[ing] the way the English-speaking world works" as fodder for your argument.
Given that the Romans use the BIPM convention (in English), why should they avoid using it when describing a Rome-related topic (in English)? As I stated previously, we have the option of writing a complicated regulation that takes into account WP:ENGVAR for articles dealing with regional issues that "belong" to places that recognize the BIPM style, and additionally acknowledges its prevalance in modern science and engineering. I think that my proposed language provides a less complicated policy statement with the same objectives, but it would essentially allow any user to choose to employ the BIPM style, even in new articles absent a topical or regional connection. That's a side effect, but given that that WP:ENGVAR cuts both ways (in that topics with a connection to a region that employs a non-BIPM convention could reasonably be changed to follow local style, even if the article style was initially BIPM), there's clearly nothing that would obstruct the ability of editors to choose an appropriate English-language convention for the article, or write neutrally when no regional or topical connection exists. TheFeds 17:55, 26 August 2009 (UTC)

Many Romans would use even weirder things when writing English, but that's not a good reason to use them in articles about Rome in the English Wikipedia. WP:ENGVAR only applies to "English-speaking nation[s]". Among the nine countries with most native English speakers, is there any where people use thin spaces in numbers such as 12345 in non-technical contexts in English? --___A. di M. 18:56, 26 August 2009 (UTC)

TheFeds: The change I reverted was nothing more than a tag-team effort comprising just you and Jc3s5h, who were feeding off each other (“say… that’s a campy idea of yours TheFeds, why not suggest some wording and I’ll put it in”–sorta stuff). That amounted to a stealth edit and did not enjoy a proper consensus that such an important change requires.
You two’s change was to a long-standing guideline governing how something as fundamental as the formatting of our numbers are done on en.Wikipedia. It is utterly absurd to start mixing up our numbering style in an encyclopedia geared for our English-speaking readership. As A. di M. pointed out, WP:ENGVAR doesn’t and shouldn’t and can’t be applicable here. You are grasping at straws trying to make a case for what amounts to nothing more than “I like ta and wanna sanctify my practice in MOSNUM by changing MOSNUM.” Please stop. I couldn’t care less if some member of an African tribe that speaks using *!* tongue pops and counts in base-seven numbering system comes here because he or she also happens to know English as a second language. Those countries wherein English is the primary language delimit numbers to the left of the decimal point only with a comma. This practice is memorialized in the U.S. Government Printing Office Style Manual and is what is used here. So it doesn’t matter if the BIPM says it should be “75 %” and not “75%”, nor does it matter if the BIPM says it should be “a population of 285568654”. Why? Because in those countries where English is a primarily the first language, those two things aren’t done the BIPM way. It’s just that simple.
If we headed down the path you and Jc3s5h wanted, which amounts to “let editors use either commas or thinspaces to the left of the decimal point whenever they want if the article is sorta ‘techie’ ”, then Wikipedia would once again be repeating the fiasco of our now-aborted experiment with the use of the IEC prefixes, where some articles said “256 kilobytes (KB)” and still others said “256 kibibytes (KiB)”. Given that readers were entirely unfamiliar with the latter, this accomplished nothing more than to confuse readers. It’s interesting to note that the proponents of the IEC prefixes used exactly the same arguments you two are using: “They’ll figure it out from context and… and, the (totally conjectured and unproven) confusion will be short lived, and… and, a *standards organization* has proposed it, and… and, it solves an ambiguity or shortcoming of some sort, so our use here on Wikipedia is nothing but goodliness and will make us look all futuristic and smart.” Uhm… no. All it did was unnecessarily confuse our readership.
I appreciate your above candor. You’d like to see the use the Euro/BIPM method of delimiting numbers in an article on Rome, since—by your argument—Italian-speaking Romans who also speak English could visit the en.Wikipedia Rome article and feel all warm and fuzzy about seeing the BIPM method of number-delimiting here too. Except your argument falls somewhat flat because in Italy (at least it.Wikipedia), they format numbers like this: “Con i suoi 2.726.539 abitanti distribuiti su una superficie di 1.285 km², è il più popoloso e più esteso d'Italia.” A. di M. will no-doubt be able to flesh in some detail on this. But I have every faith that Italians recognize the method of delimiting seen on it.Wikipedia, and the BIPM method, and the English-speaking method.
I will no longer waste my time arguing this point with you, TheFeds. Count how many editors, above, support what you are proposing. Do you see a consensus for what you desire? Or do you just hope that by not dropping the stick that we will all just come around? I’m going to leave this to Tony, A. di M., and Ohconfucius for a while. Don’t count my absence from this discussion as acquiescence; I simply tired of arguing with you.
Frankly, if I had my way, the use of gap-delimited numbers to the left of the decimal point would be limited strictly to when text is being quoted directly from a scientific paper. The practice has no place in an article like Moon, for text like “The Moon is 384403 km away from the Earth” and MOSNUM should clearly reflect that. Greg L (talk) 20:57, 26 August 2009 (UTC)

A. di M., I've got to disagree with the idea that WP:ENGVAR applies strictly to nations where English is the dominant native language. Germany has around the same number of English speakers as England has people. France has tens of millions as well. (Not to mention that India has something like 100 million English speakers, and Nigeria probably has over 50 million.) I don't think it makes sense to assume that WP:ENGVAR can't apply to those English-speaking populations. When those people communicate in English, they often employ particular regional conventions—loan words in Indian and Nigerian English are perfect examples. (In other words, there's no good policy reason to believe that "English-speaking" in WP:ENGVAR means "natively-English-speaking".)
If Wikipedia's policy was to always employ the most popular variety of English uniformly, perhaps it would minimize confusion. And then it might logically follow that the most popular numbering scheme should always be employed as well (despite regional eccentricities). But that's certainly not the way most similar cases were decided, and the policy guidelines reinforce the idea that regional preferences matter.
Greg, I think you missed the point of the Roman example: this is about English-language usage, not Italian-language usage (as I clearly specified). I'll of course defer to A. di M.'s presumed experience with Romans, but in my experience, Continental Europeans writing formal English prose will employ the BIPM style, irrespective of the conventions used in their native language. (And with English being the dominant language for international communication in Europe, there's no shortage of usage.)
With regard to Greg's paragraph citing the IEC prefix dispute, I'm accused of using their arguments ("They’ll figure it out from context", "a *standards organization* has proposed it" and "it solves an ambiguity or shortcoming").
The first argument, as I noted earlier is logically equivalent to Greg's argument that many Americans will struggle to figure it out—both my assertion (that context will make most usage clear) and Greg's are conjecture, though both reasonably well founded. Absent actual evidence, you can't accept one and reject the other on a logical basis.
The second is a strawman, as I reminded Greg prior to his reiteration of it. It's immaterial that the BIPM is a standards organization, just as it's immaterial that the U.S. Government Printing Office authored a standard that encapsulates Greg's preference. Regional usage is at issue.
The third would be a fair point, if it weren't for the inflammatory corollary that Greg appended ("so our use here on Wikipedia is nothing but goodliness and will make us look all futuristic and smart"). Notwithstanding Greg's misrepresentation, it does address a shortcoming. As I noted above, Wikipedia could have solved the question of how to deal with variations in English usage by mandating a fixed house style (for numbers, spellings, synonyms, etc.)—but that was not adopted. Instead, consensus dictated that regional usage was permitted within an appropriate sphere of influence. MOSNUM ought to reflect the outcome of that high-level consensus. As I explained before, my proposal was more permissive than that—but the crux of the issue is that regional English-language styles are appropriate on the English Wikipedia. The additional permissiveness in my proposal reflects my belief that adoption of the BIPM style is sufficiently widespread that the effect of adding it on an equal footing with either of the comma-based styles would be essentially harmless. It's much the same as the difference between the two comma-based styles (listed at the top of A. di M.'s proposal)—readers will understand either one, even if they think one or the other is in error (because they have not been exposed to it).
That additional permissiveness also has the effect of simplifying the MOS regulation—but if that prospect is so abhorrent, the formulation that permits the BIPM style only when regionally or topically appropriate (e.g. Continental Europe, Canada—especially French Canada, science, engineering, etc.) would minimally satisfy the existing guidelines, and would be acceptable. TheFeds 23:21, 26 August 2009 (UTC)

The traditional way to delimit numbers in Italian in handwriting is a superscript dot; but since no-one knows where to get that character, it is approximated with either a period or an apostrophe ("10.000" or "10'000"); the former is more common in Italy and the latter is in Switzerland. Recently the BIPM way is becoming common too; I guesstimate that approx. 70% of stuff published in 2009 use periods and 30% use thin spaces. But I've seen that my cousin's elementary school textbook only mentions the thin space method. There are many Italians who are unfamiliar with the comma as a thousand separator and wouldn't realize that "40,125" can mean anything else than forty and one eighth, but those Italians don't understand English enough to read an encyclopaedia article in it, so I don't see the need to cater with them in the English wiki. As for "continental Europeans writing formal English prose will employ the BIPM style", that's true, but only because an Italian is more likely to write a scientific paper than a novel in English. (And as of 2009 there's no real ground to consider India an English-speaking country; it has fewer native English speakers than Germany, and a smaller percentage of people able to speak English than the whole world.) --___A. di M. 12:51, 27 August 2009 (UTC)

Choosing a resolution

Alright, it looks like Greg and I cannot agree on the specific details that we'd like to see in this section. We've both dropped the issue for about a week—I think out of some measure of frustration, rather than satisfaction.
But there are still proposals on the table, and we have yet to see any conclusive resolution that approximates a consensus.
So my suggested resolution is as follows:
1. I'm willing to compromise by going along with A. di M.'s proposed text, with two changes: omit the first 3rd-level-bulleted sentence (redundant, though not objectionable), and omit the recommendation portion of the second 3rd-level-bulleted sentence "so avoid using it when discussing general-interest topics" (as described above, that's contrary to the principle of following topical English conventions in appropriate articles).
2. If other editors feel it necessary, I would be (marginally) willing to support the insertion of a neutrally-worded sentence stating that BIPM style is recommended only when regionally or topically appropriate (but not the converse—I object to a statement prohibiting it except in specific cases).
3. If we're uncomfortable with that compromise, we can get to the root of some of the objections by making a policy inquiry. I'll ask the contributors at Village Pump (policy) what they think of the proposal, what they think of the discussions we've had (now and previously), and what they think about the specific item of contention between Greg and I—namely confusion of some readers versus regional style preferences, and the broader history and implications of advocating for one or the other through the MOS.

TheFeds 06:56, 3 September 2009 (UTC)

Yes, having a RfC is the way to go. As well as WP:VPP, I'd advertise it at WP:VPR, WP:CENT and WP:PHYS (physicists are the ones most likely to ever use any number with more than four significant digits; maybe WP:MATH and WP:SCIENCE as well?). But someone has to summarize the points made so far so that a newcomer needn't reed hundreds of kilobytes of discussions. --___A. di M. 10:02, 3 September 2009 (UTC)

Quoting TheFeds: Alright, it looks like Greg and I cannot agree… You’ve notably truncated the list from “Greg L and A. di M. and Tony and Ohconfucius”, to just “Greg L.” Choice.
Please don’t confuse my apparent willingness to engage you on this issue and the relative silence from the others, as signaling that they are somehow in major agreement with you. The words of Tony and Ohconfucius, above, are short and sweet and seem to convey their sentiments clearly enough (unsupportive) as to what you propose. However, I would be exceedingly pleased if you would start an RFC so we can be done with this and I don’t have to periodically check back here, only to discover that you have again reprised this issue.
A consensus is not arrived at by seeing who harps the longest and mostest on a given subject. Nor does one get his or her way on Wikipedia by catching people sleeping, nor by changing the documentation on templates to convey something along the lines of “better not use this template because—boy—is it gonna change soon…” nor by changing templates without having had any real discussion beyond tag-teaming with one other editor where you both go “campy idea—cup of tea?” to each other.
Judging from the reception of me and several others, above, turning Wikipedia into a mix of numbering styles by greatly expanding the use of a number format that isn’t even used by those general-interest readers for whom English is their first language, has pretty much no chance of being adopted. And it shouldn’t, for it ignores the most basic fundamentals of Technical Writing 101. If you have to prove this through an RFC rather than examine the reception your proposal has received so far, by all means.
As for I'm willing to compromise… language, uhm… we all have to accept the consensus of the community—period; it doesn’t much matter what you are I are “willing to compromise” on.
Someone please e-mail me if this goes to an RfC. I don’t make it a practice to keep following TheFeds wherever he goes on Wikipedia with this idea of his. Greg L (talk) 02:23, 4 September 2009 (UTC)

Greg, do you seriously believe that I'm trying to imply that Tony and Ohconfucius are somehow in agreement with me?
You might have noticed that while Tony and Ohconfucius both made short comments concerning portions of this discussion, you and I wrote at length—and my post addressed that conflict. You might also have noticed that I also excluded mention of Jc3s5h's comments in support, and did not state that A. di M. disagreed in part and agreed in part.
And when you list several ways in which "A consensus is not arrived at", are you making an accusation, or just introducing examples that are irrelevant? I've repeatedly warned you during the course of this discussion not to jump to inaccurate conclusions about my motivations, and now I feel that I need to warn you to avoid baseless accusations of things like "catching people sleeping" and screwing up template documentation, and to avoid flippantly misrepresenting legitimate discussion as “campy idea—cup of tea?”.
You said "uhm… we all have to accept the consensus of the community—period; it doesn’t much matter what you are I are 'willing to compromise' on"; but I don't see any basis for your objection. When we make proposals, we are free to discuss and make compromises among ourselves, in order to establish mutual support for a compromise proposal. (As an illustrative example, consider how a legislature generally works: mundane issues are discussed in committee, leading to one compromise bill, rather than by taking up-and-down votes on opposing ideologically extreme proposals.) Nothing of that process prevents a "consensus of the community" from existing. TheFeds 17:23, 4 September 2009 (UTC)

Quoting you: Greg, do you seriously believe that I'm trying to imply that Tony and Ohconfucius are somehow in agreement with me? I’m trying to point out that it’s not just “you vs. me” and that, given the above reaction of others, it seems exceedingly improbable that what you propose will be well received by the community. It’s a hint that you are likely wasting your time by persisting at this.
One sort of thing that has been the source of spectacular amounts of vitriol on Wikipedia (and the Wikipedia-equivalent of suicide bombers and Turkish butt-stabbings), has been the launching of RfCs by a lead advocate on one side of an issue. This resulted in RfCs that suffered from unconscious bias and were not respected by the other side. If you seriously think your proposal has a snowball’s chance of being accepted with a clear consensus (that’s a big “IF”), then the next step is an RfC. So the proper step, IMO, is to not launch an RfC, but to propose RfC wording, we all discuss the proposal and tweak it until everyone is clear on what is being proposed and how it would change things and are mutually satisfied the “package” wording is sufficiently neutral, and then we launch an RfC.
I have zero interest in starting all that. It’s time-consuming and, ultimately, a waste of time if it goes as I expect. I suggest you seek some assistance from Headbomb and Ryan Postlethwaite (I have no idea if they might be interested) since they both have experience in RfCs.
Perhaps, an even better course of action would be to privately contact an editor or two that you feel are relatively unbiased and whom you have a respect for their opinions. Just ask them if they think there is a fair chance of your succeeding at what you desire. I think that is much fairer given that your persistence at this means that everyone else has to *sigh* and start jumping through hoops once you start things rolling. Greg L (talk) 18:43, 4 September 2009 (UTC)

I've taken some time to follow Greg's suggestion, and conferred with another editor about this topic. They felt that going through the complete process for creating a formal RfC, with another round of proposals to determine the question itself, would be a little absurd and "pointlessly bureaucratic". I concur, and like Greg, don't really want to argue about meta-proposals.
As for asking around (less formally), they thought that it could plausibly be well-received elsewhere on Wikipedia, with the main concern being that other venues might not be interested enough in minutiae of style to comment constructively. They figured that it would be harmless enough to just ask, rather than attempting to predict the outcome.
So, we discussed what I had in mind, and through a couple of revisions, we pared the essential question down to something general ("On Wikipedia, should the selection of digit grouping styles depend upon regional and topical conventions used in the English language?"), with a neutrally-phrased explanation of context. The question is posed at WP:VPP, in the section Digit grouping style question (from WT:MOSNUM), and I'm placing notices on some other talk pages directing users to WP:VPP for comment. TheFeds 03:46, 9 September 2009 (UTC)

Continuing discussion

This is the proper place to further discuss matters pertaining to MOSNUM.

TheFeds: What you call a “pointlessly bureaucratic” step is a valuable one to ensure the right thing is done on Wikipedia. You are now gaming the system by framing the nature of the problem and the nature of the solution on your own. Moreover, you did so by jumping over to an entirely different venue clearly hoping to drum up support with a different group (were you trying to drum up opposition there?). That is not how things are properly done on Wikipedia; it is venue-shopping.
You clearly want your way, didn’t like what the others had to say, above, on this issue, and you now put us all in the position of having to chase you over to WP:VPP. No. I won’t chase you to some other venue as you hop-scotch across Wikipedia with this agenda to change MOSNUM. I even wrote above Someone please e-mail me if this goes to an RfC. I don’t make it a practice to keep following TheFeds wherever he goes on Wikipedia with this idea of his. Yet, you conveniently elected to not alert me to this “RfC” of yours; I had to do one of my periodic checks on this thread to see what you are up to. This sort of move deprives that RfC discussion from the input of the editors here who have already weighed in on this issue and are no longer paying attention to this thread nor following your every move. You can hop-scotch over to Jimbo’s page and pitch what you want there. But even he doesn’t determine what occurs here on WT:MOSNUM; he has an abiding respect that the “community consensus is always the right thing to do.”
Discussions of how to change WP:MOSNUM must occur here on WT:MOSNUM. Period. Please drop this. You don’t win by being persistent to the point of a fault. When you have a consensus here to change WP:MOSNUM, then WP:MOSNUM will be changed. If you just want to get input from a new group that has less day-to-day familiarity with the goings-on here on MOSNUM and this talk page, then, be my guest. There is nothing wrong with that. But, please don’t commit the colossal error of running off to some other forum, obtaining a result you find favorable with a new audience, and then start making your edits to MOSNUM. Pages have their associated talk pages for a reason and you might well find yourself sanctioned if you try to change MOSNUM as a result of venue-shopping. What occurs over on the Village Pump may be interesting to you, but it is not binding on the content of MOSNUM.
In the end, I think you are wasting your time. If you want to change MOSNUM, you must achieve a clear consensus here. Greg L (talk) 18:38, 9 September 2009 (UTC)

(inserting response) Greg, your accusations of abuse of process are utterly ridiculous.
First, with regard to alerting you: presumably you watch this page and visit often, given your numerous contributions to this talk page? I notified everyone of my action, right where one would expect to see it—in the discussion thread. (Only absent my not-so-stealthy post and link, might you have had a reasonable cause for concern.)
With regard to your concern about venue shopping, the discussion on WP:VPP is a simple and straightforward way to discuss one sticking point (among the many facets of the MOSNUM proposals), without attaching the trappings of our prior argument. The idea is to keep things on-topic, without having to saturate the discussion with refutations of alleged "Europeanization" or the like.
It is also completely proper to ask relevant questions elsewhere, when the discussion here is deadlocked without consensus or compromise. I shouldn't have to explain that that is not a substitute for the detailed proposals at MOSNUM. Rather, it is a way to inform our discussion with the opinions of interested and relevant contributors (who frequent the policy- and science-related forums rather than MOSNUM). Unsurprisingly, that that's exactly the point of the Village Pump. This can lead to a viable consensus on an issue of mutual interest to VPP and MOSNUM, but that consensus would obviously only deal with the specifics of the VPP question, rather than forcing the adoption of a MOSNUM proposal.
As for depriving others of input from this thread: no, I clearly linked to this thread, and advised readers that they could consult it for further information, or comment in it if desired.
The words "pointlessly bureaucratic" were not mine—that's why they're in quotation marks. But I do sympathize with the sentiment. (I think it's overkill to make endless proposals about the question to pose—would you find that discussion particularly enlightening, and do you really foresee anything but a deadlock there as well?)
If you object to the framing of the question, that's fair enough. I made a good faith effort to seek advice (per your suggestion) and work out a concise, neutral phrasing with an uninvolved party. You suggested having a round of discussion to decide the question for a formal RfC, but then stated that you had no interest in participating—you can't really have it both ways. TheFeds 04:34, 10 September 2009 (UTC)

Quoting you, TheFeds: I don't believe that someone with a working comprehension of written English would be so hopelessly confused by that format as to fail to comprehend the meaning after a short pause to think about it. You might well be right. But, it doesn’t matter. The whole point of technical writing is to communicate with minimal confusion. What you are proposing is inconsistent with the teachings of Technical Writing 101.
Quoting you again: To me, the convention used by the BIPM is a necessary inclusion in the MOS because it is the dominant English-lanugage usage in some regions. Yeah, I got that much. I figured that bit out in the first four seconds after seeing what you were trying to do. MOSNUM and the editors who comprise it simply don’t care about how things are done “in some regions.” What matters is how things are done for the vast majority of readers for whom English is their first language. Italians, for instance, have their own Wikipedia and en.Wikipedia needn’t be unnecessarily muddling things up for those English-speaking Italians that choose to visit an article here. The whole point of technical writing is to communicate with minimal confusion.
Let’s touch upon why en.Wikipedia shouldn’t be kludged-up with multiple numbering systems in our general-interest articles in order to better accommodate readers for whom English is their second language. As I’ve previously explained, cross-Atlantic (or Pacific) recognition of alternative number-delimiting schemes unfortunately isn’t a two-way street. There are many ways the Europeans format numbers. In Sweden, the “Swedish1” technique (there’s yet another) is to write the population of America as “285.865.855” so why don’t we just go ahead and let articles here use that system too(?), right along with the BIPM method (which Swedish school children are also taught)? That’s a rhetorical question, please don’t answer it. The answer is because Swedish school children are also taught to recognize the American-style of delimiting numbers. In fact, Europeans by and large are not in the least bit confused when they encounter numbers with American-style delimiting. The trouble is that American’s know of only one way; they’ve been taught no other. That is why Wikipedia has long-used the most widely recognized method of delimiting numbers: it causes the least confusion (by far) over other methods that aren’t recognized by many English-speaking readers. The whole point of technical writing is to communicate with minimal confusion.
Quoting you: [Editors are given spelling freedom via] WP:ENGVAR, and choose instead to cater to one region's preferences. Wikipedia is written for an international, English-reading audience. That means that we need to accept that occasionally, a user may encounter a term or convention from elsewhere, and be briefly confused. But this is not a critical flaw… I see you don’t seem to mind (you don’t see it as a “critical flaw”) that readers might be “briefly confused” with multiple numbering systems. I do. And, why would we cause this confusion? So that editors from all walks of life (perhaps some editor from Africa who speaks in *!* tongue pops and also speaks English as his second language) can merrily write The population of Congo in year so ‘n’ so was 66020000 because he was the first major contributor. Given that Wikipedia is has an all-volunteer contributing authorship, allowing “lorry” in some articles and “semi-truck” in another is a reasonable and necessary compromise to address how editors in England spell differently from those in the U.S. and use different words—notably for nouns. Note however, that these are differences within the English language for those editors for whom English is their first language. It is patently absurd to think that an article on the Democratic Republic of the Congo is going to have a different numbering technique that is foreign to many native-English speakers because the first major contributor to the Congo article uses that numbering technique. WP:ENGVAR does not, should not, and can not apply here. Believe it or not, Wikipedia is not about us, the editors of Wikipedia; we write for our readership. The whole point of technical writing is to communicate with minimal confusion.
Even though you might not like to listen to others, please read comments from others, above, such as the words of Ohconfucius (04:13, 26 August 2009 (UTC) post), where he wrote The use of commas as delimiters is pretty much universal – the comma separator is not only American, it's Canadian, British, Australian, Irish, South African, Singaporean - which should take care of about 95% of the native English-speaking population. Things are done on the en.Wikipedia version of MOSNUM for a reason. Even if you don’t understand or agree with those reasons, you must accept the consensus view here. The whole point of technical writing is to communicate with minimal confusion. Is that sinking in yet? Your argument that “brief confusion” is “not a critical flaw” is bizarre and wholly uncompelling. Greg L (talk) 23:00, 9 September 2009 (UTC)

You're needlessly repeating your statements from above (almost verbatim in places). Repetition doesn't bolster your arguments.
Your invocation of the Italian Wikipedia seems to me like a fundamental misunderstanding—nobody is proposing using Italian-language style here. As I pointed out above—and you overlooked again—English-language usage is at issue. (Do the Swedes use Swedish dots in English? Probably not. BIPM with spaces? Probably.) And you're stating that English as a first language is the determining factor. That's not what "English-speaking" means. (I've already presented several counterexamples, like India.) If you mean to advance that as a proposition, then do so, but avoid presenting it as axiomatic.
When, in reference to things like "truck" and "lorry", you say "these are differences within the English language", you make a false distinction: consider digit grouping schemes mentioned in the European and American manuals of style—they are obviously both "within the English language". And that fact is not influenced by whether or not some editors have English as a first language, or otherwise.
You're also implying that Wikipedia 101 = Technical Writing 101. Unfortunately, you're wrong. In short, technical writing can often be geared to a specific and generally well-educated audience with easily-ascertained expectations. Wikipedia, because of its diversity of readers and contributors, has chosen (by way of guidelines and precedents) to use regional (or other) styles in some instances. If you disagree with that, it's incumbent upon you to raise that discussion at an appropriate level.
I will, however, grant that your opinions about minimal confusion are a convenient approximation, though not a well-formed universal solution to the issue of how to present text in a manner that is effective and appropriate. If "minimal confusion" was an obvious and infallible dictum, we wouldn't need to have discussions about much of the MoS. The fact that we disagree on certain points of style—just as others have disagreed before on other topics—is ample demonstration that your doctrine does not make conclusions about style self-evident.
So what of the "brief confusion"? Although we both know what a lorry is, you must concede that an American reader might not—he might be briefly confused, until he clicks the wikilink, or figures out from the picture of a truck what is being referred to. That is more confusing than number formatting (a wholly-unfamiliar word vs. groups of digits that might be read as a number), and yet, for good reason, it is permitted on Wikipedia, even in an article that has nothing to do with Britain, but which speaks of lorries in some other context. Minimal confusion would dictate that we prescribe the most common form among our readership—which would probably be "truck" in deference to the plurality of American readers of Wikipedia. Because this is an unacceptable simplification to many readers and editors alike, regional and topical conventions that enjoy wide English-language adoption should likewise be accorded latitude despite the potential to briefly confuse whatever other group might be slightly disadvantaged.
Furthermore, by exclusively requiring one region's style (even granting its greater adoption), you systematically disadvantage the significant set of English speakers who do not employ that convention in properly-constructed English-language usage. That can be construed as a bias, and has been the subject of many arguments. By having MoS guidelines that account for regional or topical conventions, we assure readers that they will receive an acceptable format for the subject of their inquiry, and for the editors, specify a reasonable link between the style and the content to minimize ambiguity. We therefore avoid controversy about why a British subject is described in American style. By extension, this implies that the most interested editors will have justification for employing the conventions that are most appropriate to their area of interest or expertise.
To extend that principle, for the articles that do not have well-defined regional or topical links, one could perhaps prescribe a house style, and still present the topic in an appropriate format and avoid the potential for formatting disputes. (This seems to be what you're suggesting with your Congolese example.) But based on precedent, Wikipedia has specifically chosen not to do that—it instead falls to the first or major contributors to pick formatting conventions for the article. (That precedent and its associated consensus are clear and directly applicable to the present discussion.) This also has the side-effect of allocating bias in rough proportion to the number of major contributions by various groups, rather than biasing all such articles in favour of one popular style.
I'm citing well-founded precedents like WP:ENGVAR, and describing a balance between the competing objectives that must necessarily be considered when policy is at stake. I think that this represents a fairer approach to Wikipedia policy than steadfast and singleminded advocacy for "minimal confusion" as the principal doctrine of the MoS. TheFeds 04:34, 10 September 2009 (UTC)

Fine. We’ve both had our say. Now, please convince the others here that using a numbering system that isn’t used by some 95% of readers for whom English is their first language is the right thing to do on en.Wikipedia. Your aren’t convincing me with your arguments, which I find to be shear nonsense. Moreover, your responses are revealing a colossal inability to absorb the simple basics of my points, such as Italians and English and readers for whom English is their first language. So it is quite clear that I am wasting my time by further arguing with you. If I or the others here don’t want to respond to you any more, please don’t consider that to mean that we concur with you; it just means we’ve tired of this. If you run off to some other venue and find three editors who will soon graduate from junior high school who agree with you, don’t confuse that with having achieved the necessary consensus; you need to obtain a consensus here on MOSNUM’s talk page. Merely because you demonstrate an uncanny willingness to flog a dead horse until the heat death of the universe isn’t going to give you a *win* here. The only clear consensus so far is for MOSNUM to stay as it currently is and long has been. Your persistence in the face of this simple reality is troubling. Greg L (talk) 14:36, 10 September 2009 (UTC)

← I believe TheFeds' question on VPP was way too vague to be of any use, and that discussion doesn't seem to be going anywhere, anyway. I'd go with a two-step schedule as was done on WP:DATEPOLL or WP:IECVOT: in step 1, we create a page (I'd use a subpage of this talk page) where an editor can make a proposal, discuss about other editors' proposals, and tweak his/her proposal to address the points made by other editors. In step 2, no further edit is allowed to the proposal, and editors will be allowed to vote for proposal using a decent voting system (I'd go with the Schulze method). The first step should be advertised here, on WT:MOS, on WP:CENT, on WP:VPP and WP:VPR; the second step should be advertised as widely as possible on Wikipedia, including a watchlist notice. As for the time schedule, I'd go with seven days for each step. After the second step is concluded, the proposal which wins according to the chosen voting system will be incorporated in WP:MOSNUM to stay unchanged for six months. Or something like that. --___A. di M. 15:09, 10 September 2009 (UTC)

I'm a little curious about your objection, because as I explained to Greg, the intention is not to mandate a particular style proposal through WP:VPP. The question is phrased that way because VPP is the most appropriate place to discuss policy implications that affect the site, and limited in scope because the specific proposals from above should not be discussed at VPP.
As for the RfC mechanism you've outlined, that level of formality is—I think—inappropriate for the limited question asked at VPP. The RfC process you outlined tends to be used for votes on fully-formed proposals—and I could support that procedure if we were voting on entire MOSNUM proposals. But for a policy consultation, it's not a good fit. TheFeds 16:33, 10 September 2009 (UTC)

Indeed, I think that discussing specific wordings would be more useful than discussing vague general principles. (Two persons might agree on a principle but disagree on the way to implement it, or they might agree in giving some recommendation of style but for different reasons.) --___A. di M. 17:54, 10 September 2009 (UTC)

(inserting response) That's a fair comment, and I accept the possibility of different interpretations arising from the policy consultation. However, I think that the comments on VPP are, despite their limited scope, valuable as a sanity check against the unsupported assertions made in this thread (especially the opposing common-sense interpretations that Greg and I have offered). Let me reiterate that the VPP process complements the MOSNUM process, but does not replace it. (Despite Greg's unjustified insistence that I subscribe to that theory.) TheFeds 00:22, 11 September 2009 (UTC)

I agree with A. di M. I told you this once, TheFeds, about how to properly conduct an RfC but you didn’t take the advise and ran off to the Village Pump to do your thing all by yourself. Ill-considered, biased RfCs are nothing but pure trouble on Wikipedia. You have two choices now. 1) drop it, or 2) do things the right way and begin the process of creating an RfC that both sides work on until it is fair, complete, clear, and balanced. And then the RfC, which must be conducted here if it the result is to be a change to MOSNUM, goes live and the editors who frequent MOSNUM (and anyone else who wants to come here) can register their opinion. As to why you would persist at this seems wholly unrealistic given the above reaction of many of the editors here. But if there is to be an RfC, then we should do what worked well with Ryan’s date-linking RfC:

A simple, unbiased preamble explaining the essence of what it’s about
Statement of the existing wording.
Statement of the proposed wording.
A 300-word “for” essay
A 300-word “against” essay
Room for editors to state how they feel about the proposal (you know, what the losing side calls “!votes”)

If you want to waste your time (and that of others), you can kick it all off and take care of points 1, 2, 3, 4, and 6. I’ll volunteer to be the lead shepherd with #5 (with help from others).

I suppose there is a third option for you: to endlessly keep on arguing this on the assumption others will come around to “see the light of your reasoning”. If that’s the case, then it might be time to just let you rant here all by yourself. There is no rule that says anyone has to respond to you. Greg L (talk) 19:26, 10 September 2009 (UTC)

Greg, are you overlooking what I wrote above? I've already explained to you that I see a distinction between the RfC procedure above, and a policy reference question on VPP. You pretend to speak with authority about RfCs, when it appears that you're just substituting that procedure for a process you dislike. You had a perfectly good chance to express your opinions, and make constructive suggestions, and instead you expressed disinterest in further discussion and wanted this thread to go away without consensus or compromise. TheFeds 00:22, 11 September 2009 (UTC)

Given all of the above, in lieu of the discussion and compromise on the MOSNUM proposals that I referred to in the previous subsection, is there now interest in conducting an RfC offering a choice between proposed changes to WP:MOSNUM? (Let me distinguish that from the question that I posed at VPP, which was clearly not a question about one proposal versus another, and was not intended as such.)
To be perfectly honest, I'm not sure that there's strong enough interest to expect a meaningful RfC result (as in, a response from people other than those who have already clearly expressed their opinions).
I am ambivalent about the need to go through all of that formality over a paragraph in the MOS: I would be weakly opposed on those grounds. But I'm also concerned because I believe it will become mired in meta-debate. And that meta-discussion, especially if conducted by Greg in the style he's employed to date in this thread, will probably be marked by the same incivility, unwillingness to compromise, and tritely-phrased misrepresentations that he employed above. If it's likely to end up like that, I would oppose it.
There's also the broader question of whether we tacitly support a proliferation of RfCs to resolve simple changes that lack clear consensuses. I'd say that this debate is somewhat unique, in that it's lacked widespread input, is not of critical importance, and yet has consumed a lot of text. Are we saying that when mundane proposals go bad, we should proceed to an RfC, rather than first trying less formal tools for advancing the discussion? TheFeds 00:22, 11 September 2009 (UTC)

Quoting you: Are we saying that when mundane proposals go bad, we should proceed to an RfC, rather than first trying less formal tools for advancing the discussion? Uhm… yeah… apparently. It’s clear as glass from the responses from me, A. di M., Ohconfucius, and Tony during these “less formal” debates that there isn’t much enthusiasm for what you are proposing. Yet, here you are again, hammering away on the same ol’ issue. If you have to go to a properly-conducted RfC to smell the coffee, then I guess that’s what it takes. Wearing out your keyboard until everone’s eyes glaze over and we all cry “OK, I can’t take it any more so you get your way” isn’t in the cards. After over 100 kilobytes (really) of verbiage on this, you are no closer to achieving a consensus here to introduce a mishmash of two different numbering schemes in the general-interest articles of the English-language version of Wikipedia than you were from the start. Nothing’s broken so there is no enthusiasm to fix anything. Greg L (talk) 05:52, 11 September 2009 (UTC)

Back to the point. I come fresh to this debate, and was not aware until now that it was going on. User:Greg L is correct in proposing that numbers (to the left of the decimal point) be delimited by commas. But contrary to what Greg L perhaps assumes, it is not only an American thing, it is normal practice here in Britain too, so covers most of the mother-tongue-English-speaking world, in terms of population (apologies to Canadians and Australians). If it is true as alleged that the BIPM style is dominant in some English-speaking regions, they must be very much in a minority.

BIPM (of which I had never heard until today), based in France, appears to be trying to impose French practice on the rest of the world. I can reveal from personal experience that the only reason the European Commission translation service's English style guide lays down the BIPM policy in this particular respect (it does not do so in many others) is because they are translating thousands of documents every day from French to English, and for purely technical reasons it makes their lives much easier just to leave the numbers in the French format. The people who work there are well aware that this isn't normal British practice, and is a departure from the usual EU policy of using British English, but they have adopted a pragmatic compromise to save time and money in their particular special circumstances.

The Oxford Dictionary for Writers and Editors (a British publication) says:

Use commas to separate each group of three consecutive numerals, starting from the right, when there are four or more, except in math. work and pagination; in scientific and foreign-language work thin spaces are used instead of commas.

-- Alarics (talk) 13:35, 13 September 2009 (UTC)

Al, Canadians use the same numbering system, and as to BIPM, according to a recent press release, the Republic of Kazakhstan acceded to the BIPM on 31 December 2008, which kind of makes it seem that nations are "coerced" into the accord, one by one? FWiW Bzuk (talk) 13:53, 13 September 2009 (UTC).

Right, so even if we assume that the French-speaking Canadians use the French system, that's another 20 million English-speakers on our side. Can we ask User:TheFeds, when he writes of the BIPM style that "it is the dominant English-language usage in some regions", which regions he has in mind? -- Alarics (talk) 16:03, 13 September 2009 (UTC)

That applies primarily to Continental Europe, where people use dozens of languages with regularity, but where English (as a second language) is a common denominator across most regions. There are, conservatively, at least 100 million English-speaking Europeans, not counting the British and the Irish (and by some estimates, over 160 million).
And at least in my experience, publications written in or translated into English in Europe use the BIPM style. (To cite a particular example, many French graduate schools use English as the language of instruction, and students write their theses in English.)
It might well be that the EU wishes to simplify their transcription of documentation from French to English by prescribing that style—but I suspect that the motivation goes a little beyond economy. In my estimation, because many European regions have their own traditional conventions in their native languages, and just as Europeans have settled upon English as a de facto language of collaboration and commerce (albeit while trying to maintain their regional dialects for culture's sake), they've settled upon the BIPM-style digit grouping to reduce ambiguity in communication. For example: the traditional French convention was commas for the decimal place and periods for digit grouping—the inverse of British usage, and obviously confusing. (In other words, I don't think the EU or BIPM is trying to push French style on everyone.)
Additionally, the BIPM convention is understood in English Canada, and has been taught in their schools for many years. (As well as being universally used in French Canada.) You're quite right about Britain, though; they do prefer the comma-based style. I'm not completely certain about the rates of usage in Australia and New Zealand, but I can scarcely imagine that either convention would be unfamiliar to them—I'd speculate that they are somewhere between Britain and Canada in terms of usage. TheFeds 04:25, 14 September 2009 (UTC)

Let me also add that the question of first-language usage versus other-than-first-language usage came up above, and that it's a source of disagreement. I'm of the opinion that the existing Wikipedia guidelines are not intended to make such a distinction, and that it is reasonable to consider significant usage among major English-speaking populations, rather than sticking strictly to official languages.
As for the bigger picture, it's an open question whether Wikipedia should allow regional usage in region-neutral articles, or insist upon a fixed style—but that's not really even the heart of the issue as it relates to MOSNUM. TheFeds 05:47, 14 September 2009 (UTC)

Conclusion

It's pretty apparent that the discussion above has been inconclusive. The discussion ended up as a back-and-forth between myself and Greg L, and my attempt to seek policy advice from WP:VPP didn't shed any light on matters.

If the proposals are stale, then there's only one more order of business: establishing what the consensus was for digit grouping, so that we can revert to it.

Let me preface by saying that this is in no way a personal attack—quoting Greg L:

...One other note: en.Wikipedia adopted the U.S. style and standardized on delimiting to the left of the decimal marker using commas. Let’s please accept that nothing in this debate can change that and limit the discussion to the number of digits per group.
— Greg L, 15:16, 8 October 2008 (UTC), WT:MOSNUM Archive 112

...Now, Gerry, let’s get real shall we? I’ve mentioned several times above that en.Wikipedia adopted the US convention of delimiting to the left with commas. Nothing we’re discussing here is ever going to change that fact. The people over on fr.Wikipedia will keep doing as they like. As I wrote several times above (it would be nice if you actually read some of the goings-on here because I’m way ahead of you here) this practice of comma-delimiting to the left is far too entrenched in the U.S. and across the Internet for you to change that with your above epiphany. None of us here in this debate on this mote of a backwater discussion is going to change the way the U.S. works in this regard nor en.Wikipedia’s adoption of that widespread convention. As I also wrote above, this is an issue of simply adhering to the three-digit practice that is common throughout Europe and which has been standardized for use with the SI....
— Greg L, 18:07, 9 October 2008 (UTC), WT:MOSNUM Archive 112

That is from the discussion that brought about the phrasing that Greg reverted to (kicking off this lengthy discussion). It's focused on the RHS of numbers, rather than both sides of the decimal point. When other users mentioned that SI/BIPM prefer spaces on both sides, there was really only one argument for (what we later discovered to be) the U.S. GPO style—Greg asserted that it was a fait accompli that commas were used on the LHS by Americans, and said that Wikipedia might as well go along with that well-entrenched usage.

But because of that, the thread avoided discussion establishing why commas-on-the-left should (or should not, or should sometimes) be the preferred format. It bypassed the concern that SI compliance would entail spaces on both sides, and instead dealt with the RHS digit grouping to define the behaviour of {{val}}. As a result, no consensus was formed about what to do with the LHS.

It is, however, where the (permissive) technical usage clause comes from (courtesy of A. di M. as Army1987)—that part seems affirmed by consensus.

To find a discussion that arrived at a consensus on how to group the LHS of numbers, or to find an overarching agreement on both the left and right sides, we're sort of out of luck. Going back much further, MOSNUM used to say to use commas only (without regard to any special cases)—but that was basically just an arbitrary convention that hadn't been extensively discussed, and wasn't uniformly followed. Even in Archive 19, and Archive 74, consensus was absent, and the issue was dropped without formal proposals or major revisions to WP:MOSNUM.

On another note, I'm going to quote Greg L again here:

SI is clearly a wonderful thing, and it is so because it doesn’t unnecessarily push the “Euro” way of doing things over the “U.S.” way, nor visa versa. The SI acknowledges and embraces practical reality. “Full SI writing style” recognizes delimiting via either commas or narrow spaces in the mantissa because that’s the reality of the American style of delimiting numbers. Like it or not, there’s simply no fighting it; that style is extraordinarily common and well entrenched—both in print and on the Web. Wikipedia—like the BIPM and their SI—can’t find itself in the position of trying to promote change in the way the world works by pretending to adopt a single style of numeric notation that isn’t well recognized in the U.S. The whole point of encyclopedias is to unambiguously and clearly communicate. Intuitively easy, familiar writing customs must be observed. There is no “right” or “wrong” with regard to commas or narrow spaces in the mantissa—not according to SI and not according to common sense simply because the English-language version of Wikipedia is read by readers in both Europe as well as the U.S. Accordingly, Wikipedia (and in the SI) recognizes both methods. We don’t have to agree that Wikipedia should adopt one style or the other with regard to delimiting the mantissa…nor should we. We can simply make two versions of a numbering template (or an option to check in a single template). Trying to necessarily link the treatment of the decimal portion to how we delimit the mantissa will only doom to failure any efforts here. We should address only one issue: should a template be made to make it easier to delimit the decimal portions to make long strings easier to read(?). My point would be that narrow spaces are so damn easy to read, that even a novice who has never seen it before instantly understands what it’s all about. And in articles where numbers are important, delimiting is crucial because long strings of non-delimited digits to the right of the decimal point unusable to the point of being barbaric. There should be an easy way for others to do so (rather than hand-coding it all).
— Greg L, 03:59, 20 December 2007 (UTC), WT:MOSNUM Archive 94

Strangely enough, that's a lot like what I was talking about. Yes, there are distinctions, but they are minor; that argument was used in a discussion about how to deal with the RHS of numbers—group in threes, fives, or don't group at all. (I'm wondering what's so false about Greg's previous argument that it doesn't apply any longer.)

In any event, the question of what level of confusion will result, or is acceptable in this case is not settled. And we haven't done justice to weighing the need to limit confusion versus other objectives on Wikipedia.

Later on, when Jc3s5h and I were allegedly trading campy ideas, there was in fact a substantial discussion about digit grouping (related to my edits). After a shaky start, where we got sidetracked over some possibly-misremembered standards, we consulted style guides, got input from a few editors (in addition to the regulars), looked at the archives, and managed to formulate a proposal that was not opposed. Now that's not necessarily the same as a clear consensus—because there were really only three of us commenting upon and implementing the final draft.

But it's certainly better on basing our treatment of delimiting in general on the results of a series of discussions that were specifically framed to deal only with RHS delimiting and templates, or which (going back several years) were more concerned with the thin-space handling in IE6 than digit grouping per se.

The take-home message is therefore this: the long discussions on MOSNUM were primarily based on how to handle {{val}} and its relatives, not to set a policy for numbering styles in general, and certainly not to require a particular convention. The question of regional usage per WP:ENGVAR is not settled—the VPP reference question was split, and we've hardly resolved any of that here. The question of technical usage was agreed upon previously.

Unless someone wants to resurrect the proposals, maybe we should just call this a "dismissal without prejudice": one of these days, when someone works up the courage to propose a resolution (maybe even through an RfC, if that option is more popular than traditional discussion), we can revisit this topic properly, with a more thorough and civil discussion, and buy-in from a sufficient cross-section of editors to establish a clear consensus one way or another.

In the meantime, all we've really got is consensus on how to make the RHS work (especially in templates), and how to use SI-style notation in technical articles. Let's accept that at face value, and move on. TheFeds 06:33, 21 September 2009 (UTC)

For the digits to the left of the decimal point, MOSNUM currently says:

Numbers with five or more digits to the left of the decimal point (i.e., 10,000 or more) should be delimited (visually separated into groups so they can be easily parsed) using commas every three digits; e.g., 12,200 and 255,200 and 8,274,527 etc.
Numbers with four digits to the left of the decimal point may be delimited with a comma; that is, there were 1250 head of cattle and there were 1,250 head of cattle are both acceptable.
In scientific articles, particularly those directed to an expert readership, numbers may be delimited with thin spaces using the {{gaps}} template.
The style of delimiting numbers to the left of the decimal point must be consistent throughout an article.

This appears to coincide almost precisely with the instruction I quoted some way up this page, from the Oxford Dictionary for Writers and Editors:

Use commas to separate each group of three consecutive numerals, starting from the right, when there are four or more, except in math. work and pagination; in scientific and foreign-language work thin spaces are used instead of commas.

Is TheFeds now saying we can leave that as it is? That would suit me fine. -- Alarics (talk) 11:32, 21 September 2009 (UTC)

It's not that I've changed my opinion on this subject, only that I don't feel this particular thread is going to lead us to a resolution. Basically, I'm expressing the fact that we haven't found a consensus for many of the issues that came up in this and previous discussions. Most importantly, there's no basis (past or present) to declare that any one (or any set of) digit grouping schemes enjoy consensus for anything other than technical articles.

However, this wouldn't be the only thing in the MoS that exists despite a lack of specific, widespread consensus, but which is unchallenged due a feeling that it has a low priority, or outright disinterest. As long as it is very clear that it is a permissive, rather than prescriptive guideline (e.g. "may" rather than "must", etc.), I expect that we won't see undue pressure to reject or apply one style or another.

So, I'd say the text should be minimally amended to say "...should be delimited (visually separated into groups so they can be easily parsed), such as by using commas every three digits..." to avoid the impression that a consensus exists on the minutiae of the issue. TheFeds 04:01, 22 September 2009 (UTC)

xt?

Wasn't there a proposal to do an uplift of the use of {{xt}} on the MOS/MOSNUM just a while ago? Did that die? Headbomb {^ταλκ_{κοντριβς} – WP Physics} 20:12, 9 September 2009 (UTC)

What does “uplift of the use of”… mean? Use it more extensively throughout the two style guides? I started to update MOSNUM with more of it, but it is damned slow and tedious. Greg L (talk) 20:19, 9 September 2009 (UTC)
- Greg, paste into Word and use a macro (comprising open finder, type " into the find box, search next, delete, type in the xt opening option-right-arrow, etc ...: so easy! MoS main needs the same treatment, but don't worry: all is in hand. I think an editorial note at the top reminding users of the xt thing would be desirable. Tony (talk) 09:58, 10 September 2009 (UTC)

By "in hand" do you mean someone is doing it? If you want, I am happy to convert most "Do it like this." examples to "Do it like this." (using something better than Word). What about this existing text: There is no such ambiguity with recurring events, such as "January 1 is New Year's Day". Should the text in quotes be in an {{xt}}? Johnuniq (talk) 10:31, 10 September 2009 (UTC)

Johnuniq: Fantabulous. I certainly don’t have “a problem” with volunteer efforts like that! Greg L (talk) 23:32, 10 September 2009 (UTC)

This is a little besides the point, but I just find the existing shade of green rather ugly and hard to read on the existing default background color (a sort of very faint aquamarine or sky-blue) that most editors (and I) keep. —— Shakescene (talk) 23:37, 10 September 2009 (UTC)

The {xt}-shade of green is a compromise that has been tweaked and tweaked so the loud din of complaints has largely diminished to a mild case of tinnitus. Tony, for instance, has a 24-inch iMac and to listen to him, {xt} produces a Liberace/fluorescent-green that could only be produced by an explosion at the Disney factory. Simultaneously, still other editors with Barbarian-OS PCs and horribly tuned monitors with gammas set to near-infinity sometimes complain that the {xt}-green is nearly indistinguishable from regular black text. The current compromise value—while perhaps not perfect—seems to have minimized (though not entirely eliminated) objections. Greg L (talk) 05:19, 11 September 2009 (UTC)
FWIW, the standard gamma approved for use with the World Wide Web is the one used by PCs (in which the squares in have uniform luminosity), not that used by Macs. Browsers running on OSs using different gammas are supposed to compensate. --___A. di M. 08:49, 11 September 2009 (UTC)

Hmmm… I switched my gamma setting from “iMac” to “Wide Gamut RGB” and the center squares disappear without the need to tilt my LCD display at what appears to be a 30° angle. In fact, they disappear when the monitor is tilted just about dead-on square with my eyes. That suggests there is some technological “magic” underlying this. Unfortunately, neutral grays take on a distinctly bluish cast. And (no surprise here), {{xt}}‑generated text is quite a bit darker. The display also went much darker but I easily compensated for that via a brightness boost. I’m going to try this for a few days—if I can.
Truth be told, accurate color work is impossible on this 17-inch iMac because the parallax change caused simply by scrolling the above color-swatch from top to bottom of my screen causes the center squares to go from noticeably too-dark to too-light. My really, really good Sony 21-inch CRT monitor is still attached to my old Mac, which will forever be “Peter Pan”ed at OS 7.5.5 so I can continue to use a certain CAD program (I really scream on that old wire-frame application). Now that monitor is for high-fidelity work with color. Greg L (talk) 18:30, 12 September 2009 (UTC)

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)

~~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)

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)

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)

Yes, by all means go ahead with that limited change, for what it's worth. Alarics (talk) 21:09, 20 September 2009 (UTC)

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)

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)

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)

(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. _wjemather ^bigissue 21:54, 20 September 2009 (UTC)

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)

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)

smile: ahh, another literal-minded sort! i meant "go for the editrequest". Sssoul (talk) 10:04, 21 September 2009 (UTC)

Yes, I think this is a good first step. Dabomb87 (talk) 12:27, 21 September 2009 (UTC)
- Looks fine, but can we have the hyphen back in "all-numeric"? You could remove "they are often ambiguous in that", and the two "the"s could be removed from "the day or the month". I like the bracketed use of both formats. Tony (talk) 13:13, 21 September 2009 (UTC)
  - The edit request which I made (and I see has been implemented) used the first version of the wording I proposed in this section (the one with the bullet and no border or background), which I think it is as terse as it could be while remaining reasonably readable. --___A. di M. 15:17, 21 September 2009 (UTC)

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)

Summary done

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

Specific proposal on YYY-MM-DD

I propose to put to an RfC and centralised discussion the following change:

Present text: YYYY-MM-DD style dates (1976-05-31) are uncommon in English prose, and should not be used within sentences.

Proposed text: YYYY-MM-DD style dates (1976-05-31) are uncommon in English prose, and should not be used in sentences or footnotes.

-- Alarics (talk) 18:29, 29 September 2009 (UTC)

The RfC has now been set up at Wikipedia:Mosnum/proposal_on_YYYY-MM-DD_numerical_dates. All are invited to add comments in support or opposition, giving succinct reasons. I hope people will confine their remarks to this specific question and not merely reproduce the rambling conversation we have had on this page. -- Alarics (talk) 18:47, 29 September 2009 (UTC)

- I and Alarics added this to Template:Centralized discussion at almost exactly the same time, so it's now a fusion of our two wordings, as at the right. (Since I hadn't learned the specialized [as opposed to the everyday] meaning of "deprecate" until well into the Great Date-Autoformatting War, I changed the word to "disapprove", although "discourage" [my original word] or some other word might convey the meaning better. And if you don't like "like", feel free to change it to "such as", "for example" or "e.g.".) —— Shakescene (talk) 05:49, 30 September 2009 (UTC)

Having looked at the RfC results so far, it is becoming clear now what the proper solution is: appoint three editors who have journalism degrees to oversee MOS and MOSNUM and kick all the neophytes—including me—out of it. If there is anything that ought to be truly “professional” it is MOS and MOSNUM; all else can suffer from the standard drive-by shootings by youngsters who don’t know what the hell they are talking about. The two things in common to many editors here is they 1) think they know what they are talking about (citing new international standards such as IEC prefixes like “mebibyte” and “kibibyte” or ISO 8601 and how this somehow constitutes an excuse to use them on Wikipedia), and 2) they actually know precious little about technical writing. Wikipedia is just a playground for the galactically clueless to nourish their self esteem. It is just so absurd. I find this phenomenon to be simultaneously amusing and disgusting. Greg L (talk) 21:28, 30 September 2009 (UTC)

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 kilogram_force-meters to Newton meters & foot-pound_force 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 kilogram_force-meters & Jimp says we should use kgfm. I say we should use ft-lb for foot-pound_force & 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)

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⁻⁶ 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)
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)

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-pound_force”), 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)

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)

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)

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)

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)

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)

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-pound_force” 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-pound_force” 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)

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-pound_force 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)

I'd use either "kg_f·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)

That sure is a “local style”. Seems especially novel. Greg L (talk) 03:31, 22 September 2009 (UTC)

I'd would agree that you should use "kg_f·m" for kilogram (force) metre and also suggest that you use "ft·lb_f" 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)

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)

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)

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)

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)

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)

(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)

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)

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)

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)

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)
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)

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)

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:

Is “kg‑m” (without the “f” suffix to denote force) far and away the most common form in the real world(?), and…
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)

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)

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)

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)

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)

(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)

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)

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)

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"/"kg_f·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)

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/cm², 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)

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-lb_f, kg_f-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)

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)

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)

Template:Convert/list of units/torque Thoughts? 「ɠu¹ɖяy」¤ • ¢ 23:36, 22 September 2009 (UTC)

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)

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)

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)

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)

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 "MW_e" and "MW_th" 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)

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)

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)

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)

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)

Articles have been separated; Foot-pound (energy) & Pound-foot (torque). 「ɠu¹ɖяy」¤ • ¢ 03:14, 23 September 2009 (UTC)

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)

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)

Thank you to you all, Gu1dry, Hrothulf, and LeadSongDog. Greg L (talk) 19:40, 23 September 2009 (UTC)

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)

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)

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)

Newton meters needs to be coded twice, due to their measurement counterparts (kilogram_force-meters & foot-pound/pound-foot). 「ɠu¹ɖяy」¤ • ¢ 00:06, 24 September 2009 (UTC)

Righto. Greg L (talk) 00:32, 24 September 2009 (UTC)

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)

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)

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)

I have added the conversion factor/N·m to the table, please correct me if I am wrong. 「ɠu¹ɖяy」¤ • ¢ 05:24, 24 September 2009 (UTC)

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:

Measures are things like volume, length, temperature, and mass.
Units of measure are liter, meter, degree Celsius, the kelvin, ohm, pound, and kilogram
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)

All of it is right here: Template:Convert/list of units 「ɠu¹ɖяy」¤ • ¢ 19:04, 24 September 2009 (UTC)

Gad! I woulda fixed it, but it’s a bunch of tranclusions and I’m busy right now. I just gonna re-post this on the associated talk page. Greg L (talk) 21:05, 24 September 2009 (UTC)

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)

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)

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)

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. _wjemather ^bigissue 20:02, 23 September 2009 (UTC)

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)

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

Actually I'm looking at MOSNUM and thinking it might be easier to use (and possibly maintain) if split into MOSNUM and MOSDATE. Each part is long and complicated enough, and one doesn't really affect the other (does it?), and it would make summary in MoS slightly easier. Rd232 ^talk 08:32, 29 September 2009 (UTC)

Support the split proposed by User:Rd232 - whilst dates may actually be stored as integers (sorry, but I'm a computer database specialist), they are displayed as text. I know of no common instances where dates and numbers are interchangeable, although they may occur together (eg. "Six days later, on 29 September 2009, agreement had not yet been reached") --Redrose64 (talk) 10:12, 29 September 2009 (UTC)

Support also. Dates are bloody difficult because there are seventeen different things aysing how to do it. (I will give examples later.) So lets split it so we can discuss it. SimonTrew (talk) 00:21, 2 October 2009 (UTC)

Gatekeepers with journalism degrees?

I had a post, above, where I suggested what I wasn’t seriously thinking would really be adopted: Appoint three editors who have journalism degrees to oversee MOS and MOSNUM and kick all the neophytes—including me—out of here. And that started me thinking… who the heck here actually has a four-year degree in journalism? If we can identify three such experts, we could, conceivably, appoint them to special positions here. Anyone… anyone? Before we get bogged down in what special responsibilities they might have, let’s first identify who these editors, if any, might be.

P.S. Please spare the rants about how others with elite privileges might infringe on your God-given right to influence the universe through Wikipedia. Let’s reserve the infinitely expandable white space, below, for those who have journalism degrees to identify themselves. Greg L (talk) 22:17, 30 September 2009 (UTC)

If only I had confidence that a journalism degree qualified one to opine on matters of punctuation and style... A glance at my daily newspaper disabuses me of that notion quickly. Powers ^T 22:55, 30 September 2009 (UTC)

Seconded. Simple grammar and punctuation issues abound in the local publication, which is by no means a small-town rag. I have little confidence in this suggestion. Shereth 22:59, 30 September 2009 (UTC)

Speaking as someone who had to proofread the technical documents written by the professional writers before they went out to the clients (because we didn't want to look like complete idiots), I don't think it looks like a solution. This is not the Second Punic War, we don't have to appoint a dictator to make all the decisions. (In fact it reminds me of a bunch of archeologists arguing about Etruscan pottery.) RockyMtnGuy (talk) 23:20, 30 September 2009 (UTC)

Oh, well… What outstanding arguments for those with no formal training in journalism to reign supreme; the experts are all screwed up! That’s why we don’t look towards the internationally distributed, English-language Encyclopedia Britannica for guidance, the pros over there don’t inspire “confidence.” Greg L (talk) 00:18, 1 October 2009 (UTC)

¶ (edit conflict) Qualifications in journalism and formal certificates in journalism vary very greatly between countries and eras. In Germany, you can get a certificate in journalism from a higher technical high school. When I attended the University of California, Berkeley, which has educated hundreds of highly-professional journalists, the School of Journalism wouldn't even grant bachelor's degrees; undergraduates had to major in something else. (It's often thought infinitely more important to get a either sound liberal education that includes English and other languages, or to learn a specific field such as history, political science, economics, natural science, religion, international affairs or regional studies, or both.) And I think that even today, at least in countries where entry isn't governed (as it has been in England) by union and apprenticeship regulations, a large proportion of the best writers in journalism have always been those who never received (or even) sought any formal degree in journalism.

But knowledge of usage, grammar and punctuation is secondary to good writing for publication or broadcast, and good writing is only one of the skills a good reporter or editor must learn. So while I understand the sentiment (without agreeing with it), formal certificates in journalism would only be a peripherally-useful indication of ability to police the Manual of Style. The job, for better or worse, still remains with us. —— Shakescene (talk) 00:47, 1 October 2009 (UTC)

Well, actually, I agree with you Shakescene. I was really making a point with this thread rather than holding out any real expectation that we would limit the ability of those who don’t have the foggiest idea about technical writing to come here and have full ability to muck things up. I would say, however…

We should generally be parroting the major manuals of style (Chicago, the internationally distributed A.P., etc.) and also observe the practices of the internationally distributed, English-language Encyclopedia Britannica. WP:MOS and WP:MOSNUM should depart from these manuals of style only for an exceedingly good reason (and with a wide consensus). Permitting a cabal of naive kids to wade hip deep into MOSNUM and write that “binary storage may also be denoted using the IEC prefixes (kibibyte, mebibyte, etc.)” was industrial-strength stupid and never should never have happened. That practice lasted for three years and took mountains of effort and debate and bickering to undo. That whole time, Wikipedia looked foolish.

Now we have editors quoting stuff like how ISO 8601 means this and that. Doesn’t matter. Not in the least. Too much time is spent educating editors about common sense. All it takes now to qualify for editing MOSNUM is having been a registered editor for three days (to become an “established” editor). That doesn’t inspire me with confidence. Greg L (talk) 01:10, 1 October 2009 (UTC)

I think the whole mebi stuff actually made little impact outside MoS. I guess that was round about when I stopped visiting MoS, only returning when some particularly appalling change had occurred. The key thing with MoS is the majority of items are clear and obvious, those where there is a choice it matters more that a choice is made than that it is accurate to the nth degree. For example p.m. vs pm. And really those who think "we must cite according to Harvard/AP/AMA whatever if we want to be taken seriously" have it wrong. We need to provide clear citations and well laid out citations. Those who looks and say "tsk, they abbreviate Vl. instead of Vol." will never take WP "seriously" because they don't want to or because they are looking for something that WP is not. People for whom WP is useful take it seriously now. Rich Farmbrough, 05:16, 1 October 2009 (UTC).

More people still would take WP seriously if it didn't look so amateurish, and one reason it looks amateurish, to me anyway, is that the footnotes/references section of very many, if not most, articles is an appalling mess -- gross inconsistencies of presentation, above all, but also unnecessary information provided, necessary information not provided, and generally a widespread lack of understanding of the basics of citing sources. -- Alarics (talk) 10:12, 1 October 2009 (UTC)

When experienced (read: "old") journalists get tired of chasing leads, they sometimes graduate to the "copydesk" and get the title of "copyeditor". Sure, it wouldn't hurt to have some kind of participation from copyeditors, but they generally don't work for free. In the U.S., most of them follow AP Stylebook, so there are a few Wikipedia conventions they wouldn't care for. - Dank (push to talk) 15:07, 1 October 2009 (UTC)

Another reason why it looks amateurish is that it is amateurish. No-one's ever paid me one cent to edit Wikipedia (and I'm sure I'm not alone at that), so I can't see any plausible reason why I must behave as if I were. And a way to make people "take WP seriously" would be to write less bullshit in articles; most people don't even know the difference between a hyphen and an en dash, so even if there were no hyphen out-of-place anywhere in Wikipedia that'd not cause anyone to "take it seriously" by itself. ___A. di M. 15:48, 1 October 2009 (UTC)

A similar idea was actually tossed around at WT:FAC this week. That proposal suggested that all MOS pages be locked, and once per quarter gatekeppers (who should not be required to have a particular degree - something we can't verify anyway) would implement any changes that have reached consensus on the various talk pages in that time. This would help make the MOS a lot more stable and actually require consensus for making changes. Karanacs (talk) 15:55, 1 October 2009 (UTC)

That really tugs at a difficult duality in the Manual of Style: if it were just giving helpful guidance and tips about clarity, best practice and common practice, the manual of style wouldn't need to be locked down so that ordinary editors don't get vertigo when opinion and participation here changes, with consensus naturally evolving or oscillating in different directions (e.g. towards or away from certain formats or the use of certain conventions in punctuation). But for many purposes, such as evaluating Good and Featured Article candidates, it is seen as prescriptive rather than—or as well as–descriptive. —— Shakescene (talk) 04:07, 2 October 2009 (UTC)

Yeah, not to mention when bots and scripts get turned loose to enforce MOS conventions. A lot of people won't even bother to comment here because rather than advice on good practice, it's treated as the be-all-and-end-all battlefield of HOW WE WILL DO THINGS. And it's always the same 10 or 20 people with dug-in trenches who treat anyone happening in as if they are kibibyte guy all over again. Franamax (talk) 05:15, 2 October 2009 (UTC)

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)

... 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)

I can't see one illiterate character space there. Tony (talk) 07:53, 17 September 2009 (UTC)

Looks fine to me..—MDCollins (talk) 09:53, 17 September 2009 (UTC)

Me too. What is Sssoul talking about? Alarics (talk) 10:01, 17 September 2009 (UTC)

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)

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)

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)

So do we let the community know via VP and Centralized Discussion? Tony (talk) 11:16, 17 September 2009 (UTC)

If you say so. I have no idea what VP and Centralized Discussion are. Alarics (talk) 11:29, 17 September 2009 (UTC)

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)

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)

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)

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)

← (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)

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)

So the practice of practically every newspaper and book is "against nature", is it? Alarics (talk) 17:58, 17 September 2009 (UTC)

Wikipedia isn't a newspaper, or a book. I don't see the problem. - Denimadept (talk) 18:13, 17 September 2009 (UTC)

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)

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)

“Open nature [of Wikipedia]” is not an excuse for “Let me do it MY WAAAAAY” when it isn’t proper English-writing practice. Good grief. It’s posts like these that make me realize how it might be terribly unwise of me to argue a darn thing here. Greg L (talk) 18:11, 17 September 2009 (UTC)

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)

It’s like this: you’re right on that point, Denimadept. Good for you; that’s the Wikipedia spirit! Greg L (talk) 18:27, 17 September 2009 (UTC)

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)

{{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)

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)

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)

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)

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)

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)

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)

¶ 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)

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)

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)

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)

Go get ’em, Alarics. You’re doing a good job. I’m just checking in once in a while and watch as you and others expose some of these editors here to Technical Writing 101.” Greg L (talk) 22:25, 17 September 2009 (UTC)

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)

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)

I'm on board with Greg.--VMAsNYC (talk) 22:42, 17 September 2009 (UTC)

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)

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)

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)

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)

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 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)

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)

- 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)

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)

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)

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)

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)

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)

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)

"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)

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)

"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)

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)

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

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)

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)

No… I “get” it. Not everything here needs to be dreadfully serious. Thanks, Shakescene. Greg L (talk) 05:23, 19 September 2009 (UTC)

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)

It appears that Klingon language is at times exceedingly compact. According to The Klingon Language Institute, the phrase “Hab SoSlI' Quch!” means “Your mother has a smooth forehead!” We might find something good there. Greg L (talk) 17:21, 19 September 2009 (UTC)

¶ 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)

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)

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)

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)

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)

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)
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)

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)

You know because the media in the US uses MM/DD/YYYY and in Norway we commonly use DD/MM YYYY (not standardized, but in use), we get cases where even people get a lot of problem (You apply to appear for a US court, and get cases like this: http://www.aftenposten.no/nyheter/iriks/article1470803.ece (Google translate: http://translate.google.com/translate?prev=hp&hl=en&js=y&u=http%3A%2F%2Fwww.aftenposten.no%2Fnyheter%2Firiks%2Farticle1470803.ece&sl=no&tl=en&history_state0=). So it's extremely ignorant to speak frankly ... The last sentence is not true. No one has ever written a date like YYYY-DD-MM. We should use ISO 801 in all parameters in all templates. This is extremly important when for other language project (of course you can ignore this, but automatic translkations get a lot easier. So please, dont remove this option! Nsaa (talk) 17:03, 4 October 2009 (UTC)

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)

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)

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)

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. _wjemather ^bigissue 17:30, 19 September 2009 (UTC)

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)

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)

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)

(edit conflict x 2)

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.
It's so unfamiliar to many people that many don't even recognize at first glance that 2001-09-11 is even a date.
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.
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)

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)

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)

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)

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)

(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)

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)

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)

And we don’t just write out the name of the month, which is what all professional publications do… because why? Greg L (talk) 21:40, 19 September 2009 (UTC)

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)

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)

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)

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)

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)

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) _wjemather ^bigissue 09:22, 20 September 2009 (UTC)

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)

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. _wjemather ^bigissue 20:06, 20 September 2009 (UTC)

Your statements are uncivil and are shear nonsense. You have forfeited your right to be taken seriously. Goodbye to you on this issue. Greg L (talk) 20:29, 20 September 2009 (UTC)

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)

That was logic pudding that makes no sense at all. I can’t begin to chase down the convolutions of logic. Greg L (talk) 19:28, 20 September 2009 (UTC)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

(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)

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. _wjemather ^bigissue 20:10, 20 September 2009 (UTC)

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)

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. _wjemather ^bigissue 20:40, 20 September 2009 (UTC)

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)

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)

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)

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)

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)

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)

I also strongly oppose using ISO 8601 and other notations like it with other separators (e.g. 2024/04/27). 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).

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)

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)

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)

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)

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)

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)

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)

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)

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. _wjemather ^bigissue 17:00, 23 September 2009 (UTC)

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)

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. _wjemather ^bigissue 18:16, 23 September 2009 (UTC)

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)

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. _wjemather ^bigissue 18:42, 23 September 2009 (UTC)

(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)

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. _wjemather ^bigissue 19:15, 23 September 2009 (UTC)

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)

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)

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. _wjemather ^bigissue 19:54, 23 September 2009 (UTC)

(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)

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)

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. _wjemather ^bigissue 21:16, 23 September 2009 (UTC)

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)

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)

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)

(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)

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)

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)

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)

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)

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)

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.) _wjemather ^bigissue 07:20, 24 September 2009 (UTC)

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)

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)

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)

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)

(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)

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)

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)

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)

~~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)~~

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)

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)

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)

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)

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)

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)

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. _wjemather ^bigissue 00:31, 26 September 2009 (UTC)

←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)

Well count me as being OK with A. Vegaswikian (talk) 03:05, 26 September 2009 (UTC)

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)

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)

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)

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. _wjemather ^bigissue 07:57, 26 September 2009 (UTC)

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)

Thanks, of course I meant different, not opposite. (I'll be awake soon, hopefully) _wjemather ^bigissue 08:53, 26 September 2009 (UTC)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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? _wjemather ^bigissue 10:30, 26 September 2009 (UTC)

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)

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)

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/09" appears 91.9 million and 6,340 times in googles web and news searches.
"Jan. 1, 2009" appears 43.7 million and 177 times.
"January 1, 2009" appears 20.5 million and 111,000 times.
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.
"01/01/2009" appears 13 million and 1,840 times.
1 January 2009" appears 11.5 million and 2,870 times.
"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)

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)

[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)

For an example of what a centralized discussion would be like, please see a previous discussion on a similar topic, in Wikipedia:Manual of Style (dates and numbers)/Proposal on international date format. My advice on the procedural issue is to drop the matter. Whatever small benefit would come from banning YYYY-MM-DD in footnotes is not worth the hassle exemplified by that previous discussion. If we want to improve the encyclopedia, we all have better things to do than engage in longwinded and fruitless discussions about date formats. Eubulides (talk) 20:04, 26 September 2009 (UTC)
- Agree. I really couldn't care less if YYYY-MM-DD is used in footnotes, as long as it is discouraged in prose and not used in tables unless absolutely necessary. Dabomb87 (talk) 20:09, 26 September 2009 (UTC)

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)

Yes, but then we need to spell out that "long lists" doesn't include footnotes. -- Alarics (talk) 08:13, 27 September 2009 (UTC)

Related discussion: Wikipedia:Village pump (policy)#accessdate format. ---— Gadget850 (Ed) ^talk 00:56, 27 September 2009 (UTC)

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)

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)

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).

I've left an example of the sort of bot change I was referring to (the bot changing a date from non-YYYY-MM-DD format to YYYY-MM-DD format) as recent as this month at [5].--Epeefleche (talk) 02:38, 28 September 2009 (UTC)

Ah yes, this is a recent AWB general fix from dates like 7/7/1977 to 1977-07-07. There won't be many of these around, and there are a fraction of the number of x/x/x dates compared to the three permitted formats, perhaps partly because I manually fixed the all (to month names IIRC) some years ago. This is not going to affect WP statistics, let alone Google. Rich Farmbrough, 04:43, 1 October 2009 (UTC).

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).

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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.

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
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)

BTW, a quick google skim yields the following references to YYYY-DD-MM -- maybe just a number of one-offs, but I couldn't say for sure (this would seem to bolster the view that the YYYY-MM-DD format is not without ambiguity): [6], [7], [8], [9], [10], [11], [12], and [13].--Epeefleche (talk) 10:21, 29 September 2009 (UTC)

Do we have a consensus on this much…

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, the name of the months should generally be written out in full: “On 7 September 1795, the gram was decreed in France to be equal to…”.
For citations, A.P. short-form months may be used: “(Science News, Vol. 172, Sept. 17, 2007)”.
For tables, three-letter abbreviations may be used. Accordingly, editors should modify USGS data-ralphs so the temporal column reads “Jun 9, 2009, 7:30PM” instead of “ “2009-06-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)

Agree w/Greg L.--Epeefleche (talk) 21:00, 28 September 2009 (UTC)
Agree with Greg L. HWV258 21:51, 28 September 2009 (UTC)
Now you also want to discourage the use of 24-hour clock, which is widely used by many native English speakers in Britain (as well as by the military in the US and in Canada) and doesn't have the problems at noon and midnight of the 12-hour clock? (And BTW no-one ever suggested to use a T to separate the date and the time in any date intended to be human-readable, in tables or elsewhere.) --___A. di M. 22:13, 28 September 2009 (UTC)

For god's sake let's not get started on the 24-hour clock here. I'm all in favour of it and I hate the 12-hour clock, but if you want to have a debate about that, please do it in a separate section. It's hard enough to keep this discussion on track as it is. Here we are discussing the question of YYYY-MM-DD numerical dates in footnotes. -- Alarics (talk) 23:22, 28 September 2009 (UTC)

Indeed… what Alarics said. Let’s try to make progress here and identify the proper practices governing the most fundamental aspects of rendering dates in human-readable form on Wikipedia. Duct taping C4 under our burkas and trotting into a crowd of “12-hour-clock editors” can wait for later. Greg L (talk) 23:35, 28 September 2009 (UTC)

Greg's post of 19:46, 28 September 2009 (UTC) is fine as far as what we won't do to dates, but there is no consensus that we will abbreviate dates in footnotes. Time of day is seldom mentioned in footnotes and so is outside the scope of this thread. --Jc3s5h (talk) 01:18, 29 September 2009 (UTC)

I started looking at the ramifications of my wording and was wondering if someone was going to call me out on that. It was not my original intention that my wording be in the form of—and interpreted as—an actual guideline (item #3 makes that much abundantly clear), but for it to be an outline of the most fundamental elements of rendering dates in human-readable form. I’ve revised it, Jc3s5h, so it reads a little bit more like a guideline. I’d rather not get bogged down at this juncture into the minutia of guideline-type proscription/prescription/sorta-kinda recommended/all-things-holy. What is written, above, covers the three ways months can be conveyed using letters: written out, A.P. short-form, and three-letter abbreviation and provides examples of suitable uses for these three ways. If we have a general consensus on that much, we can move on. Greg L (talk) 02:28, 29 September 2009 (UTC)

I agree on all three points. Easy to identify the date without being cumbersome. 「ɠu¹ɖяy」¤ • ¢ 02:42, 29 September 2009 (UTC)

I believe there is consensus that in footnotes, all-numeric dates, including the YYYY-MM-DD format, are undesireable. The date format should agree with the citation style chosen for the article, and I know of no style guide that suggests numeric months in citaions or reference lists. As for the home-grown {{Citation}} and Cite xxx templates, let template user argue about that in one of the citation related pages. Perhaps they will remember the citation templates were originally based on the APA style, which would use a date such as "(1993, September 30)" in a reference list. --Jc3s5h (talk) 03:06, 29 September 2009 (UTC)

¶ Perhaps this is an unnecessary and undesirable sidetrack (in which case, I'll add a quaternary sub-head and maybe move it), but I have no fundamental objection to using something like "2009 Sep 09, 09:26:03.2" in something specialized like transcribing seismic readouts, although as a practical matter, for browsers that are not using even-width fonts like Courier, it might be better to right-align everything and put the variable-width alphabetic month abbreviations on the left, in spite of the consequent damage to the monotonic downward progression from year to fractions of a second. We all want to end the ambiguity and perplexity caused by all-numeric dates in any order. —— Shakescene (talk) 04:27, 29 September 2009 (UTC)

In that particular table, all dates are from the same year, so "Sep 9, 9:26:03.2" (note the hard-space instead of the zero) would be fine enough (except that the prose uses "29 September") and the listing would stay monotonic and vertically aligned. Dunno how to generalize to table spanning several years. In table only containing dates (no times of the day), 9 Sep 2009 would be kinda monotonic, too. I don't see any real problem with YYYY-MM-DD in tables, but if so many people don't like it these are viable alternatives. (I don't think any table is likely to give dates to more precision than a day and over a greater range than a year.) ___A. di M. 17:13, 29 September 2009 (UTC)

I've created Template:Tdate which can do that: 09-09 09:26:03.2 Sep 9, 9:26:03.2, 2009-09-09 9 Sep 2009. ___A. di M. 11:51, 1 October 2009 (UTC)

Of course there is no consensus, that much is abundantly clear. You are not convincing anyone by constantly repeating your false assertions. I am at a loss to understand why you are still pushing this here, when it has long since been established that a wider audience is needed. _wjemather ^bigissue 06:58, 29 September 2009 (UTC)

I agree with the 2/3 of those who have spoken up above who are against the use of all-numerical dates in footnotes/references.

As to what constitutes consensus, I've found the following: Wikipedia:What is consensus?. Hard to apply, but it strikes me that where we are may well reflect the spirit of that article as to what constitutes consensus -- and I'm not even sure that high a level is even required to simply more clearly state the status quo -- the current guidance states where YYYY-MM-DD is allowed, and that does not include references/footnotes. The editors who have been discussing this issue from the early days inform us that there was no intent to allow that format in footnotes/references, and that the absence of any statement allowing that format in footnotes was not inadvertent.

That said, if someone has thoughts as to how to invite comment from additional editors, I would support that as well. I believe that comments have been left elsewhere (e.g., the village pump--which seems to be a prime place to go when one wants to make sure that an issue reaches a wide audience) by editors pointing them to this discussion (and I've invited a few editors to it myself, including those who are running two bots that are inputting the YYYY-MM-DD format in footnotes--obviously approaching this with a view contrary to mine). I will leave word at a couple of wikiprojects that might naturally have interest as well.--Epeefleche (talk) 07:12, 29 September 2009 (UTC)

i concur that it's not clear at all that there's consensus for recommending AP-style abbreviations in footnotes but three-letter abbreviations in tables (three different formats per article – what for??), and that more people need to participate in the discussion.

has anyone pointed out this discussion to the denizens of citation template talk pages?

and/or an RfC is always a possibility, if anyone feels like summarizing the options under consideration clearly, so that newcomers to the discussion don't have to wade through all the foregoing. Sssoul (talk) 07:34, 29 September 2009 (UTC)

I've just left word of this discussion at the Wikipedia talk pages for the following: Footnotes, Citing Sources, Manual of Style, and Make technical articles accessible.--Epeefleche (talk) 08:07, 29 September 2009 (UTC)

There is obviously no consensus to ban yyyy-mm-dd formats in citations. Also, many of the above comments seem to be based on incorrect assumptions. Please see #Real world often uses yyyy-mm-dd in citations below. Eubulides (talk) 09:21, 29 September 2009 (UTC)

Just repeating myself since my previous comment was archived: I still think YYYY-MM-DD is the best, since it's the shortest and most unambigous format and standard in international communications. The only ones having problems with this format are the Americans, but there's no reason to give them special treatment, as this not their Wikipedia, but an international one. Writing out month names is too inefficient. YYYY-MM-DD also helps international/interwiki understanding since it doesn't require knowledge of month names and their abbreviations. Offliner (talk) 10:10, 29 September 2009 (UTC)

Is there anybody able to read English enough to bother going to the English Wikipedia who wouldn't figure out what "Sept." means in "29 Sept. 2009"? ___A. di M. 16:58, 29 September 2009 (UTC)

@ Offliner; you have to remember there are hundred of thousands, if not millions, of editors on en.wikipedia, all from different backgrounds. How many of them are aware of international standards for numerical only dates. I'll admit it, I didn't until I was in this discussions, and I bet major of the editors on en.wikipedia, don't either. Many times I'm second guess the dates do to this wide array of editors from various backgrounds if 2009-04-09, means 9 April 2009 or 4 September 2009. Just my little tid bit rebuttal to that comment. 「ɠu¹ɖяy」¤ • ¢ 17:41, 29 September 2009 (UTC)

Also @Offliner - you say [t]he only ones having problems with this format are the Americans. Check my user page, and you'll find that I am not an American. I have a problem with these dates because - even though I've been part of this discussion for several days - the most obvious interpretation of 2009-04-09 to my mind is still 4 September 2009. I live in a country where the only numerical date order in common (non-technical) use is date-month-year. It is natural for me to interpret 04-09 as 4 September. The fact that the year is at the beginning doesn't change this reaction because YYYY-MM-DD is a format that I very rarely see outside Wikipedia. I'm hardly a non-technical reader - I'm a physicist by training - but that doesn't mean I regularly use date styles that are at odds with those used by custom in my country - I have no reason to.

For many if not most readers, the fact that YYYY-MM-DD is technically an international standard is trivia. It is something that we cannot reasonably expect our readership as a whole to know. We should be catering for the whole of our audience, not just that part of it that is most like those who edit Wikipedia.

While we can't expect our readership to know the international standard, and to be able to find it recognisable, we can expect them to speak a reasonable level of English. This is an English-language encyclopædia, and as such our audience is presumed to be English-speaking. Yes, of course we should make things easier for those for whom English is not a native language - but only provided that by doing this we don't make it less clear for those for whom it is a native language. In this case, YYYY-MM-DD does make it less clear for native speakers - and if a person's English is not good enough to understand such simple abbreviations as Aug and Jan, then chances are they won't understand most of the rest of the article anyway. Pfainuk talk 20:07, 29 September 2009 (UTC)

I disagree with Pfainuk's statement "the fact that YYYY-MM-DD is technically an international standard". There are international standards that use the YYYY-MM-DD format, but there is no assurance that a number in the format NNNN-NN-NN is a date, or is goverened by any of the group of international standards that more-or-less agree with each other. There are enough computer-oriented pages mentioning YYYY-DD-MM to make me suspect that might be a standard too. Or, it could just be an independent invention of the format without knowledge of the ISO 8601 standard and standards derived from it. Furthermore, Wikipedia has never adopted ISO 8601 so it does not apply to Wikipedia. --Jc3s5h (talk) 21:49, 29 September 2009 (UTC)

Real world often uses yyyy-mm-dd in citations

Several of the comments in the above thread seem to be based on the incorrect assumption that yyyy-mm-dd dates are a Wikipedia eccentricity, and that such dates do not appear in style guides and by and large do not appear in real-world scholarly sources. This assumption is incorrect.

Not only do many style guides allow yyyy-mm-dd dates in citations, there is at least one style guide that requires it, namely ISO 690-2.
It's routine for reliable sources outside of Wikipedia to use yyyy-mm-dd format in citations, independently of ISO requirements. Here are just a few recent examples, with quotes from the papers showing citations containing yyyy-mm-dd dates:

Atkinson NL, Saperstein SL, Desmond SM, Gold RS, Billing AS, Tian J (2009). "Rural eHealth nutrition education for limited-income families: an iterative and user-centered design approach". J Med Internet Res. 11 (2): e21. doi:10.2196/jmir.1148. PMID 19632974. URL: http://www.healthypeople.gov/Document/tableofcontents.htm#Volume2 [accessed 2008-10-24]{{cite journal}}: CS1 maint: multiple names: authors list (link)
Balčiauskas1 L, Kawata Y (2009). "Estimation of carrying capacity and growth rate of wolf in Lithuania". Acta Zoologica Lituanica. 19 (2): 79–84. doi:10.2478/v10043-009-0018-3. http://www.baltic21. org/ reports/indicators/fo01a.htm (Accessed 2009 04 26){{cite journal}}: CS1 maint: numeric names: authors list (link)
Bohigas PA, Santos-O'Connor F, Coulombier D (2009). "Epidemic intelligence and travel-related diseases: ECDC experience and further developments". Clin Microbiol Infect. 15 (8): 734–9. doi:10.1111/j.1469-0691.2009.02875.x. PMID 19486073. (http://ecdc.europa.eu/en/Health_Topics/ebola_marburg_fevers/Article_20080805.aspx accessed 2009-01-24){{cite journal}}: CS1 maint: multiple names: authors list (link)
Holmqvist K, Halbach T, Kristoffersen T (2009). "Virtualization as a strategy for maintaining future access to multimedia content". Proc 1st Int Conf Adv in Multimedia: 29–32. doi:10.1109/MMEDIA.2009.13. ISBN 978-0-7695-3693-4. S2CID 698944. http://www.nr.no/pages/dart/project_ flyer_mariage, accessed 2009-02-25{{cite journal}}: CS1 maint: multiple names: authors list (link)
Joubert P, Roodt S (2009). Using persuasive technologies for energy consumption management: a South African case study. Lecture Notes in Computer Science. Vol. 5709. pp. 197–203. doi:10.1007/978-3-642-04052-8_20. ISBN 978-3-642-04051-1. International Telecommunications Union, http://www.itu.int/ITUD/ict/newslog/South+Africa+Mobile+Penetration+Edges+Towards+100.aspx (accessed 2009-01-12) {{cite book}}: |journal= ignored (help)
Simon H (2009). "Technical realization of the ELISe experiment at FAIR". Int J Modern Phys E. 18 (2): 367–72. Bibcode:2009IJMPE..18..367S. doi:10.1142/S0218301309012409. http://bt.pa.msu.edu/index cosy.htm, accessed 2008-09-13

I found the above sources with a quick Google search and just peeled off the first few I found that looked interesting. There are many more.
WP:IDONTLIKEIT is not sufficient justification for banning a date format that is commonly used both inside Wikipedia and out.

Eubulides (talk) 09:21, 29 September 2009 (UTC)

But those are all technical journals for boffins! Wikipedia isn't a technical journal, it is an encyclopaedia for a general readership, most of whom are neither boffins nor technophiles. -- Alarics (talk) 07:15, 30 September 2009 (UTC)

As I reflected above, a) google searches covering many millions of entries show use of the YYYY-MM-DD format to be in a distinct minority; and b) it is probable that many if not most readers will not know that the format is not YYYY-DD-MM, and thus the ambiguity issue that attends MM/DD/YYYY formats would attend this format as well (but that ambiguity would not be a problem were the month is written out in letters).--Epeefleche (talk) 09:32, 29 September 2009 (UTC)

Your argument would be more convincing if you could find an English language pubication that deals with historical dates (pre-1752), as Wikipedia does, and which uses the YYYY-MM-DD formaat. It would also be interesting to know if the journals you mention just use the format, or if they actually adopt ISO 8601.

As for ISO 690 I reject it because it costs US$165. --Jc3s5h (talk) 15:31, 29 September 2009 (UTC)

There are many articles on WP which don't contain any non-Gregorian date at all; so the "ISO 8601 says you should only use it for Gregorian dates and many readers believe it" objection isn't by itself a good reason to avoid YYYY-MM-DD in such articles. ___A. di M. 16:38, 29 September 2009 (UTC)

Eubulides, it's nothing to do with WP:IDONTLIKEIT. Several people have said they find YYYY-MM-DD ambiguous. If the thing is an obstacle to understanding (because some people find it ambiguous), then we shouldn't be using it. It's as simple as that. -- Alarics (talk) 21:19, 29 September 2009 (UTC)

In my view saying that an interpretation of the format as YYYY-DD-MM is possible, represents ill will. The format is simply never used that way. −Woodstone (talk) 21:55, 29 September 2009 (UTC)

No, I've never seen it used that way, either. That's not the point. It remains the case that some people think it might be used that way, and how would they be sure that it never is? So in practice it is ambiguous - and, indeed, some people on here have actually said that they themselves found it so, and could not be sure what it meant. When real people say that they actually do find it ambiguous, it seems exceptionally perverse to keep on repeating the mantra that is is unambiguous. -- Alarics (talk) 22:17, 29 September 2009 (UTC)

(edit conflict) It's not a bad-faith Straw Man, because no one's saying that YYYY-DD-MM is commonly found, but that there's no way for those unfamiliar with the format to know how it's ordered, and for all they'd know YYYY-DD-MM is as likely a reading as YYYY-MM-DD. In fact, an editor who's a physicist but almost never comes across MM-DD in common usage (apart from 9/11) said that his instant reaction is to read an YYYY-XX-ZZ date as YYYY-DD-MM, since he always thinks of dates as of 4 March and never as March 4. —— Shakescene (talk) 22:31, 29 September 2009 (UTC)

It has nothing to do with WP:IDONTLIKEIT because WP:IDONTLIKEIT has nothing to do with style guidelines; instead (for those who may care to look it up), it's an abbreviation for Wikipedia:Arguments to avoid in deletion discussions, i.e. discussions of retaining or deleting articles, sections of articles, lists, templates, etc. —— Shakescene (talk) 21:47, 29 September 2009 (UTC)

I think we all understand the sentiment clearly enough. Wikipedia:I just don't like it is perhaps the essay that was meant to be referred to. _wjemather ^bigissue 22:03, 29 September 2009 (UTC)

Thanks for the link. I recommend the section discussing novice users' reactions at Wikipedia:I just don't like it#User interface discussions. —— Shakescene (talk) 22:31, 29 September 2009 (UTC)

I looked at the ISO 690 citation standard, and, yes it does recommend the ISO 8601 date format (not surprising considering it is the same standards organization). The complaint "Several people have said they find YYYY-MM-DD ambiguous" is somewhat specious. It's not likely to be mistaken for any other format. They're really saying, "I don't like anything new", somewhat like the people who resisted the introduction of Arabic numbers because they thought Roman numerals were the only proper way to express numbers. RockyMtnGuy (talk) 00:33, 30 September 2009 (UTC)

You implicitly acknowledge in this comment hat this is a "new" format to many people. Wikipedia should not be in the business of trying to introduce formats to people who are unaware of them. That's not what we're here for. In some ways, the notion fails WP:NPOV because it implies that we should all be adopting the YYYY-MM-DD standard - something that Wikipedia has no business in implying.

Wikipedia should use date formats that reflect common usage, and reflect common usage throughout the English-speaking world. Fact is, 1 Oct 2009 and 1 October 2009 are nigh-on universal in the English-speaking world. If 2009-10-01 is common in Canada, then that's great, but it isn't common in many English-speaking countries outside Canada. There is no reason to assume that the fact that Canada uses a format should mean that it is well understood outside Canada, and there is no reason for it to be used on Wikipedia just because it's used in Canada.

If the format in use is not customary in a reader's country/culture, they'll have to stop to try and work out what it means. I'm sure I speak for millions when I say I have to take two or three seconds to work out what a YYYY-MM-DD date actually means. My subconscious reaction is that dates come before months, and so - if the date number is less than 12 - I read a YYYY-MM-DD date as YYYY-DD-MM. So, when I say that I generally misinterpret YYYY-MM-DD if the date number is less than 12, I mean that I generally misinterpret YYYY-MM-DD if the date number is less than 12.

A format should not be acceptable to Wikipedians if it makes our articles harder to read for a significant proportion of our audience with little if any benefit to readers in general. YYYY-MM-DD falls into that category. It does not matter whether the errant dates are in footnotes, tables, or elsewhere: there is no benefit to YYYY-MM-DD that outweighs its problems. Pfainuk talk 17:55, 30 September 2009 (UTC)

Excuse me. I couldn’t participate in this all day until just now. I spent the day trying to find my copy of ISO 8601. I just couldn’t find it. So I went next door. My neighbor manages a K-mart store and you’d think he’d be sophisticated enough to have a copy. But he didn’t. Not even when he climbed his sideways-rolling ladder in his wood-paneled library to access the top shelves. It just couldn’t be found. Then I called my brother, who taught journalism at a university. Funny… not only did he not have a copy, he didn’t even know anything about ISO 8601, ISO 690 or any of these other international standards that editors here are proudly flaunting with their chests puffed out with immense pride. It appears we’ve got a few editors here debating about proper technical writing practices, but their arguments are predicated upon technical nuances that exceedingly few people have the faintest clue about.

Now, I see editors making the argument that YYYY-MM-DD intrinsically references only Gregorian dates (at least to the extent that any exhibition of YYY-MM-DD can be presumed to be necessarily conforming to the ISO 8601 standard). My question is this: So what? Writing out a date in an all-numeric format of any form doesn’t make anything clearer with regard to the distinction between Gregorian and Julian dates for 99.99% of our readership. In fact, over 99% of our readership doesn’t even know there is a difference between Julian and Gregorian calendars.

If there is a Julian date to some event or document that needs to be cited, just write out the month and place a parenthetical “Julian date” at the end of it. You know… we would actually communicate <audience gasp>clearly</audience gasp> and desist with trying to make a rational sounding argument that would require us to pretend that the vast majority of our readership is some sort of brainiac George Jetson with a Ph.D. (BTW, I was, of course, joking about going next door to my neighbor and to my brother. But I do invite any of the above editors who are spouting about these standards to please tell us just who amongst their friends, families, and associates has a copy of ISO 8601 and/or ISO 690 and is familiar with their scope and what connotations these *standards* have with regard to Julian and Gregorian dates. All the above debate just proves to me that some editors here are more interested in showing how smart they are about damned standards but have mighty little interest in writing clearly. That’s my honest take; so shoot me.) Greg L (talk) 04:37, 30 September 2009 (UTC)

Easy, there, Greg. Calm down and take your blood pressure medication. The reason we have computers is so that we don't have to spend all day at the bookstore trying to find an obscure manual. Rather than having to tell people to RTFM (Read The Manual), we can now tell them to JFGI (Just Google It.) Somebody out there in WWWland almost certainly will have scanned it in and put it up on a server with no regard whatsoever to copyright laws, and until the ISO tracks him down and threatens to sue him, with a little creative use of Google you can have free access to the documents.

The reason I have a copy of ISO 8601 is that I used to create international documents as part of my consulting adventures. Also, my clients would ask me, "What standard date format should we use". I'd think about it and tell them "ISO 8601" and send them a bill for that information. I'd also bill them for the copy of ISO 8601 I bought to research the subject. It's called "time and materials billing". And of course there is the airfare to international cities, luxury hotels, gourmet meals, and fine wines that are a necessary part of conveying the information to the client. That's called "travel expenses". Consulting is a great life.

But to get back to specifics, the argument about only using the Gregorian calendar with the ISO date is specious, because as you noted,you could write "1066-10-14 (Julian calender)" for the Battle of Hastings, and everyone will know what you mean, but most of them will neither know nor care about the difference between Julian and Gregorian calenders. In text you would normally write "14 October 1066" or "October 14, 1066" without indicating which calendar. You might use the ISO format in citations (I always do), but it is very rarely a citation would use the Julian calendar. Citations are pretty cryptic anyway, and people who want to read them have to be pretty good at decrypting them. RockyMtnGuy (talk) 17:11, 30 September 2009 (UTC)

If you write 1066-10-14 (Julian calender) you are not using ISO 8601. That means there is no presumption that the Gregorian calendar is intended in the statement "The Guy Fawkes attempted Gunpowder Plot occurred 1605-11-15." It also means that if a date is written in a context where it is normally machine-readable, the machine-readability would have to be turned off. If you say you are using ISO 8601, you are either incompetent or a liar, and either way, your entire body of work is called into question. --Jc3s5h (talk) 17:54, 30 September 2009 (UTC)

Nowhere in ISO 8601 does it say anything about anybody having to turn off machine readability if they can't come to an agreement. The ISO document uses the phrase "mutual agreement" a lot. If you and I were to come to a mutual agreement (which I can see would never happen), we could exchange Julian dates in an ISO-compatible format. The Manual of Style could represent such a mutual agreement and we could put the specifications in it. However, the point is somewhat moot because we're not exchanging dates, we're writing an encyclopedia.RockyMtnGuy (talk) 20:50, 30 September 2009 (UTC)

Jc3s5h: 1) No-one is proposing to use YYYY-MM-DD in sentences; 2) Spelling out "5 November 1605" doesn't magically make clear which calendar is being used; indeed there are articles such as Benjamin Franklin providing dates between 1583 and 1752 using both calendars. ___A. di M. 22:17, 30 September 2009 (UTC)

A. di M. 1) I know no one is proposing to use YYYY-MM-DD in sentences, where the important information is conveyed. Thus the benefit of using it in footnotes, where less important information is conveyed, eludes me. What is the benefit of a person with a marginal grasp of English understanding the footnotes, if he/she can't understand the sentences?

2) As you say, writing "5 November 1605" definitely does not indicate which calendar is being used, which puts the reader on notice that the calendar will have to be discerned from context. Writing "1605-11-05", on the other hand, to a reader who knows how ISO 8601 works, and who thinks it applies to Wikipedia articles, is in the Gregorian calendar, and which is an entirely different date than the original Guy Fawkes night (as distinguished from commemorations of that night). --Jc3s5h (talk) 23:19, 30 September 2009 (UTC)