Wikipedia talk:Manual of Style/Dates and numbers

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Manual of Style
WikiProject icon This page falls within the scope of WikiProject Manual of Style, a drive to identify and address contradictions and redundancies, improve language, and coordinate the pages that form the MoS guidelines.

Clarification on DATERET[edit]

A problem has arisen with a conflict between DATETIES and DATERET in a number of Canadian geographic articles. An editor made a consensus decision based on a discussion here and applied it to other articles in the same region. There are two questions

  1. Can consensus override DATERET on an article-by-article basis? If so, can consensus change at a later time and reverse that decision?
  2. Do dates in prose carry more weight than dates in references? My contention is that the tools used for references often apply an ISO 8601 format and sometimes a DMY format automatically and so it may not be valid to assume the editor chose to apply that date, although one edit in particular makes it clear that the editor did choose that date format.

Feel free to ping me if needed. Walter Görlitz (talk) 05:44, 1 April 2015 (UTC)

DATETIES and DATERET do not conflict; DATETIES is an exception to DATERET. DATERET specifically says: "If an article has evolved using predominantly one format, the whole article should conform to it, unless there are reasons for changing it based on strong national ties to the topic or consensus on the article's talk page." However, DATETIES would not require a change to MDY format in this case, as it says: "Articles related to Canada may use either format consistently."
On point 1, local consensus can override DATERET (indeed, it is also explicitly excepted in the above quoted text) and, of course, consensus can change.
On point 2, in general, I would think that dates in body content (prose, lists, etc.) carry more weight than dates in references in determining whether DMY or MDY is the predominant format of a given article because they are more noticeable; changing the format in footnotes is less likely to be controversial than changing the format in the body. sroc 💬 06:22, 1 April 2015 (UTC) [amended 06:26, 1 April 2015 (UTC)]
Certainly an interesting question regarding "date format chosen by the first major contributor in the early stages of an article should continue to be used". I believe the real question whether the first major contributor "choose" the date format or not -- regardless of whether it was in the reference or prose section. For prose we have a fairly good assumption that they chose the format, and for references we cannot be certain if they did or did not. Perhaps they used a tool, but equally as likely, perhaps they didn't use a tool and choose the other. References started becoming more popular around 2006-2009 for city articles and almost always the first time we see a date format is in reference form. That's because specific dates in those articles were almost always only month and year. The article Delta, British Columbia was an example where it evolved with one format and still to this day, no prose date is present in the article. If someone were to add a different date format in the prose now, I don't think it should override nearly a decade of use of the other one in the references. I think the solution is to prioritize the first bullet point in DATERET and to focus on "evolved using predominantly one format, the whole article should conform to it". The issue of first date format should only be applied if the article evolved using both without one clear dominant date format. Mkdwtalk 16:59, 1 April 2015 (UTC)
sroc's comments are somewhat inconsistent. His view that WP:DATETIES overrides WP:DATERET is a questionable view that he has been pushing above at #Military date format in biographical articles. However, he does state that local consensus can override DATERET (which is the general rule and practice). And notes the explicit statement in DATETIES that "[a]rticles related to Canada may use either format consistently." I would further point out that WP:DATEUNIFY (partiallly quoted above) does not require consistency across the different classes of dates, so what ever usage has evolved with your reference dates might not be fully applicable to dates in the text. As to the main point that was raised here: yes, consensus can change, and thus override what ever has evolved. Which is something you should work out at the article's talk page. ~ J. Johnson (JJ) (talk) 21:05, 4 April 2015 (UTC)
@J. Johnson: "His view that WP:DATETIES overrides WP:DATERET is a questionable view ..." How so? DATERET explicitly excepts cases where "there are reasons for changing it based on strong national ties" (i.e., where DATETIES applies) as well as for following "consensus on the article's talk page". I am merely reading the guideline. How is this "questionable" or "inconsistent"? sroc 💬 05:14, 5 April 2015 (UTC)
The issue comes down to whether the exceptions to DATERET ("reasons ... based on strong national ties", or "consensus") are permissive, or mandatory. In a prior discussion about this (above, at #Military date format in biographical articles, where "military usage" is based on DATETIES) you said (11:51, 22 Mar) 'But the guideline says "[military articles] use day before month"; it doesn't say "may use" or "sometimes use" ....'
Subsequently you said (18:27, 26 Mar) "My position remains clear: ... Where a topic contains strong national ties ... that will direct whether to use DMY or MDY... thus, DATETIES overrides DATERET." [Emphasis added.]
In your rejection of "may use", and explicit use of "will direct", you are saying that if there is a "strong national tie" then use of the national style is mandatory, irregardless of usage previously established in the article. However, you overlook the "should generally use" qualification of DATETIES, or that in DATERET "strong national ties" does not override "consensus".
You should also bear in mind that the broader guidance of WP:MOS#Retaining the existing variety (MOS:RETAIN) clearly states:

When an English variety's consistent usage has been established in an article, maintain it in the absence of consensus to the contrary. With few exceptions (e.g. when a topic has strong national ties or a term/spelling carries less ambiguity), there is no valid reason for such a change.

It seems clear to me that DATERET is permissive: articles should use an established format, but may use another if there is consensus to do so. ~ J. Johnson (JJ) (talk) 20:25, 5 April 2015 (UTC).
Both DATETIES and DATERET use "should"; these are, of course, subject to consensus to overlook this guidance in specific instances. DATETIES doesn't make an exception for DATERET. DATERET makes an exception for DATETIES. Simply put, the order of precedence is clear:
  1. If there is consensus to follow a particular format for a specific article, follow that consensus.
  2. DATETIES: articles with strong national ties to an English-speaking country should use the common format for that country (i.e., MDY for US, DMY for US military and the rest of the world, but either MDY or DMY for Canada), except in the case of 1.
  3. DATERET: don't change the date format from DMY to MDY or vice versa, except in the case of 1 or 2.
This is consistent with the text you quoted from RETAIN. sroc 💬 06:07, 6 April 2015 (UTC)
To be clear, I never said that DATETIES and DATERET override local consensus. The issue in the earlier discussion was how to reconcile a conflict between DATETIES and DATERET, and I pointed out that there could not be any such conflict because DATETIES is an explicit exception to DATERET. Another editor argued "Provided an article is consistent in date format usage, there is no good reason to change the date format used"—I pointed out that this disregarded that DATETIES may provide a good reason to change the date format where an article uses a format inconsistent with strong national ties (ignoring consensus, which I believed to be an understood exception but irrelevant to the discussion as between DATETIES and DATERET). Please do not misrepresent my comments or position. sroc 💬 06:18, 6 April 2015 (UTC)
You said that "DATETIES overrides DATERET" without specifying whether that applied to the specific part of DATERET about consensus; please do not fault me for your own lack of clarity.
I would agree with your levels of precedence except for one omission:
  • If an article has evolved using predominantly one format, the whole article should conform to it .... [Per MOS:DATERET.]
There is no requirement that such a predominant format be consistent with strong national ties, therefore the lack of such consistency does not "provide a good reason to change the date format". (More precisely, is not itself a sufficient reason to change.) I note also that such inconsistency is not itself a reason based on strong national ties. ~ J. Johnson (JJ) (talk) 22:23, 6 April 2015 (UTC)
Actually, in the case of Canada, STRONGNAT/DATETIES is immaterial as both DMY and MDY apply. So the question is a bit deeper than what editors are commenting on here. Walter Görlitz (talk) 03:52, 7 April 2015 (UTC)
Indeed. I believe we have gone from the specific issue that was raised here to the broader applicability of DATETIES and DATERET. ~ J. Johnson (JJ) (talk) 22:26, 7 April 2015 (UTC)

@J. Johnson: "There is no requirement that such a predominant format be consistent with strong national ties ..." There is no need to re-state the need for consistency in DATETIES as this is already covered in the immediately preceding section, MOS:DATEUNIFY: "Dates in article body text should all use the same format ..." Neither DATETIES nor DATERET is exempt from this basic principle of DATEUNIFY. sroc 💬 04:53, 7 April 2015 (UTC)
  • While these date-format discussions give me a headache, I see the potential for some good here. You two seem close to agreeing on how these policies interact, and the trouble of getting to that point may act as a roadmap for improving the guidelines so others won't be similarly vexed. Can you two work together to propose something? EEng (talk) 22:49, 6 April 2015 (UTC)
You have found me out! I am hoping that we will have convergence, but the basis for our different views needs to be understood before we can resolve it. Everyone please be patient. ~ J. Johnson (JJ) (talk) 22:29, 7 April 2015 (UTC)
@sroc: I think we agree (and everyone else?) that per WP:DATEUNIFY there should be consistency of date format within each class of dates (text, publication [references], and access/archive) in each article. I think we also agree that an article's date format (possibly differing for each class of dates) may be set by consensus of the involved editors. (Here I note a possible conflict with "strong national ties", to discuss later.)
Our difference is this: does a claim of a strong national tie "provide a good reason to change the date format" (as you said) even though an article has "evolved using predominantly one [presumably different] format" (DATERET}? In other words, must established usage (absent any declared consensus) always yield to a claim of "strong national tie"? ~ J. Johnson (JJ) (talk) 22:35, 7 April 2015 (UTC)
@J. Johnson: In the absence of consensus to the contrary, yes, a valid claim of strong national ties provides a valid reason to change the predominant date format in an article. That's what DATERET says: "If an article has evolved using predominantly one format, the whole article should conform to it, unless there are reasons for changing it based on strong national ties to the topic or consensus on the article's talk page." For example, if the article on New Zealand Prime Minister John Key had consistently used the MDY date format since its inception, DATETIES would provide the justification to change it to DMY (in spite of DATERET) unless there was consensus to disregard the guidelines. That's how I read the current guidelines. Do you disagree? sroc 💬 06:19, 8 April 2015 (UTC)
Yes, I disagree. A predominately consistent usage in an article is an implicit consensus of the several editors. It is uncivil and creates ill-will when some editor unilaterally (and sometimes idiosyncratically) makes sweeping changes while waving "DATETIES" as a big stick of justification. I can see DATETIES (or rather, reasons based on it) as a point to raise in a discussion, and as a deciding factor when editors are dead-locked on proper usage, but not as license to run rampant. As I have previously said (5 Apr), I think it is a matter of whether the DATETIES exception is permissive, or mandatory. That is, whether DATERET allows exceptions to established usage, or requires them. ~ J. Johnson (JJ) (talk) 20:54, 8 April 2015 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────@J. Johnson: Did you mean "... but [not] as license to run rampant"?

[Ooops! Yes, of course.~ J. Johnson (JJ) (talk)]

In any case, I believe that the words "unless there are reasons for changing it based on strong national ties" mean, simply, that if "there are reasons for changing it based on strong national ties" (i.e., if DATETIES applies), then DATERET does not apply to counter it; otherwise. (This is all assuming, of course, that the editor is acting in good faith in asserting that DATETIES applies in the particular case.)

I think this is an entirely understandable and legitimate way to read it. In fact, I think it is the only way to read it, and you should not see users invoking DATETIES as "running rampant" unless there is an explicit "consensus on the article's talk page" to keep the existing date format. If it were otherwise, the exception would be in DATETIES instead—"Articles on topics with strong ties to a particular English-speaking country should generally use the more common date format for that nation, unless another date format has already been established in accordance with MOS:DATERET"—but it isn't. sroc 💬 07:20, 9 April 2015 (UTC)

I think sroc's reading is correct. Jc3s5h (talk) 20:30, 9 April 2015 (UTC)
It is a possible reading, but not the only one. And we should consider what reading is most acceptable. E.g., does "strong national ties" give any drive-by editor a right to unilaterally change date formats where explicit consensus is not to be found "on the article's talk page"? Does it count if it is buried deep in the archives? Does the presence of {{mdy}} or {{dmy}} templates indicate explicit consensus? ~ J. Johnson (JJ) (talk) 21:19, 9 April 2015 (UTC)
Archives are still evidence of explicit consensus arrived at on the talk page (it doesn't stop being consensus when archived). Maintenance templates are not a substitute for explicit consensus on the talk page achieved through discussion. sroc 💬 03:21, 10 April 2015 (UTC)
By the way, the use of terms like "drive-by editor" and "unilaterally" betray a failure to assume good faith. Users may make valuable contributions by applying Wikipedia's policies and guidelines (including the MOS) to clean-up articles, even if they are unfamiliar with the subject or do not otherwise edit particular articles. For example, I routinely fix formatting to add missing commas after MDY dates (per MOS:DATEFORMAT) and after city–state or city–country combinations (per MOS:COMMA) as I browse articles I read; this is not vandalism.
If an editor changes an established date format citing DATETIES, assume that they have a good faith reason to believe that it's the right thing to do according to the guideline. If they are mistaken that DATETIES applies (e.g., the subject is Canadian and either DMY or MDY is acceptable, or the subject is US military and DMY is preferred instead of MDY), then revert the edit and explain why. If it is contentious whether DATETIES applies (e.g., it is unclear whether the subject has strong national ties to an English-speaking country), raise the matter on the article's talk page. If there is explicit consensus to use a particular date format for the article, revert the edit and point to the earlier discussion that established consensus (there may be an opportunity to discuss whether consensus has changed). But do not simply revert the change citing DATERET if there is a valid reason to apply DATETIES just because no one has had the presence of mind to do so before. Certainly do not bully or undermine editors who may have been trying to do the right thing (or what they thought was the right thing). sroc 💬 12:59, 10 April 2015 (UTC)
Please note that Accusing others of bad faith is itself a violation of AGF. (See also WP:Assume the assumption of good faith.) Your objection to "drive-by" and "unilaterally" suggests you see those as inherently colored terms, or that I have some cryptic meaning intended. Which are both incorrect, and an assumption of bad faith on your part. The fact is that no one (not even yourself) considers unilateral action itself to "betray a failure to assume good faith." Similarly for "drive-by". These terms are innocent.
The problem with unilateral action is when it contravenes consensus, including those cases where (as you said) "no one has had the presence of mind" (or just not seen the need?) to document it before. This does not have to result from, nor does it "betray", any nefarious intent. It could be nothing more than shear bullheadedness. More commonly the problem stems from editors thinkig it is (as you say) "the right thing to do according to the guideline", but they may also (as you explain) presume upon that, without any inquiry or discussion. For any non-MOS matter such Bold editing could be Reverted, to be followed with Discussion. But date-format discussions all too often get short-circuited into assertions that DATETIES overrides all other considerations (except explicit consensus previously obtained), including established ("evolved") usage.
You state: "Certainly do not bully or undermine editors who may have been trying to do the right thing ...." For sure! Please note that the WP:Civility nutshell says: "Do not ignore the positions and conclusions of your fellow editors", and: "Participate in a respectful and considerate way". I say these include respect for extant work, including established usages, and to not make broad changes unilaterally without the courtesy of discussing it with those who have made major contributions. ~ J. Johnson (JJ) (talk) 21:59, 10 April 2015 (UTC)
If I edit an article to add commas after MDY dates, without the matter having ever been discussed on the article's talk page but ensuring consistency with MOS:DATEFORMAT and MOS:COMMA, would you object on the basis that it is against consensus on the article's talk page? I would hope not. Why then treat edits to comply with DATETIES any differently (assuming that there is a valid basis and the matter has not been addressed for that article before)? sroc 💬 10:48, 11 April 2015 (UTC)
Why would you presume to drop-in on an article where you have never made any major contributions and make broad changes of a frequently controversial nature "without the courtesy of discussing it with those who have made major contributions"? Even if we assume that such changes are proper, it is arrogant to do so without any consultation. It assumes as a right or a license what is really only a guideline. Do you assume that other major contributors are so ignorant of the guidelines that only you can set matters right? Why should any such edits not be subject to the R of WP:BRD?
There is a right: it's the B in BRD. I never said that controversial edits are not subject to R—in fact, I wrote: "If they are mistaken that DATETIES applies ... then revert the edit and explain why." Reverting presumes there is a valid justification to oppose the change.
In longer articles with many dates, it may be prudent to make a comment on the talk page, but this is not a strict requirement when the application of DATETIES does not appear controversial; if it really is controversial, someone will revert it. In stubs or short articles with only one or two dates, a switch in date formats when DATETIES obviously applies (say, a short biographical article on a relatively obscure Australian written by a handful of contributors) is unlikely to be controversial—would you call it arrogant to make such a change? sroc 💬 08:14, 12 April 2015 (UTC)
The problem isn't so much where you or anyone else claims a right - which is to say, to claim a moral or legal entitlement - to change a date format, but where editors insist that their changes may not be reverted. That is arrogance, just as it is arrogant to assume that one's own sense of "obvious" (implying that explanation is not necessary) is superior to anyone else's sense of "obvious". If a "handful of contributors" has consistently used any format, then, yes, I would call it arrogant to assume any right to revert their efforts. To simply "make a comment on the talk page" suggests that discussion is not necessary, and implies there is nothing they could say that would change your intention. ~ J. Johnson (JJ) (talk) 23:17, 13 April 2015 (UTC)

Sroc seems to be taking a wikibreak. To summarize where we have gotten to, sroc seems to allow that Reversion can be applied to "controversial edits", but apparently only where it is mistaken to apply DATETIES, where there is "valid justification to oppose the change." To me this sounds like an attempt to give edits that claim DATETIES an exemption from reversion, which I find arrogant. And there the matter stands, without resolution. ~ J. Johnson (JJ) (talk) 23:33, 24 April 2015 (UTC)

Arbitrary break[edit]

I see there's been agreement limiting Iran's nuclear ambitions. Any chance of similar progress here? EEng (talk) 21:25, 12 April 2015 (UTC)

As the Tennessee gentleman said: "I begin to doubt.". But as was said in one of my favorite moveis: "we'll keep pumping air." ~ J. Johnson (JJ) (talk) 23:23, 13 April 2015 (UTC)

DATETIES: Is DMY format now acceptable for the U.S.?[edit]

I ask the following question in consequence of earlier comments (under another section) where it was suggested that usage of the DMY format is increasingly common in the US. The question is the extent of this shift and whether the MDY format remains in use to such a predominant extent or whether it might now be considered that both formats are acceptable, as in the case of Canada? Cinderella157 (talk) 01:52, 11 April 2015 (UTC)

Good question. On one hand I am so immersed in scientific areas where DMY is nearly universal that I can't really assess how far MDY has been supplanted in non-scentific areas. And any poll would strongly reflect how a sample was selected. On the other hand, does it really matter? When writing shortened numeric dates, there is a big difference between 4-11-15 and 11-4-15. But when the month is spelled out (even partially) I think most people have no problem with either Apr. 11 or 11 Apr.
At a somewhat broader level, I wonder whether the "strong national tie" ought to arise from the topic itself — or from the audience most likely to be reading the topic. E.g., should an article on an ancient Chinese history use ancient Chinese dates? Or those familiar to modern English speakers? For local or parochial topics of mainly local interest there is no problem, but what about (say) the first trans-Atlantic telegraph cable? ~ J. Johnson (JJ) (talk) 22:16, 11 April 2015 (UTC)
If it is, then the whole issue of DATETIES might well be mute. Cinderella157 (talk) 00:04, 12 April 2015 (UTC)
Well, if anything's patently obvious it's that the DATETIES issue is not mute. EEng (talk) 00:10, 12 April 2015 (UTC)
Just to be perfectly clear: DMY format dates are not acceptable in articles written in American English -- with a limited exception for military topics. DMY format dates are not used with any frequency in mainstream American media, nor are they recommended/endorsed by American English style guides. No, DMY format dates are not an acceptable mainstream alternative practice in American English.
P.S. The abbreviation "U.S." (with periods) is still the preferred form of abbreviation in American English, too. Dirtlawyer1 (talk) 00:41, 12 April 2015 (UTC)
However, some reputable publications are using US, and I perceive a trend toward that usage. Also, statements such as "UK and U.S. officials ..." irritate the sensitive reader.—Finell 03:49, 12 April 2015 (UTC)
@Dirtlawyer1, "acceptable mainstream practice" is established by the mainstream, not by authority, nor by lawyering. One can observe style guides and other official compilations, but they are not the source of what is "mainstream"; they are at best a reflection. At worst, they tend to be conservative and behind any curve of changes. Mainstream changes tend to just happen; they are not organized. But the mainstream in America is always absorbing the influences of the other practices around it, and is not rejecting DMY either. It's recognized as "another style", not American in origin, but acceptable all the same thank you very much. If you think otherwise, I would challenge you to find a story of objection or ire directed against this un-American activity. But really, "mainstream" is "the people", not "officialdom". Evensteven (talk) 20:25, 19 April 2015 (UTC)
Evensteven, please feel free to provide evidence for the DMY in American mainstream practice . . . if you don't trust "conservative" American style guides, please feel free to list all of the major American publications that use DMY dates which you can find. You know, "conservative" publications like The New York Times, The Washington Post, Los Angeles Times, Chicago Tribune, USA Today, Time magazine, People, Sports Illustrated, The Sporting News, Bon Appetit, The Wine Spectator, The Harvard Law Review . . . Can you name a single major American daily newspaper or weekly/monthly magazine of national circulation -- exclusive of technical journals -- that actually uses DMY dates in publication? Good luck, and be prepared to spend a lot of time searching! And for every example of an American publication that uses DMY which you manage to uncover, I can easily provide the names of 100 publications that use MDY dates with 1/100th the effort: that's what I mean by "mainstream practice." Dirtlawyer1 (talk) 22:33, 19 April 2015 (UTC)
FWIW, I would note that the guideline suggests either format is appropriate for Canada is completely out of touch with reality. DMY hasn't been in common use (or even rare use) in English Canada for decades. And honestly, I don't see evidence that it is becoming prevalent in the US either. So my position is that for general, no, DMY would not be appropriate for American (or Canadian) articles. Resolute 02:46, 12 April 2015 (UTC)
The statement that DMY is not in common use in English Canada for decades is not correct. While Alberta seemingly does use MDY more commonly, and the Canadian media use MDY, there are plenty of examples (not only rare ones) where DMY is used. Service Canada and the Canada Revenue Agency (as one example) use ISO 8601 most of the time, but use DMY for the times they do not. Particularly in the business sector for things like Records of Employment, benefits, and medical reports. XFile and a number of other Canadian tax processes require DMY importing. Citizen and Immigration Canada requests documents be submitted in the ISO 8601 or DMY. In any regard, the only consensus among Canadians is that both are and may be used. Mkdwtalk 04:00, 18 April 2015 (UTC)\
You are overstating things. Most newspapers, magazines and universities use MDY over DMY. No such consensus exists among Canadians. The last time this was discussed, I found exactly two universities using DMY and at least fifty that used MDY, in-line with American scholarly publication guidelines. Similar issue for publications. Walter Görlitz (talk) 06:40, 18 April 2015 (UTC)
I didn't overstate anything and request you retract that statement. I gave two examples of there the MDY format is readily available and in NO way said those were the only places. In fact they were concession examples that I used to show that MDY is widely used in some (never said only or all) highly visible areas. It was a carryover so please read it more carefully before you make baseless accusations. My point was that there are other places where DMY is used and not as "rare". Both date formats can be used. It states so here on the Wikipedia guideline for DATETIES, the article date format by country, but more notably the issue of date format is found in multiple places. Maybe I need to put this more plainly but there is no prohibition on date format over the other in Canada; only preference. Even at the federal and legislative level despite "adoption" of ISO 8601 the dual format system exists even at our government level. There is absolutely no where that it states Canada has one format over the other. Mkdwtalk 07:32, 18 April 2015 (UTC)
I plainly refuse to retract my statement because it's correct.
I'm not stating that it should be changed for Canada, just that most publications and universities use MDY format and it applies to more individuals than government documents. Walter Görlitz (talk) 14:40, 18 April 2015 (UTC)
Cinderella: I could only hope that the ever-going DATETIES arguments would "mute", but not likely. And possibly you meant "moot"? Even so, no such luck. Granting that either format is acceptable leaves lots of room to argue which should be used. [Removed extraneous comment added here by Walter Görlitz.]
On the same basis of "strong national ties", DMY seems as appropriate for scientific topics as military topics. ~ J. Johnson (JJ) (talk) 03:45, 13 April 2015 (UTC)
Hey, I already made the "mute" joke. Get your own humor! EEng (talk) 03:56, 13 April 2015 (UTC)
There was still some flavor left. :-) ~ J. Johnson (JJ) (talk) 22:37, 13 April 2015 (UTC)
The irony is that the error is perhaps not so erroneous, even if technically incorrect. Cinderella157 (talk) 23:30, 13 April 2015 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── My own take on most of these date arguments is that the rule/guide isn't meant to tell you the best date format to use - it is meant as a tie breaker when we have arguments. As mentioned above, the subject of the article can't exclusively decide (eg articles on China should not use the Chinese date format) and you can't tell which readers you have (an American wanting to visit a Chinese city, an Australia looking up a American company for business research, etc). Since the reader could be anybody, the actual format used is irrelevant as long as it can be deciphered: eg, 1 May 2015 or May 1, 2015 or 2015-05-01 (the last not for general prose). But historically we have seen many articles written in, say, 1 May 2015 style and an American will 'correct" the date format. A Brit or an Australian will then "correct" it back and so it goes for a few weeks until some editors leave WP in disgust. By having a tie breaker guideline we can allow the main contributor to choose a style they are comfortable with while still allow a way to choose when opposing parties can not reach a conclusion. I would be very against interpreting the guides as "this type of article MUST use this date format". Best to leave it as a tie breaker, not a straight jacket.  Stepho  talk  00:02, 14 April 2015 (UTC)

I also oppose any interpretation of the date format guidelines as mandating either DMY or MDY. But use as a tie breaker is not optimal, as it encourages arguments, where DATRET and DATETIES are then used as battering rams. I think we need to accept (as Stepho said) that date format is irrelevant as long is it understood. Particularly, that all readers will understand BOTH "11 April" or "April 11", quite aside from their relative prevalence. And that arguing which is more common in any given context is neither relevant nor useful. ~ J. Johnson (JJ) (talk) 22:55, 24 April 2015 (UTC)
People will argue about it. People will cruse about Wikipedia changing any format for which their are national favorites to their favourite. Rules for how to choose seem to help with this problem. Jc3s5h (talk) 23:35, 24 April 2015 (UTC)
To say that a given rule is to be applied whenever there is a controversy encourages creation of controversy to get the rule applied. We certainly have plenty of editors unilaterally changing date formatting on the sole basis of DATETIES/DATERET, controversy or not. And note the discussion just above, where it is argued (12:39, 10 Apr) that DATETIES is superior to DATERET, and constrains the reversion of "bold" date format edits.
I think we should formulate a new principle: that MDY and DMY are BOTH acceptable (though articles should be consistent in using one or the other), that "national" or other contextual ties are a factor editors should consider, but is not a mandate, and may not be argued except where an existing split in discussion cannot be otherwise resolved. ~ J. Johnson (JJ) (talk) 21:29, 25 April 2015 (UTC)

I urge my esteemed fellow editors to comment here[edit]

Wikipedia:Village pump (proposals)#Proposal: creation of "style noticeboard" EEng (talk) 15:09, 1 April 2015 (UTC) Thanks to Neby for bringing this to our attention elsewhere on this page -- important enough that I thought it should get more prominence.

Proposed style noticeboard[edit]

There is currently a discussion at the village pump about creating a noticeboard (similar to the RSN, ORN and NPOVN) for people with questions about how to implement Wikipedia's style policies. The proponents say that one centralized board would be easier for editors to find than many talk pages, and opponents say that it might be a venue for forum-shopping and drama. Participation is welcome. Darkfrog24 (talk) 18:59, 14 April 2015 (UTC)

Grouping of digits[edit]

Acceptable number formats[edit]

According to wide-spread use on Wikipedia and in written English in general, and to what seems to be long-standing consensus, there are two basic ways of delimiting numbers: with commas and with thin spaces. Each of these have two variants giving four styles of grouping as follows.

1a) Separate four or more digits to the left of the decimal into groups of three using commas. Don't group digits to the right.
1b) Separate five or more digits to the left of the decimal into groups of three using commas. Don't group digits to the right.
2α) Separate digits both sides of the decimal into groups of three using thin spaces, except that a space should not be added if it leaves a lone digit on the left.
2β) Separate digits both sides of the decimal into groups of five using thin spaces.

It's a well-established principle that grouping style should be consistent throughout a given article but what exactly does this mean? Obviously we don't want one style to the left and another to the right of the decimal point. I think it also goes without saying that if we're using commas we shouldn't use spaces and vice-versa. Also, we should be consistent with regard to whether to delimit exactly four digits to the left. However, since grouping by fives is intended only for numbers with very many digits we should not have to use this style throughout an article simply because we use it once. Therefore consistency would mean a choice between using 1a, using 1b and using one or both of 2α and 2β. Jimp 14:30, 14 April 2015 (UTC)

The current wording[edit]

It seems that the above is the intended meaning of the text of Grouping of digits, as posted below.

However, I don't think that this is made clear. By looking at the left and right sides separately it would appear that hybrid styles are allowed. For example, it seems to permit a number with commas to the left and spaces to the right (e.g. 12,345.67890) or spaces to the left and no delimitation to the right (e.g. 12345.67890). To make matters worse, it's suggesting an inconsistent grouping of digits in mathematical articles; digits are allowed to be grouped by fives to the right but not the left of the point (e.g. 12345678.90123456789012345678).

Of course, it should be obvious that delimiting style should be consistent both sides of the decimal point but I don't think that the current text makes it obvious and it should. The problem arises, it seems to me, that the current text doesn't exactly define what a style is (or misdefines it). I don't think that this is just some kind of non-issue; I've seen, for example, a suggestion that MOSNUM is recommending 12,345.67890. So, I'd suggest that the text be rewritten to make it clear what is and what is not acceptable. Jimp 14:30, 14 April 2015 (UTC)

An unreasonable ban on thin spaces[edit]

The current text restricts the use of thin spaces (left of the decimal) to scientific/engineering articles. However, I don't believe that this truly reflects use in the real world out there. A few months ago, Dbfirs mentioned that the use of thin spaces for thousands separators is what's taught in British schools. It's also quite normal in Australia. Furthermore, this is the style recommended by the SI.[1] Why, then is MOSNUM suggesting that this style may only be used in scientific/engineering articles? It should be preferred in such articles but allowed in any. Jimp 14:30, 14 April 2015 (UTC)

  is one of the few code points I know by number, but IIRC it doesn't have the "no break" property of   or the also existing "no break hyphen". IOW, just using thin space instead of   might be not good enough, because you certainly don't want a line break within a number. Please correct me if "IIRC" means "not correct" here.Face-smile.svgBe..anyone (talk) 12:24, 15 April 2015 (UTC)
Thin spaces are also the standard thousands separator in South Africa, although certain sectors such as the financial press are increasingly using the "American" comma. Roger (Dodger67) (talk) 12:27, 15 April 2015 (UTC)
Perhaps we need "U+202F narrow no-break space   NNBSP" -- see Non-breaking_space#Width_variation. EEng (talk) 13:33, 15 April 2015 (UTC)

Mark up[edit]

There are a couple of questionable suggestions regarding mark up. Currently, the text is suggesting the use of {{val/delimitnum}}. This is a subtemplate of {{val}} and as such we shouldn't be encouraging its use in the article space. It also suggests {{gapnum}} but this somewhat obscure template should probably be merged with {{val}}.

There is a hidden comment here which goes "perhaps should say something more re nbsp here since some will hand-code the markup; also, should {{val}} and {{gaps}} use nbsp? (answer may be different left of the point vs right of the point)". I wonder what more we might say about   and, no, neither {{val}} nor {{gaps}} should use   and the answer should be the same either side of the decimal point. Firstly,   is too wide, the spaces should be thin; secondly, as noted,   causes problems for screen readers it also causes problems when copying and pasting numbers into a calculation program (e.g. Excel). Jimp 14:30, 14 April 2015 (UTC)


I'm proposing a rewrite of the section to clarify what is and what is not acceptable and where.

Wording as of 16 April 2015:

  • Left of the decimal point: Five or more digits should be grouped (and exactly four digits may optionally be grouped) into triples separated by commas (never period/full stop): 12,200;   255,200;   8,274,527;   1,250 (optionally 1250).
  • Exception: never group four-digit page numbers or four-digit calendar years (not sailed in 1,492, though 10,400 BC).
  • In scientific/engineering articles, long strings left of the point may be grouped into triples without commas: 8274527
  • Right of the decimal point: Five or more digits may be grouped into triples without commas: 99.123456.
  • In mathematics-oriented articles, digits right of the point may be grouped into fives: 3.14159265358979323846....

Grouping style should be consistent throughout a given article.

Markup: Templates {{val}}, {{val/delimitnum}}, {{gaps}}, and {{gapnum}} may be useful in grouping digits. Use of hard-coded spaces, such as the regular space character, the non-breaking space (  or {{space}}), and the thin space (  or {{thinsp}}), is problematic for screen readers because they read out each group of digits as separate numbers (e.g. 30 000 is read as "thirty zero zero zero").


  • Digits should be grouped and separated either by commas or thin spaces (never a period/full stop).
Grouping with commas
  • Left of the decimal point, five or more digits are grouped into threes separated by commas (e.g.  12,200,  255,200,  8,274,527).
  • Numbers with exactly four digits left of the decimal point may optionally be grouped (either  1,250  or  1250), provided that this is consistent within each article.
  • When commas are used left of the decimal point, digits right of the decimal point are not grouped (i.e. should be given as an unbroken string).
  • Markup: Generally this is hard-coded; however, {{formatnum:}} may be used to produce this formatting (useful in templates).
Grouping with thin spaces
  • Digits are grouped both sides of the decimal point e.g. (e.g.  6543210.123456).
  • Digits are grouped into threes or fives.
  • Digits should generally be grouped into threes; however, right of the decimal point, the final group of digits should not be a single digit. Instead add the final digit to the preceding group (e.g.  99.1234567).
  • For numbers with a large number of digits in mathematics-oriented articles, digits may be grouped into fives (e.g.  3.14159265358979323846...).
  • This style is especially recommended for articles related to science, technology, engineering or mathematics.
  • Markup: Templates {{val}} or {{gaps}} may be used to produce this formatting. The use of hard-coded spaces, such as the regular space character, the non-breaking space (  or {{space}}), and the thin space (  or {{thinsp}}), is problematic for screen readers because they read out each group of digits as separate numbers (e.g.  30 000  is read as "thirty zero zero zero").
  • Delimiting style should be consistent throughout a given article.
  • Either use commas or thin spaces, but not both.
  • Either delimit exactly four digits left of the decimal point or do not.
  • However, grouping by threes and fives may coexist.
  • An exception is made for four-digit page numbers or four-digit calendar years. These should never be grouped (not  sailed in 1,492,  though  dynasty collapsed around 10,400 BC  or  by 13727 AD, the Earth's axial precession will have made Vega the northern pole star).


ordinals, numerators, denominators and non-base-ten numbers[edit]

There is some reading between the lines to be done here. Firstly, I would take it as given that if there is no decimal point that the left-of-the-point rules apply (e.g.  "123456"  or  "98,765"). Secondly, the rules apply to ordinals as well as numerals (e.g.  "the 1010th day of the human totem pole"  or   "the 12,000th contestant"), to quantities (e.g.  "1234 kg" or  "1,250 ml") and to numerators and denominators of a fraction (e.g.  "1234 12345678"  or  "4,321 7,6549,876"). Thirdly, that this applies to base-ten representations of numbers (e.g. not binary  "101110001"  or hexadecimal  "12A,F09,7E2"). Should we bother making any of this explicit? Jimp 20:03, 14 April 2015 (UTC)

Good idea. Maybe just include these as examples?
  • Digits should be grouped and separated either by commas or thin spaces (never a period/full stop).
Grouping with commas
  • Left of the decimal point, five or more digits should be grouped into threes separated by commas (e.g.  12,200,  255,200 km,  8,274,527th,  12,345 34,56767,890).
  • Numbers with exactly four digits left of the decimal point may optionally be grouped (either  1,250  or  1250), provided that this is consistent within each article.


sroc 💬 05:27, 16 April 2015
... or something like
  • Digits should be grouped and separated either by commas or thin spaces (never a period/full stop).
Grouping with commas
  • Left of the decimal point, five or more digits are grouped into threes separated by commas (e.g.  12,200,  255,200 km,  8,274,527th,  13,600).
  • Numbers with exactly four digits left of the decimal point may optionally be grouped (either  1,250  or  1250), provided that this is consistent within each article.
Grouping with thin spaces
  • Digits are grouped both sides of the decimal point e.g. (e.g.  6543210.123456,  520.01234 °C,  1010th,  101325/760).
Jimp 07:35, 18 April 2015 (UTC)
Looks good, except that the fraction example needs to have at least five digits in the numerator and/or denominator for the rule to apply (136,000 requires a comma but 13600 doesn't). sroc 💬 15:04, 18 April 2015 (UTC)
Can I also suggest collapsing the three- and five-digit grouping points?
  • Digits should be grouped and separated either by commas or thin spaces (never a period/full stop).
Grouping with commas
  • Left of the decimal point, five or more digits are grouped into threes separated by commas (e.g.  12,200,  255,200 km,  8,274,527th,  186,400).
  • Numbers with exactly four digits left of the decimal point may optionally be grouped (either  1,250  or  1250), provided that this is consistent within each article.
Grouping with thin spaces
  • Digits are grouped both sides of the decimal point e.g. (e.g.  6543210.123456,  520.01234 °C,  1010th,  101325/760).
  • Digits should generally be grouped into threes—however, right of the decimal point, the final group of digits should not be a single digit; instead add the final digit to the preceding group (e.g.  99.1234567). For numbers with a large number of digits in mathematics-oriented articles, digits may be grouped into fives (e.g.  3.14159265358979323846...).
sroc 💬 15:15, 18 April 2015 (UTC)
Good point regarding 13,600; yes, 186,400 is probably better. Also, it seems clear enough with the threes and fives collapsed but perhaps we could swap "should ... be" for "are". Jimp 22:55, 18 April 2015 (UTC)
Grouping with thin spaces
  • Digits are grouped both sides of the decimal point e.g. (e.g.  6543210.123456,  520.01234 °C,  1010th,  101325/760).
  • Digits are generally grouped into threes—however, right of the decimal point, the final group of digits should not be a single digit; instead add the final digit to the preceding group (e.g.  99.1234567). For numbers with a large number of digits in mathematics-oriented articles, digits may be grouped into fives (e.g.  3.14159265358979323846...).

Left vs right[edit]

General comments:
  • I find commas to left and spaces to the right jarring; but I also find commas to the left and no spaces to the right jarring, if there are (say) 6 or more digits to the right. I'm not sure what to suggest.
  • As for "consistency", something I'm usually in favor of: I don't see a need for consistency between display of "small" integers (say, less than 106) and long mathematical constants (20+ digits). I'm not sure how to express the idea that display should be generally consistent, but there are reasonable exceptions. Possible example of problems, without checking whether there actual problems, would be the article on the trajectory of the Earth's axis, which might include 5-digit years (for which I would prefer commas) and precession and nutation coefficients which might be accurate to more than 10 decimal places.
  • I think we should take a stand against spaces or commas in fraction numerator or denominators when using the {{frac}} template; any such article should be mathematical, so the {{frac}} template is discouraged
I'm on a smartphone, so placing these comments in the correct subsection is difficult. As a tax preparer, this is not a good time for me. But I'm on the train on my way to fill out some forms for my wife's doctor's appointment, so I have a little time to comment. — Arthur Rubin (talk) 16:17, 15 April 2015 (UTC)
Perhaps you could post your wife's X-rays and diagnosis when they're available. EEng (talk) 16:44, 15 April 2015 (UTC)
Concerning spaces in fractions, you may like Thnidu's examination of the problem at Talk:Torr#fraction format and his eventual triumph. NebY (talk) 17:02, 15 April 2015 (UTC)

Can anyone refer us to any style guides or standards, or even textbooks, that provide rules or guidance on this? NebY (talk) 17:13, 15 April 2015 (UTC)

Thousands separators are addressed in some detail by the International System of Quantities. The international standard is thin spaces to left and right of the decimal marker. Wikipedia prefers to ignore the international standard and invent its own rules. Dondervogel 2 (talk) 17:57, 15 April 2015 (UTC)
The US Government Printing Office Style Manual calls for commas to the left of the decimal and spaces to the right; see the top of page 272. Jc3s5h (talk) 18:08, 15 April 2015 (UTC)
@Dondervogel 2:Really? The International System of Quantities concerns quantities such as the base quantities length, mass, time, electric current, thermodynamic temperature, amount of substance and luminous intensity. I don't believe it's concerned with the representation of numeric values. ISO may well publish an international standard that covers typographical representation of numerical quantity values and I'd be glad to know what it is and what it says - it just won't be the ISQ. NebY (talk) 18:24, 15 April 2015 (UTC)
Page 27 of ISO 80000-1:2009 contains the following text
  • To facilitate the reading of numbers with many digits, these may be separated into groups of three, counting from the decimal sign towards the left and the right. No group shall contain more than three digits. Where such separation into groups of three is used, the groups shall be separated by a small space and not by a point or a comma or by any other means.
EXAMPLE 1 1 234,567 8 rather than 1 234,5678 0,567 8 rather than 0,5678
  • In the case where there is no decimal part (and thus no decimal sign), the counting shall be from the rightmost digit towards the left.
EXAMPLE 2 In the number “1 234”, the right-most digit is that underlined.
  • The separation into groups of three should not be used for ordinal numbers used as reference numbers, e.g. ISO 80000-1.
  • The year shall always be written without a space, e.g. 1935.
  • A plus or minus sign before a number (or a quantity), used to indicate “same sign” or “change of sign”, is a monadic operator and shall not be separated from the number by a space (see Example 3). However, for operations, signs and symbols, there shall be a space on both sides of the sign or symbol, as shown in the examples given in Example 4. See also 7.1.3. For signs denoting a relation, such as =, < and >, there shall also be a space on both sides.
EXAMPLE 3 A Celsius temperature from −7 °C to +5 °C.
EXAMPLE 4 5 + 2 5 − 3 n ± 1,6 D < 2 mm > 5 mm"
Dondervogel 2 (talk) 18:56, 15 April 2015 (UTC)
  • These are enlightening and may very well help us decide what our MOS should say, but please, no more talk of "the" international standard. There's no such thing. It's nonsense. EEng (talk) 19:27, 15 April 2015 (UTC)

The US Government Printing Office Style Manual doesn't have the luxury of dealing with the issue on an article-by-article basis. It seems that they're attempting to create some kind of compromise by hybridising the "traditional" (commas left and no grouping right) with the "modern" (spaces either side) and, I'd assume, they're hoping that this doesn't produce too many jarring juxtapositions of the two. At Wikipedia, on the other hand, we're free to chose one or the other as appropriate to the topic at hand. On a page where it's advantageous to delimit digits after a decimal point, the most sane thing to do would be to use spaces either side (not Frankennumbers like  "987,654,321.123456789").

I would not think that treating numbers differently according to whether they are followed by a unit of measure or not (e.g. "7,845 entrants ran the 14000-metre course from Hyde Park to Bondi Beach") would be good writing style. Moreover, the ISQ deals with SI units, so you might argue that spaces be used if and only if followed by an SI unit (e.g. "3776.24 m (12,389 ft)"). Surely, inconsistency like this is something we wouldn't want. Perhaps choice between commas and spaces might be influenced by whether there is a predominance of quantities on the page in question but we should consistently use one of the other.

I too find commas to left and spaces to the right jarring, we never use this in English (I doubt even US Government Printing Office publications would do this in spite of a literal interpretation of their style manual). If commas to the left and no spaces to the right (if there are enough digits to the right) is also jarring, then spaces both sides would be an obvious solution. Large numbers of digits after a decimal point is a pretty good indication that the topic is a bit of a technical one anyway so using spaces shouldn't generally be a problem.

With respect to grouping I would not advocate consistency between long and short (in terms of number of digits) numbers. It makes perfect sense (as I see it) to reserve grouping by fives to the longer numbers. I'm not sure whether we need put a specific number on it but if we were to, perhaps 15 digits on one side and/or the other of the decimal point might be good. However, we never group by fives using commas (not in standard English) so grouping by fives should be done with spaces. If we're using spaces to group digits in long numbers, it would seem natural to do so for short ones on the same page. Again, we shouldn't expect to run into long numbers except on technical pages so using spaces should be fine here too. I'd like to mention again, though, that it would only be sensible to be consistent within the one number: we should never group by fives on one side of the decimal point and by threes on the other.

As for long numbers in numerators and denominators, using {{sfrac}} instead of {{frac}} as on Torr (mentioned above) should generally solve any issues here.

Jimp 04:57, 16 April 2015 (UTC)

Four-digit numbers[edit]

I read in a guide many moons ago that commas in four-digit numbers were optional but should be included in a list with other numbers with commas, e.g.:

  • 123; 4,567; 7,890 or 123; 4567; 7890
  • 1,234; 4,567; 78,900 but not 1234; 4567; 78,900

I think this was especially jarring in mathematical sums, e.g.:

YesYCorrect: NIncorrect:
+ 78,900
+ 78,900

Should we include guidance on this? sroc 💬 05:37, 16 April 2015 (UTC)

The same would go for tables too.
YesYCorrect: NIncorrect:
1,234 1234
4,567 4567
78,900 78,900
84,701 84,701
I'd agree with this. The question is whether then other numbers on the page should follow suit. I'd say it would be best if they did. Jimp 07:29, 16 April 2015 (UTC)
  • I'll need time to catch up on the intervening discussion, but on this last bit... Please, we don't need to specify absolutely everything -- we can rely to some extent (maybe even a lot) on editors' good sense. I would really prefer we not go so far as to rigidly insist that all four-digit numbers be treated the same way throughout an article, and for tables and so on, we might just mention that alignment should be considered. I think the following is fine, for example:
+   4567

— Preceding unsigned comment added by EEng (talkcontribs) 16:39, 16 April 2015

Well I don't (think it's fine). Perhaps it is browser related but the columns are out of alignment on my screen. Jimp's version is clearer. Dondervogel 2 (talk) 16:48, 16 April 2015 (UTC)
(I've changed the example slightly to emphasize what I'm about to say.) If you mean that the comma in the total is directly below the thousand's place in the addends, yes, that's intentional, because maybe where there are a lot of little 4-digit addends, adding to a big 5- or 6-digit number, you might not want the clutter of commas in all the addends, but want the comma in the sum. I really think we should be leaving little choices like this to the editors of individual articles -- let them decide what looks best, and put something in MOS only when it's clearly needed because of it keeps coming up as a problem in multiple articles. EEng (talk) 17:10, 16 April 2015 (UTC)
Perhaps this kind of thing would be best dealt with elsewhere, like a section on aligning digits in tables etc. (note, though, that calculations like the aboves aren't going to be common); then let people figure it out themselves. Too many mini rules have the potential to cloud this guidance. Also, if we're going to talk about the alignment of digits, we'd have to deal with the problem of varying numbers of digits after the decimal point like in the example below.
Japanese unit Metric Imperial/US
character tsubo square
shaku 1100 0.03306 51.24 0.3558 0.03954
110 0.3306  512.4  3.558  0.3954 
12 1.653   2562   17.79   1.979  
tsubo 1 3.306   5124    35.58   3.954  
bu 1 3.306   5124    35.58   3.954  
se 30 99.17    1.537×105 1067      118.6    
tan 段, 反 300 991.7     1.537×106 1.067×104 1186     
chō 町, 町歩 3000 9917       1.537×107 1.067×105 1.186×104
Jimp 17:39, 16 April 2015 (UTC)
Yes, I agree this kind of detail is best left to editors. A note providing general advice on alignment would address my concern. Dondervogel 2 (talk) 17:57, 16 April 2015 (UTC)
Good, and let's put additional considerations involving tables on hold for now, if I may suggest. EEng (talk) 18:06, 16 April 2015 (UTC)

Four-digit grouping on the right[edit]

Jimp's proposal says:

Digits should generally be grouped into threes; however, right of the decimal point, the final group of digits should not be a single digit. Instead add the final digit to the preceding group (e.g.  99.1234567).

This is new; the current guideline does not provide for four-digit groups, much less say that a single-digit group "should not" be used. As Dondervogel 2 has pointed out above, ISO 80000-1:2009 advocates three-digit groups and makes no allowance for a final four-digit group.

I have no objection to allowing a final four-digit group, but think this should probably be optional, e.g.:

Grouping with thin spaces
  • Digits should generally be grouped into threes. Right of the decimal point, the final group of digits may include four digits to avoid having a single digit after a gap (e.g. 99.1234567 or 99.1234567). For numbers with a large number of digits in mathematics-oriented articles, digits may be grouped into fives (e.g.  3.14159265358979323846...).

Note the use of "may" in the above wording. sroc 💬 15:46, 18 April 2015 (UTC)

It may seem new but it's actually quite old. It dates back to 2008 when thin-space formatting was introduced and remained part of the guideline until only last year. It's pretty much been the norm on WP ever since we've been using space formatting. {{Val}} has been formatting numbers this way almost ever since its creation. {{Gapnum}} also uses this style. So, really not following the rule would be new; not only new but it would potentially lead to style clashes on pages which use {{val}} and/or {{gapnum}}. Jimp 18:46, 18 April 2015 (UTC)
Thanks. I thought this was familiar and was surprised not to find it in the current wording. In any case, should it be a "may" rather than a "should"? sroc 💬 19:43, 18 April 2015 (UTC)
May it be a "should" rather than a "may"? Jimp 20:44, 18 April 2015 (UTC)
That that is is that that is not is not is that it it is. sroc 💬 20:47, 18 April 2015 (UTC)
The real question is: Can can can can can can can can can can? sroc 💬 20:50, 18 April 2015 (UTC)
To be honest, I'd have to admit that I'm a little in two minds about it. Of course, we don't want to be too strict and stifle creativity by too many rules but adding yet another formatting style by switching "may" for "should" is not without its problems. Firstly, people come to the MOS for advice on what the standard style is; having too many options leaves us unenlightened. Secondly, the more options there are the less consistency we get. Thirdly, to accommodate the various options templates become more and more complicated making their code harder to read and write, pushing up their load time and entailing that fewer of them can be used on a page before we hit the template limits. So, unless there is a good reason to make this optional, I wouldn't be in favour of doing so. That said, though, perhaps there is a good reason. We'd prefer to have digits line up vertically in a table and this won't always be possible if we insist that this rule always be followed. So, instead of a "should" or a "may" perhaps a "generally" would be best. Perhaps something like this ... Jimp 22:09, 18 April 2015 (UTC)
  • Digits are generally grouped into threes. Right of the decimal point, having a single digit after a gap is generally avoided by including four digits in the final group (e.g.  99.1234567  or  99.1234567). For numbers with a large number of digits in mathematics-oriented articles, digits may be grouped into fives (e.g.  3.14159265358979323846...).
... or like this. Jimp 22:37, 18 April 2015 (UTC)
  • Digits are generally grouped into threes. Right of the decimal point, usual practice is to avoid having a single digit after a gap; so, the final group may include four digits (e.g.  99.1234567  or  99.1234567). For numbers with a large number of digits in mathematics-oriented articles, digits may be grouped into fives (e.g.  3.14159265358979323846...).
Revision by EEng:
  • Digits are generally grouped into threes. Right of the decimal point, usual practice is to have final group of four instead of a final lone digit (e.g.  99.1234567  or  99.1234567). In mathematics-oriented articles long strings right of the point may be grouped into fives (e.g.  3.14159265358979323846...).

You guys are moving too fast for me to keep up given other stuff I've got on my plate, but I like the apparent progress. Jimp, since there's been no comment on your last version I've made some adjustments which you should feel free to revert. Also, in the group-by-5 style, should there be a special provision for "6 at end instead of isolated digit"? And is the ... at the end of the "math" example really needed? If not, it's confusing. EEng (talk) 01:00, 19 April 2015 (UTC)

I'd make three points.
  • Your wording does seem to read better than mine.
  • I'm not sure why we'd want to restrict grouping by fives only to the right of the decimal point (a recently introduced idea). If grouping by fives is okay on one side, why not the other? Suppose we have a number with many digits on both sides, would we really want to group by threes on one side and fives on the other of the very same number (e.g.  123456789012345.678901234567890)?
  • Allowing for an optional (or even a compulsory) group of six when (otherwise) grouping by fives, it seems to me, just makes things that much more complicated. It might be a solution for a problem which doesn't exist; how often is this going to occur? Also, unlike the analogous provision when grouping by threes, it doesn't seem to draw from actual practice in the real world.
So, how about this? Jimp 02:00, 19 April 2015 (UTC)
  • Digits are generally grouped into threes. Right of the decimal point, usual practice is to have a final group of four instead of a lone digit (e.g.  99.1234567  or  99.1234567). In mathematics-oriented articles long strings may be grouped into fives (e.g.  3.14159265358979323846...).

I'm just guessing, but I suspect that if there's any grouping done on the left, it's always by threes, because the notion of 1000s, millions, billions, etc. is so universal. I wouldn't be surprised to see threes on the left and fives on the right, but again I'm just guessing. I think we need someone to dig up some actual examples in the wild. Again, this is all going too fast for me but maybe in the next few days I can catch up. Please, though, try to remember my usual advice that MOS shouldn't opine on things that editors have been able to, or are likely to, be able to decide for themselves on individual articles. (The threes-on-left-with-fives-on-right dilemma may be an example. Maybe we should say nothing about whether or not 3s can be combined with 5s, and editors faced with the question will have sources available to act as examples for them.) EEng (talk) 03:48, 19 April 2015 (UTC)

I'm inclined to agree with you. I see your point about grouping on the left's being naturally by threes in a way the grouping on the right isn't, so maybe banning  123456789012345.678901234567890 isn't the way to go after all. On the other hand, though, we might also say that it's natural to group digits consistently on both sides, so banning  123456789012345.678901234567890 doesn't seem right either. I'd be happy to have MOSNUM keep silent about whether one is preferable to the other and which that might be at least until it ever becomes an issue or until we do have a clearer picture as to what the actual practice out there is. As for the idea that "MOS shouldn't opine on things that editors have been able to, or are likely to, be able to decide for themselves on individual articles", yes, generally speaking, this pretty much goes without saying. Jimp 05:23, 19 April 2015 (UTC)

A specimen found in the wild[edit]

Look at Heegner number, which foregoes any spacing on the right, and sometimes on the left (262,537,412,640,768,743.99999999999925...6403203 + 744 − 0.00000000000075). I think failing to group the digits makes it particularly hard to read (i.e., count the repeated digits), but there may be special reasons to do this. Do we take any examples of this or treat this as exceptional? sroc 💬 12:05, 19 April 2015 (UTC)

I meant someone should look at some article in math / physics / astro journals. EEng (talk) 14:41, 19 April 2015 (UTC)
I'd be guessing that the special reason to do this is sloppiness. Heegner number, like any article, is a work in progress, so I don't think we can necessarily take how things happen to be done there as the way things should be done. There's always room for improvement. Jimp 12:39, 19 April 2015 (UTC)
Here's what the article would look like if numbers were formatted. It's a whole lot more readable. However, when I was over there I noticed a hidden comment "don't put thousands separators under <math>!". I cannot, however, think of any valid reason to make an exception for numbers that happen to be produced using <math>. My guess is that whoever was insisting on this was labouring under the misapprehension that thousands separators within <math> are going to produce spaces after the comma like <math>262,537,412,640,768,743.99999999999925</math> would but <math>262{,}537{,}412{,}640{,}768{,}743.99999999999925</math> (as used on the page in spite of this insistence) gives normal comma formatting and <math>262\,537\,412\,640\,768\,743.999\,999\,999\,999\,25</math> gives thin spaces. I've raised the issue on the talk page. Jimp 13:23, 19 April 2015 (UTC)
A little digging around and I believe I've found the answer. It was just as I'd expected, <math>262,537,412,640,768,743.99999999999925</math> puts spaces after the commas which is undesirable. So, it's not that thousands separators shouldn't be used in <math> but merely that people should take the time to look up how to do this properly. Thus, the special reason seems to be that nobody bothered to read Help:Math ... which could be called sloppiness. Jimp 14:01, 19 April 2015 (UTC)
Should we mention formatting mark up when using <math>? Jimp 14:06, 19 April 2015 (UTC)
For the specific question of math/physics/etc. (especially very long numbers unlikely to arise in articles on general topics) why don't we raise the issue at project Math or whathaveyou? EEng (talk) 14:41, 19 April 2015 (UTC)
I must say, even after skimming Help:Displaying a formula (WP:MATH) and searching in vain for "comma", I couldn't find any advice on this. This may be worth raising on that talk page and/or Wikipedia talk:WikiProject Mathematics. sroc 💬 17:22, 19 April 2015 (UTC)
Wikipedia:Manual of Style/Mathematics (MOS:MATH) also addresses formatting formulae but doesn't clearly explain what to do with commas; worth raising on that talk page, too. I suggest that's the most appropriate place to raise this issue and link from the MOS:MATH and WikiProject talk pages to that discussion. sroc 💬 17:26, 19 April 2015 (UTC)
In direct response to the question "Should we mention formatting mark up when using <math>?" I don't think we need to overload MOS:NUM with this; it belongs at MOS:MATH and/or WP:MATH where <math> is already covered and will find a more relevant audience. sroc 💬 17:33, 19 April 2015 (UTC)

Year in article head[edit]

Articles for Bandy World Championships have recently been moved from (e.g.) Bandy World Championship 2015 to 2015 Bandy World Championship. Is this due to some rule in the Manual of Style which I can't find? Skogsvandraren (talk) 14:13, 19 April 2015 (UTC)

Sorry, definitely not our department. (We're in charge of whether the year has a comma in it.) Why not ask User_talk:Shirt58, who made the move you linked here? EEng (talk) 00:25, 20 April 2015 (UTC)

How to write January 1, 1[edit]

There is a discussion at Talk:Julian day#Timestamp column about whether January 1, 1, should be written Jan 1, 1 in a table. User:Be..anyone would like to write it Jan 1, 0001. Jc3s5h (talk) 22:19, 24 April 2015 (UTC)

Subject to the approval of my esteemed fellow editors, I've added [2] an entry to the dos-and-don'ts table re not zero-padding years. For the record, please comment even it it's just a support. Notice that, since we've got that numbskull provision that YYYY-MM-DD can't be used before 1583, the question is moot for the one place zero-padding might actually make sense i.e. the YYYY in YYYY-DD-MM. EEng (talk) 23:33, 24 April 2015 (UTC)
We can't seem to agree if ISO 8601 applies to dates in the YYYY-MM-DD format. I think I found a few vague diffs from near the founding of Wikipedia hinting that it did, but I didn't stash them in a safe place. If we don't declare what standard applies, who is to say the way to write January 1, 1 in the all-numeric format isn't 1-01-01? Jc3s5h (talk) 23:53, 24 April 2015 (UTC)
Support but I think it would be more helpful to comment on the talk pages of Julian day, Rata Die, where this format has been introduced by User:Be..anyone. Jc3s5h (talk) 23:41, 24 April 2015 (UTC)
A few more supports here and that debate will be moot (at least the zero-pad part of it). EEng (talk) 23:48, 24 April 2015 (UTC)
Support, of course. That said, I would not write "January 1, 1", just as I would not write "2004-05" for "May 2004", as it's a confusing and ambiguous construction. – Jonesey95 (talk) 23:57, 24 April 2015 (UTC)
What would you suggest for that somewhat unusual situation? – perhaps January 1, 1 AD? EEng (talk) 02:17, 25 April 2015 (UTC)
I would suggest avoiding it. It's very much a hypothetical date, isn't it? I don't think it even makes sense to write it down. Nobody was watching the ball drop with Dick Clark or arguing about which year was the first year of the new millennium on that particular day, I suspect. I read the discussion on the linked talk page, and it looks like a morass to me. And that's from someone who watches this page.... – Jonesey95 (talk) 04:17, 25 April 2015 (UTC)
Indeed a shocking indictment! However, in a technical discussion you might want to say something like days since January 1, 1 AD. I just thought the AD would help the reader parse. EEng (talk) 10:46, 25 April 2015 (UTC)
Cambridge University Press saw fit to publish Dershowitz and Reingold's Calendrical Calculations (several editions, in fact) and that book does contain it (see p. 15 of the 3rd ed. as an example). So Jonesey95's suggestion that there is no need to write it down is dashed to smithereens. Jc3s5h (talk) 11:19, 25 April 2015 (UTC)
OK, but please, let's keep the rhetorical smithereen-smashing to the talk pages of the articles in question. EEng (talk) 11:23, 25 April 2015 (UTC)
  • Support. And I believe I would, as a rule, always use AD/BC/CE/BCE on one- or two-digit years to make them easier to parse. The first barrier is making it understood that it is in fact a year, and to my mind "January 1, 1" and "1 January 1" probably fail on that. Kahastok talk 11:41, 25 April 2015 (UTC)
I think what's going on here is that the brain tends to parse a one- or two-digit number as a day-of-month, so there's a moment of brain-freeze when confronted with January 1, 1 or 1 January 1. I've made another bold edit [3], subject to the approval of my esteemed fellow editors. EEng (talk) 12:09, 25 April 2015 (UTC)
I support this change. Kahastok talk 19:55, 26 April 2015 (UTC)

Using AD/BC/CE/BCE for any year less than 100 AD wherever there is potential confusion (i.e. in most cases) seems the most sane approach. Zero padding is just something we don't do when writing dates in normal English (in though yyyy-mm-dd we would might). Jimp 08:45, 26 April 2015 (UTC)

We would write January 1, AD 1 as 0001-01-01 if we had adopted a standard telling us what to do so. If we ever allowed dates in that format before 1583 we would have to adopt a standard or make up our own telling editors what to do. Jc3s5h (talk) 15:52, 26 April 2015 (UTC)
It is not obvious to me (other than based on context) that "0001-01-01" is even a date. But I have never been happy with the YYYY-MM-DD format at all, because it takes that much longer to parse at the best of times, compared with the "26 Apr 2015" format that does not require significantly more space. Kahastok talk 19:55, 26 April 2015 (UTC)
In practice I don't think this is likely to be a problem. It's a rare occasion when you'll see dates from before 1583 in a table, for example. In most instances where it comes up, I'd say just leave it to the intelligence of the editors working on the article. Adding BC/AD/BCE/CE to disambiguate years close to 1 AD is pretty commonsense and should not be controversial. Archon 2488 (talk) 14:10, 27 April 2015 (UTC)
Violating my exhortation below... the funny thing about YYYY-MM-DD is that, if we allowed e.g. 27Apr2015 (without spaces) that would actually be as or more compact horizontally than 2015-04-27 -- compactness being the primary argument for YYYY-MM-DD (sort-ability being handled another way). Check it out:
Results would be slightly different for different particular values, but I double DDMMMYYYY would ever be wider than YYYY-MM-DD. EEng (talk) 15:31, 27 April 2015 (UTC)
It's harder to parse and not very aesthetically pleasing without spaces. I think that's more important than saving a tiny bit of space at the edges; space isn't at that much of a premium on our pages, surely. Archon 2488 (talk) 16:12, 27 April 2015 (UTC)
Well, space does matter in e.g. tables. I agree 25Apr2015 isn't very nice-looking, but I'm just pointing out it's as nice-looking, or nicer, than 2015-04-25, and as or more compact. I'm not advocating either. EEng (talk) 16:57, 27 April 2015 (UTC) Why the hell am I fanning the flames of this conversation?
YYYYMMDD satisfies this new criterion of compactness while remaining eminently sortable - e.g. 20150427. I'm grateful to EEng for so gently leading us to this conclusion which I am sure will satisfy everyone. NebY (talk) 16:43, 27 April 2015 (UTC)
Oh, fuck. What have I done? EEng (talk) 16:57, 27 April 2015 (UTC)
It's also language neutral. Dondervogel 2 (talk) 17:42, 27 April 2015 (UTC)
All online references for this special date in tables on two pages use 1 January 0001 or 0001-01-01 (+time where discussed.) I haven't read the book. Trivia, if I understood it correctly the Go (programming language) manual claims that it is perfectly okay to consider 0 as invalid or undefined, because nobody would ever need this date. Nobody outside of MOS talk pages. –Be..anyone (talk) 22:50, 27 April 2015 (UTC)
I can't think of any good reason to use yyyy-mm-dd at all on WP. Jimp 01:00, 27 April 2015 (UTC)