Wikipedia talk:Manual of Style/Dates and numbers

Manual of Style

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

Archives

General 1, 2, 3, 4, 5, vote, 6, 7, 8, 9��(AD/CE), 10, 11, 12, 13, 14, 14a, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 49a, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161 Binary prefixes B0, B1, B2, B3, B4, B5, B6, B7, B8, B9, B10, B11, B12, B13, B14, B15, B16, B17 Years and dates D1, D2, D3, D4, D5, D6, D7, D8, D9, D10, D11, D12, D13, D14 See also Wikipedia:WikiProject Dates Wikipedia talk:Date debate Wikipedia talk:Naming conventions (calendar dates) Wikipedia talk:Timeline standards Wikipedia:Measurements Debate Wikipedia talk:Manual of Style (dates and numbers)/Date autoformatting Complete rewrite of Units of Measurements (June 2008) Dec. 2008 RfC on Date linking/autoformatting (three proposals) Dec. 2008 RfC on Date linking/autoformatting (detailed)

This page has archives. Sections older than 15 days may be automatically archived by Lowercase sigmabot III when more than 2 sections are present.

This is the talk page for discussing improvements to the Manual of Style/Dates and numbers page.

Put new text under old text. Click here to start a new topic. New to Wikipedia? Welcome! Learn to edit; get help. Assume good faith Be polite and avoid personal attacks Be welcoming to newcomers Seek dispute resolution if needed

Archives: Index, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163Auto-archiving period: 15 days

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

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

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. Mkdw^talk 16:59, 1 April 2015 (UTC)[reply]

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

@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)[reply]

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).[reply]

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

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

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

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

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

@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)[reply]

• 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)[reply]

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

@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)[reply]

@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)[reply]

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

@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)[reply]

I think sroc's reading is correct. Jc3s5h (talk) 20:30, 9 April 2015 (UTC)[reply]

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

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

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

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

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

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

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

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

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

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

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

If it is, then the whole issue of DATETIES might well be mute. Cinderella157 (talk) 00:04, 12 April 2015 (UTC)[reply]

Well, if anything's patently obvious it's that the DATETIES issue is not mute. EEng (talk) 00:10, 12 April 2015 (UTC)[reply]

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

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

@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)[reply]

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

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

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. Mkdw^talk 04:00, 18 April 2015 (UTC)\[reply]

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

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. Mkdw^talk 07:32, 18 April 2015 (UTC)[reply]

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

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. The current tax forms use ISO 8601, not DMY.

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

Hey, I already made the "mute" joke. Get your own humor! EEng (talk) 03:56, 13 April 2015 (UTC)[reply]

There was still some flavor left. :-) ~ J. Johnson (JJ) (talk) 22:37, 13 April 2015 (UTC)[reply]

The irony is that the error is perhaps not so erroneous, even if technically incorrect. Cinderella157 (talk) 23:30, 13 April 2015 (UTC)[reply]

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

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.[reply]

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

A difference in interpretation has arisen concerning the advice on the correct symbol for gigabit per second. Feedback is requested at GDDR5. Dondervogel 2 (talk) 17:07, 10 April 2015 (UTC)[reply]

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

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

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

  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. –Be..anyone (talk) 12:24, 15 April 2015 (UTC)[reply]

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

Perhaps we need "U+202F narrow no-break space   NNBSP" -- see Non-breaking_space#Width_variation. EEng (talk) 13:33, 15 April 2015 (UTC)[reply]

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

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:

Proposal:

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+1234⁄5678"  or  "4,321+7,654⁄9,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)[reply]

Good idea. Maybe just include these as examples?

—sroc 💬 05:27, 16 April 2015

... or something like

Jimp 07:35, 18 April 2015 (UTC)[reply]

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 (1⁄36,000 requires a comma but 1⁄3600 doesn't). —sroc 💬 15:04, 18 April 2015 (UTC)[reply]

Can I also suggest collapsing the three- and five-digit grouping points?

—sroc 💬 15:15, 18 April 2015 (UTC)[reply]

Good point regarding 1⁄3,600; yes, 1⁄86,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)[reply]

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 10⁶) 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)[reply]

Perhaps you could post your wife's X-rays and diagnosis when they're available. EEng (talk) 16:44, 15 April 2015 (UTC)[reply]

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

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

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

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

@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)[reply]

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

• 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)[reply]

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

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

YCorrect:	NIncorrect:
1,234 4,567 + 78,900 ———————— 84,701	1234 4567 + 78,900 ———————— 84,701

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

The same would go for tables too.

YCorrect:	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)[reply]

• 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:

    1234
    4567
    1234
    4567
    1234
    4567
    1234
    4567
    1234
    4567
    1234
+   4567
————————
 123,701

— Preceding unsigned comment added by EEng (talk • contribs) 16:39, 16 April 2015 (UTC)[reply]

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

(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)[reply]

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
romanised name	character	tsubo	square metres	square inches	square feet	square yards
shaku	勺	1⁄100	0.03306	51.24	0.3558	0.03954
gō	合	1⁄10	0.3306	512.4	3.558	0.3954
jō	畳	1⁄2	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)[reply]

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

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

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

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

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

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

May it be a "should" rather than a "may"? Jimp 20:44, 18 April 2015 (UTC)[reply]

That that is is that that is not is not is that it it is. —sroc 💬 20:47, 18 April 2015 (UTC)[reply]

The real question is: Can can can can can can can can can can? —sroc 💬 20:50, 18 April 2015 (UTC)[reply]

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

... or like this. Jimp 22:37, 18 April 2015 (UTC)[reply]

Revision by EEng:

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

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

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

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

Look at Heegner number, which foregoes any spacing on the right, and sometimes on the left (262,537,412,640,768,743.99999999999925...;  640320³ + 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)[reply]

I meant someone should look at some article in math / physics / astro journals. EEng (talk) 14:41, 19 April 2015 (UTC)[reply]

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

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

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

Should we mention formatting mark up when using <math>? Jimp 14:06, 19 April 2015 (UTC)[reply]

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

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

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

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

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