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.

It has been 106 days since the outbreak
of the latest dispute over date formats.

Date retain argument at Evo 2015[edit]

I'm dealing with a dispute over at Evo 2015 related to Date Retain, where I user named @Tony1: is insistant that all the dates within the article's sources should be changed to match those within the article prose. (first change) This argument seems rather convoluted to me? After all, the "yyyy-mm-dd" format can't even be used in prose last time I checked. Surely, this is not how the guideline was intended? There are some other issues as well, such as that the prose dating-style has changed a bit since I brought the article in the mainspace, and that to undo Tony1's change in date-format, I keep undoing his other changes during that edit as well >.> ~Mable (chat) 19:09, 24 August 2016 (UTC)

WP:DATEFORMAT would seem to indicate that the use of YYYY-MM-DD is indeed permissible in citations. --Izno (talk) 21:04, 24 August 2016 (UTC)
No. Unfortunately these rules are the wreckage of a decade-plus of arguing, they're pretty complicated, and really have to read the entirety to be sure your getting all the exceptions and notes. See WP:DATEUNIFY -- yyyy-mm-dd is OK for access and archive dates only, not publication dates. EEng 21:50, 24 August 2016 (UTC)
The third point of "publication date" at DATEUNIFY explicitly says that yyyy-mm-dd is allowed for regular publication dates, Eeng. I've read through these guidelines a year ago and concluded that that format suits my preference the best. I've also seen it used on a lot of pages, so I kinda took it as a "Wikipedia standard". ~Mable (chat) 22:34, 24 August 2016 (UTC)
"Publication dates ... may be ... the format expected in the citation style." And at WP:CITESTYLE we have, "Although nearly any consistent style may be used, avoid all-numeric date formats other than YYYY-MM-DD." Which seems to say that YYYY-MM-DD is acceptable. And we usually don't do mass style changes without a good reason or at least a talk page discussion. I'm not crazy about this style but MOS seems to say it's ok. Kendall-K1 (talk) 23:01, 24 August 2016 (UTC)
Oops, sorry, I read hastily and got distracted by something else. My apologies. EEng 05:00, 25 August 2016 (UTC)
Haha, it's alright - don't commit Seppuku just yet. I'm just glad I'm the one not going crazy :) ~Mable (chat) 07:30, 25 August 2016 (UTC)

Wrong/contradictory examples for time durations in "Mixed units"[edit]

The table in MOS:NUM#Unit names and symbols gives "1 hr 30 min 7 sec" as a correct example and "1 h 30 min 7 s" as an incorrect one, whereas the next section, MOS:NUM#Specific units, clearly says that the correct symbols for hour, minute and second are "h", "min" and "s" respectively (it also does not mention "hr" and "sec" as correct, which probably implies that they are at least not recommended, but in fact are incorrect according to SI rules). That is, "1 h 30 min 7 s" is actually perfectly correct, and "1 hr 30 min 7 sec" is not SI-compliant and contradicts the rest of MOS:NUM ("hr" and "sec" are not mentioned anywhere else). — Mikhail Ryazanov (talk) 07:31, 27 August 2016 (UTC)

Some points:
  • Note that the Specific Units table explicitly endorses both min and m for minutes.
  • Wikipedia quite consciously is not always SI-compliant. As I recall (for example), SI doesn't recognize day as a unit of time, and we're certainly not going to tell editors they can't use that!
Clearly there's a discussion needed here, so let the games begin! EEng 07:44, 27 August 2016 (UTC)
I guess what the table is trying to say is that a mixed time should be internally consistent; choose the long abbreviations hr-min-sec or the short ones h-m-s but don't mix them. Kendall-K1 (talk) 14:21, 27 August 2016 (UTC)
I suppose Kendal-K1 is right about the intent of the table, but according to the SI brochure, hour and minute, while not SI units, are accepted for use with SI. The correct symbols, according to the brochure, are h and min. Using m as a symbol for minute is not especially desirable, because it could be confused with meter. So "min" is a suitable symbol to use together with "h" and "s". Jc3s5h (talk) 19:59, 27 August 2016 (UTC)
Yes, in theory it could be confused with the metre - but in context? I doubt it. We do say already (in a different part of the text), "Use m for "minute" only where there is no danger of confusion with meter".
I just did a Google search for "hr", "min" and "sec" in Wikipedia, and this unit style seems to be used mostly for sports articles and early aviation records.
I don't see it as problematic to allow hr and sec to be used consistently with min in a mixed unit. YMMV, but I don't have the impression in particular that h is common in English as a unit symbol for the hour, even if it is accepted by SI. Kahastok talk 20:30, 27 August 2016 (UTC)
I don't think it's common to use a unit symbol for hour in English at all. Time of day and duration in mixed units are usually expressed just with a colon (or, if seconds are included, a colon between hours and minutes, and a second colon between minutes and seconds). For example, the various English language formats for time of day or duration in Excel all use colons. I think most other ways of writing durations in short form would be found in scientific and technical work, and would thus lean toward following the SI brochure. Jc3s5h (talk) 21:13, 27 August 2016 (UTC)
I agree that 1:30:07 is the most accepted and probably the best format, but my point is that giving "1 h 30 min 7 s" as unacceptable while "1 hr 30 min 7 sec" as acceptable looks really wrong and inconsistent. Regarding the usage, "h" is used, but I have also seen idiotic examples like "2 hrs." ("idiotic" because "2 hours" is much more readable and only slightly longer, and if those people wanted a shorter form, then it should be "2 h", which is even shorter and actually standard). As I understand, WP:MOS is supposed not to invent its own rules but to combine the existing ones in a consistent manner. From this perspective, "h", "min" and "s" (and, regarding EEng's comment, "d" for "day") are codified by BIPM and NIST, but I haven't seen any style guide prescribing to use "hr" for "hour" (I also suspect that if these are considered as abbreviations rather than symbols, then at least "min." and "sec." should have periods). — Mikhail Ryazanov (talk) 02:49, 28 August 2016 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── I did some search through the history, and it seems that previously "1 h 30 min" was actually listed as an acceptable example. Then these "hr" and "sec" were added [1] by EEng without any references. Then sroc made [2] the current version after some discussion [3] among him(her)self... :–) Frankly, I could not understand how "1 h 30 min" became unacceptable, neither I could find any justification for "hr" and "sec". It was also mentioned in that discussion that "1h 23m 45s" is used for astronomy and navigation, but "1 h 30 m 7 s" seems to be just made up. So, unless somebody can provide reliable sources advocating these notations ("hr", "sec", and "m" for minutes) or rational arguments why we should keep them here, I would suggest to move them to "unacceptable" and return "1 h 30 min 7 s" to "acceptable" in order to make this MOS self-consistent and consistent with the BIPM/NIST notation. — Mikhail Ryazanov (talk) 08:33, 29 August 2016 (UTC)

Not to make excuses, but at that time "we" (I and some others) were reorganizing this page, with the intention of improving the presentation without changing the substance. This would be one of the few edits which did more than reformat/reword existing examples. I notice that around that time I also did this [4] so I'm pringing sroc to see if he remembers anything about this. It's also possible there was some Talk traffic on the subject too.
While Wikipedia's MOS generally borrows from styles used and seen elsewhere, it adapts, modifies, and extends to suit its own needs, and it certainly isn't bound by RS the way article content is. EEng 03:33, 30 August 2016 (UTC)
Certainly min and sec can't be mixed. It's min and s, or minute and second. Tony (talk) 08:37, 30 August 2016 (UTC)
I agree with Tony, and (contradicting Eeng) would add day (symbol d) to the list. I see no need (ever) on wp for the abbreviations "sec" and "hr" (yuk!). Dondervogel 2 (talk) 09:11, 30 August 2016 (UTC)
I'm happy to be the scapegoat if it helps us toward a better guideline, but how does adding d contradict me? EEng 09:38, 30 August 2016 (UTC)
Aren't ' and " the usual abbreviations for minutes and seconds? Hawkeye7 (talk) 09:59, 30 August 2016 (UTC)
These are widely used in other contexts, so we do not allow them to be used for units of time (or for feet and inches). Instead, they are used (or more correctly, the single and double prime are used) only for minutes and seconds of arc. See the "Specific units" table under "Angle".
My thoughts are to deprecate the nonstandard symbols "hr" and "sec" and to require the use of "h" and "s" as symbols for the units of time; "d" for day may also be acceptable. The use of "m" to denote the minute should be strongly discouraged. In short, I agree with Mikhail Ryazanov. Archon 2488 (talk) 11:39, 30 August 2016 (UTC)

Proposal T1[edit]

So, since no new thoughts appeared here in the passed week, and most editors seem to agree with my concerns, here are the proposed changes:

General guidelines on unit names and symbols
Aspect Guideline Acceptable Unacceptable
... and in expressing time durations ...
  • 1:30′07″
  • 1 hr 30 min 7 sec
  • 1 h 30 m 7 s

Notes to table:

  1. ^ Only use this format if it is clear from the context whether this means hours and minutes (H:MM) or minutes and seconds (M:SS).
  2. ^ This format is used in astronomy (see the IAU Style Manual[1] for details).
Guidelines on specific units
Group Name Symbol Comment
Time second s Do not use ′ (), ″ (), apostrophe (') or quote (") for minutes or seconds. See also the hours–minutes–seconds formats for time durations described in the Unit names and symbols table.
minute min
hour h
year a Use a only with an SI prefix multiplier (a rock formation 540 Ma old, not Life expectancy rose to 60 a).
y or yr See § Long periods of time for all the affected units.
Notes and references
  1. ^ Wilkins, G. A. (1989). "5.14 Time and angle". IAU Style Manual (PDF). p. S23. 

I think, adding day (d) to the last table is not necessary, since that "table lists only units that need special attention", and I cannot imagine what wrong can happen with it. — Mikhail Ryazanov (talk) 00:13, 6 September 2016 (UTC)

  • To summarize the changes:
  • In the first table, 1 hr 30 min 7 sec is moving from Acceptable to Unacceptable
  • In the first table, 1 h 30 m 7 s is moving from Acceptable to Unacceptable
  • In the first table, 1 h 30 min 7 s is moving from Unacceptable to Acceptable
  • In the first table, 1 hr 30 m 7 sec is moving from Unacceptable to nowhere
  • In the second table, you're dropping the note text, Use m for "minute" only where there is no danger of confusion with meter
  • In the second table, you're dropping everything about years
OK, everyone... thoughts? EEng 01:20, 6 September 2016 (UTC) Mikhail Ryazanov, did you really mean to drop the material in the second table about years?
I only included changes related to hours–minutes–seconds. Everything about years and the rest in these tables stays as it is. — Mikhail Ryazanov (talk) 01:28, 6 September 2016 (UTC)
OK, I added the years stuff to the second table so that it's clear it's not being changed or removed. EEng 02:35, 6 September 2016 (UTC)
  • Looks good to me. Tony (talk) 03:34, 6 September 2016 (UTC)
  • Sorry for the absence. This proposal looks good to me, too. sroc 💬 11:12, 15 September 2016 (UTC)

Commas instead of Periods as decimal separators[edit]

For a website which is global, shouldn't acceptance of both Latin and Arabic numeral systems be equally acceptable? One such example is the 2016 Central Italy earthquake article, where in the talk page it was noted an editor used a comma and not a period. Considering most of Europe and over half of the world use the Arabic comma separator, it just seems that in some circumstances, such as this about an Italian event, systems of the locality should be used, as is the case with spelling differences between American and English when talking specifically about a country-related topic.Grez868 (talk) 00:41, 28 August 2016 (UTC)

Italian usage has no weight here, because this is the English Wikipedia, and in the 21st-c English-speaking world the period/full stop are overwhelmingly the decimal separator, though there are minor exceptions. EEng 01:51, 28 August 2016 (UTC)
The English language version of Wikipedia is a worldwide encyclopedia for people who speak English, which is why spelling variations are accepted. Of course, English Wikipedia is read and edited by people who are not fluent in English and I welcome this. I think a fundamental principle behind Wikipedia is, however, to have versions of articles in all languages but delivered as separate language works using separate local cultural styles. This should hopefully reduce the disadvantages faced by people, who are not fluent in English, when they wish to access knowledge. I think a major objective of Wikipedia is to not force people to read only the English version of Wikipedia. An Italian person should be able to read a high-quality article about DNA in Italian Wikipedia using their native language and familiar notation. I think Wikipedia is about recording the knowledge of all cultures but that's not the same as having to present it in all formats in a single work (English Wikipedia). I think it is not unreasonable for English Wikipedia to adopt the decimal (and other) notation used in English-speaking countries. I wouldn't go to Italian Wikipedia and confuse readers by using a decimal point instead of the decimal comma that is used by Italians. It's also problematic for the thousands separator. One million is usually written as 1,000,000 in English-speaking countries but can be written as 1 000 000 in Poland but 1 000 000 or 1.000.000 in Germany. Similar issues are linked to e.g. quotation marks, which vary from country to country even more than decimal notation. I think the solution to this issue probably involves improving the content of Wikipedias in other languages rather than making English Wikipedia even more dominant while the other Wikipedias fall into disuse and force everyone to use English. GeoWriter (talk) 12:07, 28 August 2016 (UTC)
"which is why spelling variations are accepted"—yes, standard varieties within the anglophone world. I used to think it was a little racist, but in reality it's because standard varieties are the most accessible, in the larger scheme, by second-language speakers who read en.WP. Now, comma and point reversals spin out anglophones' minds, my own included: you have to stop a little to process it, and many readers will be foxed by it if they don't know. I'm afraid the comma–point usage is hardwired into the language, just like not writing 445 €, which is really annoying and has to be corrected frequently. I understand where you're coming from, but English is English, and we're stuck with it as part of the translation task. Tony (talk) 12:15, 28 August 2016 (UTC)
My personal philosophy here would be to pick one and stick with it; since English typically uses the period as a decimal separator, that is what en.wp uses. Personally, I am opposed to using commas in numbers at all because of this ambiguity; the SI standard, for example, is to permit either the comma or the period as a decimal separator, so long as one of them is used consistently (BIPM publications in French use the former, while in English they use the latter), while large numbers should be split up with thin non-line-breaking spaces to avoid ambiguity: 10590 km. Formally, "10,590 km", "10.590 km", and "10590 m" mean exactly the same thing. Archon 2488 (talk) 15:08, 28 August 2016 (UTC)
GeoWriter says "I wouldn't go to Italian Wikipedia and confuse readers by using a decimal point instead of the decimal comma that is used by Italians." I don't understand. GeoWriter has just argued for using the typography local to what the article is about -- Italian notation for an earthquake in Italy is the example. Wouldn't an article about an American earthquake in the Italian Wikipedia then use the American decimal point by this logic? This doesn't make sense, so I suspect is some kind of special pleading along and so I've lost interest in the proposal. Herostratus (talk) 15:38, 28 August 2016 (UTC)
Did you mean to position this as a response to me? I am confused. On my reading of GeoWriter's comment above, it does not mean what you say it means. Rather, GeoWriter says explicitly that " is not unreasonable for English Wikipedia to adopt the decimal (and other) notation used in English-speaking countries." He does not say that the English WP should use Italian notation or that the Italian WP would be expected to use American notation (rather the opposite), and he does not use the phrasing "local to what the article is about" – I would be cautious about paraphrasing people in this way unless you can be confident of their intended meaning. I am, however, confused by his closing remarks about improving non-English wikipedias vs. "making English Wikipedia even more dominant". I don't understand what this has to do with typographical matters. Archon 2488 (talk) 15:55, 28 August 2016 (UTC)
Herostratus wrote: "GeoWriter has just argued for using the typography local to what the article is about -- Italian notation for an earthquake in Italy is the example." That is not my position. My position is: use English notation on English Wikipedia and Italian notation on Italian Wikipedia. Perhaps you have mistaken me for another contributor, because I think your comments about what you think I've said seem to more closely reflect the proposal made by Grez868 who started this discussion. GeoWriter (talk) 16:24, 28 August 2016 (UTC)
Oops sorry you're write I misread it. Herostratus (talk) 21:56, 28 August 2016 (UTC)
It was hard to see what Grez868 was getting at, with his Arabic versus Latin concept. I thought he meant Roman numerals at first. We all use Arabic digits, but the separator conventions do not come from there. In the English encyclopedia, we use point for decimals and commas (optionally) for digit grouping; mixing these up in different articles would be a disaster for our readers, so we don't. Dicklyon (talk) 16:30, 28 August 2016 (UTC)
And I agree with Archon that the optional use of commas to group digits is a bad idea and introduces ambiguity for those who sometimes interpret the comma as a decimal point; the BIPM says not to do this, yet WP allows it. If anything, we should be moving toward stricter, more uniform, more standard, less ambiguous number styling, not toward more ambiguous as Grez868 proposes here. Dicklyon (talk) 16:36, 28 August 2016 (UTC)
Archon 2488, I think many non-native speakers of English contribute to English Wikipedia, even in preference to their native language version, because English is the dominant Wikipedia version. I welcome these editors. I think improving non-English Wikipedias to address the dominance of English Wikipedia is relevant to typography and notation because I think it is a contributory reason why e.g. decimal commas occur on English Wikipedia. GeoWriter (talk) 17:23, 28 August 2016 (UTC)
I understand what you're saying, but the solution here at en.wp is to create a consistent style and require editors to stick to it (and you don't seem to disagree with this). We need to bear in mind that, although its servers are based in the USA, WP is an international project with a global scope, and we would like our content to be equally accessible (as far as that is possible) to everyone – so we cannot just follow the Associated Press Stylebook (for example). We need to accept that a very large proportion of our readers and editors are not native English speakers, and so our notation should be as close to a standard international style as possible (while not totally disregarding Anglosphere norms); this is why I say that commas in numbers should not be used, since they can cause confusion with the decimal separator widely used in non-Anglophone cultures (and using the comma as a decimal separator, conversely, confuses Anglophones).
Of course, the need for global reach is also why we have wikiprojects in languages other than English – but clearly, we are not capable of implementing solutions that would require enormous editor-power to make every version of WP of roughly equivalent quality. If your native language is Greek or Latvian, you're probably resigned to the fact that you can get access to a lot more information in English than in your native language (there are concepts in statistics and economics that explain the emergence of such monopolies), and realistically, nothing we do at Wikipedia is going to change that, because the reasons why it happens extend far beyond the scope of Wikipedia. Archon 2488 (talk) 12:05, 29 August 2016 (UTC)
I think you actually raise a very good point there. Often times when searching for something in another language, the content of the page is close to nothing compared to what is on the English version. Infoboxes are sparsely used and only pushes everyone to the English Wikipedia. After reading all the views here, I have to conclude that (personally), I agree that there should be a single international convention developed where separators are used only when actually speaking of a decimal integer where a period (".") is necessary and spacing should then be used for other extended integers. For an international project where English is obviously the most used, it just seems this would be the thing to cause least confusion to the reader-base as an entirety, and using spaces in lieu of decimal commas/points would be obvious to everybody, even when a decimal point is used to indicate a number with decimal places/fractional numbers. It's the same with commas as separators of large numbers (i.e. 1,001). Someone in Germany would read this as 1.001 (a number with three decimal places), whereas some countries (even English speaking) would be confused as to why there is even a comma there. I for one in School in the UK was never taught to use a comma for 4 digit numbers, only for 5 and above. The system, as-is, is a farce for the international audience and isn't working by the number of edits which have to take place to correct them.Grez868 (talk) 22:31, 3 September 2016 (UTC)
  • Um, would I be right in summarizing the above as: Everyone except the OP agrees we should retain the current guideline i.e.
A period/full point (.), never a comma, is used as the decimal point (6.57, not 6,57).
EEng 19:55, 28 August 2016 (UTC)
  • Yes. Kendall-K1 (talk) 20:04, 28 August 2016 (UTC)
  • Yes. Peter coxhead (talk) 12:32, 29 August 2016 (UTC)
  • Yes. Robevans123 (talk) 14:41, 29 August 2016 (UTC)
  • Me too. The important principle here is adopt a rule and stick with it, consistently. One can argue about whether that rule should be a period or full stop, but a comma? Not on the English wp Dondervogel 2 (talk) 22:18, 29 August 2016 (UTC)
  • Me too (in case it wasn't clear). We haven't heard from the OP since he/she OP'd, so I think this is dead anyway. EEng 00:09, 30 August 2016 (UTC)
  • Yes. By the way, I have seen a script change the dot to a comma in "9.999" where 9 is any digit. It even changed 0.342 to 0,342! That's on the principle that someone must have copied the number from another wiki where dot is a thousands separator. Johnuniq (talk) 01:32, 30 August 2016 (UTC)
  • On the contrary, there are comments saying that "something" needs to change to achieve better standardisation and cause less confusion amongst the readerbase as a whole, especially considering how many of them are not native to the UK/USA. Read my comment above for more on what I think.Grez868 (talk) 22:31, 3 September 2016 (UTC)
What I see are concerns that the "thousands separator" (shall we call it) should be a space/thinspace instead of comma. I see no one (including you) advocating any change to the bit of guideline text I quoted above. EEng 23:00, 3 September 2016 (UTC)
To be honest, I'm a little confused myself right now whether i meant that percentile numbers should be adjusted or numbers depicting large numbers as the word decimal covers all forms of number which we actively use (alternatives being of course Binary, Octa and Hex). I tried finding my original logic by looking through the edits of the initially mentioned article but can't seem to find it. Timestamp of my original post for me is a little after midnight, August 24th (UTC) but the article wasn't started until hours after that. In any case, both scenarios could be cleared up by only having one punctuation used in numbers of all kinds, because doing so would eliminate any cause for confusion of what it is (a percentile/number with decimal point or a long integer). As aforementioned, this would be done by eliminating commas from long integers. I guess this suggestion is an unlikely one though because reflecting, with the number of articles we have on the English side of Wikipedia, adjusting as necessary would literally take forever. I'm with the consensus.Grez868 (talk) 23:44, 3 September 2016 (UTC)


We should stick with the dot as the decimal separator. This is English, not French or whatever Wikipedia. Something like "47.5" is read aloud as "forty-seven point five" because English uses a point here, not a comma.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  18:46, 8 September 2016 (UTC)

Looks like we're done re . as decimal point; now what about the thousands separator?[edit]

I would support the deprecation of the comma as a thousands separator. It would need to take forever to implement (that's what bots are for) but even if takes a long time, it's still worth making this improvement. Isn't that what the thin space is for? Dondervogel 2 (talk) 15:51, 5 September 2016 (UTC)

Well, if you guys want to take on convincing people to deprecate comma, I'll enjoy the show, but no matter what this should not be a bot-implemented mass change. Aside from the problem of subtle errors of some kind (imagine an article on IBM data formats) for people who will be suspicious in the first place that the thinspaces are some kind of internationalist commie politically correct typographical plot, nothing will be more infuriating than a bot arriving to implement it automatically. Take the Fabian approach. EEng 18:14, 5 September 2016 (UTC)
Happy to defer to EEng's greater wisdom re Pasionariabot (sincerely meant - no sarcasm intended, honest guv). My preference for the thin space over the comma remains. Dondervogel 2 (talk) 18:23, 5 September 2016 (UTC)
While some scientific topics are exceptions, there is no prospect of replacing commas with gaps generally. Anyone wanting to make that proposal should work out how to deal with the wikitext and the copy-paste problem. Try copying the following text and pasting it somewhere:
  • 1,234,567 → 1,234,567
  • <span style="white-space: nowrap">1<span style="margin-left: 0.25em">234</span><span style="margin-left: 0.25em">567</span></span>1234567
  • 1&thinsp;234&thinsp;567 → 1 234 567
The first and second lines can be copied/pasted as expected, but the third line does not give a useful number. Very few enwiki editors would want to use anything other than 1,234,567 and would not want to use {{gaps}} or other klunkiness. Johnuniq (talk) 01:15, 6 September 2016 (UTC)
I agree that the potential advantages of deprecating , as thousands separator aren't worth the trouble. This people can live with. EEng 07:39, 7 September 2016 (UTC)
Notwithstanding my preference for the thin space, I agree we can live with comma. Dondervogel 2 (talk) 11:42, 7 September 2016 (UTC)
The thousands separator has been a mess in the world of computers at least since the time we stopped printing on 14 inch (35 cm) wide green bar paper with tractor-feed holes, and expected ordinary people to read numbers produced by a computer. The computer industry is nowhere close to solving the problem, and I don't think Wikipedia is in any position to fix it. Lets just curse under our breath and stick with commas. Jc3s5h (talk) 13:07, 7 September 2016 (UTC)
Stick with somma. Using a space of some width or other is a non-English and (in English) specialist usage that is unrecognized by and confusing to the majority of our readers.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  18:47, 8 September 2016 (UTC)
Somma my as­so­ci­ates think we should change the thousands separator...
See right. But to be clear, though I think people would understand a thin space without problem, I agree we should leave this particular hornet's nest alone. EEng 21:35, 8 September 2016 (UTC)

Double prime for inches[edit]

Prompted by a comment in another discussion above, and maybe this is a question for Wikipedia:WikiProject Military history. We've got these two similar articles, one with quote mark and one with double prime:

Are both acceptable? Then there is also for example 3-inch M1902 field gun. Kendall-K1 (talk) 13:00, 30 August 2016 (UTC)

No. See the specific-units table right at the top. EEng 16:32, 30 August 2016 (UTC)
That actually says both are equally unacceptable. The problem with that is that 3"/23 is a pretty standard name for this gun, as used in the reliable sources. So if you consider it a name rather than a measurement, I think it's acceptable, but still don't know which glyph to use. I agree that it would be incorrect to say, for example, "this gun has a barrel that is 3" in diameter." Kendall-K1 (talk) 18:05, 30 August 2016 (UTC)
Sorry, I didn't look closely enough at the usage the OP was discussing (excuse: I was on my mobile) and was responding only to the 3" bit. Kendall's response is exactly right. EEng 18:41, 30 August 2016 (UTC)

Centuries and millennia[edit]

I've come across something in Wikipedia:Manual of Style/Dates and numbers that puzzles me. It is in the section on Centuries and millennia at MOS:CENTURY. The first indented bulleted item within the first main bulleted item is:

  • The 18th century (1701–1800) and the 1700s (1700–1799) are not the same period.

This is perfectly clear to me, and I'm glad it is here because this is often misunderstood.

The second indented bulleted item just below that is:

  • When using forms such as the 1700s ensure there is no ambiguity as to whether e.g. 1700–1709 or 1700–1799, is meant.

This, I find confusing. What is the point of singling out 1700–1709 and contrasting it with 1700–1799? To me, any confusion between those would most likely be a matter of typing or keyboarding in the right numbers. It would make more sense to me if the first range were 1701–1800. Then the contrast would be between the years of the 18th century and the years of the 1700s, and this sentence would be further support for the first bulleted item.

I was also going to say that I think "the 1700s" (in "When using forms such as the 1700s") should be in bold or highlighted in some way when I realized that it is in a different font and, if my eyes are seeing correctly, slightly green in color. I can't believe this shade of green is being used for highlighting words, phrases and numbers on this page. Is it just my eyes? To me, it is such a dull shade of green, and not much darker than the text surrounding it, that it doesn't stand out. I think the color used for words, phrases and numbers to be highlighted (kind of like putting them in quotation marks) should be either a brighter shade of green or bolded or otherwise highlighted.  – Corinne (talk) 01:13, 31 August 2016 (UTC)

This second point is separate from the first. The ambiguity is between the 1700s as a century (1700–1799) and the 1700s as a decade (1700–1709). Maybe this could be made more clear? Kendall-K1 (talk) 02:21, 31 August 2016 (UTC)
I clarified [5]. EEng 02:30, 31 August 2016 (UTC)
As for the font color contrast, I can't find much about contrast ratios between fonts, but there is much written on the subject of contrast between font and background. ISO and ANSI recommend a minimum of 3:1, and W3C recommends 4.5:1.[6] The ratio between our green (which is W3C "dark green") and black is 2.82:1.[7] The contrast between dark green and black is very apparent to me, but it will depend a lot on your screen technology and settings. Kendall-K1 (talk) 02:35, 31 August 2016 (UTC)
Oh, now I get it. Thanks, Kendall-K1 and EEng. However, how often do people really say "in the 1700s" to mean "some time during the years 1700–1709", or "the whole period from 1700 to 1709"? I don't think it's very often. I think what is more common, and clearer, is "in the first decade of the 1700s", "during the first decade of the 1700s", or "during the first decade of the 18th century". Perhaps we could suggest some of these wordings.  – Corinne (talk) 23:01, 31 August 2016 (UTC)
P.S. Regarding the green color of the highlighted text, I barely see the green color at all, but I clearly see the green color of the bullets next to changes to articles on my watch list.  – Corinne (talk) 23:03, 31 August 2016 (UTC)
Odd, it's the exact opposite for me. I can barely make out those green dots. In theory, the fonts at least should be customizable by setting your own user css, but I have never been able to get that to work. If you want to try, it's under Preferences -> Appearance -> Skin. Click on "Custom CSS" which will probably be a redlink. Create the page and put your css in it. Kendall-K1 (talk) 23:19, 31 August 2016 (UTC)
Thank you, Kendall-K1! Maybe I will, even though that kind of thing is a bit of a mystery to me.  – Corinne (talk) 23:33, 31 August 2016 (UTC)
I'm not sure of the precise wording, but perhaps we should consider depreciating the use of the term "the 1700s" etc.
  • "The 1700s" is ambiguous. It could mean 1700-1799 or 1700-1709.
  • If "the 1700s" refers to the decade 1700 to 1709, it would be better to specify the years rather than using an ambiguous term.
  • If "the 1700s" specifically refers to the century 1700-1799, it would be better to specify the years rather than using the ambiguous term.
  • In many cases *The 18th century" (1701-1800) is an unambiguous substitute even though 1701-1800 is not the same as 1700-1799.
Michael Glass (talk) 00:37, 1 September 2016 (UTC)
I've boldly made a change from 1700s to 1900s, since (as Corinne said) it's rare for anyone to intend the 1700–1709 decade when saying "the 1700s", but it's quite common for this to be the case when either "the 1900s" or "the 2000s" is said. This change also removes any confusion about this point being related to the one immediately preceding it. — Crumpled Fire contribs 00:54, 1 September 2016 (UTC)


I support getting rid of BC/BCE in the examples. You would never see this in a WP article. The example should match what you would see in article text, unless it's an example of what not to do. Which this isn't. Kendall-K1 (talk) 02:28, 1 September 2016 (UTC)

@Kendall-K1: Which examples? Are you talking about the entire MOS:ERA section or this sentence: Treat the 1st century AD as years 1–100, the 17th century as 1601–1700, and the second millennium as 1001–2000; similarly, the 1st century BC/BCE was 100–1 BC/BCE, the 17th century was 1700–1601 BC/BCE, and the second millennium 2000–1001 BC/BCE. ? If the former, we definitely need that section. If the latter, the point is not to say to use "BC/BCE" but that either one is acceptable/applicable. McLerristarr | Mclay1 03:27, 1 September 2016 (UTC)
BC and BCE are alternatives, and where the guideline text says BC/BCE it means "either BC or BCE, whichever". Only one or the other would actually be used. You'll notice that BC/BCE doesn't appear in actual examples -- our editors are smart enough to understand that this. EEng 03:31, 1 September 2016 (UTC)
I am agreeing with Crumpled Fire's comment and edit, "BC/BCE shouldn't be used together here." Yes, I know these are not examples in the red/green font sense of the word. Kendall-K1 (talk) 03:59, 1 September 2016 (UTC)
The intent seems clear enough to me, but I suppose it wouldn‘t hurt to say something like 100–1 BC (or BCE) and so on. Until someone decides to interpret it as expressing a preference for the era not parenthesized, that is.Odysseus1479 05:22, 1 September 2016 (UTC)
I thought of this, but it gets tiresome repeating that over and over. BC/BCE means the same thing, and as I said, our editors are smart enough to understand. No one's gonna actually think they're supposed to write "He died in 5 BC/BCE." EEng 05:51, 1 September 2016 (UTC)
It needn’t be used every time; at the first occurrence in a series ought to be enough.—Odysseus1479 07:36, 1 September 2016 (UTC)
  • Is it clear whether this thread concerns communication with editors or readers? Tony (talk) 08:34, 1 September 2016 (UTC)
I was responding to a revert on the project page, so editors only. Kendall-K1 (talk) 15:02, 1 September 2016 (UTC)

Archived discussion regarding WP:DATERANGE[edit]

For future reference, because I spent too long trying to find it, the discussion over data ranges was archived at:

When discussions like that take place outside of the MOS talk pages, should a link not be left here in the archives after the discussion has concluded? Maybe I missed such a link. I did find a pointer to the discussion in these archives here, but nothing after the discussion closed. Oh. I've just seen the note added here. Managed to miss that somehow... I'll still leave this note here, in case that note gets removed at some point. Carcharoth (talk) 06:15, 5 September 2016 (UTC)

Guidance on mid-2000 or mid 2000[edit]

Is it mid-2000 or mid 2000? Similarly for early-2000 and late-2000. I could not see this issue covered in the style manual. Perhaps someone could decide which form is acceptable and add this information to the guide. Best wishes. RobbieIanMorrison (talk) 23:53, 23 September 2016 (UTC)

Context, please? EEng 00:10, 24 September 2016 (UTC)

Range-dash wording[edit]

"(as is any range)", at the top, should be "(as is any range not preceded by "between" or "from")", if we're to be precise. Or otherwise reworded. Tony (talk) 02:43, 25 September 2016 (UTC)

[8] EEng 05:19, 25 September 2016 (UTC)