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

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 135 ← Archive 138 Archive 139 Archive 140 Archive 141 Archive 142 → Archive 145

Fuzzy language re non-breaking spaces

In several places (separating units and values, before an endash, etc.), this page says something like:

...preceded by a space (preferably a hard space or  )...

Is there a reason this fuzzy, ambiguous language is used? It's either policy or it isn't, right? Is there any reason why one would not use the correct character here? If not, I'd like to change such language to remove the ambiguity, e.g.:

...preceded by a hard (non-breaking) space, which is created with the HTML character entity reference  

Additionally, the main MOS page doesn't even mention this issue (any more, if it ever did), and I'd like to add that language there as well. —[AlanM1(talk)]— 09:36, 15 April 2013 (UTC)

The convention of inserting a non-breaking space between a number and its unit is one I've gotten used to in Wikipedia, but I've never been comfortable with it. I'm not bothered by a number followed on the next line by its unit. Alternatively there are many other places where it could be used to just as good effect, but we don't generally do so. The downside I see is that it makes it difficult to read text when editing which makes editing harder. I'd prefer to see the rule go away instead of making it less ambiguous. Thank you. SchreiberBike (talk) 18:34, 15 April 2013 (UTC)
IMHO  s should have the priority over U+0020 (at least in body text), but special templates like {{val}} should be used (and procreated) whenever it is practical. Incnis Mrsi (talk) 19:41, 15 April 2013 (UTC)

Expressing conversions with the same value (linear yards→meters with poor precision)?

I recently came across "50 to 100 yards (46–91 m)". The conversion to meters is too precise. I could correct this to "50 to 100 yards (50–100 m)", but even that seems unnecessary given that the numbers could stay the same after conversion. My instinct is to write this as "50 to 100 yards (meters)" but that might be confusing. Any preference? (I also considered "50–90 m", but felt even that was too precise given that the range is really intended to express an uncertainty of around 50 yards, which makes 90 seem like an odd bound.) --Fastolfe00 (talk) 01:50, 16 April 2013 (UTC)

What does the source say? If the 50 to 100 yards is verbatim you might want to consider
  • "50 to 100 yards" (about 45 to 90 m)
Is there not a better source that provides a more precise distance? Dondervogel 2 (talk) 07:33, 16 April 2013 (UTC)
I don't know what the value concerned is, so it's difficult to answer for a given situation. In general I would go with Dondervogel 2's answer.
If it is genuinely an uncertainty in a scientific sense, MOSNUM formally prefers 75 ± 25 yards, which could then be converted to 68 ± 23 m.
But often, what you're actually dealing with is a range of values. The example I'm thinking of is the dimensions of a sports pitch, where the governing body has set maximums and minimums but allows variation between those limits. You might know that your number is more than 50 yards and less than 100 yards, but don't know exactly what it is. In that case, you should base your conversions on how precise the measurements of the limits of the range are - how precisely you know that it's 50 yards and how precisely you know that it's 100 yards. Kahastok talk 17:35, 16 April 2013 (UTC)

Thanks for the feedback. The value here is intended to be a single linear measurement with a high degree of imprecision. The source estimates the distance is between 50 and 100 yards. --Fastolfe00 (talk) 23:23, 16 April 2013 (UTC)

IEC vs ISO binary prefixes

The section "Quantities of Bytes and Bits" has the following two assertions:

  1. "The IEC prefixes kibi-, mebi-, gibi-, etc. (symbols Ki, Mi, Gi, etc.) are not familiar to most Wikipedia readers"
  2. "consensus on Wikipedia currently favours the retention of the binary prefixes in computing-related contexts."

These two seem to be the only reasons given on the MOS for marginalizing/eliminating the IEC binary prefixes. They also strike me as uncomfortably weasely for the following reasons: First, Wikipedia, by its nature, should be informative, so a lack of familiarity with a prefix should not preclude its use on Wikipedia, especially when it is more accurate than the familiar prefix (in specific contexts). Second, if the current consensus is used to justify a certain style, that style cannot be expected to change. Current consensus about a style should be noted, respected, and referenced, but it shouldn't be used to justify the removal of another "style" (intentionally quoted; again, IEC prefixes are more accurate), or Wikipedia runs the danger of contemporary styles being dangerously self-reinforcing.

Wikipedia should be informative, and its articles should value precision and accuracy more than consensus of preference. I welcome discussion about changing not only articles, but also author attitudes about this section and other similar sections in the MOS. Liberulo (talk) 20:52, 12 February 2013 (UTC)

In my view Wikipedia should inform a reader about the topic the reader chose to look up, without forcing unfamiliar terminology upon the reader that is only peripheral to the subject the reader is trying to find out about, especially when the terminology is not generally used in general English-language publications. By the way, this has been extensively debated in the past. Jc3s5h (talk) 21:17, 12 February 2013 (UTC)
Thank you for your reply. I'm aware of the extensive debate, and have read most of it. I come from a university where we learn about things like binary prefixes and their importance. You can certainly imagine people like scientists and students using Wikipedia to look up information about unfamiliar prefixes precisely because they are uncommon, right? I happen to want to see the more accurate binary prefixes used more (Ubuntu uses them by default, by the way; that's not a publication, but it's also not an insignificant amount of exposure to the prefixes), but what concerns me more are those two reasons used in the rationale. I don't see how that's not an obvious issue; don't you see a danger of circular self-reinforcement of possibly bad style, forget the specific example of binary prefixes for now?Liberulo (talk) 08:48, 15 March 2013 (UTC)
The binary prefixes are more precise, in a sense, but they are not used in any reliable sources (other than the standard, itself), including sources published by the standards organizations. For other commentary, please see the extensive debates. — Arthur Rubin (talk) 22:27, 18 February 2013 (UTC)
My operating system (Ubuntu) uses those prefixes for system measurements by default, so that's significant. I've seen the extensive debates. The two rationale that came from it are worrisome to me, even if we collectively decide to be imprecise (unscientific?) for the sake of not having to learn/explain two sets of prefixes.Liberulo (talk) 08:48, 15 March 2013 (UTC)
Most of the technical world chooses not to use the IEC "bi" nonsense. Wikipedia follows what most of the technical sources choose to do. Glider87 (talk) 06:46, 24 March 2013 (UTC)
No matter if they chose to use the IEC prefixes or not, the world is quasi-unanimous regarding the International System of Units (SI). Using the SI prefixes as binary prefixes is an error made by the solid-state memory industry, and it should be stopped before it's even more costly/dangerous (think Mars Climate Orbiter) or difficult to change. Compvis (talk) 23:56, 13 April 2013 (UTC)
It's not out job to stop it. Terms become ambiguous, that's life. We've just got to find a good way of avoiding the ambiguity. Using a set of terms that never caught on doesn't seem like one of them. It would be a bit like using gillion, tetrillion, pentillion, etc. to avoid the ambiguity of billion, trillion, quadrillion, etc. JIMp talk·cont 03:38, 14 April 2013 (UTC)
It is not Wikipedia's job to save the world. Wikipedia's job is to present information in a clear, concise and unambiguous way. Trivialising the gibibyte (backed by at least three International Standards, used by all operating systems that attempt to remove this ambiguity as well as dozens of scientific articles every year) by a comparison with the gillion (not backed by a single International Standard, not used by a single operating system in the history of the universe, and not used by any serious publication) does not contribute helpfully to the discussion. Dondervogel 2 (talk) 13:38, 14 April 2013 (UTC)
Actually, I see what you mean, but I think your example is bad. A better example would be if the whole world used the word "million" in a given way (analogy to the SI prefixes established in 1960), and then out of convenience or lazyness or something, some tiny industry redefines it as meaning 1,048,576, which is exactly what has been done. There is absolutely no ambiguity on kilo, mega, giga, in all industries, sciences and countries worldwide, except in some parts of the computer industry. And even then, it's mostly the parts related to storage, but even then the hard disks use the SI prefixes in accordance to SI. I'll consider binary SI prefixes much more seriously as soon as anyone can tell me exactly where they are used to mean binary prefixes and where not. In the mean time, my proposition is simple: some parts of the computer industry made an error, and it will be helpful for everyone that they show technical leadership and fix it. About "find a good way of avoiding the ambiguity", what about using one of the most widely used standards (SI)? It's the NPOV way to go. Compvis (talk) 19:30, 14 April 2013 (UTC)
Yes, it is Wikipedia's job to present information in a clear, concise and unambiguous way. Gibibytes are concise and unambiguous but that are not clear since they are not widely understood by the general public. Okay, my analogy is a bit flawed since "gillion" is purely made-up whereas "gibibyte" at least has some backing but backing just is not good enough until the term is adopted by the general public. About using SI to avoid ambiguity, the ambiguity is out there the term "kilobyte" has two meanings (like the word "billion" or worse, "gallon", "ounce", "ton", etc. with more than two), it doesn't matter what MOSNUM says, it's an ambiguous word. JIMp talk·cont 18:13, 18 April 2013 (UTC)
Wikipedia uses many terms that are not in use by the general public, usually when it wants to be precise. Units like avoirdupois pound and long ton are similar to the mebibyte in that they are unambiguous terms that are unfamiliar to the average reader. In its present state, mosnum promotes the long ton (a good thing because it promotes precise language) and deprecates the mebibyte (a bad thing because it encourages ambiguity). I have heard the argument many times that the advice is to use footnotes, but in practice it is extraordinarily difficult to explain by means of footnotes that a word means two different things, and you have to work out which one it is from the context. At the moment, WP addresses this by explaining to the reader how confusing it all is, while doing little or nothing to diminish the confusion. I will make a specific proposal that addresses both the ambiguity of the megabyte and the unfamiliarity of the mebibyte, and could be implemented now if the will were there. Dondervogel 2 (talk) 21:56, 19 April 2013 (UTC)

Is there really a consensus? Perhaps, but if so it has been established recently. Certainly not during the so-called "debates". In my opinion the question is worth asking. Dondervogel 2 (talk) 21:05, 1 April 2013 (UTC)

The IEC binary prefixes were approved in January 1999 and after 14 years virtually nobody uses them. Not every standard is accepted by industry, the IEC binary prefix is a failed standard. The IEEE was an early proponent of the IEC binary prefixes but today their flagship magazine, Spectrum, still uses kilobyte not kibibyte. Here is a quote from an article on spacecraft computers. "In use since 1974, the triply redundant Argon-16 had 2 kilobytes of RAM and 16 kB of ROM and ran at 200 000 operations per second." [1] -- SWTPC6800 (talk) 03:25, 2 April 2013 (UTC)

I think that if factors 1024, 1048576, and so on are assumed and precision is important, then units may not be spelled as “kilo-”, “mega-”, and so on, or abbreviated as k, M, G, T, and so on. But, since “??bi-” spelling (and pronunciation) are disfavoured by industry and IT community, these units should not be spelled so. I propose the following solution:

  • All kibibyte–kilobyte article pairs have to be merged under kilobyte, and information about 210n factors and proposed names should form a section or have an anchor to link through redirects.
  • All such articles should inform the reader that the word “kilobyte” can denote 1024 byte in some contexts, especially outside Wikipedia.
  • The MoS should discourage the use of either “kilobyte” (kB) or “kibibyte” (spelled so) for 1024 bytes, but KiB and KB (uppercase K) should be allowed.

I hope that KiB, MiB, GiB, TiB, and PiB do not conflict with anything. IMHO ugly wordings like “4 [[KiB|KB]] page” and “RAM is measured in MiB” are a better solution than current fear, uncertainty and doubt. Incnis Mrsi (talk) 07:02, 2 April 2013 (UTC)

For some considerable time the IEC prefixes have been the disambiguation mechanism of first choice of those serious about making precise statements about computer memory, whether in science (ca. 150 scientific articles per year use this notation) or industry (e.g., Apple, Ubuntu operatring systems), and these prefixes have the backing of powerful bodies such as ISO and IEEE. Wikipedia can either follow their example or, if there really is a consensus that ambiguity is preferred over unfamiliarity, to continue on its present course. Which is preferred? Dondervogel 2 (talk) 21:24, 2 April 2013 (UTC)
The question has been asked and answered. I leave it to you to find the yottabytes of discussion in the archives. The conclusions were the statements that are in the guideline now. One approach to finding the previous discussion would be to find when the current phrasing of the guideline was introduced using the WikiBlame tool and read the archives of the talk page for the corresponding dates. Jc3s5h (talk) 22:33, 2 April 2013 (UTC)
"asked and answered"? That's true but not in the way you think. The world has quasi-unanimously adopted the International System of Units (SI) which states without any ambiguity that its prefixes are multiples of 10. It never mentionned any exception for the semi-conductor industry. Period. To pretend otherwise is not NPOV. Using the SI prefixes as binary prefixes is an error, and it should be corrected as soon as possible before it's even more costly/dangerous (think Mars Climate Orbiter) or difficult to change. The only reason why such a consensus was reached is because the internet back then was much more US-centric, and as we know, the US is not the strongest defender of the SI. But the world is more and more present, and it DOES use the SI. Use the binary IEC prefixes if you want, but the SI prefixes are definitely NOT binary prefixes. Compvis (talk) 23:56, 13 April 2013 (UTC)
The vast majority of our readers (99.314159%) have never heard of kibibyte or mibibyte. They will never encounter it when purchasing a computer product. Apple does not use these terms to describe the amount of RAM in their computers.[2] How does an unknown unit of measure improve the user's understanding? Standards organizations propose standards, but they are not always successful. The adoption of the IEC binary prefixes started slow then tapered off. It is time to give up the crusade to get Wikipedia to promote this failed standard. (Thunderbird2 you know how the debate ended.) -- SWTPC6800 (talk) 23:00, 2 April 2013 (UTC)
As swtcpc points out, I am familiar with the process that led to the deprecation of the IEC prefixes. I would not describe it as a debate though because that would imply it was a civilised process when it wasn't, and because of the incivility could not possibly have led to consensus, by definition. But like I said, consensus might have been reached since then, and that is what I was inquiring about. Swtcpc is correct to point out my error about Apple - I was aware that they had adopted the definition 1 MB := 1000^2 B so I naively assumed they had dropped the definition 1 MB := 1024^2 B. His or her link proves that to be an incorrect assumption, so clearly Apple is not serious about disambiguation and I withdraw that part of my comment. That still leads Ubuntu (and Gparted) on the one side, and an exponentially increasing number of scientific articles on the other that make this choice, with about 10 articles appearing in 2003, 70 in 2008 and 170 in 2012. I agree with "started slow", but their use is now increasing exponentially and definitely not "tapering off". My question, in a nutshell, still stands: is there now a consensus for preferring an ambiguous (and familiar) unit over an unfamiliar (and unambiguous) one? Dondervogel 2 (talk) 16:50, 4 April 2013 (UTC)
Yes, I believe there is still a consensus for preferring the familiar (though ambiguous) unit over the unfamiliar (though unambiguous) one. Use footnotes in preference to failed neologisms to dispel the ambiguity i.e. write English instead of jargon. JIMp talk·cont 09:23, 7 April 2013 (UTC)
Thank you for providing a clear answer to a clear question. Perhaps more importantly, this is the first civil discussion I can recall having on this page for more than 5 years. As a result, I might even start to edit articles again. Dondervogel 2 (talk) 12:17, 7 April 2013 (UTC)

A technically advanced proposal

It is so sad that my previous proposal was not considered seriously. The last try: let’s wrap (almost) all 210n prefixes into a template which will expand to both styles (megabyte and mebibyte in verbal mode, MB and MiB in abbreviation mode), but make IEC names and abbreviations invisible via CSS. Those users who prefer the precision will redefine classes in their personal styles, for example, making traditional spelling invisible and IEC spelling visible. If in 2021 or so the consensus about these prefixes appeared, then these rules would easily change with two edits: to a template and to MediaWiki:common.css. But no one could able to fix intermixed usage of “units” without a great effort. Incnis Mrsi (talk) 15:38, 7 April 2013 (UTC)

The reason why I have consistently objected to deprecation of IEC prefixes is that these prefixes provide precise information that is lost with the ambiguous MB, GB etc. The problem with IEC, which I have consistently acknowledged, is that MiB, GiB are unfamiliar to many readers, but using MB to mean two different things has always seemed an unsatisfactory alternative. If I understand it correctly, Incnis's proposal would provide a means of retaining the precise information of MiB, GiB without the downside of their unfamiliarity. If it is technically feasible (I cannot judge this) I would support it. Dondervogel 2 (talk) 22:10, 8 April 2013 (UTC)
One problem with Incnis Mrsi's proposal is that this isn't a simple matter of conversion, like showing both centimetres and inches via the {{convert}} template. If you read that a machine has "a 500 GB hard disk and 8 GB of memory", often the first is based on powers of 10, the second on powers of 2. Supposing this is the case, then the "correct" version would be something like "a 500 GB (465.7 GiB) hard disk and 8 GB (8 GiB) of memory". Whether hidden or not, is this what we would actually want? It looks odd to me. Peter coxhead (talk) 11:39, 9 April 2013 (UTC)

IMHO GiB and GB are sufficiently close to each other that no conversion is needed - however, it is appropriate that we know which we are using - it might be appropriate that if an artcile follows the IEC notation, then this be made clear at the first instance of the prefix. For example

"... a 500 GB hard disk and 8 GiB of RAM[n 1]
Notes

  1. ^ This article used the IEC prefix notation for 210×N

Martinvl (talk) 13:33, 9 April 2013 (UTC)

Um, but this is what the MOS says not to do, i.e. not to use GiB as a main unit, and it's unlikely that there will be a consensus to change this guidance. So it's not really relevant to Incnis Mrsi's proposal. The question is whether there is some way of both following the current MOS and yet providing precision. (By the way, there are situations where the two systems are not sufficiently close to each other. I've been caught out by adding up file sizes actually in MiB but said to be in MB and then finding they didn't fit onto a DVD whose size is conventionally measured in MB not MiB. The same issue can arise if you want to partition a hard disk to ensure that one partition has no wasted space. It does matter which units are meant by the ambiguous "MB", etc.) Peter coxhead (talk) 15:03, 9 April 2013 (UTC)
If I understand the proposal above, it would more look like:
"... a 500 GB hard disk and 8 GB of RAM",
but instead of blue, the second GB would be such that it could be automatically shown as GiB by means of a user defined CSS style. Every binary unit would be in a span than can be styled as required. There might even be a popup, showing that it's binary.−Woodstone (talk) 16:55, 9 April 2013 (UTC)
Inline styles are not supported in WP, so the idea is difficult to demonstrate, but here is a color analogy, where green stands for normal text and red for invisible text. The binary unit template would by default show GBGiB, by applying span classes (to be defined) to both parts. The user could reverse the visibility in his user styles, to show GBGiB, making this user experience properly disambiguated units. −Woodstone (talk) 17:17, 9 April 2013 (UTC)

A simple proposal

Mosnum already explains that MB is ambiguous. It could also explain that a simple way to remove this ambiguity is to reserve MB to mean 1000^2 B, with MiB equal to 1024^2 B, and that this is the preferred disambiguation method in scientific literature. It could go on to explain that Joe Bloggs is not familiar with MiB. In order to miminise confusion to JB, it is therefore preferable to replace MiB with a system of footnotes explaining that 1 MB sometimes means 1000^2 B and sometimes 1024^2 B, depending on context. If this advice were implemented it is easy to imagine disambiguation occurring in two phases:

  1. The text "300 GB hard drive and 512 MB RAM" is replaced with "300 GB hard drive and 512 MiB RAM" (simple step; likely to happen quickly)
  2. The text "300 GB hard drive and 512 MiB RAM" is repalced with "300 GB hard drive[1] and 512 MB RAM[2]", where [1] and [2] are footnotes explaining that 1 GB = 1000^3 B and 1 MB = 1024^2 B, respectively

The benefit of this two-step approach is that it removes the huge barrier that at present prevents effective disambiguation of WP articles about computers and computer technology. The presence of step 1 acts as a catalyst to step 2. Dondervogel 2 (talk) 22:15, 19 April 2013 (UTC)

The "double footnote" shouldn't be necessary, since it's only the use of "MB" to mean powers of 2 that is the problem here. What about something like "300 GB hard drive and 512 MB (512 × 220 B) of RAM"? A standard template could then be used to generate the alternative text for uses of kB, MB, GB, etc. to mean the powers of 2. Peter coxhead (talk) 07:51, 20 April 2013 (UTC)
I think confusion is such that one needs to disambiguate GB as well. How about "300 GB (300 × 1000^3 B) hard drive and 512 MB (512 × 1024^3 B) of RAM" or just "300 GB hard drive and 512 MB of RAM? Dondervogel 2 (talk) 20:30, 21 April 2013 (UTC)
or (avoiding link to MiB) "300 GB hard drive and 512 MB of RAM". See changes to Comparison of smartphones. Dondervogel 2 (talk) 15:58, 28 April 2013 (UTC)
As long as any template avoids linking or mentioning the IEC prefixes then it would be OK. Trying to make "32 MB" read like "32 MB (32 MiB)" is just confusing to the average reader and importantly isn't how the real world generally disambiguates this situation. If the real world disambiguates (which it does, just not often) then it usually does so by writing the number of bytes or expressing the number of bytes in power notation. There is already a template that does this, I think User:Headbomb wrote it. Glider87 (talk) 11:01, 1 May 2013 (UTC)
The template is {{BDprefix}} Glider87 (talk) 11:03, 1 May 2013 (UTC)

Please, offer feedback regarding a proposed edit.

Hello, a dialog which started here... 2013_April_21#New_template ...and led to... Template talk:Quantity/sandbox ...seems to be leading to editing "MOS:NUM". Input before doing so would be appreciated.

Are there existing options which already well & directly address the lack of defined measurement instances we were discussing? If not, is there somewhere other than MOS:NUM to consider editing and linking a... {number(s) needed} ...— or similar —template to? General feedback would be appreciated as well. I'm somewhat new to active editing. --Kevjonesin (talk) 17:02, 29 April 2013 (UTC)

Years in titles

A quick question - what should we do for year ranges in titles, eg/ Latvian anti-Nazi resistance movement 1941–1945, or 1939–40 Winter Offensive? A strict reading of WP:YEAR suggests that for four-digit years we should use 19xx-yy rather than 19xx-19yy, but personally this feels unnatural to me, and it's not clear if this guideline is intended to deal with titles. I suspect the answer may also depend whether it's at the start or end of the title.

Third opinions appreciated :-) (Original discussion here) Andrew Gray (talk) 13:09, 6 May 2013 (UTC)

To me, shorter is neater and better for a title. Tony (talk) 13:22, 6 May 2013 (UTC)
I think it's pretty clear that the 1941–45 format is the one specified by the MOS section cited. There are exceptions provided by WP:YEAR, but none appear to apply in the present case. However, please note in main body text or other prose that constructions such as "the war was fought from 1941–45" should generally be avoided in favor of phrasing that uses a preposition instead of the ndash, such as "the war was fought from 1941 to 1945." Dirtlawyer1 (talk) 14:02, 6 May 2013 (UTC)
As long as Y2K isn't a concern, I will continue to be the most ardent supporter of YYYY-YY titles. If anything, the titles should use a style that is shorter than the running text. Marcus Qwertyus (talk) 23:21, 6 May 2013 (UTC)

"Measurements are normally stated in figures, even when the value is a small positive integer"

Does this, by logic, extend to years used as measurement, and thus ages as well? As a matter of style, I know MLA and a few other well-known guides ALWAYS use the numeral when expressing age, e.g. 8-years-old (vs eight-years-old). Rip-Saw (talk) 03:09, 15 May 2013 (UTC)

Sorry, I can’t speak to the intent of the guideline (my own preference is to spell out ages), but your hyphens caught my eye: an eight-year-old child but the child was eight years old. Since you wrote “years“, which is not idiomatic in the former case, I read your example as excerpted from the latter—where hyphens aren’t wanted.—Odysseus1479 (talk) 06:18, 15 May 2013 (UTC)
My bad, 8-year-old and 8 years old. What about 8 hours? 8 cups of flour? Are not ALL measurements to be numerals? Rip-Saw (talk) 18:38, 15 May 2013 (UTC)

WP:ORDINAL

A question was just raised on my talk page re: WP:ORDINAL ("Centuries are given in figures or words using adjectival hyphenation where appropriate: the 5th century BCE; nineteenth-century painting."). Is the compound adjective "a 19th-century [x]" (using "19th" rather than "nineteenth") also hyphenated, the same way we hyphenate the compound adjective "9-millimetre gap" as long as the unit (here, "century") appears as a full word? Thanks for your input. -- Khazar2 (talk) 14:11, 24 May 2013 (UTC)

Khazar, I think the short answer is "yes." Whenever "19th century," or any similar construction, is used as an adjectival phrase, it should be hyphenated, regardless of whether it is written in full as "nineteenth" or abbreviated as "19th." Dirtlawyer1 (talk) 14:28, 24 May 2013 (UTC)
Thanks--that was my take, too. -- Khazar2 (talk) 14:37, 24 May 2013 (UTC)
My take is the same as Dirtlawyer1's. Whenever the ordinal and the century are working together as a compound adjective, it is hyphenated. SchreiberBike talk 20:17, 24 May 2013 (UTC)

What's with the BC and AD versus B.C. and A.D.?

Is that a Wiki invention (or one of those language reformer things where people are trying to drive usage away from the norm)? I almost always see the periods in books and newspapers and the like. Has this been hashed out? (I searched archives but did not find much).TCO (talk) 16:54, 27 May 2013 (UTC)

My impression (I emphasize that it's only an impression) is that it isn't unusual to see BC/AD elsewhere without periods—but in small caps, which we don't use. Cynwolfe (talk) 17:06, 27 May 2013 (UTC)

We have the same issue with BCE/CE vs. B.C.E./C.E. -- Avi (talk) 17:58, 27 May 2013 (UTC)

It's parallel with the acronyms at WP:ACRO which also says "Note that Wikipedia generally avoids using full stops in upper-case acronyms." I suspect it's just a style choice that was made at some point in the past and there hasn't been any reason to change. SchreiberBike talk 18:04, 27 May 2013 (UTC)
Technically those aren’t acronyms, because they‘re spelled out when pronounced—they're in the larger category of initialisms, in turn a subset of abbreviations. Sometimes the first two are differently, e.g. setting only acronyms in small caps: “The EU and NATO have some members in common.”–Odysseus1479 01:48, 28 May 2013 (UTC)
This is an ENGVAR thing; see Acronyms#Orthographic_styling. The use of full stops looks incredibly old-fashioned to me, as someone used to writing British English. Maybe it doesn't to those used to American English? It would be possible to allow the style to follow the ENGVAR of the article, I guess, but at the expense of further increasing the variability of styles in the English Wikipedia. Peter coxhead (talk) 21:46, 27 May 2013 (UTC)

A question in MOS - WP:TIMEZONE

(Cross-posted from Village pump)

MOS states that: When writing a date, first consider where the event happened and use the time zone there.

However, in some cases, a historical event took place where the time zone in that particular location is different than what is today. That is, the time zone has changed since the event took place. MOS did not make note of this.

Example, 1920 Haiyuan earthquake stated that it hit at local time 20:06:53 (GMT 12:06:53), of which it is expressed modern China time zone, which is GMT +8. However, during Republic of China, China was divided into five time zones. The epicenter is at Haiyuan County, Ningxia Province which at that time is in Kansu-Szechuan Time Zone, which is in GMT +7.

Corresponding article in Chinese Wikipedia noted this fact and recorded in 19:06:53 (GMT+7).

Opinion on this? SYSS Mouse (talk) 04:13, 13 May 2013 (UTC)

GMT is an absolute clock. Clearly, the conversion should only be done with the local and temporal offset valid for the event. −Woodstone (talk) 08:18, 13 May 2013 (UTC)
Care to explain the second part? SYSS Mouse (talk) 15:16, 14 May 2013 (UTC)
Since time-zones are a matter of convention, where the clock-time of an event is given it should reflect the conventions then in effect—otherwise it’s useless (except maybe to a modern resident who wants to mark the ‘exact anniversary’). Assuming what you say about the time-zones prevailing in 1920 is true, ISTM that the Chinese WP article is correct. In such cases it’s probably best either to give the UTC or to indicate the local offset, as they have done. Would the guideline be clearer if it said “… consider where and when the event happened …“?—Odysseus1479 (talk) 06:41, 15 May 2013 (UTC)
Use the local time of the event. It almost never matters what time it was elsewhere. If you are relating it to events that happened elsewhere, show the equivalent time in UTC in parens, calculated from the offset known to be in effect at the time. The fact that the difference between the two is different than it may be currently, due to summer time or legal change of offset, is simply the nature of time zones – any expectation on the part of the reader that the difference should remain constant is wrong, and can be corrected by their reading of the relevant linked time-zone articles. If, for some reason, the article keeps getting edited to incorrectly "fix" the times, explain it in an HTML comment in the text and/or the talk page. —[AlanM1(talk)]— 01:04, 1 June 2013 (UTC)
Please see Talk:1920 Haiyuan earthquake § Time. I believe you changed the wrong value. —[AlanM1(talk)]— 01:27, 1 June 2013 (UTC)
It might also be worth considering adding a footnote mentioning that the stated time is based on a different time zone than the one now in effect in that place, rather than simply hiding it in wikicode or on a talk page, so that the reader may take note of this when marking the anniversary of the occasion, for example. —sroc (talk) 16:58, 10 June 2013 (UTC)

What's with WP:DATERET?

Hi, I've had a bot telling me 21:48, 28 May 2013‎ AnomieBOT (talk | contribs)‎ m . . (1,429 bytes) (+14)‎ . . (Dating maintenance tags: {Use mdy dates} (undo) now I'm informed of WP:DATERET saying "don't listen to AnomieBOT". What gives? In ictu oculi (talk) 21:39, 29 May 2013 (UTC)

Have you read Wikipedia:Simple diff and link guide? If you do, you might be able to restate your question in a way we could respond to. Jc3s5h (talk) 23:43, 29 May 2013 (UTC)
Jc3s5h, Sorry, lack of caffeine and connectivity problems. I was confused having never seen it before. What I (mis-)saw was template {Use mdy dates} being dated by a Anomiebot, not the bot telling subsequent editors to correct to dmy format. This is new to me, hadn't seen WP:DATERET before obviously. Question resolved/answered In ictu oculi (talk) 03:49, 30 May 2013 (UTC)

WP:SEASON

I was under the impression that "in the summer 2012" was incorrect and that it had to be "in summer 2012". Now that I've read the guideline more closely, I'm not sure it's clear whether "the" is prohibited, required, or optional. Does anyone have an opinion on the correct interpretation? Regardless of how you interpret it as it's written now, what should the guideline be on this issue?--Bbb23 (talk) 15:28, 7 June 2013 (UTC)

I think the guideline is all about whether "summer 2012" is more or less appropriate than "January 2012" (or whatever month the event being described occurred). The guideline is not addressing whether the season may be preceded by "the". As for what the guidance should be, I think both usages are correct so it isn't necessary to mention "the" in the guideline. Jc3s5h (talk) 21:22, 7 June 2013 (UTC)
No, “in the summer 2012” is unidiomatic, but “in the summer of 2012” is fine. The version without an article reads like a headline or abbreviated point-form, but it might be okay in some contexts.—Odysseus1479 00:15, 8 June 2013 (UTC)
Based on its current wording, "summer of 2012" is wrong; look at the examples.--Bbb23 (talk) 00:20, 8 June 2013 (UTC)
What is the context here? References to seasons are generally discouraged, particularly in reference to times of a given year, unless there is a particular "seasonal" context.

As the seasons are reversed in the northern and southern hemispheres—and areas near the equator tend to have just wet and dry seasons—neutral wording (in early 1990, in the second quarter of 2003, around September) is usually preferable to a "seasonal" reference (summer 1918, spring 1995). Even when the season reference is unambiguous (for instance when a particular location is clearly involved) a date or month may be preferable to a season name, unless there is a logical connection (the autumn harvest). Season names are preferable, however, when they refer to a phase of the natural yearly cycle (migration to higher latitudes typically starts in mid-spring).

It seems like a rare instance where it would be appropriate to refer to a season of a particular year, but I suppose if an article happened to be about a seasonal occurrence in a specific hemisphere in a specified year, a reference such as the crops grew in Oregon in the spring of 2012 would be appropriate phrasing. —sroc (talk) 02:31, 8 June 2013 (UTC)
I wish we could have fewer rules about this stuff. Let the writers write. Every time you prescribe some rule about stuff like this, you annoy some non-trivial number of editors, and there's cost to that. I don't know about seasons, but I know if I write "In April of 1941", which is one of the ways that people actually talk and write and is perfectly grammatical and IMO sufficiently formal, someone will change this to "In April 1941", which is annoying. It's pointless to annoy editors to no benefit. We don't have rules that say you can't write "In 1941, he declared that..." but must write "In 1941, he said that..." and so on, so why rules on months and seasons. Some people like to write rules. They shouldn't necessarily be indulged. Herostratus (talk) 04:58, 8 June 2013 (UTC)
The rule about seasons is sensible. Saying something happened in spring of 1949 is vague, as it could refer to the northern spring (Sep–Nov) or southern spring (Mar–Jun), which depends on context; it makes sense to avoid this by using more precise phrasing such as in October 1949. I do also believe that in October 1949 is better than in October of 1949, although I probably wouldn't go out of my way to change it. I'm not sure why you find such edits "annoying". Remember, no one owns the articles and anyone editing them is probably acting in good faith. —sroc (talk) 19:16, 8 June 2013 (UTC)
By the way, we do have guidelines about the synonyms of "say"; see Wikipedia:Words to watch#Synonyms for said. Peter coxhead (talk) 00:19, 9 June 2013 (UTC)
It annoys me a little bit if I write in an article "In April of 1941..." and someone comes along and changes it to "In April 1941..." because that is not an improvement and certainly doesn't make it any clearer, it's just roiling the text to no benefit. Usually I just let it lie, because whatever. But if I change it back (which is my right per WP:BRD) on the grounds of "It was just as good before", and then someone tells me there's a rule about that so I can like it or lump it, it's considerably annoying. You want to minimize the number of times you are saying to editors "You cannot do X, period, per our rules, and if you don't like it you can go edit some other encyclopedia" (which is the subtext of any enforceable rule). If "X" is "insert your own opinions" or "insert unsourced material" or "call other editors assholes" and so forth, then it's worth it. If "X" is petifoggery such as "write 'April of 1941' instead of 'April 1941'" then it's not worth it. Herostratus (talk) 20:10, 9 June 2013 (UTC)
This is why the Manual of Style is loathed, ridiculed and/or ignored. An individual writer of good English, in any of its many regional variants, will regularly use more than one form for phrases like this. There are many things for which a Manual is needed: for example, editors aren't always aware that "summer", "winter", "autumn" (or "fall") and "spring" can mean quite different things in different hemispheres, different latitudes or different climates. But as Herostratus says, the fewer and more pertinent the rules, the more likely they are to be consulted and followed. ¶ In the case of this "rule", I think some proto-editor's teacher corrected "April of '41" to "April 1941" in a seventh-grade essay because it was better usage in that particular sentence, but was either too lazy or too ignorant to explain why, and instead declaimed some dumb and easy-to-remember rule like "Never put ‘of’ between a month and year." No reason to impose that on all English-language Wikipedia editors all the time. —— Shakescene (talk) 21:30, 9 June 2013 (UTC)
(edit conflict) Everyone has strayed from the original topic, but such is life. First and foremost, I don't see why you care. Second, you don't get to change it back per WP:BRD. The other editor's "bold change" puts the burden on you to justify the original text. Of course, you don't like rules, so I don't know why you care much about BRD. :-) Finally, I think you're exaggerating about the subtext. I know editors get all worked up here over the most amazing things, but we're talking about a style guideline, not about vandalism, edit warring or a BLP violation. Wikipedia has style guidelines for consistency within and across articles. They aren't necessarily the same styles as are found off-wiki. Why don't you just follow the guideline to begin with and save yourself a lot of grief over very little? Back to you. :-) --Bbb23 (talk) 21:35, 9 June 2013 (UTC)
I see what you mean, Herostratus and User:Shakescene: some rules seem less important than others. For the record, I think in April of 1941 is more poetic in nature which is probably why in April 1941 is preferred. As Bbb23 said, no need to get worked up about it. If someone else thinks that they're improving an article by following the style guide, and you don't think it matters, the easiest thing to do is let them have their way and not take it as a personal slight against you. —sroc (talk) 03:51, 10 June 2013 (UTC)
Just a reminder: It might be late spring or early summer in the Northern Hemisphere at this moment, but in Australia, New Zealand, South Africa, Chile and Argentina it's the beginning of winter. Therefore, references to a season can be problematic. Michael Glass (talk) 12:49, 10 June 2013 (UTC)
Michael Glass, that's a good point which should be pointed out, perhaps here in the MOS. Trying to avoid season names is good point and might be a good guideline (but not a strict rule) because it has a reason, to avoid confusion. Actually, it's kind of a complicated point. Assuming a typical northern-hemisphere person, if I write "Australian farmers revolted in the spring of 1941", they'll think "Oh, it happened around April or May of 1941"; on the other hand, if I write "Australian farmers revolted in December of 1941" they'll think "Oh, it happened when it was cold and snowy". So hmmmm. Don't know which misconception is worse.
Re WP:BRD, the editor has it wrong. The sequence is 1) person make a bold revision, 2) anybody can revert and say "Reverted, make your case and prove your point on the talk page" (or even better, for politeness, "Reverted, I've opened a thread on the talk page, let's see if there's consensus for this"). The burden is those editors pumping for the change, not those editors pumping for the status quo. If this wasn't true, things'd be very different around here, if you think about it.
@sroc, of course it's best to just let it lie, it's just that it's (slightly) annoying to have to let it lie if I'm not in the mood. Herostratus (talk) 14:08, 10 June 2013 (UTC)

Um, "that's a good point which should be pointed out, perhaps here in the MOS"? It already is in this specific section, as quoted above: "As the seasons are reversed in the northern and southern hemispheres…"

It should be noted that the MOS is itself a guideline, not a rule. That said, the MOS reflects a consensus, so if you want to disregard it in a particular case, you should be prepared to justify it. —sroc (talk) 16:25, 10 June 2013 (UTC)

Right, sorry I missed that. Everything you say is correct. Herostratus (talk) 16:30, 10 June 2013 (UTC)
By the way, in relation to your examples the "misconceptions" are purely due to ignorance of the reader, for which Wikipedia is not responsible. We are responsible for ensuring accuracy and avoiding ambiguity. The first example (Australian farmers revolted in the spring of 1941) implies that it happened in the southern spring (Sep–Nov), but this assumes the writer took this context into account and a skeptical reader might double-check the source to confirm this; the second example (Australian farmers revolted in December of 1941) is unambiguous that it happened in December, which the reader ought to be able to discern is in the Australian summer. Specifying the month provides clarity and avoids doubt. —sroc (talk) 16:43, 10 June 2013 (UTC)
I suppose for absolute clarity (and the benefit of ignorant readers from the northern hemisphere), you could say Australian farmers revolted in December 1941, at the start of the southern summer. —sroc (talk) 16:47, 10 June 2013 (UTC)
Thanks for calling this herring red. Most people learn the simple concept of inverted seasons in the hemispheres when they're around 10 years old and there's almost always geographical context for such a statement. In some subjects (like agriculture), the season is a more natural concept, and may be necessarily vague to accurately reflect the source (even if one might be able to synthesize a more precise date). —[AlanM1(talk)]— 17:06, 10 June 2013 (UTC)

Dionysian Era

I suggest replacing the term Dionysian era used in the discussion of Era style with the more commonly used Christian era. The section opens with this passage: "By default, years are numbered according to the Western Dionysian era (also referred to as the Common Era)."

While the term Dionysian era is theoretically appropriate, it seemed decidedly unfamiliar. I checked the Google Books NGram Viewer and found that the alternative Christian era has consistently been used more than 250 times as often as either Dionysian era, Julian era, or Common era.

Frequency of use of the terms Julian Era, Dionysian Era, Common Era, and Christian Era. Note that the Julian, Dionysian, and Common Era frequencies are multiplied by 250 in order to be visible on this graph.

Given these statistics, I suggest replacing the two appearances of the term "Dionysian era" with "Christian era".--SteveMcCluskey (talk) 16:05, 6 June 2013 (UTC)

You're probably right, and the Ngram is convincing. Certainly the term "Dionysian era" should not be used in articles, at least without explanation (except maybe articles concerned with the technical nomenclature of dating). This page is an internal guide for editors, though, so it doesn't really matter, as long as the meaning is clear. I would just add "Christian era" everywhere that "Dionysian era" is used, simply for clarity. About nobody has heard of the term "Dionysian era" and has to either puzzle it out or look it up. How is that helpful in a guide page? If there are no objections to this let's do it. (If there are objections, I hope they take the form "This would be confusing to editors seeking guidance here, because _______" rather than getting into Western imperialism and so on, which may be appropriate for articles but less so here.) Herostratus (talk) 17:02, 7 June 2013 (UTC)
I don't think those statistics are meaningful. A simple search for "Christian era" in Google books, upon which the Ngram data is based, returns a predominance of results for many different meanings of "Christian era", where the term refers to things other than calendar dating. For example using the term in a general context similar to "jazz era" or "enlightened era". In just a casual examination of the first page of results, I'm not sure that any of them are using it in a context synonymous with Dionysian era... Mojoworker (talk) 21:41, 7 June 2013 (UTC)
Yeah, but I'd hazard that very few people know what "Dionysian era" means. I suppose (not sure) that more know "Common Era", which is a coming term, and I'd guess that more know "Christian era" than either -- maybe a lot more. In a article, we want to be clear, but we also want to be correct, which means NPOV, and it's possibly arguable that "Christian era" is not NPOV, I suppose. But this is a guidance page. Clarity trumps everything here. Herostratus (talk) 04:39, 8 June 2013 (UTC)
Above all, let us not be stuffy. You could use both terms, one after the other, i.e.: "Dionysian era, or Christian era," or "Christian era, or Dionysian era," setting the second phrase off with commas to indicate it is an explanation. GeorgeLouis (talk) 05:03, 8 June 2013 (UTC)

I've reverted the change - I don't think four days (and four editors) is really optimal enough to establish a new consensus. I don't have an objection to a change, but please leave discussion open a bit longer. If no one else weighs in after another week or so, then we can go ahead. We may want to discuss the wording (and Wikilinking) a bit as well. Mojoworker (talk) 17:22, 11 June 2013 (UTC)

I agree that "Dionysian era" is unnecessarily obscure for the uninitiated, and "Christian era" will imply (again to those not immersed in the argument) that BC/AD is preferred over BCE/CE. I'd rather see a simpler initial directive that integrates the question of BC/AD and BCE/CE, something like By default, years are numbered according to the Western Dionysian era system, a division of time also known as the Common Era, represented by either BC and AD or BCE and CE. People are more familiar with the convention of marking a year as BC/AD or BCE/CE (and with the concept of the time division these both represent) than they are with the names for the system. The "Do not change" provision that follows seems a better place for any further explanation. Cynwolfe (talk) 18:39, 11 June 2013 (UTC)
I've never heard of "Dionysian era", certainly never seen or heard it being used. What is the point of even mentioning such an obscure term? --Mirokado (talk) 19:40, 11 June 2013 (UTC)
I've never encountered "Dionysian era" outside of Wikipedia, as best I can recall. I've heard of Dionysius Exiguus so was able to figure it out, but I think it's just to obscure to use the term at all. Jc3s5h (talk) 20:02, 11 June 2013 (UTC)
I'm not sure it matters whether it's a familiar term or not – editors consulting the MOS for guidance would certainly have no problem following the Wikilink to any term that's unfamiliar. I'm more concerned about the ambiguity of "Christian era". See the following from Calendar era (which likely should also be linked from the MOS): "For example, the Gregorian calendar numbers its years in the Western Christian era (the Coptic and Ethiopic churches have their own Christian eras...". Calendar era#Christian era also mentions several other Christian eras. Perhaps it could be worded something like: The default calendar era is the Western Dionysian era system, a year numbering system also known as the Western Christian era (represented by BC and AD), or the Common Era (represented by BCE and CE). Mojoworker (talk) 06:14, 12 June 2013 (UTC)
Thanks for pointing out the various Eastern Christian eras. Your proposed opening line seems to cover the main issues. SteveMcCluskey (talk) 22:11, 12 June 2013 (UTC)
Just a note about consulting MOS: it's my impression that new or inexperienced editors who are unfamiliar with MOS are well-represented among those who change the era style on the basis of personal preference. When I revert, I link WP:ERA in the edit summary in the hope of warding off unnecessary conflict. So I agree with the goal of making the first thing they see readily comprehensible. I'm fine with Mojoworker's clarification of the wording, but if it were not long-established consensus, I'd prefer moving the explanation to the Dionysian-Christian labels a bit deeper into the guideline. I just don't see immediately how to do that. Cynwolfe (talk) 18:02, 14 June 2013 (UTC)

Day range within a month

At WP:DATESNO, bullet 2, it says that "January 5–7, 1979" uses an un-spaced endash and that "June 3, 1888 – August 18, 1940" uses a spaced endash. What about just "January 5–7"? I expect it is an un-spaced endash, and would like to add that example as well. —[AlanM1(talk)]— 07:47, 12 June 2013 (UTC)

Per MOS:ENDASH:

The en dash in a range is always unspaced, except when both endpoints of the range already include at least one space.

So, yes, January 5–7 uses an unspaced en dash because neither element in the range "5–7" contains a space, compared with January 5 – February 7 which requires a spaced en dash because the elements "January 5" and "February 7" contain spaces. That link provides further examples, including date ranges. —sroc (talk) 14:45, 12 June 2013 (UTC)
I've just added a link from WP:DATESNO to MOS:ENDASH to provide further clarification, which I think is better than adding yet another example to an already long list. —sroc (talk) 14:48, 12 June 2013 (UTC)

Delimiting four-digit numbers

At "Delimiting (grouping of digits)":

Numbers with four digits to the left of the decimal point may or may not be delimited (e.g. 1250 or 1,250).

At the risk of WP:OR, my understanding is that numbers with more than three digits should always be delimited when part of a list where at least one of the numbers is delimited, e.g.:

  • 12 in January; 123 in February; 456 in March; 7,890 in April
  • 12 in January; 123 in February; 456 in March; 7890 in April
(the comma in the last number is optional)
  • 12 in January; 123 in February; 45,670 in March; 7,890 in April
  • 12 in January; 123 in February; 45,670 in March; 7890 in April
(the comma in the last number is not optional because a comma is used in one of the other numbers)

This is necessary to ensure consistency between whether or not numbers are delimited in the entire list. Note that this would not apply to years.

  • 12 in 2010; 123 in 2011; 45,670 in 2012; 7,890 in 2013
  • 12 in 2,010; 123 in 2,011; 45,670 in 2,012; 7,890 in 2,013

If there is consensus, I propose to amend the above as follows:

Numbers with four digits to the left of the decimal point may or may not be delimited (e.g. 1250 or 1,250). However, numbers with four digits should always be delimited when used with other numbers that are delimited (e.g. Adam spent $1,234 and Brenda spent $56,789).

—sroc (talk) 11:04, 13 June 2013 (UTC)

Oppose: According to this document from NIST, (pages 42-3), separating the first digit of a four digit number is a matter of choice. NIST are echoing the view of the BIPM in the SI handbook (page 133). User:sroc's proposal is more prescriptive that the NIST/BIPM document - I am always hesitant to be more prescriptive than an official document so I am inclined to leave MOSNUM as it is. Martinvl (talk) 12:33, 13 June 2013 (UTC)

Although this is a matter of choice, I have read style guides that indicate that a delimiter is required if other numbers in the list have them. Indeed, as both the NIST and BIPM documents state:

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

For numbers in a table, the format used should not vary within one column.

In other words:
I would think the same rule would apply to lists written in prose. —sroc (talk) 15:30, 13 June 2013 (UTC)
Note, too, that MOS already departs from the NIST/BIPM documents: firstly, MOS prescribes delimiters for numbers with five or more digits, whereas NIST/BIPM provide that the delimiters are optional for numbers of any size; secondly, MOS specifies that the delimiter is generally a comma, whereas NIST/BIPM forbid the use of commas as delimiters in favour of thin spaces. —sroc (talk) 15:49, 13 June 2013 (UTC)
Any further comments, Martinvl or anyone else? —sroc (talk) 08:58, 22 June 2013 (UTC)

Agree consistency is the order of the day and we should make the change so that we are consistent in what we present to readers. Keith D (talk) 11:43, 22 June 2013 (UTC)

Year ranges

Background: I came here after seeing this edit to a disambiguation page that changed the death year for some of the entries from a four-digit year to a two-digit year referring to MOS:YEAR. From what I've seen year ranges for birth and death almost always use full years, and yet there is the guidance here that a closing CE or AD year is normally written with two digits. The section on dates of birth and death does say When only the years are known: "Socrates (470–399 BC) was..." The year of death is given in full: "Petrarch (1304–1374) was ...", not "... (1304–74) was ...". I would assume that since the disambiguation page is using only the years for the birth and death, the latter guidance would apply, but I could see how this might be confusing. Am I correct that the full year should be used for birth and death despite the normally written with two digits guidance for year ranges? older ≠ wiser 10:40, 15 June 2013 (UTC)

In my view, the disambiguation page should adhere to the MOSNUM guidance. There seems not reason to exempt a closing year from the general rule just because someone died that year. Tony (talk) 10:43, 15 June 2013 (UTC)
So why does the exception exist when only years are known? Also, it introduces apparent inconsistencies as well. It looks a bit odd in a list of persons with birth and death years to have some given with two digits and some with four. And this would affect a huge number of disambiguation pages as well as many pages with lists of people with a surname or given name. older ≠ wiser 10:57, 15 June 2013 (UTC)
I made the edit in question, based on my understanding of MOS:YEAR; I wasn't aware of the conflicting advice at MOS:DOB. I have no personal preference; I can see that it looks inconsistent to have "1830–99" next to "1830–1900", but on the other hand, consistency with MOSNUM, and conciseness, favour two digits. I await the outcome of this discussion with interest (and in the meantime will refrain from similar edits elsewhere). Dave.Dunford (talk) 13:36, 15 June 2013 (UTC)
I too have seen 4-digit years for both birth and death in the vast majority of articles, and this is also what I would prefer personally: Abbreviated forms have historically caused a lot of confusion, therefore I try not to depend on redundancy to decipher a date and always give the full form. Also, something like "1935-05" is ambiguous, since it could read as birth year 1935 and death year 2005 just as well as birth date 1935-05 in the international date format. Independent of the date format used, this cannot happen, when both dates are given in full. --Matthiaspaul (talk) 13:09, 16 June 2013 (UTC)
I'm glad you brought this up, the inconsistency has been bothering me for some time. For years of birth and death, especially in disambiguation pages, I see full years almost exclusively, but MOS:YEAR is clear that if the second date is in the same century, just the last two years should be used. Because space is not a factor as in a paper encyclopedia, because consistency looks better in lists, and because increased clarity trumps conciseness, I'd favor a change to the language of the MoS that full years may be used, and in disambiguation pages, full years should be used. SchreiberBike talk 22:00, 16 June 2013 (UTC)
I SUPPORT SchreiberBike. It avoids ambiguity and makes the information totally clear to our readers. That is what it's all about, isn't it? Our readers. Truthanado (talk) 03:05, 18 June 2013 (UTC)
Support. As indicated, I support a change in the MOS to propose non-abbreviated years (that is, up to 4 digits instead of 2 digits, but without leading zeros) in year ranges as well. At the same time, it should deprecate the abbreviated form. --Matthiaspaul (talk) 07:31, 18 June 2013 (UTC)
Strong oppose. Tony (talk) 08:03, 18 June 2013 (UTC)
Can you, perhaps, provide a reason, why, in your opinion, 4-digit years should be allowed to be truncated to two digits in some cases despite the fact that it creates inconsistency in the way years are written within an article and that it can create ambiguity, and that it therefore makes an article more difficult to read and understand? Thanks. --Matthiaspaul (talk) 08:37, 18 June 2013 (UTC)
Support use of four-digit years, at least on dab pages (which are all I'm really concerned with). Theoldsparkle (talk) 12:49, 18 June 2013 (UTC)
  • Support use of four-digit years on DABs, per User:Bkonrad, being explicit:
    • DABs / WP:MOSDAB should adhere to MOSNUM
    • Only years are used in DABs, so
      • Known days/months are never included in DABs -> there should be no difference when they are known or unknown
    • In favour of full year ranges:
      • I agree with sentiment that abbreviated forms can be ambiguous, for example increasing life expectancy gives us more centenarian articles
      • All the DABs I've seen use full year ranges
      • WP:MOSDAB example uses full year ranges (just below MOS:DABOTHERLANG)
      • This is the same as when only the years are known in MOS:YEAR "Petrarch (1304–1374) was ...", not "... (1304–74) was ...")
      • I consider full years aids comparison in DABs (abbreviated hinder) - the only purpose of a DAB being to select based on comparison
    • This is easy, by just tweaking MOS:DOB "When only the years are known, or shown (for example on disambiguation pages): "Socrates (470–399 BC) was..." The year of death is given in full: "Petrarch (1304–1374) was ...", not "... (1304–74) was ..."" Widefox; talk 21:58, 18 June 2013 (UTC)
  • Support the use of full years rather than abbreviated years in all cases, per the above reasons, and therefore amending MOS:YEAR in line with MOS:DOB. That is:
  • Year ranges, like all ranges, are normally separated by an en dash, not a hyphen or slash: 2005–2006 setting out the years in full. However, other formats such as 2005/06 may be used to signify a period of 12 or fewer months, such as a corporate or governmental fiscal year, if that is the convention used in reliable sources. Sports seasons spanning two calendar years should be uniformly written as 2005–06 season.
  • Year ranges are normally written (1881–1886). The closing year should not be written with two digits (1881–86) even when both years are in the same century.
  • Dates are separated by an unspaced en dash (12–5 BC); except that a spaced en dash is required when both years require era signifiers (5 BC – AD 29).
  • Year ranges expressed using prepositions (from 1881 to 1886 or between 1881 and 1886) should not use en dashes (not from 1881–1886 or between 1881–1886).
I'm not really sure why there are the exceptions in the first bullet point for other formats (i.e., 2005/06 and 2005–06 season) and whether there is good reason for these exceptions to remain. I assume this would affect the titles of many articles (e.g., about sports seasons that span multiple calendar years) which could be contentious. —sroc (talk) 10:33, 19 June 2013 (UTC)
  • Why exactly is 1986–89 ambiguous? Tony (talk) 11:50, 19 June 2013 (UTC)
Not all examples are ambiguous, but some are. Let's choose 1802–12. Does it mean 1802-12 (December 1802), 1802–1812 (someone died at the age of 10), 1802–1912 (someone became 110 before he died), 1802–2012 (a 210 year period, perhaps the lifespan of a building, an organization, ...)? --Matthiaspaul (talk) 14:17, 19 June 2013 (UTC)
There are several reasons for preferring the use of full years.
  • In some cases, it avoids (potential) ambiguity as to the end date (as shown in the above examples), although in the case of birth–death ranges the correct range can usually be inferred (not necessarily accurately);
  • It avoids ambiguity with the ISO format for year–month representations;
  • It is seen as promoting consistency with other cases where the full year is required (e.g., where the dates are in different centuries, where the years have other than four digits, where the dates are BC);
  • It is more easily parsed and understood as being a year range (which may or may not be evident from the context).
Conversely, there are not really any compelling reasons (that I've seen) for preferring the use of double-digit years. As noted above, Wikipedia is not constrained to keep text to a minimum (cf. printed publications). The majority here seems to be in favour of full years in date ranges. —sroc (talk) 14:46, 19 June 2013 (UTC)
Certain ranges aren't very, and I'm sure they may have their uses in articles. The context is DAB pages, with the burden of argument on those that propose changing up to hundreds of thousands of DAB pages. What's the benefit to the reader of losing the century info when comparing random death dates presented in a vertical list? I've not seen a compelling reason for change, so I propose we accommodate full ranges for DABs in MOS:DOB. Widefox; talk 15:05, 19 June 2013 (UTC)
Real ambiguity is rare, but two digit years require interpretation on the part of the reader. If we can eliminate that, we make the reader's job easier. If we were saving ink or paper in a printed encyclopedia, it might be worth the small inconvenience, but why do it here? SchreiberBike talk 14:52, 19 June 2013 (UTC)

So far, it looks like Tony is the only one objecting to the use of four-digit years in birth and death ranges. Is there a specific change to the guidance we can propose that might help to clarify?

I would also like to say that I also think putting four digits for this matter is best in making sure we be as specific as possible. Also saying something like "1943-04" is a very informal way of giving information and so it would be better to say "1943-2004". Rainbow Shifter (talk) 15:31, 20 June 2013 (UTC)

Support use of full four digits for birth and death date ranges, particularly in dab pages. Two-and-a-half separate arguments:

  1. In some contexts, "1903-09" might be September 1903, or a 6-year range. 1903-1909 is unambiguous.
  2. I think most people would agree that we'd use 1943-2004 rather than 1943-04, but that then looks messy if it's in a group of entries where other dates are 1943-99 etc. So using 4 digits all round is better.
  3. From a purely editing point of view, I wouldn't like there to be a different standard for dab pages and for lead sentences: I often copy the date range from the lead into a dab page I'm creating or modifying (dropping days and months where present) rather than copy-typing. PamD 16:08, 20 June 2013 (UTC)

You'll need a formal RFC to change it, I think. To start with, what exactly is the text you propose changing, and how? There are probably millions of instances of double-digit closing ranges on WP. And Pam, would you mind using the correct dash for your ranges? Then there's no ambiguity with ISO-type numbers. Tony (talk) 08:23, 21 June 2013 (UTC)

I disagree with Tony's reasoning about the correct dash preventing ambiguity with ISO 8601 expressions for year and month. First, few readers will be aware of the requirement in this guideline that the only expression allowed for a single all-numeric date (as opposed to a year range) is YYYY-MM-DD. If anyone out there is in the habit of writing 2003-06 to mean June 2003, that person will be confused by year ranges where the ending year is expressed with 2 digits. Second, because of the wide variety of fonts we encounter within Wikipedia, and on our computer screens in general, it is difficult to tell if we are reading a hyphen or an n dash. Third, if someone uses a dash in a YYYY-MM expression, in contravention of this guideline, some bot will probably come along and change it to YYYY–MM, changing into an expression that is stylistically allowable but semantically wrong. Thus the reader who understands bot activity on Wikipedia will realize the hypen/n dash distinction is semantically useless on Wikipedia. [Modified example.] Jc3s5h (talk) 10:49, 21 June 2013 (UTC)
Jc: What would "2013-06" mean, if it were years? I have no idea. Do you mean "2013–16"? Tony (talk) 10:36, 21 June 2013 (UTC)
I should have picked a day and month that would be easier to misinterpret as a year range, such as June 2003. Jc3s5h (talk) 10:46, 21 June 2013 (UTC)
"would you mind using the correct dash for your ranges?" Well, no (or perhaps "yes"). I use what's on my keyboard. I suspect that only a tiny proportion of our readers are aware of any distinction between hyphens and n-dashes, and I'm not going to interrupt my typing to go picking out special characters from dropdown menus. PamD 18:52, 21 June 2013 (UTC)
If you're not going to follow basic rules of typography in English, insisted on by the major authorities, including Chicago Manual of Style, the Oxford New Hart's Rules, and en.WP's style guides, are you equipped to contribute to this debate? I've pointed out that your usage makes year ranges of any type look like phone numbers. Please don't then use that to twist the issue. Tony (talk) 14:34, 22 June 2013 (UTC)
There should not be any phone numbers in WP, so that's not leading to confusion.−Woodstone (talk) 15:51, 22 June 2013 (UTC)
There’s a saying, “It’s a poor workman who blames his tools,” but AIUI nobody is demanding that writers submit only perfectly styled text—just that they accept that if they don’t, some WikiGnome or copy-editor will come along and polish it up. (That said, I don’t think there’s any good reason Talk-page postings should be expected to conform with the MoS; here editors are speaking in their own voices, not WP’s.)—Odysseus1479 00:47, 23 June 2013 (UTC)

WP:CURRENCY

We've had disputes on the PlayStation 4 article over the removal of Australian prices, citing MOS:CURRENCY because it says to "use US dollars, euros, or pounds sterling" in non-country specific articles. In my opinion, as a guideline, that line is written in a way that makes it too strict, since it seems to suggest that we are only allowed to mention those, leading to a regional bias towards Europe and the United States (even where it may be relevant as a major market). The line in question should be changed. ViperSnake151  Talk  00:36, 24 June 2013 (UTC)

The guidance at MOS:CURRENCY seems sound to me. US$, UK£ and € are all world-leading currencies and should be preferred over others unless relevant in a specific context. In the specific case of the PlayStation 4, you will need to justify why the A$ is notable for being singled out (see Talk:PlayStation 4#Which Price is Right.3F). If you are lobbying for change in MOS:CURRENCY overall, you will have a bigger task in proposing a change and justify why it is necessary in order to form consensus — which would have broader implications that could spark much more fervent debate than the specific article. —sroc (talk) 05:51, 24 June 2013 (UTC)

Dates of Birth

One of the examples given in MOS:DOB is "Serena Williams (born September 26, 1981) ..." yet in WP:DATEFORMAT above, it seems the stipulation is that a comma must never be used. Does MOS:DOB override the earlier rule, or is the example in error. Alexbrn talk|contribs|COI 17:11, 24 June 2013 (UTC)

Exact birth and death dates in the lede

Exact birth and death dates in the lede interrupt the flow of the sentence. They are intrusive and repetitive. Why are they required? A year range should be sufficient, as in most encyclopedias I've seen. Please comment below, giving the reason why they are required. Thank you. GeorgeLouis (talk) 13:27, 30 May 2013 (UTC)

You're right. Yet how would you go about enforcing this long standing practice?JOJ Hutton 17:36, 31 May 2013 (UTC)

Gentlemen, I for one disagree that the exact birth and death dates should be replaced by only the years of birth and death. These two data points are among the most basic biographical information that readers are seeking, and I don't see the inch to inch and a half of text that the parenthetical requires as disrupting the flow of the first sentence. if you want to address a very real problem that actually does disrupt the first sentence of biographical leads, find a way to address the proliferation of redundant phonetic pronunciations, transliterations and translations of names that have been inserted into many bios, and now occupy a complete line or more of text in the first sentence of the lead. Now, that's disruptive, with very little benefit to the overwhelming majority of out readers. Dirtlawyer1 (talk) 19:03, 31 May 2013 (UTC)

Agree they are disruptive. I would not write the first sentence of a report in "the real world" like that.TCO (talk) 20:07, 31 May 2013 (UTC)

Well, I made my bold change in the MOS, stating "The exact dates (month and day) of births and deaths are not required in the lead sentence. Only the years are required, if you have them, as Jane Blow (1932-1982). The full dates are given at a logical place in the article." GeorgeLouis (talk) 21:01, 31 May 2013 (UTC)
I've reverted you. The proposed change of style may be a good one, and may have community support (the two are not always coupled!), but such a change, affecting many thousands of articles, requires a wider discussion, not least involving the biography project, and so should be centrally advertised. So far, there isn't even consensus among the four people who have so far discussed this here. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:07, 31 May 2013 (UTC)
I agree and will do my part in publicizing. Shall we make this page the place for discussion? Also, I never got an answer as to when the present policy was put into effect. I don't remember there being any discussion, but that may be neither here nor there because now we can have it. Sincerely, your friend, GeorgeLouis (talk) 21:19, 31 May 2013 (UTC)
Interesting points, the infobox is usually the place for exact dates anyway. --Nathan2055talk - contribs 20:41, 2 June 2013 (UTC)
I agree it's clutter that we can eject from the opening sentence, per WP:SUMMARY. There's plenty of room for in the body and within infoboxes. This excessively detailed for the lead. -- Ohc ¡digame!¿que pasa? 22:55, 2 June 2013 (UTC)
Just wanted to note that I don't think TCO's argument that "I would not write the first sentence of a report in 'the real world' like that" is a good one. This is an encyclopedia, not the real world (it's not even the Simple English Wikipedia). The lede can contain whatever information may be useful to the reader that might be welcome from a resource document that you wouldn't necessarily include mid-sentence in a report, because encyclopedias can do that. The question is whether we should. Personally, I see it that:
  • The information (e.g., dates of birth/death, pronunciations, alternate names) is useful;
  • It is helpful to have the information at the start of the article;
  • It is helpful to have the information in a consistent location (regardless of whether an infobox is present);
  • The information is set off by parentheses and can be easily ignored if a person is not interested in that data.
Perhaps it would be more ideal if the information could be expanded/collapsed like one of those "show"/"hide" switches, but that might be a bit pie-in-the-sky. —sroc (talk) 23:20, 6 June 2013 (UTC)

I assume that you mean in the introductory sentence ("Francesco Petrarca or Petrarch (1304–1374) was an Italian...") rather than the whole lede section. OK, a couple of things on that:

This has been discussed a lot. That doesn't mean it can't be discussed again though. There was huge discussion a couple years back (some 80-100 active commentors I think), and though it was never formally closed I don't think, the result was:

  • There was no agreement on a formal rule, so it remains up to the individual editor. As a practical matter, the first person to write the introductory sentence decides, and absent a pretty good reason that should be left alone, on the same principle as WP:ENGVAR to avoid sterile back-and-forthing.
  • Neither the arguments for or against using just the years was enough stronger than the converse argument to close on strength of argument alone.
  • With some 100-odd participants, there were enough nuanced views to make a headcount difficult, but I'd say there was a significant majority (but not really a supermajority), in favor of using just the years as a general thing, but only provided the factors shown below are not in play. (If the factors show below are in play, many editors still favored using just the years, but by a much thinner majority.) The factors are:
    • If there's no infobox, that's a factor in favor of including the dates as well as the years. Presence of an infobox removes that factor.
    • If the person's birthday or death day is a national holiday, or is celebrated or even just remembered by any significant number of people, the dates as well as the years should probably be included. (Both of the dates, for parallelity.)
    • If the article is short -- one or two paragraphs, say -- that's a good reason to put in the dates as well as the year. Otherwise you have the years in the introductory sentence, then withing a few sentences you're repeating the vital info in order to specify the exact dates. This clutters.
    • If it's a long article, and the death date is somewhere toward the end of the article, that's possibly a reason to put the dates as well as the year. Otherwise the readers who just want the vital dates have to go fishing through the article.
    • If the person is alive (and there's no infobox), and the birth date is stated anywhere in the article that's a reason to put the birth date in the introductory sentence, since that allows the reader to quickly deduce the subject's age. (A number of editors held that for WP:BLP privacy reasons the birthdate should not be stated anywhere in the article. Some people might consider their birthday to be private information, and that datum does not usually contribute to an encyclopedic understanding of the subject, unless you believe in astrology.)

One reason is that this is a vexing issue is that there's some tension over which is the controlling authority: Wikipedia:Manual of Style/Dates and numbers or Wikipedia:Manual of Style/Biographies. Herostratus (talk) 23:02, 2 June 2013 (UTC)

A very thorough summary. That's why I like "The exact dates (month and day) of births and deaths are not required in the lead sentence. Only the years are required, if you have them, as Jane Blow (1932-1982). The full dates are given at a logical place in the article." Short and sweet. GeorgeLouis (talk) 03:44, 3 June 2013 (UTC)

¶ I'm all for laissez-faire and letting an article's active editors (not those whose only interest is format) decide among themselves without appealing to Some Greater Authority, and using the first-primary-editor rule as a tie-breaker only if consensus can't be reasonably reached without undue delay or contention. I don't recall (being a partially-reformed lurker/participant in MoS-&-descendants talk pages) the 100-editor discussion mentioned above, but I did take part in a smaller discussion about the trickier, related question of whether to include or exclude places with the dates. Practice among printed reference-works (e.g. Petit Larousse) varies greatly. Again I think this should depend almost entirely on relevance to the article's subject, without any overarching Uniform Rule. But combined with day and month of birth & death (let alone those phonetic hieroglyphs and audio links), they could become a bit unwieldy though sometimes appropriate [e.g., Abraham Lincoln (Kentucky, February 12, 1809 – Washington, D.C., April 15, 1865)]. —— Shakescene (talk) 16:35, 3 June 2013 (UTC)

  • A great big "Amen" to choosing context over pettifogging. --Kevjonesin (talk) 17:06, 3 June 2013 (UTC)
  • Another possibility is a simple edit that would leave most of the MOS intact, i.e. "When full dates of births and deaths are used at the start of articles (not required), this form is used:" So I just did made that change in the spirit of WP:BRD, and don't tell me I am out of line because boldness is a virtue. Just ask Bert Lahr. GeorgeLouis (talk) 19:25, 3 June 2013 (UTC)
  • STRONG Keep exact birth dates. Exact dates in an article's lead have always been used in Wikipedia, for good reason. They provide useful information to Wikipedia readers in that they are always found in the same place in every article. Not all articles have infoboxes (where dates are always exact), so without exact dates in the intro, our readers may be forced to comb through main body text to find the exact birth and death dates. Since the goal of Wikipedia is to provide useful information to our readers, keeping exact dates in the intor is the sensible thing to do. Truthanado (talk) 23:49, 4 June 2013 (UTC)
That is a strong statement. They have not always been used. If you say they have, then prove it. GeorgeLouis (talk) 02:24, 5 June 2013 (UTC)

The only reason I put the exact date in the lede is because I don't have a better place to put it. There are biographical articles I've been trying to do clean up on where if the exact date isn't in the first sentence of the lede then either I have to put it in a paragraph of otherwise unrelated material or put it alone in a paragraph by itself, which conflicts with my trying to avoid paragraphs of only one sentence. RJFJR (talk) 14:54, 5 June 2013 (UTC)

The sense and sensibility of the writing should be paramount. If the exact date is better in the lede, use it. If it is cumbersome and breaks up the flow of the writing, save it for later. My beef is with the editors who have nothing better to do with their time than to ruin a perfectly good lede, already written and vetted, by riding up, sticking in the exact dates, thereby clunking up the flow of the sentence, and riding off again. And then "justifying" their vandalism by citing some supposed "rule." GeorgeLouis (talk) 15:52, 5 June 2013 (UTC)
The following wording was in place until GeorgeLouis's bold edit on 1 June:
"Dates of birth and death are provided in articles on people, most notably at the start of articles. For example: "Charles Robert Darwin FRS (12 February 1809 – 19 April 1882) was an English naturalist ...""
There have already been several changes to this wording whilst this has been under discussion. IMHO, the original wording should remain in place until a consensus is reached. Wikipedia:Consensus policy requires discussion of contentious edits and, where there is no consensus, the version before a bold edit will usually remain.
Additionally, I have a problem with the current wording, as noted in my edit summary before GeorgeLouis reverted it:
"When full dates of births and deaths are used at the start of articles, this form is used: "Charles Robert Darwin FRS (12 February 1809 – 19 April 1882) was an English naturalist ...""
The words "this form is used" implies that the date–month–year format shown in the example should be used, which is incorrect; the date format will depend on the format used throughout the article. The choice of wording is poor. This is another reason to discuss proposed changes before implementing what you think is right, especially in a style guide that others will use as reference throughout Wikipedia. We shouldn't be in such a rush to get our own way. —sroc (talk) 02:28, 6 June 2013 (UTC)
On the actual issue, I think the dates of birth/death are amongst the most important details that can clutter the opening line. IMHO, pronunciations, translations and AKA names are more disruptive. Translations and AKA names can be re-worked later into the lede to avoid disrupting the flow of the opening line. However, I'm not convinced that reducing the birth/death dates to years only is necessary, nor that it is the best way for achieving the objective of de-cluttering the lede.
Also, there are various encyclopedias and similar resources that use full dates. For example:
"David Sedaris, in full David Raymond Sedaris (born December 26, 1956, Johnson City, New York, U.S.), American humorist and essayist…"
"Albert Einstein (March 14, 1879 – April 18, 1955) was a German-born theoretical physicist."
"David Sedaris (born December 26, 1956) is a Grammy Award-nominated American humorist, writer, comedian, bestselling author, and radio contributor."
"Louis-Joseph Papineau, lawyer, seigneur, politician (b at Montréal 7 Oct 1786; d at Montebello, Qué 25 Sept 1871), the son of Joseph Papineau, a seigneur and moderate liberal member of the Assembly."
—sroc (talk) 02:47, 6 June 2013 (UTC)

Thanks to sroc for the research. There actually is no consensus among encyclopedias, just as there is no consensus among WP editors. Our esteemed colleague sroc is also correct about the other blocks to comprehension, the foreign lettering (Chinese, Japanese), the pronunciations, etc. What a joke! Write simply: That's the key. This is one of those areas when the spirit of Wikipedia:Ignore all rules and WP:Assume good faith should definitely be implemented. GeorgeLouis (talk) 14:12, 6 June 2013 (UTC)

Pointing out also. The examples given above by sroc I assume are from encyclopedias whose style is to list the exact birth and death dates just once. In Wikipedia, I have seen them listed three times—once in the lede, once in an infobox and once in the text. We really need them just one time, no matter where they are located. GeorgeLouis (talk) 04:35, 8 June 2013 (UTC)
However, they all use some form of the whole date (when available) in their lead sections.--RightCowLeftCoast (talk) 21:13, 6 June 2013 (UTC)
This isn't really an Wikipedia:ignore all rules situation. We're (re-)writing the general rule! There may be individual cases where we ignore the MoS in particular cases when it makes sense to do so, but this is where we should set the standard (if there is one).
BTW, my research obviously is not exhaustive. There are heaps more encyclopedias out there and I haven't the time, but that was just to counter-balance the argument that all/most encyclopedias use years only. As GeorgeLouis notes, there is no consensus amongst encyclopedias. —sroc (talk) 23:11, 6 June 2013 (UTC)

I also believe that we should only list birth and death years in the lead sentence, and add the other data later on where it is relevant. The lead is supposed to summarize the important points of the article and the exact dates and places are usually not among them. I think we do need a change to the MOS on this issue, to allow simplified birth and death dates, because as it is now if we try to write our articles that way the wikignomes will just come along and fill in the details again thinking they are making an improvement. —David Eppstein (talk) 22:44, 6 June 2013 (UTC)

FYI, this has recently been discussed at Wikipedia talk:Manual of Style/Biographies#Birth and death dates .2F Infoboxes, too. —sroc (talk) 23:34, 6 June 2013 (UTC)
  • Strong keep. There is no reason whatsoever to change our longstanding practice of adding full dates in the first sentence. They are basic biographical information and are included in most encyclopaedias that I've seen. In no way are they jarring or intrusive, as the nominator suggests. They are what I expect to see in the first line of a biographical article. They are in fact far better here than in the body of the text and certainly better than infoboxes, which should contain no information which isn't elsewhere. -- Necrothesp (talk) 13:36, 7 June 2013 (UTC)
  • While I'm fuzzy on whether we should allow just years in the opening sentence (when we have the data), I'm strong that we should not require just years. Too many of our articles are stubby little things; giving that requirement would lead to either the destruction of the date information or the creation of dense redundancy, with the opening sentence containing the years being followed a sentence or two later by the sentence with the full dates or being adjoined by an infobox with little but the dates, and then that being the article in whole. --Nat Gertler (talk) 16:37, 7 June 2013 (UTC)
  • Keep full dates. Per Truthanado and Necrothesp, full dates provide useful information; it is useful to have them in a consistent place regardless of whether there is an infobox in individual cases; readers should not have to pore through the article to find this basic biographical data; full dates should not be banished to the infobox only, as this should only summarise information included in the article; the inclusion of full dates is not overly obtrusive. The addition of other information (e.g. pronunciations, other names, etc.) may make the opening sentence unwieldy in individual cases, however:
  • IMHO, this is not a good reason to dispense with full dates against the countervailing benefits;
  • Consideration should be given to how the other elements that may actually clutter the introduction could be better handled (this discussion really should be had elsewhere);
  • In individual cases where the opening sentence becomes unwieldy due to the culmination of full date, pronunciations, alternate names, etc., this can be dealt with on an individual basis by either re-writing the lede (e.g., shifting the alternate names out of the opening sentence) or ignoring the general rule if necessary.
I might support a change to the MoS to the effect that full dates are preferred rather than years only unless: (a) the opening sentence is otherwise too cluttered with parenthetical data; (b) there is no better way to reduce the clutter to an acceptable level; and (c) the full dates are already included elsewhere in the article (including in the infobox, as an exception to the general rule). However, I do not support changing the MoS to discourage the use of full dates in the opening line generally. —sroc (talk) 02:14, 8 June 2013 (UTC)
  • Keep full dates per all of the above. Canuck89 (converse with me) 02:18, June 8, 2013 (UTC)
  • For my part, it usually makes sense to have just the years. "1389-1453" tells me 99% of what I want to know: the person was active in the first half of the fifteenth century. In almost all cases, knowing his exact birth and death dates is of no more use in getting a handle on the person than knowing his eye color, and less use than knowing his height and weight. It's traditional in many publications to include the exact dates in the opening, and that's exactly what it is: tradition, habit, that serves no very useful purpose. But, I think the system we have is fine: if you're writing the article, do what you like (we have too many rules as it is), but don't change it in an existing article absent a very good reason, described on the talk page. And our MOS should state both of those de facto practices specifically. Our rule pages are mostly supposed to codify existing practices. Herostratus (talk) 04:27, 8 June 2013 (UTC)
  • Short, but Wait: This seems like something that WikiData can solve. Once the dates, places, alt names, and pronunciations are moved to the database, the user's style sheet could be used to control the visibility of the various parts. Personally, in the lead, I would prefer (yyyy–yy[yy]]) only, with a mouseover popup that has the rest in it. This fits well with the purpose of the lead – to summarize significant data, like the era during which the subject lived. Add the alt names and pronunciations to the Infobox (if not already there). —[AlanM1(talk)]— 14:02, 8 June 2013 (UTC)

Correction: part of my arguments for retaining full dates is that infoboxes "should only summarise information included in the article". Upon review of Wikipedia:Manual of Style/Infoboxes (specifically #Using infoboxes in articles) and an earlier discussion at Wikipedia talk:Manual of Style/Infoboxes/Archive 6#References in infoboxes?, it appears that there is no such rule, although it is generally preferable that the infobox not include information that would require a reference which is not already covered in the article. That being the case, there is a stronger argument that certain data could be omitted from the lede and kept only in the infobox. —sroc (talk) 13:00, 11 June 2013 (UTC)

  • Keep full dates - per above. United States Man (talk) 12:08, 12 June 2013 (UTC)
  • Keep full dates - Per the reasoning of Truthanado and Necrothesp. (Remember that not all articles have infoboxes; nor need they.) --Orange Mike | Talk 12:20, 13 June 2013 (UTC)
  • Keep full dates - exactly per Orangemike. –Quiddity (talk) 21:51, 14 June 2013 (UTC)
  • Keep Full Dates: per the above. Tradition or otherwise, I expect to see the exact birth-death dates if known immediately upon opening an article. The place(s) can be later in the article, but the dates need to be readily seen (eg: in the lede). GenQuest "Talk to Me" 17:35, 17 June 2013 (UTC)
  • Keep full dates. Please note that I expressed my opinion above, but did not leave a bolded !vote. Please do not count my opinion twice. Dirtlawyer1 (talk) 20:52, 17 June 2013 (UTC)
  • Keep full dates- I do not think that these full dates interrupt the flow of the sentance, if they bother you then simply look over them (like the reference boxes bother some people but they just look over them). Also this site is an encyclopaedia and so we should try to be as specific as possible when writing information. Replied per RfC. Rainbow Shifter (talk) 16:34, 20 June 2013 (UTC)
  • Years only - Info boxes have made full dates in the lead obsolete. They're disappearing whether people vote them in or not. Exact dates should be in the body and the info box. Carrite (talk) 02:53, 26 June 2013 (UTC)
  • Keep full dates- They don't interrupt the flow of anything. It is easy enough for the eye to skip over them if that is not what a reader is looking for. BTW not every bio has an infobox so where else are we going to have then together for the reader that is looking for just that info? MarnetteD | Talk 03:19, 26 June 2013 (UTC)
    • Sorry, but you can't say "keep" full dates when it has never been a rule accepted by consensus. You could, however, say "use" full dates. GeorgeLouis (talk) 03:43, 26 June 2013 (UTC)

Incomplete year ranges

I brought this up at Template talk:Infobox television awhile ago, but no response. There are a few infoboxes for TV shows that have "(2000–)". The en dash is supposed to mean current or continuing (ambiguous in itself). Is this ever acceptable? It seems to me that it's grammatically incorrect to not have the dash followed by another year or "present". --Musdan77 (talk) 21:36, 16 June 2013 (UTC)

In my view, it should be "(since 2000)". Tony (talk) 08:04, 18 June 2013 (UTC)
Well I think that it would be better to either put the suggested statement (see comment above) or to but e.g. "2000-present". Rainbow Shifter (talk) 15:28, 20 June 2013 (UTC)
Which "present"? The present when the editor wrote the comment or the present when a reader encounters it a year later? For people who are still alive we don't give their dates as "1948–" but as "born 1948". So Tony's "since 2000" is surely the best solution: grammatically correct; avoids the use of the ambiguous "present"; and is consistent with other kinds of incomplete range. Peter coxhead (talk) 14:03, 22 June 2013 (UTC)
"Since" does rather imply that it is still continuing until the "present", doesn't it? I tend to this that "2000–" suggests either that it is still ongoing or that perhaps the end date is unknown, either of which may be the case. So I would support the status quo. —sroc (talk) 14:20, 22 June 2013 (UTC)
I agree with Peter Coxhead: which present? My problem with [year]–present is that it seems to imply that the range is ending right now, in the present; whereas "Since 2008" is unambiguous and a bit more elegant—not to mention fewer characters, which is important in space-constrained infoboxes. Tony (talk) 14:37, 22 June 2013 (UTC)
@sroc: Well, the exact equivalent of "born 1948" in this context is probably something like "started 2000" rather than "since 2000", but I don't think it makes that much difference. Even "born 1948" carries the implication that the person is still alive since no death year is given. So I continue to favour "since 2000". Also I don't accept that "2000–" is the "status quo". Dates that are given as ranges should follow the same patterns as given above for birth and death dates, i.e. should not have "–" without a closing date. Peter coxhead (talk) 15:17, 22 June 2013 (UTC)
The only reason the present is there is to show that the person is alive right now, in the moment you are reading this. When the person des, of course the present would be removed. Rainbow Shifter (talk) 17:08, 22 June 2013 (UTC)
But "present" should not be used; MOS:DOB is explicit: "For an individual still living: "Serena Williams (born September 26, 1981) ...", not "... (September 26, 1981 –) ...". So neither should it with TV shows or anything else, as per the quote above. Peter coxhead (talk) 18:56, 22 June 2013 (UTC)
I was not actually suggesting we use that, rather use the "since" or something symbolising that. The present was just an example of what else could be used. I am fully in favour of using since due to it being stated. Rainbow Shifter (talk) 19:01, 22 June 2013 (UTC)
@Tony1: "2008–" is shorter than "Since 2008". I was not advocating "2008–present". "2008–" does not imply "and is still going on"; certainly less so than "Since 2008" does.
@Peter coxhead: I was only referring to the "status quo" based on the original post by Rainbow Shifter. —sroc (talk) 07:56, 23 June 2013 (UTC)
Ah, I see. The objection to "2000–" remains: the en-dash here stands for "to"; "2008 to" doesn't make sense. Peter coxhead (talk) 08:12, 23 June 2013 (UTC)
In the real world, constructions such as "2008–" are commonly used to mean "starting in 2008 with no specified end date". This may not fit with current Wikipedia guidelines, but is it really more ambiguous than "Since 2008" or "2008–present", both of which I think more strongly imply that whatever-it-is is still going on? I think "2008–" could mean "2008–present" or "2008–unknown", either or which could be correct until the reference is updated when the information becomes available. —sroc (talk) 08:20, 23 June 2013 (UTC)
Well, we're into opinions here. My personal preference order, for which I think I have rational reasons, is "since 2008" > "2008–" > "2008–present". However, my preference and yours are irrelevant; the MOS is clear and should be followed unless and until changed. You're always free to start an RfC to see if there's a consensus to change the MOS. Peter coxhead (talk) 08:27, 23 June 2013 (UTC)
Of course you are right that the MOS is what counts here, not our personal preferences, and I don't feel strongly enough about it to lobby for change in the MOS. —sroc (talk) 09:04, 23 June 2013 (UTC)
I agree with Peter coxhead completely. Tony (talk) 09:05, 23 June 2013 (UTC)

Okay, let me see if I understand correctly. MOS suggests that it should be "since 2000"?

I don't recall seeing a television infobox use that for cast and crew. That would mean a lot of changes to be done (as well as inevitable conflicts). Now I think I'm even more unsure of what to do. --Musdan77 (talk) 19:41, 23 June 2013 (UTC)

I don't think that the MOS says use "since 2000". What it does clearly say at MOS:OTHERDATE is that dates that are given as ranges should follow the same pattern as birth and death dates, and there forms like "2000–" are explicitly deprecated. Peter coxhead (talk) 21:31, 23 June 2013 (UTC)
Instead of "Since 2000", how about something like "From 2000" or "First aired 2000" in order to avoid the implication that the program is necessarily still on-going? This would remain consistent with the "Born 2000" format for birth dates. If there is no established status quo, I mean. —sroc (talk) 05:38, 24 June 2013 (UTC)

I have another case in point at Matty B. The lead describes Matty B as "a former Australian rapper" (i.e., retired from a music career) while the infobox said "Years active: 1999–present" (i.e., implying his music career remains current). The article mentions no activity since 2006, strongly suggesting that he is indeed retired (particularly assuming that the "former" was added in good faith) but there is no reliable source stating that he has retired. To my mind, "Since 1999" (as with "1999–present") would misleadingly imply that his music career is still on foot when this is probably not the case. What is the best solution in such cases? "Started 1999"? —sroc (talk) 10:08, 25 June 2013 (UTC)

By the way, I think there is good reason to treat the infobox differently from prose, i.e., that formats such as "1999–" should be acceptable in an infobox as a clear and convenient summary of information whereas this would not be suitable in prose (such as a birth date in the opening line). —sroc (talk) 10:10, 25 June 2013 (UTC)

YYYY-MM-DD

Based on one of my recent edits and by the summary for the subsequent reversion, and by the fact that the reverting editor is an experienced Wikipedian whose user page demonstrates reasonableness and intelligence, I think that the YYYY-MM-DD date format (e.g., 2013-11-02) is confusing to a significant fraction of readers. Its advantage, of course, is that it is concise in a reference. However, "11 Feb 2013" is almost as concise. Should we change the MOS to deprecate or remove YYYY-MM-DD? Peter Chastain (talk) 21:04, 10 June 2013 (UTC)

It's been pushed before but no, it's not going to happen. It's use, however, is pretty much restricted to reference lists; it cannot be used for dates in prose or in tables (as you say, Mon DD, YYYY or DD Mon YYYY saves similar space), but we can't get rid of its use in references. --MASEM (t) 21:07, 10 June 2013 (UTC)
Hm, AFAIK, the ISO format can also be used in tables in order to save space and make sorting easier. At least I have seen many tables in the English WP using it... --Matthiaspaul (talk) 21:27, 11 June 2013 (UTC)
If there are tables using that, they need to be swapped out with the abbreviated month form appropriate for the page. (either DD MMM YYYY or MMM DD YYYY). Within prose including tables in the body, these aren't appropriate (baring cases where the date format itself is the subject of discussion, of course). --MASEM (t) 21:38, 11 June 2013 (UTC)
I just read it up at MOS:DATEFORMAT. As I recalled, the ISO format is one of the formats allowed in tables. --Matthiaspaul (talk) 13:30, 13 June 2013 (UTC)
Weird, I thought we got rid of it in tables. (I know there are those worried about sorting but I believe the template {{dts}} and {{dtsa}} are sufficient replacements that allow for abbreviated month versions with hidden sort text, so I do agree that we should get rid of it in tables. --MASEM (t) 13:51, 13 June 2013 (UTC)
The YYYY-MM-DD format is indeed allowed in tables, but it isn't ISO 8601 because ISO 8601 has never been adopted by the English Wikipeda. The style guide is agnostic about where the format came from, whether it came from the International Organization for Standardization (ISO), or was a preexisting concept that evolved with no formal process before ISO got their hands on it. Jc3s5h (talk) 13:54, 13 June 2013 (UTC)
I always wrap them in {{dts}} when I come across them, and nobody ever complains. -- Ohc ¡digame!¿que pasa? 02:16, 14 June 2013 (UTC)
Also, to point out, there is no system in any country or the like where "YYYY-MM-DD" can be taken as "YYYY-DD-MM". (eg there is no recognized system where 2013-05-04 is April 5 2013.) There are issues if one tries to use this ISO style for old dates (pre calender changes) but nothing in the 20-21st centuries. --MASEM (t) 21:10, 10 June 2013 (UTC)
I agree no recognized system considers 2013-05-04 to be April 4, but I have just demonstrated that some people will interpret it that way, anyway. Even if everyone were completely familiar with ISO dates, it will (IMO) always be the case that a reader of English will parse "4 May 2013" more quickly than "2013-05-04". If something is faster to read and less confusing, why not use it? Peter Chastain (talk) 21:19, 10 June 2013 (UTC)
Which is why the ISO format is not allowed in prose, because of that. On the other hand, references aren't prose, which is why it is okay there. But to the first point, we literally cannot deal with editors that are being obtusively stupid, to put it bluntly. We do consider there are regional and national variations for some things (Summer 2013 means different things depending where you are) and purposely avoid such language - that's reasonable. But there's no alternate way to read an ISO date that falls in the 20-21st century. Misinterpreted while reading, yes, but if they continue to claim it actually is the other way around, that's being flat out wrong. --MASEM (t) 21:29, 10 June 2013 (UTC)
Masem, you mean readers who are being obtusively stupid? I agree with Peter Chastain that the telephone-number dates are very unkind to the readership as a whole, even if only in ref lists. And Masem, if they're "OK" in ref lists, where space is not really at issue, why aren't they OK in tables, where it is? Tony (talk) 02:32, 11 June 2013 (UTC)
Both readers and editors who thing it is YYYY-DD-MM, which simply doesn't exist. (SEe the diff provided above). And the reason we avoid that form in tables is that tables are considered like prose and should be easier to read, not a space issue. --MASEM (t) 02:40, 11 June 2013 (UTC)
I've seen all the variants of dates being used, and I promise you they are numerous in variety as they are in number, which is why the script is necessary to remove errant formats. -- Ohc ¡digame!¿que pasa? 03:22, 11 June 2013 (UTC)
That must have been some strange custom-format then, because YYYY-DD-MM is not used as a date format in any country on this planet. Actually, that's one of the advantages of the ISO 8601 format YYYY-MM-DD; it cannot be confused with another date format (which was a very common problem in international communications before the ISO format was introduced). --Matthiaspaul (talk) 21:27, 11 June 2013 (UTC)
By using yyyy-mm-dd, you would be applying a convention. There will always be those who don't know of it or are confused by it when all there are are digits. But there's no possibility for confusion if the month was spelt out. -- Ohc ¡digame!¿que pasa? 14:51, 13 June 2013 (UTC)
  • So why are ref lists allowed to be relatively difficult to read? Tony (talk)
    • Because some ref formats in the real world use that format, and since we're open to a variety of ref formats (as long as they are consistent within the article), we need to be tolerant of that. It doesn't make sense to force conformity in dates if we're not going to force conformity in ref style. --MASEM (t) 02:51, 11 June 2013 (UTC)
    • I've heard some argue that accessdates are metadata and should not be considered data. It's the best explanation I've heard so far for the use of 'YYYY-MM-DD', because let's face it few would parse them easily or quickly. But that being the case, it would make it the only metadata on the face of the article – mighty weird. -- Ohc ¡digame!¿que pasa? 03:14, 11 June 2013 (UTC)

Here we have another reason to ditch this format once and for all. I don't see that we have to allow phone-number dates just because there exists ref formats out there that use them. WP is perfectly free to choose the format(s) we find acceptable. Requiring that all dates be easy to read shouldn't infringe too much on this or that editor's favourite ref style; it would only be a slight modification. I do wonder, though, how much is following real-world examples and how much stems from the fact that until a couple of years ago the citation templates required ISO format for input (for the purpose of autoformatting). Also, if it's metadata, who says metadata should be hard to parse? The sooner the ISO dates are gone the better but will that day ever come? I don't know. JIMp talk·cont 05:02, 11 June 2013 (UTC)

That argument doesn't fly as long as we accept multiple different reference styles, and we're never going to standardize on that. You're not forced to use ISO dates, and since they only can be read in one way, are impossible to mis-interpret, unless editors are simply being ignorant. Arguments against this are pretty much "I don't like that format" type, and the efforts to try to force this change run against the existing arbcom resolution about MOS pushing. --MASEM (t) 05:57, 11 June 2013 (UTC)
What is the arbcom resolution about MOS pushing? Peter Chastain (talk) 07:49, 11 June 2013 (UTC)
This 'tolerance' of multiple ref formats (and dates) would seem to indicate to me that MOS isn't being pushy enough by half. But retracing on the "parsability" of 'YYYY-MM-DD' dates, Asian cultures do that more instinctively because it mirrors date formats in their native conventions. -- Ohc ¡digame!¿que pasa? 08:39, 11 June 2013 (UTC)
Well, I strongly disagree about the MOS and "pushiness"; it's already too pushy in some areas. But as a computer scientist I find YYYY-MM-DD dates easy to parse as they are in the natural sort order. Also they are the way that dates are written on official forms, etc. in Canada, so it's not just an "Asian" thing. I agree with Masem that this is just another example of "I don't like it so it shouldn't be allowed". Peter coxhead (talk) 10:17, 11 June 2013 (UTC)
The international date format YYYY-MM-DD, as defined in ISO 8601, is not only used in most parts of Asia and Eastern Europe, it is meanwhile also an alternative date format in Western Europe, which traditionally used DD.MM.YYYY. Several Western European countries even have adopted it as their official date format in the past two decades (f.e. Germany with DIN EN 28601 since 1996-05-01). From personal experience I know that it takes a few weeks to get used to it, but there are so many advantages of the ISO format that I don't look back. There's a point when the other date formats start to look awkward, illogical, and more difficult to parse than the ISO format even in prose... ;-) Actually, I would highly appreciate to see the ISO format used more often in Wikipedia as well, as it is the only format, which cannot be confused with other date formats for as long as the 4-digit year is used, and this is something I consider very important in an international project like this. --Matthiaspaul (talk) 21:27, 11 June 2013 (UTC)
The fact that you know it's formally unambiguous doesn't mean that readers aren't going to do a double take, or necessarily understand them. There is a difference between formal lack of ambiguity and actual lack of ambiguity. People are not computers.
I know that, as someone who habitually uses DD-MM-YYYY, I have looked at these dates before and misinterpreted them, getting the date and month the wrong way around. I've also seen tables full of YYYY-MM-DD dates on Wikipedia before and given up trying to parse them all because it all looked like a sea of numbers and it simply didn't seem worth the effort to extract all of the information. I note that I live in Western Europe, and I do not believe I have ever seen a YYYY-MM-DD date in RL in my country, outside a computing context.
We should be using a format that is common in English. I don't believe any English-speaking country uses YYYY-MM-DD exclusively and I believe that a large proportion of English-speakers - particularly those who are not programmers or technophiles - are going to have difficulty with it. We should always write out the month in some form to make our articles as accessible as possible. Kahastok talk 21:57, 11 June 2013 (UTC)
For the record, YYYY-MM-DD is widely used in South Africa, a country where English is now the lingua franca.
@Matthiaspaul, my native language is English. I attended university in both the United States and the UK. There is absolutely nothing "ambiguous" about "December 31, 2012" or "31 December 2012" in any national variety of English, they are mutually intelligible in all national varieties of English, and such formats should be strongly preferred over all-number date formats in prose and tables across all subject contexts. Dirtlawyer1 (talk) 14:37, 13 June 2013 (UTC)

I was in favour of the ISO dates in the days when they were linked and you could get them displayed in your own preferred format, but now the use in just the accessdate for references is jarring and does not look very professional. I now think that it is about time we ditched this format of date altogether in favour of a consistent format throughout the article, including the appendix sections. Having seen a number of formats for these all numeric dates you cannot assume they match the ISO standard and are in YYYY-MM-DD format, better to be precise and spell out the month for clarity. Keith D (talk) 22:09, 11 June 2013 (UTC)

  • The use of ISO format dates should be restricted to computing and similar tech contexts. We may tolerate the ISO format in those contexts, but there is no reason to encourage its use elsewhere. This is the English language Wikipedia; virtually no one in the English language world uses ISO format dates in prose or most other common usages. The fact that ISO format dates may or may not be used in Germany, eastern Europe, Asia, or other countries elsewhere, is irrelevant to standard English language practice across all major national varieties of English (American, Australian, British, Canadian, Irish, New Zealand). Likewise, we don't write English language Wikipedia articles in German, Russian or Chinese, either. If editors want to use ISO format dates in articles dealing with computing and other tech subjects where it may be commonly used, that's okay provided that they do it consistently, but editors should be actively discouraged from inserting ISO dates into articles where such usage is unusual, odd and eccentric for the given topic (i.e. the overwhelming majority of non-tech subjects).
Unfortunately, the random insertion of ISO dates into inappropriate articles seems to occur quite frequently. It is aggravating when an existing article, with a well-established date format, and numerous footnotes properly formatted consistently with the established date format, are subject to the random "upgrade" of footnotes with ISO format dates for publication and retrieval dates. This apparently occurs most often when editors are using semi-automated editing tools that are set to use the ISO format; this needs to be actively discouraged. This careless disregard of established date formatting is contrary to the most common usages in all varieties of English, contradicts the established consensus choices for those articles and subjects, creates unnecessary work for the editors who are maintaining those articles, and it looks sloppy and unprofessional when multiple date formats are randomly mixed. The overriding principle of the MOS is that articles should be internally consistent in the various formats, styles and usages employed within a given article; that basic rule should be rigorously applied to date formats, too. Dirtlawyer1 (talk) 14:15, 13 June 2013 (UTC)
Editors "upgrading" dates to ISO across citations w/o consensus (note: this is different from just adding a citation with ISO formats but not touching the other ones) is strongly discouraged at CITEVAR and other MOS pages. Of course, I've also seen editors "upgrading" to dmy and mdy formats too when the original dates were in ISO, and this is also a no-no.
On the other hand, citation formats are hard already for the new user, and to simply get a source, they may drop to an ISO format when the rest are using dmy or mdy. This should not be considered bad or the like, as the fix to harmonize the format is simple. If you took the ISO format away, you'd get the same problem with dmy added to mdy articles or vice versa. It is not a problem that originates from the ISO format, just the CITEVAR approach. --MASEM (t) 14:21, 13 June 2013 (UTC)
  • the fix to harmonize the format is simple IFF there is only one allowable format in reference sections. Once articles are tagged dmy or mdy, any mdy dates dropped into a dmy article (or vice versa) can be aligned to the prevailing format even by bot. If it's a case where dmy (or mdy) AND yyyy-mm-dd supposedly coexist (perhaps one as a publication date and one as accessdate), automated harmonisation becomes complicated. -- Ohc ¡digame!¿que pasa? 14:47, 13 June 2013 (UTC)
  • Sorry, Masem, but it is a problem of the overly permissive use of the ISO date format, in combination with auto editors who can't be bothered to conform their edits to the established style. Many of those auto editors are experienced gnomes of long-standing, and some simply prefer the ISO format. When an article has 15-20 footnotes in an established date format, adding ISO-formatted dates is a very real and very common problem. Frankly, it is a fairly rare occurrence that an auto editor inserts MDY dates into an article where the DMY format is the preferred style (or vice versa). In my personal experience, across 2,500 watch-listed articles, the problem is invariably the insertion of inappropriate ISO dates, not the insertion of inappropriate MDY or DMY dates. I think we can agree that all references and footnotes within a given article should be stylistically consistent. Bottom line: the "gnoming" of dates should fix problems and create consistency, not create inconsistency and more work for other editors. Dirtlawyer1 (talk) 15:04, 13 June 2013 (UTC)
  • Is an article going to be completely unusable if one editor adds an ISO date reference to an article that uses mdy references? Absolutely not. Should it be fixed? Sure -- in time. What's being asked for here is an iron fist approach which, from the last ArbCom incident, cannot work when we're talking about MOS and not content itself. Having one or two ISO-formatted references where all others are dmy/mdy is not going to harm anyone's understanding of an article. As OC has said, once a style has been established, a bot can then be used to maintain that even if editors add the wrong format, so really, this is making a mountain out of a molehill. --MASEM (t) 15:09, 13 June 2013 (UTC)
  • Under the current scenario, there is no problem flipping between dmy and mdy. The problem arises when yyyy-mm-dd dates enter as an additional variable within one, two or all three date fields within references. -- Ohc ¡digame!¿que pasa? 15:21, 13 June 2013 (UTC)
  • Let's put it this way. We really should have a parameterized template that a date-fixing bot can work from that outlines what date formats have been decided for the article's body and appropriate fields (date, accessdate, archivedate) in the citations - basically expanding on the use dmy/mdy template, but adding details for citations. Only once that is added to an article should any automated fixing be considered; that template should be added to the article at the GA level at minimum (which does require proper citation formatting) though editors are free to add it before then. When that template is not yet present, normalization of dates should not take place until discussion has taken place to establish the proper formats for that article. So in the case of a new editor injecting a ISO accessdate among an article that is otherwise untagged but filled with only mdy dates (including other accessdates), this would be a case where a BOLD addition of the date format specification can be added before automatically fixing up the dates. But if it a mix of date formats, nothing should be done save for initiating discussion on how to normalize them all. --MASEM (t) 15:40, 13 June 2013 (UTC)
  • Truth is, the vast majority of editors don't care what formats articles are in. It's taken so long just to get 300k articles tagged and supposedly for one date parameter. Expand the template to accommodate the 3 date parameters in citations and you introduce 12 times the complexity when making each template decision. -- Ohc ¡digame!¿que pasa? 16:29, 13 June 2013 (UTC)
  • There is no DEADLINE, of course. That said, much of this problem extends from CITEVAR where "any format can be used as long as its consistent" is currently the rule of thumb. As long as real-world citations use ISO, we're going to be stuck with that format, unless CITEVAR can be changed to fix on dmy/mdy which would obviously simplify everything. --MASEM (t) 16:32, 13 June 2013 (UTC)
  • I agree where the problem originates from. But citation methods are often fairly uniform by category – for example scientific articles – and those tend to be fairly well maintained and homogeneous throughout. Elsewhere, there are vast numbers of articles out there with a mish-mash of date formats because few editors care. Even though there's no deadline, there's no point unnecessarily enduring a mess of dates; more articles are being created every minute. SO in practical terms, date alignment by WP:BRD would be the way to go, instead of opening up a discussion at each and every article. Then open up a discussion if there is a challenge. -- Ohc ¡digame!¿que pasa? 17:03, 13 June 2013 (UTC)
  • If it is reasonably obvious what 90% or more of the citations use, then sure, BRD to normalize the rest. But even if say that 75% of the cite templtes are one way and the other 25% another, normalizing on that could potentially be problematic, and even under claims of BRD would be considered pushing the issue. Instead dropping a cleanup template to get editors to normalize dates themselves would be best.--MASEM (t) 17:09, 13 June 2013 (UTC)
  • 75:25 is pushing the boat out too far, IMHO. It's often less clear cut than that anyhow – articles' refs sections often have a mix of dmy, mdy, yyyy-mm-dd and dd-mm-yyyy, for example. I'd draw the line at 'no dominant MOSNUM-authorised format'. -- Ohc ¡digame!¿que pasa? 02:14, 14 June 2013 (UTC)
  • @OC, why in heaven's name would we want to use one date format for a publication date and another date format for the retrieval date within the same footnote? It is jarringly inconsistent, and I believe the ISO meta data theory has already been debunked above and elsewhere. I know that you have been quite active in trying to establish consistency in date formatting across national varieties of English and withing given subject areas. In that same spirit of consistent usage, I see no reason why we should accept two different date formats within a single reference. If the consensus is to use ISO, MDY or DMY date for references in a given article, then the single chosen format should be used consistently for all references, and for both publication and retrieval dates. Two different date formats, side by side, is just odd. Dirtlawyer1 (talk) 15:04, 13 June 2013 (UTC)
  • There are real-world citation formats that use two different date formats for publication and access. It seems odd, but they exist. Because of CITEVAR, we can't force normalization like this. --MASEM (t) 15:14, 13 June 2013 (UTC)
  • And there are many, many more cite formats that use one date format throughout. If there is an established citation format that uses one date format, and some drive-by editor adds an ISO date format on anything I've watch-listed, it's gone within matter of minutes. Adding new and inconsistent date formats within an article with an established reference style and date format is contrary to everything that MOS is supposed to stand for. If we can't maintain an established footnote/date format without someone inserting ISO computer code into the article after the fact, we might as well chuck the MOS now and save ourselves the time, effort and aggravation. Dirtlawyer1 (talk) 19:10, 13 June 2013 (UTC)
  • I'm going to point back to the Arbcom issues that the MOS has been at before and remind people that the MOS is not a holy-than-thou principle. It is a guideline and not policy nor rule. If a newbie's editor accidentally breaks an article that was "perfect" against the MOS, it is not the end of the world, as you are treating this right now. The only time that MOS criteria are important are at article assessement - GA, FA, etc. and failing the MOS outside of these has zero effect on an article. The nature of the open wiki means that there are editors that will be coming in and adding material without knowing anything of the MOS. So acting like one is on a high horse and must defend an article from bad citation formats is not an argument we can use. That attitude is what led to the Arbcom cases before, and really, it is not something to get all up in arms about. An improper date format is added to an article you watch? That's an easy fix, and everyone moves on. --MASEM (t) 19:23, 13 June 2013 (UTC)
  • That's very much a straw man argument as applied to me, Masem. I think I have a pretty sound understanding of the role of MOS in Wikipedia. Wikipedia guidelines are not law, but they are the basic principles upon which we operate, and generally should not be ignored without a pretty good reason. (I would suggest that ignoring the guidelines without a sound basis for doing so is the epitome of IDONTLIKEIT.) As for "newbie" editors inserting randomly inconsistent ISO format dates into our articles, that's perfectly understandable and par for the course across a whole host of style, formatting and basic grammar issues. What is objectionable is the problem of experienced and semi-knowledgeable editors inserting inconsistent ISO dates while using auto editors in mass-edit fashion. I don't believe that maintaining consistent style and formatting within an article or family of articles puts anyone on a "high horse"; frankly, it should be something we strive for. If we are not striving for some degree of consistency in style and formatting, what purpose then does the MOS serve, if any? Dirtlawyer1 (talk) 20:06, 13 June 2013 (UTC)
  • You're putting a lot more weight on consistent and format than on actual content. That's the "high horse" I'm talking about. If a user adds in half a dozen references to support an otherwise written section but uses ISO dates instead of dmy dates that are used in the article, there is zero reason to complain to the editor they chose the wrong dates. You can point and remind the editor about consistent dates, but to say this is a bad thing and oh we need to maintain consistency is exactly the problems that led to MOS being at Arbcom in the first place. MOS inconsistencies can always be fixed. Further, this isn't because we have ISO dates - the fact we have two different allowable date systems in the first place means that even if we disallowed ISO dates, we'd still have the same problems. And then we also have variations in citation approaches means that editors may add cite templates when the article has chosen to use Harvard style. In other words, ISO dates are not the issue here, its the multiple variations in citation formations and that can occur without ISO dates present. And unless we nix CITEVAR, it will be a problem that we've all learned how to deal with in time - basically fixing the errors when they come up if the content is otherwise good. A whole few seconds to do that. --MASEM (t) 20:26, 13 June 2013 (UTC)
  • With all due respect, there are real problems in practical terms: someone adds 12 citations to an article using reflinks (Usually such an editor doesn't care about the format). Another editor align the article's dates to dmy per the dominant style or per previously templated {{dmy}}, a third editor comes along and objects to the second's edit, saying that there is a presumption that the first editor intended on placing the yyyy-mm-dd-formatted citation dates arguing that they should be kept. Worst case: conflict ensues and escalates. The first editor will have created a problem by introducing the yyyy-mm-dd-formatted citation, when combined with the insistence of the third, we potentially have an impasse. Best case, a certain class of dates defaults to the yyyy-mm-dd format as a "compromise", which in fact isn't because it's the only format the third editor will accept. But the dates end up non-uniform. -- Ohc ¡digame!¿que pasa? 02:14, 14 June 2013 (UTC)
  • And again, I point to the fact that the allowance of ISO dates has nothing to do with this problem - it exists because we allow for more than one date type, and more than one citation across WP but idolize internal article consistency. And as I don't think CITEVAR is going anywhere soon, much less formalizing on dmy or mdy or the other, it will remaining a problem, and one removing ISO dates would not solve. It's something we need to learn to deal with, the balance between wanting editors to add content with sourcing, and the ideals of perfectly consistent articles. --MASEM (t) 14:40, 14 June 2013 (UTC)
  • (edit conflict)You'd be surprised. Let's just say that there could be maybe one or two editors who get extremely upset if I or another script user aligns away any yyyy-mm-dd access dates even if these may have been placed by someone using Reflinks. If you're interested, there's quite a lot of such verbiage in my talk page and also at ANI. So I'm now often resigned to not touch accessdates even though there may be dmy (or mdy) coexisting with yyyy-mm-dd dates there. -- Ohc ¡digame!¿que pasa? 15:16, 13 June 2013 (UTC)
@OC, I hear you, and I note that the objecting parties will always object most loudly when you are using an auto edit program to conform the formats (and, yes, I have your talk page watch-listed, and I do follow these date-format discussions there). Personally, I don't use any of the auto edit programs, and I don't cover nearly as many articles as you do, but in my watch-list backyard, I do everything I can to maintain MDY/DMY date formats, and new ISO date format footnotes are conformed as soon as the diff pops up on my watch list. For the handful of articles that have an established ISO format for their footnotes, I leave them the way they are.
Part of what I object to most about ISO format dates is the creeping advocacy to use them elsewhere, and building a case for their use in templates, tables and text. ISO format dates are simply not an acceptable alternative in English language prose or most other mainstream English language situations. I cannot name a single mainstream English language publication that uses them. Attempts to justify the use of ISO format dates in English based on the supposed use of ISO computer-coded dates in foreign languages is illogical when there are two well-established, unambiguous, and mutually intelligible date formats already in predominant use. As I said above, there is no ambiguity in "31 December 2012" or December 31, 2012," and every literate person in the English-speaking world understands the exactly meaning of DMY and MDY dates. The use of ISO dates solves a non-existent problem and actually makes the date harder to understand for a substantial portion of our readers, which should hardly be surprising given that ISO dates are not the majority usage in any major national variety of English. Expanding the use of ISO dates beyond the areas where they are presently tolerated accomplishes nothing. Dirtlawyer1 (talk) 19:10, 13 June 2013 (UTC)
Basically, WP:IDONTLIKEIT? There is zero ambiguity in the ISO format from what we expect our readers to be able to understand. If you believe that readers may confuse ISO dates (something that is well standardized and effectively cannot be misinterpreted), then we better remove complex words and use Simple English for our articles too, because those also make the work harder for a substantial portion of our readers. Of course, that's a crap argument because we do assume our readers are educated and can understand high-school level English and related topics. --MASEM (t) 19:27, 13 June 2013 (UTC)
IDONTLIKEIT is too often used to disparage the argument of another editor with which the editor citing IDLI disagrees. Contrary to your assertion immediately above, no one teaches ISO format dates in North America high schools and universities outside of some sort of computer-programming or other tech-related class. So, yes, assuming that most native English-speaking people are familiar with ISO is a bad predicate upon which to base any support for the expanded use of ISO dates. Most English speakers are unfamiliar with ISO dates. If you have English language style guides that support the use of ISO format dates, I would love to see them quoted on point, but I'm pretty sure that I can find twenty or more style guides that don't support ISO computer-coded dates for every one that does. That there exist citation formats that use ISO dates means that we should tolerate them per CITEVAR when the ISO format references are the established consensus form of citation for a given article; it does not mean that we need to permit their willy-nilly expansion everywhere else. Dirtlawyer1 (talk) 20:06, 13 June 2013 (UTC)
I do note for the record that WP:CITEVAR generally approves of "imposing one style on an article with incompatible citation styles (e.g., some of the citations in footnotes and others as parenthetical references): an improvement because it makes the formatting consistent." — Preceding unsigned comment added by Dirtlawyer1 (talk • contribs)
Incorrect – only formats with the month written out (in short or in full and not in numbers) are truly 'zero ambiguity'. As has been already stated, 2013-06-12 is only zero ambiguity for those who are aware of the convention. Anecdotally, it's not unambiguous, and I keep on seeing incorrect variants on a daily basis. -- Ohc ¡digame!¿que pasa? 02:14, 14 June 2013 (UTC)
@DirtLawyer: "North America" is wrong in your comment above; "US" may well be true, but in Canada the ISO format is widely used in official forms (try filling in a customs declaration when you land, or giving your date of birth in a similar kind of form) and hence is taught in schools.
More generally, this has all been discussed before and the consensus was that because access and archive dates are not of equal importance to publication dates, they don't need spelling out in as long-winded a form as "10 December 2006"; "2006-12-10" is sufficient. I strongly support this view. Let's not have yet more instruction creep in the MOS, preventing what many editors think is a sensible use of ISO dates. Using ISO dates in text or tables is another matter. They should never be used in running text, and uses in sortable tables can be converted to {{dts}}. Peter coxhead (talk) 06:39, 14 June 2013 (UTC)
@Peter, my words were carefully chosen. I believe you will be hard pressed to find a Canadian style guide or English language text book that explains the use of ISO dates and promotes their use in Canadian publications and everyday writing. Yes, I readily acknowledge your previous statement that the Canadian government uses ISO dates. Do you acknowledge that the majority of Canadian writers and publications do not use ISO dates in daily life? The ISO date format is tech speak that is mostly used for the convenience of database data entry and programming convenience. Used almost anywhere else, it is usually inappropriate "geek speak." In the United States, the U.S. military routinely uses DMY dates, and I have seen recent computer-generated correspondence from the Internal Revenue Service that uses ISO format dates. That does not mean that ISO format dates are common or readily understood by the majority of the American population, nor does it mean that DMY dates are a commonly accepted format among American civilian publications, either.
As you know from our previous MOS talk discussions, I am not a fan of MOS instruction creep, either. In this case, what I am advocating is not the prohibition of ISO format dates (outside of text, where they are inappropriate abbreviations, as are any other all-number date formats, and area already banned by MOS), but their limitation to use in references when that is the established, consensus style used within given articles per CITEVAR. As described by OhConfucius and others, ISO advocates should not be able to effectively force style changes incorporating ISO dates based on the careless drive-by reference/citation/footnote edits by auto editors who are making changes without regard to the established date and reference styles of an article.
As for the logic of using MDY/DMY dates for publication dates and ISO dates for retrieval dates based on their perceived relative importance, I think such a justification is merely a rationale for keeping ISO dates in some form or fashion. If there is an established citation format that is being used that employs ISO format dates, that's fine per CITEVAR. If the insertion of ISO dates for retrieval dates is based merely on personal preference, or the perceived lesser importance of retrieval dates vis a vis publication dates, that strikes me as incompatible with MOS's basic principle of internal article consistency. Dirtlawyer1 (talk) 16:08, 14 June 2013 (UTC)
As described by OhConfucius and others, ISO advocates should not be able to effectively force style changes incorporating ISO dates based on the careless drive-by reference/citation/footnote edits by auto editors who are making changes without regard to the established date and reference styles of an article. This is what CITEVAR already says. Editors that are "drive by" dropping refs and intentionally forcing ISO are just as bad as when OC and others were forcing date changes prior to the Arbcom cases and subsequent resolution - neither approach is tolerated. The key word however, is intentionally. There is big difference when an established editor adds a few references but accidentally using ISO formats when the rest of the article's refs uses dmy/mdy, and someone that submarines in these refs for the purpose of later say "oh, but most of the refs use ISO, therefore we must use ISO." The problem is that that difference is nearly impossible to tell with good faith assumptions; only by repeat behavior can it be spotted. (And I will also argue that the same point I made above: it's not ISO that is the problem, it is the allowance we have for multiple date and citation styles that creates this situation; ISO is just being used as a scapegoat here). There is no need to make change to MOS or policy, only to enforce behavioral approaches when an editor is discovered forcing refs into one format or another without prior consensus. --MASEM (t) 16:31, 14 June 2013 (UTC)
Yes, I know what CITEVAR states, Masem, but in several places above you have softened the explicit message of CITEVAR. Let's be perfectly clear. Established reference and date formats should be honored. Furthermore, there is absolutely nothing wrong with enforcing those established citation and date formats per the express language of CITEVAR, and where there never was an established citation/date format it expressly recognizes that establishing consistency is considered to be an improvement. As for your comment above, that I am emphasizing consistency in formatting at the expense of content improvement, I would assert I am doing no such thing and put forward my strong personal track record of content creation, expansion and improvement. Properly understood, well-written content goes hand-in-hand with consistency in style and formatting. Poorly written, poorly maintained and poorly formatted articles attract more than their share of cruft, vandalism and RS and BLP violations, and inevitably become the battleground over which auto edits play themselves out. As for the auto editors who cannot be bothered to make an effort to determine the existing citation and date formats, perhaps they should not be using an auto editor program. Again, the real problem is not rookies, but editors who have enough experience to be making mass edits with an auto editor program. No reasonable editor, myself included, faults a newbie for making a good-faith attempt at improving anything.
And, yes, there are editors who do have an ISO advocacy agenda, and several of them have hinted as much in this thread. (E.g., please see IP user's comment below.) Perhaps the ISO date format is a "scapegoat" as you suggest, but discussions such as this one do clarify that its uses are limited and agenda-pushing will not be tolerated.
Oh, and by the way, I would like to see a link or other reference to a real world citation format that uses DMY/MDY dates for publication dates, and ISO dates for retrieval dates, or otherwise mixes date formats. Can you provide one or more such references? If such exist, it would be interesting to see if such mixed-date citation formats are actually being used in the articles that have ISO dates in their references. I strongly suspect that most of this mixed-date business really occurs simply as the result of default settings in the auto editor programs, not because most of the auto editors are attempting to adhere to a given reference style. Dirtlawyer1 (talk) 17:20, 14 June 2013 (UTC)
The way you are expressing "inconsistent formatting of citations will not be tolerated" is what worries me. You're throwing bad faith that editors that put in the wrong citation format on an article are being purposely disruptive. Since fixing citations is simple, it should not be an issue to get all up in arms over, compared to having articles that lack content. I personally haven't used an auto program to add citations (AWB for other things) so I don't know if editors have a choice to work around that, but again, this is point too much emphasis on the formatting and less over the contributions. The latter is the most important part as that's the hard work to find and summarize sources, and to pish-posh the contribution because they use the wrong format is absolutely the wrong attitude that you are seeming to present here. And of course, auto-editor programs are likely not going to be able to handle different citation styles that fall outside the cite templates or harvard, but that's no reason to abandon them. I stress this point: we are not losing readers because our citations may be inconsistent. It's a nice feature to have but not at the cost of penaltizing editors or tools that are helping to add content. The MOS is just a guideline, that's key.
As of cite formats that use a mix if dmy/mdy and ISO, I'm not aware (it's one date style through the citation fields consistently, not the mix within a single citation). That said I have run into situations where I'm citing a magazine that posts content online but only ascribes it to a month or bi-monthyl period, where the article is otherwise presently in ISO. I have to use date = Month Year alongside accessdate = YYYY-MM-DD as there's no ISO equivalent of the former. --MASEM (t) 17:36, 14 June 2013 (UTC)
WP:CITEVAR states: "Editors should not attempt to change an article's established citation style merely on the grounds of personal preference". It further suggests that citation style be defined as parenthetical, <ref> tags or the "style preferred by an academic discipline". I have heard CITEVAR used as an argument for retaining year month date style dates (e.g. "(2013 June 14)") – that MOSNUM already implicitly rejects. So I guess CITEVAR could be one facet of the problem. -- Ohc ¡digame!¿que pasa? 17:45, 14 June 2013 (UTC)
Basically what that suggests to me is that CITEVAR and this MOS need to work together to say what the bounds are for staying true to an academic style so there's consistency between these two pages. It should just be a matter of clarification - such as that regardless what date format a certain field may use, the date needs to be kept in one of the accepted formats listed at MOSNUM. That is, even if every paper in a specific field uses YYYY Month DD, we would want it changed to one of the three to avoid that confusion. However, if it is the intent of CITEVAR that the date format must stay true to the work, then MOSNUM needs to be fixed in dealing with dates on references because that is inconsistent. --MASEM (t) 17:54, 14 June 2013 (UTC)

Masem, as for "there's no ISO equivalent of the former" [year and month], there IS an ISO 8601 expression for that, YYYY-MM. But that is not allowed in Wikipedia because it might be confused with a year range, such as 2008-12 possibly meaning 2008 to 2012.

As for real world examples of mixed date formats consider this from pg 200 of the APA manual (6th ed.)

  • Schwart, J. (1993, September 30). Obesity affects economic, social status. The Washington Post, pp. A1, A4.

Obviously dates in the running text would use a more conventional format, although the manual doesn't seem to say which format. Jc3s5h (talk) 17:58, 14 June 2013 (UTC)

N things:
  1. Wikipedia should be an initiative.
    1. The reason why people find YYYY-MM-DD hard-to-read is because they're not used to it.
    2. An internationally standard format has been proposed for multiple reasons:
      • The diversity of (short versions of) formats led to confusion.
      • There is some benefit in dates being interchangable between different languages.
    3. If a considerable portion of people switches to a common, standardized format, then that will be beneficial for those people in the long run, but at the expense of a required one-time learning.
    4. It is understood that, in case of multiple independent groups that could switch to a standardized format, the first group to switch (independently, likely alone) would experience the most deficit, until a considerable portion has also switched, at which point sticking to an old format would be arguably relatively detrimental. However, if everyone concentrated only on short-term goals, then a global switch will never occur.
    5. A general goal of Wikipedia is to support humanity (in some way related to information spreading) without aiming for profit, so I propose that Wikipedia be an initiative in switching to a standardized format.
  2. A switch need not be significantly radical. Beginning with small changes — for example, first permitting the standardized format in certain places, then (upon "ripeness") enforcing it there, then extending such a policy to other places, and so on — sounds like a plausible route.
  3. As a somewhat analogous example, the romans used fancy numerals to describe numbers, but that convention was eventually superseded. — Preceding unsigned comment added by 78.92.209.87 (talk) 09:52, 14 June 2013 (UTC)
  • IP user:78.92.209.87, please review WP:GREATWRONGS. Wikipedia does not exist to fix anything; it is an encyclopedia that is supposed to chronicle the world as it exists, not as some of our editors wish it to be. Wikipedia does not have an "agenda" in promoting changes to the English language, writing styles, vocabulary, punctuation, or formatting. Editors who bring such agendas with them, and attempt to enforce them through changes to the Manual of Style, are one of the primary sources of conflict on these MOS talk pages. Dirtlawyer1 (talk) 16:08, 14 June 2013 (UTC)
  • Neither does Wikipedia have an "agenda" against promoting such changes. In case of strongly advocated, incompatible opinions, something must be chosen, by weighing reasons and supporters. For example, logical quotation makes more sense, but is less popular; in this case, Wikipedia decided to go with logical quotation.
  • I vote and reason for using YYYY-MM-DD literally everywhere (as described above). I understand that this will partially be voted down, but regardless, I try to convince people otherwise.
  • Yes, there are conflicts on these pages. And that's good. It's good that the editors discuss opinions and reasonings here, rather than ignorantly acting against the MOS. — Preceding unsigned comment added by 81.182.28.119 (talk) 23:18, 14 June 2013 (UTC)
  • Wikipedia doesn't have an "agenda" against promoting change, no, but that's not the point. This is simply not the business of WP. Our use of logical quotation is a completely different issue. WP is not pushing LQ but just using it as a means of avoiding ambiguity.
  • People find YYYY-MM-DD hard to read because we're not used to it, yes, and since we find it hard to read it's better to avoid it. Again, we're not in the business of getting people used to it.
  • We should avoid confusing date formats, yes, in English the best way to do this is to avoid all-numeric dates. ISO dates are technically unambiguous: noone who is familiar with them will get years, months or days muddled up. The thing is that people still do get muddled and confused (as has been demonstrated) because they are unfamiliar with it.
  • Canadians may make some use of YYYY-MM-DD (I've also seen it on cheques) but it's limited; the overwhelmingly popular formats used in Canada are dmy & mdy. As for what formats are common in non-English speaking countries, this is of zero relevance.
  • There may be some benefit in dates' being interchangable between different languages. Yes, but it doesn't much apply here on the English Wikipedia. Translation for other Wikipedias is of no import: this is generally a once-off thing with any dates being only a very small and a very easy-to-translate part of an article (primary school kids and even autotranslators can easily translate a dmy or mdy date from English).
  • In the body of the article only dmy or mdy are permitted. Why allow inconsistency by letting telephone number dates into the refs?
  • CITEVAR, it has been argued, allows for freedom with respect to citation style. This, it is noted, includes the freedom to use YYYY-MM-DD dates. This can't be changed (so my reading of the argument goes) because there are people out there who actually use it. Here's the specific guideline.

    Although nearly any consistent style may be used, avoid all-numeric date formats other than YYYY-MM-DD, because of the ambiguity concerning which number is the month and which the day. For example, 2002-06-11 may be used, but not 11/06/2002. The YYYY-MM-DD format should in any case be limited to Gregorian calendar dates where the year is after 1582.

    DD/MM/YYYY and MM/DD/YYYY are ruled out a priori regardless of whether or not people out there actually use it. Any reference style out there which uses DD/MM/YYYY or MM/DD/YYYY would have to be modified before we'd allow it on WP. Why then, in principle, could CITEVAR not simply rule out all all-numeric date formats? I say it could. The revised wording could go something like this.

    Although nearly any consistent style may be used, avoid all-numeric date formats, such formats may be unfamiliar or ambiguous. For example, 11/06/2002 may not be used because of the ambiguity concerning which number is the month and which the day; 2002-06-11, on the other hand, should also be avoided because unfamiliarity makes YYYY-MM-DD harder to parse and prone to error.

    Whilst the case against YYYY-MM-DD may not be as strong as that against DD/MM/YYYY and MM/DD/YYYY, I see it as strong enough to ditch this format once and for all. What about the case for YYYY-MM-DD ... what case?

JIMp talk·cont 07:58, 15 June 2013 (UTC)

What is the disagreement?

It seems to me that much of the debate here is just "I don't like it" versus "I do like it." On the substantive issues I don't see that much disagreement. My hopefully not too biassed summary is:

  • Debate in the wrong place In citations, ISO dates should be restricted to access and archive dates as explicitly allowed in WP:CITEVAR. Those who want a change to get rid of ISO dates altogether should be discussing it there, not here.
  • Consensus Citation styles should be consistent within an article. If the article uses the same style consistently for all dates in citations, and this matches the style in the text, the style should not be changed. If the article consistently uses ISO dates in access and archive dates in citations, and another consistent style for all other dates, this should not be changed.
  • Consensus ISO dates should not be used in running text.
  • New proposal ISO dates in tables are a useful initial step for editors wanting to make the table sortable, particularly for inexperienced editors not familiar with using templates, but changing ISO dates to use one of the "dts" templates should be allowed.

Could we perhaps focus on the last point, where it might be possible to reach a conclusion and make a change? Peter coxhead (talk) 05:41, 15 June 2013 (UTC)

Much of the argument may be based on personal preference but I don't think all.
  • Yes, I agree that this debate as to whether YYYY-MM-DD dates should be allowed in ref should be moved to the CITEVAR talk page.
  • Yes, I agree that there is consensus that citation styles should be consistent within an article. There is also consensus that if all dates (in the text & refs) are dmy or mdy they should not be changed. I do not agree that there is consensus that ISO dates should be allowed at all.
  • Yes, I agree that there is consensus that ISO dates should not be used in text.
  • I oppose the use of ISO dates in tables. Using {{dts}} is easy compared to creating a sortable table. If we start allowing ISO dates (even though we say that they're only temporary) in tables, people will begin to think that these are the norm, the cat will be out of the bag and their use may easily spread, a couple of years down the track we'll be debating whether to allow them permanently in any table sortable or not. This thin edge of the wedge is worse than any potential sorting malfunction ... but wait, is there any potential sorting malfunction any more? I'm not involved in the development of sort tables but I have been noticing improvements in their function. Haven't they already dealt with this? Isn't {{dts}} already redundant?
JIMp talk·cont 07:58, 15 June 2013 (UTC)
To clarify, I wasn't proposing allowing ISO dates in tables, merely noting that we shouldn't jump on editors who use them because of sorting, whether this is needed or not, but should agree that they can be changed.
As for consensus, there has been consensus at WP:CITEVAR that ISO dates are allowed in access and archive dates. What the consensus is here is not relevant. If you want a change, go there and try to achieve it. Peter coxhead (talk) 08:48, 15 June 2013 (UTC)
Okay, no jumping on editors for putting ISO dates in the wrong place, just tidy up after them, fair enough, but I don't think we need anything saying so for this specific case, it's a general rule that we don't go round punishing people for good faith edits.
There is no consensus here as to whether ISO dates should be accepted but the debate belongs elsewhere, like you say. I was talking about consensus amongst the users participating in this discussion. You were talking about consensus at the talk page where the discussion belongs. We're not really contradicting each other just meaning different things.
JIMp talk·cont 07:29, 16 June 2013 (UTC)
On that we can definitely agree! Peter coxhead (talk) 10:21, 16 June 2013 (UTC)
  • There's little doubt for me "Retrieved 15 November 2011" can be written "Retrieved 2011-11-15" without people batting an eyelid as to whether it's prose or not. But would any of you consider the following to be prose?

    Archived from the original on 15 November 2011.

    -- Ohc ¡digame!¿que pasa? 12:26, 16 June 2013 (UTC)
As for "Citation styles should be consistent within an article. If the article uses the same style consistently for all dates in citations, and this matches the style in the text, the style should not be changed", I think the proper forum is WP:CITE and the consensus is that if citation dates consistently follow a certain format, that format should be maintained, even if it differs from the format in running text. An example is APA style which would use "2013, June 19" for the publication date for something published today, even though some other format would be used in the article text for that style. Jc3s5h (talk) 11:52, 19 June 2013 (UTC)

In tables

It seems we can't agree on whether to allow YYYY-MM-DD in refs but I don't think anyone is advocating allowing it in tables. Surely there is no reason to have YYYY-MM-DD dates in a table (except hidden e.g. for sorting like {{dts}} does). Even the proponents of YYYY-MM-DD in the discussion above seem (to me) to agree that it has no place in tables. However, parts of the guideline (still?) allow it. Is this an oversight? Can we agree to remove this? Jimp 03:24, 30 June 2013 (UTC)

  • No question that this needs to be removed. Nobody ever objects to them being wrapped in dts templates. -- Ohc ¡digame!¿que pasa? 05:03, 30 June 2013 (UTC)

RFC: punctuation when quoting

Friends, an RFC has been started to settle issues of punctuation around text in quotation marks. Keep WP:LQ as it is, or allow alternatives? Tony (talk) 09:24, 30 June 2013 (UTC)

Titles usd instead of names, and wp:dated

I think this belongs somewhere (unless already there and I've missed it). It's appropriate to the shortcut WP:dated but not to Wikipedia:Manual of Style/Dates and numbers. Does anybody have any suggestions where to put it, or disagree with the content? It's not really MOS:HONORIFIC.

Suggested addition to MOS:
In relation to people who are often referred to only by their title, which may be assumed by later incumbents, the text should clearly indicate the particular incumbent unless it is clear that the holder at the time of events described is meant. For example, it is common in Britain to refer to Charles, Prince of Wales as "The Prince of Wales", and Wikipedia articles about current matters sometimes have this usage (often with a piped link [[Charles, Prince of Wales|The Prince of Wales]]). In the foreseeable future "The (current) Prince of Wales" will be "William, Prince of Wales", and articles will become misleading. This is less problematical in articles dealing with the more distant past. Pol098 (talk) 15:31, 10 July 2013 (UTC)

Uncertainty

It seems that the formats "value ± uncertainty × 10n unit" (especially the "do not group" phrase) and "value ± percent unit" contradict the ISO/IEC and NIST rules. Where they come from, and what is the reason to use them instead of the accepted standards? — Mikhail Ryazanov (talk) 01:17, 13 July 2013 (UTC)

Non-breaking spaces in mixed numbers

MOS:FRAC gives this example of correct usage for a mixed number (integer + proper fraction) when using imperial measurements: 5 1/4 inches.

The example uses a space between the integer and fraction, which means that they can wrap over the end of the line (as it did on my screen). Surely a non-breaking space (&nbsp;) should be used? (It does use a non-breaking space between the fraction and "inches".)

Not sure whether or not this also needs to be explicitly stated as a rule. —sroc (talk) 11:07, 2 July 2013 (UTC)

I agree that any space should be non-breaking. I'm not really convinced that there should be a space there at all though. I'd rather the space be eliminated (or if we must have one, that it be a thin space). Jimp 04:11, 3 July 2013 (UTC)
Yes, good point. Not sure whether there is any particular consensus on this. For the time being, I will be bold and simply remove the space in the example but not make any further comment. If necessary, someone can push for some particular standard (no space, thin space, non-breaking space) to be specified for consistency. —sroc (talk) 09:59, 3 July 2013 (UTC)
Actually, having done this, it does appear that some space is needed when using a slash as in the example. For some reason, the example uses manual formatting instead of the templates provided. Interestingly, the templates themselves use different spacing.
This table may change over time by added examples and tests
Format Code Output Copy-paste*
(from Firefox,
via Notebook++) 		Copy-paste**
(from Firefox) 		Copy-paste***
(from Safari 5.1.6)
No space 5<sup>1</sup>/<sub>4</sub> 51/4 51/4 51/4 51/4
Thin space 5&thinsp;<sup>1</sup>/<sub>4</sub> 5 1/4 5?1/4 5 1/4 5 1/4
Non-breaking space 5&nbsp;<sup>1</sup>/<sub>4</sub> 5 1/4 5 1/4 5 1/4 5 1/4
Non-breaking space in superscript 5<sup>&nbsp;1</sup>/<sub>4</sub> 5 1/4 5 1/4 5 1/4 5 1/4
Non-breaking thin space 5&#8239;<sup>1</sup>/<sub>4</sub> 5 1/4 5?1/4 5 1/4 5 1/4
Zero-width space
(U+200B ZERO WIDTH SPACE) 		5&#x200B;<sup>1</sup>/<sub>4</sub> 5​1/4 5?1/4 5​1/4 5​1/4
Hidden "+" sign
(U+2064 INVISIBLE PLUS) 		5&#x2064;<sup>1</sup>/<sub>4</sub> 5⁤1/4 5?1/4 5⁤1/4 5⁤1/4
{{frac}} {{frac|5|1|4}} 5+1⁄4 5 1/4 5 1⁄4 5 1⁄4
{{sfrac}} {{sfrac|5|1|4}}} 5+1/4 514 514 5
1
4
* Copy-pasted from Firefox 22 page into Notebook++, that (ASCII) result copied back here. Added red/green code.
** Copy-pasted from Firefox 22 page into WP edit source window here. Added red/green code.
*** Copy-pasted from Safari page into wp edit source window here, replaced line breaks, added red/green mark-up.
Note that the thin space does allow wrapping at the end of lines, so this would not overcome the initial problem where the integer is separated from the fraction. —sroc (talk) 10:26, 3 July 2013 (UTC)
So you have removed that space in the MOS [3] (be it nonbreaking or not). That was not what the OP is about! And aside from consensus, I request consistency. As it is now, existing {{frac}} does not comply with this MOS. Frac (still) adds a space: 5+1⁄4. Since I want to use this outcome, I'd ask how to get at a consistent MOS in this. (As for the NBSP: yes I say).
Why am I here? I happen to be very interested in this, coming from {{RailGauge}}, because this space is an issue (when using inches). If this topic section did not exist, I'd have started one. We want to have the inches-part (some 200 options Atre in view) to be correct. Now what to do? At least we should ask people who know about imperial (inches) formats. -DePiep (talk) 20:00, 8 July 2013 (UTC)
I have added a non breaking thin space to the table. Vegaswikian (talk) 20:28, 8 July 2013 (UTC)
Thanks, Vegaswikian. I wasn't sure how to do that! —sroc (talk) 00:44, 9 July 2013 (UTC)
My concern is about the MOS to apply: will {{frac}} be changed? It looks a bit speedy to me. -DePiep (talk) 20:41, 8 July 2013 (UTC)
Yes, there is inconsistency between {{frac}} (which uses a space) and {{sfrac}} (which has no space). I adopted no-space format in the manually formatted example in the MOS just to avoid the line break, but it could be replaced with a non-breaking space or non-breaking thin space depending on consensus. I agree that {{frac}} and {{sfrac}} should be amended to conform unless there is good reason otherwise. Stylistically, I would prefer a non-breaking thin space, but I don't know which is correct. —sroc (talk) 00:44, 9 July 2013 (UTC)
Actually, this has been discussed in detail — see Template talk:Frac#Spacing. Evidently a space (of some kind) is needed to preserve the fraction in the case of copy-pasting. —sroc (talk) 00:50, 9 July 2013 (UTC)
To some extent, this is the opposite of what's needed in {{gaps}}—there, the gaps aren't HTML entities at all, they're CSS, so you don't have parse them out when pasting data. In {{frac}}, you need something to indicate where the parts of the fraction begin and end. You could replace it with a hidden plus sign (that appears when copied, to make it mathematically unambiguous), but that might look unusual (though comprehensible). The non-breaking thin space is great typographically, but might not be supported by some browsers. (I'm not up to date on what browser versions en.wikipedia is targeting these days, so maybe this is a non-issue.) You might consider white-space: nowrap CSS, with a conventional thin space, if that is more compatible among browsers. TheFeds 04:16, 9 July 2013 (UTC)
A lot of earlier talks to be read. Thanks.
Re the Original Question: indeed, we never allow a line break within a number. End of story.
Remaining: copy-paste effect? Added the "invisible plus" character, as discussed earlier. I have performed a c/p from Firefox, and added to the table. It looks this basic check (even before EI) rules out some options. Maybe {{sfrac}} needs a review for this.
Remaining: add space or not? The thin spaces are ruled out for the bad c/p effect. Then, I get the impression that the reasons to add a space are: for the c/p effect and maybe for the accessability (reading the fraction). So: not for the number itself (see earlier linked talks). Am I correct in this? -DePiep (talk) 06:41, 9 July 2013 (UTC)
Added to the table: zero-width space. Does not do well in c/p. -DePiep (talk) 06:53, 9 July 2013 (UTC)
One other quirk I just thought of: even if you do get a plus sign in the pasted version, you'd also want brackets to preserve order of operations when pasting into something with an adjacent multiplication. That's getting uglier and uglier, for the user who doesn't care about math, and just wants to paste the article. TheFeds 07:37, 9 July 2013 (UTC)
Yes. I only added the invisible plus for completeness: it was discussed & tried earlier on. I also found out that {sfrac} uses CSS display:none &tc. to squeeze in a regular nbsp and / (slash) sign for c/p. But it does not show in my Ff copy/paste test. I tend to conclude that for wp:accessability and c/p we should add a regular space (nbsp); also in {sfrac}. -DePiep (talk) 07:45, 9 July 2013 (UTC)
No not in {sfrac} because it would not work and does not have the access (in line readability) problem. -DePiep (talk) 07:47, 9 July 2013 (UTC)
Added to the table: copy-paste test in Safari. —sroc (talk) 09:07, 9 July 2013 (UTC)
FYI, {{frac}} places a nbsp in superscript before the numerator, so it's smaller than a regularly-formatted space but should not have any impact on accessibility or copy-paste functionality (although my test in Safari suggests otherwise). —sroc (talk) 09:10, 9 July 2013 (UTC)
If it were an issue (what's that in your Safari?), we could propose a change in the code (plain space, not within <sup> tags).
Added to the table: use of nbsp in superscript. Copy-paste tests well in Firefox and Safari. Looks better than {{frac}} (which uses a fraction glyph rather than a slash) when copied from Safari. —sroc (talk) 09:20, 9 July 2013 (UTC)
@DePiep, could you elaborate on why {{sfrac}} "would not work" with a nbsp and why it "does not have the access (in line readability) problem"? It does indeed seem to have copy-paste issues as shown in the table above. I've read through the discussion at Template talk:Frac but don't understand why this is inconsistent with {{frac}} unless it is purely readability. Just curious. Thanks! —sroc (talk) 09:35, 9 July 2013 (UTC)
About adding a space to {sfrac}, I'll be explicit. 1. It does not work w.r.t. the copy/paste requirement: even if the space would c/p well, the slash does not appear. For 5+1/4: instead of 514 (example from the table) we would start with 5 +1/4 and end up the c/p with 5 14, which is still an incorrect number. The slash problem is not solved. 2. IMO adding a space is not needed for WP:ACCESS (accessability): the horizontal bar makes clear reading from the start. (While, OTOH, in {frac} it does help separate the more confusing numbers in 51/4, when reading plain Wikipage inline text: the visual distiction between "5" and "1" may be quite unclear with some browsers or readers). Concluding: by themselves: {{frac}} needs the space (and does c/p OK), {{sfrac}} does not need the space (and will c/p not OK either way). Now for consistency over the two (and into general MOS description?), we could add the space to {sfrac}, without introducing an issue. -DePiep (talk) 11:03, 9 July 2013 (UTC)
Thanks! Very clear. On reflection, it seems that the inconsistency is reasonable on the basis that a space technically does not belong there (hence the preference to omit it from {{sfrac}}) but is necessary in {{frac}} for visual accessibility and technical (copy/paste) reasons. Do you agree? —sroc (talk) 12:18, 9 July 2013 (UTC)
I agree. But purists might argue against it. (Leaving this issue unresolved, or changing one of the two templates in this. My money is on the stalling). -DePiep (talk) 18:47, 11 July 2013 (UTC)
re copy/paste test: indeed, the results are better when copied into the WP edit box (not into the more flat Notebook++ as I did). Hof far does the c/p requirement reach? (how is the requirement defined?). If it is the tough rule (check via some Notebook), we'll probably end up with full space (nbsp). -DePiep (talk) 11:12, 9 July 2013 (UTC)
I would think the aim should be for copy/paste to be as compatible with as many targets as possible. I'm not familiar with Notebook++ — does it handle text in an unusual way? Why might it treat it so differently from pasting into the edit window? Or is it because I'm on a Mac and our systems just format copy/paste differently? In any case, I think we should aim to make it as compatible as possible, and {{frac}} seems to do the best job of this from the (only two) samples we've done — and presumably based on the collective research that goes into maintaining the template.
This may all be moot anyway — I only raised this from one isolated example in the MOS that (for some reason) uses plain text instead of using a template at all. It would be better if everyone just used the templates so they can uniformly use the best format as technology allows. —sroc (talk) 12:18, 9 July 2013 (UTC)
Notebook++ is a simple text editor (open source, much like the MS Office Notebook program or out WP source text editor). e.g., it does not save any layout in a file. The tests show it does not recognise or use the two thinspace characters that we used there. I do not know whether this would be prohibiting (forbit the use of thinspace), I don't know the reach of "keep it in copy/paste" requirement. Maybe we'll have to visit this issue later on.
About being moot: this is the MOS, so this should dictate handwritten text and templates. Only external limits (like browser issues) could force the MOS. -DePiep (talk) 18:47, 11 July 2013 (UTC)
Re C&P, one could add spreadsheet (Excel …) paste compatibility as a requirement or at least as a plus point. 2A02:908:F322:1980:A8A9:2ADC:BD7A:F323 (talk) 22:48, 11 July 2013 (UTC)

Convert doesn't give you a space: {{convert}} gives 1+1⁄2 miles (2.4 km) whereas {{frac}} gives 1+1⁄2, making articles that use both look inconsistent. Edgepedia (talk) 16:44, 16 July 2013 (UTC)

Then shouldn't {{convert}} be updated to use the {{frac}} template for such output so that it is (and remains) consistent? —sroc (talk) 23:49, 16 July 2013 (UTC)
Added a comment at Template talk:Convert#Formatting_fractions. —sroc (talk) 23:56, 16 July 2013 (UTC)
In light of all the above, returning to the genesis of this thread, there does not seem to be any reason why MOS:FRAC formats fractions using hard-coded HTML tags, so I'm converting them to the {{frac}} as appropriate. If anyone disagrees that this is the right thing to do (i.e., if I have the wrong end of the stick), please feel free to revert and discuss further here. —sroc 💬 13:20, 22 July 2013 (UTC)

Ugly fractions

  • While we're at it on fractions, is there ever going to be pressure put on the vasty expanded WMF tech department to give us fractions that don't look ugly in the run of the text? Tony (talk) 15:22, 10 July 2013 (UTC)
Tony, I have separated your question from the earlier discussion because to me it reads like a different topic. I have no opinion on the uglyness, however the readability is highly relevant (See also WP:ACCESS). -DePiep (talk) 18:54, 11 July 2013 (UTC)

Negative currency amounts?

The section on currency formatting is extensive, but says nothing about negatives.

For example, is it -$9.99 or $-9.99 commonly, and are there local specific exceptions?

140.168.78.24 (talk) 05:21, 23 July 2013 (UTC)

Good question. I've never understood the −$9.99 format. I see the $ as akin to a unit that should go outside the number (including the minus sign), so $−9.99 and not −$9.99, but I'm sure someone will disagree (and hopefully explain why). —sroc 💬 05:49, 23 July 2013 (UTC)

Converting regnal dates

MOS:DOB specifies that when dates of birth and death are known only approximately we use {{circa}}. One example of this would be when a date is converted (per WP:CALC) from a regnal year that's shown in a source. Unless the source specifies the exact date (day, month) this almost invariably leads to two consecutive years being possible. For example a death recorded as occurring in the regnal year "1 Henry VII" (being the 1st year of the reign of English king, Henry VII who reigned from 22 August 1485) could equally well have occurred in 1485 or 1486. We can't tell.

Since we know the date only approximately, MOS:DOB indicates that we should record it as c. 1485 (or c. 1486), but this does not impart the maximum amount of information that is available, and gives an inaccurate impression of the uncertainty. We could decide instead to record it as just the first year (or the second?), in which case information is lost and it will be wrong 50% of the time.

I propose an addition to MOS:DOB that specifies that we should use the format 1485/6 when conversions from regnal years have been employed. This format is as precise as it can be, it indicates to those in the know that such a conversion has taken place, and it would indicate to everyone else that it's some sort of special case. I believe this convention is already widely used outside WP – see this online calculator for instance.

There has been some recent discussion of this at the No original research noticeboard.  —SMALLJIM  09:26, 10 July 2013 (UTC)

And, as pointed out there, it's a very common problem with more recent people where the source is a dated news article or obit which gives the age in years, so the birth date is definitely one of two adjacent years - again, "c. 1913" is less informative than "1912 or 1913", for someone whose obit today says "died aged 100". I'd like to see an established convention for how to quote dates like this. PamD 09:54, 10 July 2013 (UTC)
This also comes up when a source dates an event with an AH date and the year in AD or CE form needs to be added.SchreiberBike talk 20:38, 10 July 2013 (UTC)
Yes, it must occur whenever dates are converted between systems that don't start on the same day of the year. Would adopting a 1912/3 type format cause any problems – could its meaning be confused with anything else? There are display issues to determine: at decades it would have to be 1919/20 because 1919/0 looks like an error, even though it makes sense once the principle is understood. Even 1799/800 looks odd and would probably keep getting changed to 1799/1800. Another compact format that would work would be 1799+1, (using the same principle as ±), though that looks so unfamiliar it would never take off. Just brainstorming here, really. —SMALLJIM  08:37, 11 July 2013 (UTC)
This doesn't come up often, but I think what I've done is to say 1912 or 1913. When it's accompanied by an AH date or a regnal year, I would think most readers would understand the meaning immediately. Use of a slash would cause confusion with the existing rule "2005/06 may be used to signify a period of 12 or fewer months". Let's keep throwing out ideas. SchreiberBike talk 18:16, 11 July 2013 (UTC)
The other problem with the slash notation is that it could be confused with YYYY/MM date notation, and we don't want to get involved in that perpetual controversy. I like using "or" for this situation, but in some situations a footnote might be in order.

The ± conventions are understood a little differently in different contexts: as an engineering tolerance, you might say 1000 ± 1 = 1000 +1/-1 ≠ 999 +2/-0, even though as a year range, they're the same. (Also note that the zero side is nevertheless indicated.) We should be rigourous if we borrow a ± from somewhere, but I don't think it's necessarily ideal. TheFeds 07:34, 12 July 2013 (UTC)

  • It sounds as if "or" is the most widely acceptable format: perhaps we should add it to MOS:DOB. Something on the lines of:
  • When a date is known to be one of two years (eg from a regnal or AH year, or a known age at death), use "or": "Anne Smith (1912 or 1913 - 2013)"
to be added after the "known only approximately" example of John Sayer.

PamD 23:28, 15 July 2013 (UTC)

I can see that "or" is the only option so far expressed that's likely to take root, and it's probably fine when just one date needs to be shown, such as: He died in 1485 or 1486. But as you've shown it above – with both birth and death dates – it compels a second look to ensure that one has understood it correctly, and a nitpicker could claim that it could be mis-parsed as "(1912) or (1913–2013)".
Anne Smith (born 1912 or 1913; died 2013) would actually read better. I see that this is not an easy problem to solve: perhaps that's why it's never been codified.  —SMALLJIM  17:35, 16 July 2013 (UTC)
Good point, but surely it can't be beyond the wit of us all to find a solution! Yours may be it, but how does that translate to, for example, her dates when listed in a dab page? To convert to either "c.1912" or "c.1913" is wasteful when we know exactly that she was born in 1912 or 1913 because her obituary said she died in July 2013 aged 100 (in this fictional example). PamD 20:13, 16 July 2013 (UTC)
So I don't shoot off at a tangent when replying, can you clarify what you mean by "yours" (the 1485/6 notation or the born;died one?), and, forgive my ignorance, but why are dab pages different?  —SMALLJIM  20:41, 16 July 2013 (UTC)
Sorry for the ambiguity: I meant to support "born 1912 or 1913; died 2013" in article leads and other contexts, but I'm not sure it would sit comfortably in among the so much shorter (born 1952) and (1812-1899) etc dates in a list such as Anne Smith (disambiguation).
On the Anne Smith (disambiguation) page I'd be comfortable with (c. 1912–2013). It's accurate and gives sufficient information to disambiguate which Anne Smith is being referred to. Then on Anne Smith's actual page, "born 1912 or 1913; died 2013" in the lead as above.SchreiberBike talk 23:41, 16 July 2013 (UTC)
Thanks for that, PamD. Although I suggested it, I'm not really sure if a format like Anne Smith (born 1912 or 1913; died 2013) would be accepted in the lead since it's so different from all the others at MOS:DOB, i.e. there's no en-dash. What do others think?
Regarding a dab page entry, I'd have thought that Anne Smith, died aged 100 in 2013 would best convey the relevant info if the age is the important factor; if it isn't then Anne Smith (died 2013), ... would be sufficient – a case for IAR perhaps. And maybe that provides another suggestion for the lead: Anne Smith (died aged 100 in 2013), followed up in the text by Anne Smith was born in 1912 or 1913 ...? It would at least avoid those rather unsightly three years in the brackets.  —SMALLJIM  23:50, 16 July 2013 (UTC)
Well, no further comments after a week and the three of us would accept Anne Smith (born 1912 or 1913; died 2013) for the lead in the uncommon cases where this would be necessary. With over 500 page watchers here, it sounds like "silence implies consent" and maybe we can claim to have consensus. Any dissenters?  —SMALLJIM  11:29, 23 July 2013 (UTC)
Silence. I've added a new bullet to MOS:DOB as above. If reverting, please continue discussion here. —SMALLJIM  10:29, 2 August 2013 (UTC)

There is another problem with using a slash for year dates in England before the implementation of the Calendar (New Style) Act 1750 in 1752. If the year is written "1617/18" one could take that to mean in the period before 25 March 1618. -- PBS (talk) 00:53, 6 August 2013 (UTC)

Dual dating

In a recent discussion re the date of the Battle of Dettingen (16/27 June 1743) I suggested that dates which fall within the overlap between the introduction of the Gregorian calendar and its general adoption in most European countries should be more prominently indicated when the parties involved were using different calendars at the time. My feeling is that a tacit conversion to the Gregorian calendar might cause readers to miss the fact that the date given did not apply in all affected countries. An example is the Treaty of Lübeck where a caption explains the date format given in the original document. Is there a policy on this issue? Thanks. --TraceyR (talk) 22:00, 16 July 2013 (UTC)

  • Of course we need to be careful about Gregorian and non-Gregorian dates when dealing in comparative history. Nobody in the modern world can relate to dates other than in the Gregorian calendar. I see absolutely no point in placing non-Gregorian dates in any article. If a non-G date is given in a source without a corresponding G-date, a footnote should be made of that and move on. Having to state both dates would merely clutter up the article with little or no benefit. -- Ohc ¡digame!¿que pasa? 01:29, 19 July 2013 (UTC)
Remember, not everyone uses the Gregorian calendar even today. WP:JG provides for this: "Dates can be given in any appropriate calendar, as long as the date in either the Julian or Gregorian calendars is provided, as described below." Of course, other date systems should only be used if there is a particular need and, as you say, care will need to be taken to avoid confusion. Maybe some sort of hatnote would be useful? —sroc 💬 02:12, 19 July 2013 (UTC)
  • Of course, there will always be learned subjects of very special interest, but our job as editors is to make articles as accessible as possible to the general public. Even if an article is about ancient Egyptian or Chinese history, those dates therein must be brought to the modern era (and not left as referring to the reign of a certain emperor or a certain year of the republic). WP:JG does not specify where such dates are expected to appear. Using dates that non-experts cannot be expected relate to is confusing, and a general disservice to our generalised readership, and as such I would certainly expect to see Gregorian dates thereto in the body of the article rather than glossed or put in notes while I would see no problem with footnoting the 'old style', 'ancient' or 'imperial' dates. Our information also needs to be verifiable, consistently presented and needs to avoid confusion, although that goal is yet to be achieved universally – this is a wiki, after all. -- Ohc ¡digame!¿que pasa? 09:20, 19 July 2013 (UTC)
Isn't that what WP:JG is saying? You can give dates in another calendar where relevant, but you must also provide the equivalent in the Gregorian calendar. —sroc 💬 09:33, 19 July 2013 (UTC)
Maybe I read it wrong. But my understanding is that the OP implied that two dates, or just the non-Gregorian, perhaps ought to appear in the body of the article. I'm saying it's quite enough for the non-Gregorian date to appear only as a footnote; in fact it's undesirable to have both, or just the non-Gregorian, in the body as this will confuse. -- Ohc ¡digame!¿que pasa? 13:32, 19 July 2013 (UTC)
At present, WP:JG seems to assume that the Gregorian calendar was adopted in 1582: "Dates before the adoption of the Gregorian calendar on 15 October 1582 are normally given in the Julian calendar". Surely this should read e.g. "Dates before the adoption of the Gregorian calendar in the country/administrative area in question are normally given in the Julian calendar". IMHO WP should provide accurate information; if this means having a hat-note or footnote, so be it. Not providing this information would be a "general disservice to out ... readership". Perhaps a template would be useful which would require the two dates in question; its output would be (a) the Gregorian date in the body and (b) the Julian date in a standard explanatory note of some kind. Perhaps the template could also include a table of countries/administrative areas and the date on which each one adopted the Gregorian calendar, so that the note could include this information too (via an optional (?) third parameter which specified the administrative area concerned). This would be verifiable, consistently presented and avoid confusion. Or is this too idealistic or impracticable? --TraceyR (talk) 20:26, 19 July 2013 (UTC)
I think that "Dates before the adoption of the Gregorian calendar in the country/administrative area in question are normally given in the Julian calendar" is open to misunderstanding as it is not the dates used in primary sources that matter it is the dates used in modern reliable secondary sources, that are used. For example what was the the date for the Charge of the Light Brigade? Most English language histories are going to record that as 25 October 1854, not by the date in the "country/administrative area in question" (I have no idea what modern Russian sources do, but if they follow the English language tradition they will recoded it as a Julian date which will be 11(?) days different from the English language date). -- PBS (talk) 00:34, 6 August 2013 (UTC)
I think the idea is good, but would it help or create more confusion? I have no idea. Vegaswikian (talk) 20:52, 19 July 2013 (UTC)
I think the footnote as it appears in the lead of Battle of Dettingen (from the original post) is a good way of dealing with it. It should take the form of a separate note from the footnotes used for references, though. —sroc 💬 00:09, 20 July 2013 (UTC)


Guidance on this was worked out years ago see Wikipedia:Manual of Style/Dates and numbers#Julian and Gregorian calendars (short link WP:OSNS) for a detailed description of the problem see the article Old Style and New Style dates.

The conversation at Talk:Battle of Dettingen#Dual dating about the dating of Battle of Dettingen hinged around the use in primary sources "It was common at the time for dates to be given according to both calendars". As the guidance explains we do not date things via primary sources, we date them from reliable secondary sources, which in this case I suspect will overwhelmingly be in the Gregorian calendar. This is explained in more detail in the article Old Style and New Style dates and an example given which matches this battle is the Battle of Blenheim (13 August 1704). There is no need to dual date Blenheim because most secondary sources do not use the Julian date for this battle (of course a contemporary British newspaper would probably have used a Julian date, but that is not a concern as the article uses the dates commonly used in reliable secondary sources).

The problem of primary sources and dates is addressed in Old Style and New Style dates with the example of of the execution of Charles I which took place on 30 January 1649. The guidance makes it clear WP:OSNS for British events during the War of the Three Kingdoms because secondary sources use Julian dates, Wikipedia uses the Julian calendar with the year adjusted to 1 January. IE Wikipedia does not tipple date that event: 30 January/9 February 1648/49 because there is no need to, as secondary sources inevitably use either 30 January 1648/49 or for books aimed at the general public "30 January 1649".

It is only occasionally that a Wikiepdia article need to use dual dating -- as in the example of the Glorious Revolution -- were events are described using two different dating systems (because the events move between two counties that used different systems) so the detailed secondary sources that cover the events in different countries use different dating systems: eg William of Orange came ashore in England on 5 November having left Holland on 13 November! So the article on the Glorious revolution uses both Gregorian and Julian dates for most of the article with the section that covers the invasion using dual dating all of which is explained in a footnote. -- The modern equivalent of this is the international date line and the notion that the Pacific war started in Asia shortly before or at the same time as the attack on Pearl Harbor but a day later according to the local time.

The Glorious Revolution is an unusual article and for the vast majority of articles where the secondary sources use either Julian dates or Gregorian dates, there is no need to footnote which is being used. For example it would look pedantic/odd to put into the article on the Siege of Drogheda Gregorian dates as the only comments in the secondary sources about different dates are those about s:Cromwell letter to William Lenthall because Cromwell got the day/date wrong. All the secondary sources use Julian dates to date the events. This means there is no need to footnote in the article Siege of Drogheda that the dates are Julian any more than there is a need to document that the article on Battle of Waterloo is using Gregorian dates.

This thing with primary sources gets much more complicated in the medieval period, Juliet Barker in her Agincourt: The King, the Campaign, the Battle (2005) has a few paragraphs on how difficult it is to date things of this period accurately (Barker (2005), pp. 225–7). First the year is given from the start of a kings reign rather than (in the year of our Lord). Secondly the day is given in two ways one is by saints days (or as an offset from a saints day for example "two days after the feast of St. Andrew"), and the other by the Ides. For example one English document may be dated from the start year of Henry V reign and the day as an offset from an ide, while a French document for the same day will use their King coronation year and then use a local saint's day to date an event that happened on the same day.

A classic example of the dangers of using primary sources is given in by Samuel Seyer (1823), Memoirs Historical and Topographical of Bristol and It's Neighbourhood: From the Earliest Period Down to the Present Time, vol. 2, pp. 73–74 In it he reviews several primary sources about a visit by King Edward to Bristol at Christmas 1284. He notes on page 74 about the apparent date mismatch in one source: "This writer dates the event in 1285, because it happened at Christmas 1284, as we now compute; but which he reckoned the beginning of the year 1285".

This detailed knowledge about dates in the medieval period is a very good reason not to mention the dates in primary sources as good secondary sources will already have worked this out for Wikipedia editors and working out such dates from primary sources takes OR and expert judgement (particularly when primary sources disagree). -- PBS (talk) 00:08, 6 August 2013 (UTC)

YYYY-MM-DD in tables and lists

What is the consensus regarding the use of the YYYY-MM-DD date format outside of references? Following the June discussion on YYYY-MM-DD the guideline was adjusted to reflect what appeared to be the general consensus that this format really had no place in tables.

Yesterday this was reverted with the claim that no consensus had been reached. Allowance for YYYY-MM-DD in tables and lists was reinstated along with the spurious claim that "they may be useful in long lists and tables for conciseness".

Rather than using a format which is quite unfamiliar we could use three-letter abbreviations for months. Dates written in dmy or mdy format with three-letter months are only slightly longer than the YYYY-MM-DD equivalents if they are any longer at all. This can easily be seen in examples such as the following.

2000-01-01
1 Jan 2000
Jan 1, 2000 		       2000-05-05
5 May 2000
May 5, 2000 		       2000-10-10
10 Oct 2000
Oct 10, 2000

The claim that YYYY-MM-DD may be useful for conciseness is false and the exception to the rule that this format has no place in the article body is unnecessary. I propose that the reversion in question be reversed. Jimp 09:58, 9 August 2013 (UTC)

Where to use ISO dates has been discussed more than once, and I agree that no consensus for a change to the current guidelines was reached, so the status quo prevails. (The fact that "raw" ISO dates sort correctly is another point in their favour in tables.)
The problem with abbreviating month names is that if you review various style guides, you'll find that different systems are recommended, both as to the actual abbreviations and as to whether a full stop/period is needed. I haven't done a systematic check but I suspect we would end up with an ENGVAR difference: US English seems mainly to require a period, British English is less likely to require a full stop. The advantage of YYYY-MM-DD is that it is a single defined standard. Peter coxhead (talk) 10:19, 9 August 2013 (UTC)
To expand on Peter coxhead's comments, the subject of dates and date formats has been discussed several times, with no consensus reached. Therefore, Wikipedia allows several date formats; the only consensus I am aware of is that the date formats should not be mixed within an article; pick one format and use it consistently. YYYY-MM-DD can be useful for searching in tables, and therefore it's reasonable to allow it. In main body text, that format is more problematic, and day-month-year and month-day-year formats are preferred. I do not support Jimp's reversion request. Truthanado (talk) 13:41, 10 August 2013 (UTC)
I was pretty sure there was consensus for removing ISO dates from in-article tables and lists. The sorting issue is moot with templates like {{dtsa}} which formats right but includes the numerical codes to sort. --MASEM (t) 13:46, 10 August 2013 (UTC)

The YYYY-MM-DD discussion mentioned at the beginning of this thread was not a well-advertized RFC. Since date formats have been discussed extensively for years, I don't think that discussion was well-know enough to change consensus. Even then, the "in tables" subsection only contains two entries. Jc3s5h (talk) 14:39, 10 August 2013 (UTC)

My view is the same as Jc3s5h's. It might be that if there was a properly advertized RfC there would now be a consensus to change to not allowing ISO dates in tables (provided that templates like {{dtsa}} were well flagged in the MOS). On the other hand, there is always resistance to requiring the use of templates (just try adding a citation template to an article where the existing editors have a consensus not to use them!), so I'm not sure that the existence of "sortable date" templates would convince enough people. Peter coxhead (talk) 15:45, 10 August 2013 (UTC)
The issue of using templates for citations vs hardcoded cites is far far different from just using templates for other purposes. I would not take that as a sign of resistance for using templates. (Of course, the invis ISO date can be hard coded too and avoid templates, so really , this isn't an issue) --MASEM (t) 16:18, 10 August 2013 (UTC)
The input date in the dts template is not an ISO 8601 date. It must satisfy this format specification which has some overlap with ISO 8601 but is not identical with ISO 8601. The invisible output of the dts template is certainly not ISO 8601; the year portion is 5 characters with the leftmost character being either "0" or "-". Jc3s5h (talk) 11:07, 11 August 2013 (UTC)
{{dts}}'s output is not designed to print the ISO-like date to the reader, but the dmy or mdy version, with the hidden-text ISO-like date left in the front as allow the easy table sort (hence why the first digit is - or 0 for that, so that it also sorts on BC/AD years). --MASEM (t) 12:20, 11 August 2013 (UTC)

I don't believe that sortability is really an issue. Sort tables can now handle most dates and where they fail we have templates (such as the ones mentioned above) to fix the problem. That editors use templates is less of an ask than that readers be faced with YYYY-MM-DD. But, sure, if someone puts YYYY-MM-DD dates into a sortable table because they haven't got the time/skill/etc. to use the appropriate code, then let them, just don't disallow another editor from improving readability.

As for three-letter abbreviations possibly not being appropriate for certain dialects (e.g. US English), yes, okay I can accept this. In fact the MOS already allows for different styles. As far as I know, though, the longest abbreviation we'd be looking at would be "Sept.", thus the worst-case scenario would be something like "Sept. 30, 2020". Compare that to "2020-11-30" and, sure, you've saved a bit of space but it's hardly significant weighted against the cost to readability. Thus I still contend that YYYY-MM-DD are not useful in lists or tables for conciseness.

Nor do I believe that that argument from commonality holds any weight. Okay, yes, "The advantage of YYYY-MM-DD is that it is a single defined standard." as opposed to the various ways of abbreviating the month along with the question of whether to put the day or month first. We have one single defined standard which is equally difficult for us all to read verses a handful of different but easily recognisable options. I suggest that readability trumps commonality again.

Truthanado, you suggest that "YYYY-MM-DD can be useful for searching in tables, and therefore it's reasonable to allow it." I don't know how. Surely, the more readable the format, the easier it will be to search (if you're searching by eye, if, on the other hand, you're using [Ctrl]+[F], the computer doesn't care).

Masem says that he thought that the consensus to remove this format from lists & tables was achieved. So did I. In fact the feeling I got was that it had been achieved some time back but the guideline hadn't fully caught up. (I still have that feeling.) But, no, the YYYY-MM-DD discussion mentioned above was not a well-advertised RFC and the discussion of YYYY-MM-DD in tables was only a small part of it. So, I'm bringing it up again to test the actual consensus. If we want to make an RFC out of it, let's go. Jimp 09:58, 12 August 2013 (UTC)

  • I seem to be under the impression that there is consensus for yyyy-mm-dd dates to be isolated to the reference sections. I have never been faced with resistance or opposition when replacing yyyy-mm-dd dates inside tables, and I usually use a sort template for that. Of course, there are other ways. I would favour clarifying this in the guideline. -- Ohc ¡digame!¿que pasa? 10:11, 12 August 2013 (UTC)
    • Is it just my quirk? I find it several levels easier to comprehend the abbreviations set out above than the phone-number ISO gobbledies. Tony (talk) 10:20, 12 August 2013 (UTC)

YYYY-MM-DD is the natural format when a table is arranged chronologically. I'd be surprised if there were consensus to ban it. — kwami (talk) 10:37, 12 August 2013 (UTC)

What people find easier to read and comprehend depends on their experience of different formats. I find the US-style "Sept. 11, 2011" harder to read and understand than either "11 Sep 2011" or "2011-09-11". But WP:IDONTLIKEIT isn't a good reason either way. The ISO style is (a) a standard style (b) preferred by some editors for some purposes. It would be unreasonable WP:CREEP to ban it. Just learn to live with it, if you don't like it, as I rightly have to with US-style dates. Peter coxhead (talk) 11:49, 12 August 2013 (UTC)
  • @kwami: Your surprise or otherwise of the [in]tolerance for the format's existence on WP has just about as much to do with as whether you like it or not. The fact of the matter is that, depending on which country you are in, human beings in the western world are brought up to parse "January 23, 2013" or "23 January 2013" easily to a greater or lesser extent. And most certainly parse these more easily than "2013-01-23". It's quite another thing if you're a computer or Asian, but this isn't machine Wikipedia nor is it Asian WP, so it should be ditched. -- Ohc ¡digame!¿que pasa? 13:04, 12 August 2013 (UTC)
    • And to most Americans, 23 January 2013 is confusing to parse too, at first (and vice versa), but it is not an insurmountable difficulty so that argument doesn't apply. I do agree that in the prose body of an article, we should avoid it for either the dmy or mdy format as those are geared towards being visually and verbally structured right in the grammer of a sentence compared to ISO, but when used for date, which isn't read in sentences, it can be appropriate, though I will agree that in tables and lists in body there's no practical difference (when we have the ability to sort via templates/hidden text) and should prefer the dmy/mdy formats instead. --MASEM (t) 13:15, 12 August 2013 (UTC)
      "Prefer" is one thing; "impose" another. The proposal, as I understand it, is that the MOS should forbid the ISO date format other than in two places in citations. ("Forbid" because a revised MOS would allow any other editor to change ISO dates in tables to another format.) No good reason has been put forward for this instruction creep other than that some people don't like it and find it hard to parse because they aren't used to it. Particularly in an international encyclopaedia this is not a good reason. Peter coxhead (talk) 13:50, 12 August 2013 (UTC)

The English Wikipedia has never adopted ISO 8601 for use in articles (although it is available to logged-in users in "Preferences", under the "Date and Time" tab, for display of system timestamps). If you want to have an RfC about allowing ISO 8601 for tables, you should first have one about adopting ISO 8601 at all. 14:03, 12 August 2013 (UTC)

Most likely because prior to the date delinking discussion, people used whatever they wanted; we never previously said that editors can't ues ISO for dates since we all worked on the assumption that magical linking would fix it. As a result of date delinking and subsequent date consistency discussions, there we said that ISO should never be used for prose text. Only recently, as best as I recall, we had a second discussion about discouraging ISO within tables, and a more recent discussion affirmed that ISO was okay to use in citations but pretty much the only place where its use was promoted. --MASEM (t) 14:11, 12 August 2013 (UTC)
I am not discussing when to use the YYYY-MM-DD format, only what to call it. If someone showed you a picture of a disassembled electrical outlet with voltmeters hooked up to it, and you saw the green wire read 0, the white wire read 0, and the black wire read 120, you would not be justified in saying that the jurisdiction where the outlet was located had adopted the National Electrical Code. Likewise, just because the correct all-numeric dates in Wikipedia articles look like a subset of the formats allowed in ISO 8601 does not mean Wikipedia has adopted ISO 8601. I see this as an issue because it may confuse software developers who want to reuse Wikipedia content, and if they see ISO 8601, they might think our dates comply with that standard to a greater extent than they actually do. Also, if we ever wanted to extend the way we write numeric dates beyond what is now allowed, for example by allowing years earlier than 1583, or allowing dates and times to be combined, it would be helpful to know if we had decided to be guided by ISO 8601 or not. Jc3s5h (talk) 14:41, 12 August 2013 (UTC)
WP:DATEFORMAT calls it ISO 8601, but I guess ISO 2014 (which is a subset of ISO 8601) would be more accurate as no-one has suggested including times. (If you want another name, how about "Canadian standard date format"? See Date and time notation in Canada#Date.) Peter coxhead (talk) 14:59, 12 August 2013 (UTC)
No, WP:DATEFORMAT does not call it ISO 8601. It says "Because year-initial dates might be assumed to follow the ISO 8601 standard...." [Emphasis added.] Jc3s5h (talk) 15:16, 12 August 2013 (UTC)
Sorry, my mis-reading. Given that it says "this format should only be used for dates expressed in the Gregorian calendar and for the years 1583 through 9999" then actually it will follow the date part of ISO 8601 or the whole of ISO 2014, so why not call it this? Peter coxhead (talk) 15:50, 12 August 2013 (UTC)
Our format isn't ISO 8601, it seems to be a subset of ISO 8601. If you look at any of the other variant to ISO 8601 that other organizations have, such as RFC 3339, they take care to give a different name to their variant. So if we want to, we could define our own variant of ISO 8601 and give it a name. Or, we could find a variant that is identical to our variant, and adopt it (but that would cause problems if the other organization revised their standard in a way we don't like). Or we could continue to call it the YYYY-MM-DD format.
I can't find a copy of ISO 2014, so I don't know if it the same as our usage or not.
So far I haven't expressed an opinion about whether we should adopt an ISO standard or not, just said we shouldn't say we have if we haven't. But I am actually opposed to adopting anything from ISO. In the August 2013 issue of IEEE Spectrum Andrew Russell claims that one of the reasons the Internet protocol suite won over Open Systems Interconnection was the high fees charged by ISO for copies of their standards. (p. 43.) If their fees are an obstacle for big business, they certainly aren't suitable for the (mostly) volunteers at Wikipedia. Jc3s5h (talk) 16:34, 12 August 2013 (UTC)
As someone who has been a member of two British national committees on standards, which like all such committees, ultimately input to ISO standards, I could say a lot about this. The problem has been that although many members of such committees are unpaid volunteers – like Wikipedia editors – and others are supported by their companies, there is a real cost to coordinating across many countries and agreeing standards. Previously governments gave financial support, but in the last 15 years or so this subsidy has increasingly been withdrawn as part of the current "neoliberal" consensus, so both national standards organizations and ISO have to charge more. I don't see this as a good reason not to support internationally agreed standards; at the base level, they are dependent on volunteers. Peter coxhead (talk) 15:40, 15 August 2013 (UTC)
For me, this isn't about philosophy, it's about practicality. Standards, and ISO 8601 is a superb example of this, often have gotchas that will ensnare those who do not have access to the standard, because examples they find in sources or popular summaries they come across only deal with common everyday situations; dates in the 20th or 21st centuries, minutes which contain 60 minutes rather than 61, etc. The unwary misuse the standard because they try to apply it to a case where a gotcha governs.
In my mind, standards committees should ask themselves who will need to read the standard. If the answer is megacorporations, go ahead with their normal pricing strategies. If the answer is everyone who writes, they need to either develop a way to distribute the standard for free on the internet, or disband the committee and let some organization that does have an appropriate price structure do it.
The National Fire Protection Association is an example of an organization that has finally made the National Electrical Code available for free on the internet. The free version is less convenient to use than the printed or CD-ROM versions, but at least people who can't afford to buy the printed version or hire an electrician will have a lower chance of burning to death or being electrocuted. Jc3s5h (talk) 17:02, 15 August 2013 (UTC)
Hm, I don't think the ISO standards are more difficult to obtain or more expensive than f.e. ANSI, DIN, ETSI, or many other standards. I don't think we should avoid it simply because it isn't a free download (Google will still find many places, where you can download it inofficially) - our ISO 8601 article has all that is needed for our purposes. Also, we should not invent a new name for it, and just call the YYYY-MM-DD format an ISO 8601 format (because that's what it is) or simply the international date format. We don't have to allow all other format variations to call it an ISO 8601 format.
--Matthiaspaul (talk) 14:18, 20 August 2013 (UTC)

I must disagree with you, Peter. I suggest that people's finding YYYY-MM-DD hard to parse is a very good reason not to use it. This format is unfamiliar to most English speakers (i.e. enWP's audience) and, yes, this is exactly because we in general don't have much experience of the format. Thus it is in no way "natural" whether in a chronological table/list or elsewhere. Jimp 00:10, 13 August 2013 (UTC)

  • Any date with the month spelt out (whether in full or abbreviated) is disambiguated, by definition. Even in cultures that follow year-month-day order when using Gregorian dates seem to necessarily specify which one is the year, month and day (e.g. 2001年9月11日). Clearly, as has been demonstrated by JC3, we have not adopted any ISO standard nor is it appropriate that we did. We should simply ditch this machine language that is confusing to ordinary folk. -- Ohc ¡digame!¿que pasa? 01:35, 13 August 2013 (UTC)
    • I call bullshit on the confusion aspect, because, to someone that is used to mdy, dmy will be just as confusing at first, and same for a dmy experiencing mdy, and thus that should give us the reason to standardize on or the other (which of course is not a smart decision). The ISO-like format takes the same amount of minimal time to understand as learning the opposite prose-friendly date style. I do support removing ISO-like dates from the body of an article (unless of course it is the subject of discussion), including from lists and tables, since in reading prose, the ISO-like dates break up the flow significantly, and the issues of sorting are readily dealt with using templates or other coding schemes. I just can't support its removal on the aspect of reader confusion, since that reasoning suggests standardizing the MOS to one specific style for all other factors like dates, spelling, etc. for all others, and that is not a direction we're going. --MASEM (t) 02:09, 13 August 2013 (UTC)
I agree that any date format you're not familiar with is confusing. (I still get muddled by a few websites I have to use to buy things which use US date order.) But the yyyy-mm-dd order isn't inherently more difficult than any other system; travellers to Canada seem to cope with it ok – millions must fill in Canadian custom forms each year which require this format.
We all agree that it shouldn't be used in text. I personally wouldn't use it in a vertical list or a table, but I don't agree that the MOS should be changed to prevent editors doing this if they want to. Peter coxhead (talk) 15:32, 15 August 2013 (UTC)
At least we should be grateful that we haven't adopted one of the slash-separated dates. -- Ohc ¡digame!¿que pasa? 15:51, 15 August 2013 (UTC)
For good reason, because that can be immediately confusing. "8/9/2013" can be read in two ways (unlike dmy, mdy, or ISO-like) and should be avoided at all costs (save when talking about the slash-date format itself). --MASEM (t) 16:01, 15 August 2013 (UTC)
My doctor recently wrote 9/12/2013 on an appointment slip; meaning neither "9th December" nor "12th September", but, it transpired, "the 9th month" of 2013. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:16, 15 August 2013 (UTC)

The Canadian customs forms (I'm sure ... it's been a while but ...) make it clear to the traveller what they have to put in which box. Suppose you're filling in your address on a form with boxes for country, state, city, suburb then street; I'm sure you'd manage though it's not a familiar way of writing your address in English. Whilst we're at it, let's stop to consider this Canadians-use-ymd notion, how true is it? Okay, you might see it on a few forms and on cheques but the most common format by far in Canada is mdy (sometimes you see dmy).

It's true that anything you're not used to can get you perplexed. Suppose mdy is what you're used to you may well be just as puzzled with your first experience of dmy as you would be with your first experience of ymd ... but if the month is spelt out (or abbreviated) the dmy date might be easier to figure out. Suppose dmy is what your used to, that'd be a similar story. What if ymd is what your used to? ... Hang on what country are we talking about now? How about we talk about this country (the English-speaking country I'm in right now)? I recall being completely familiar with both dmy and mdy (with the month spelt out) even as a kid; I'd never seen ymd before went oversees. I'm suggesting that English speakers are in general familiar with dmy and mdy but not so much ymd. Yes, a new format can be vexing at first, of these three formats, though, which is more likely to be presenting the reader with a new experience if used on a WP page?

With respect to changing the MOS to prevent people from using ymd, there is another way of looking at it. People might still use ymd even though the MOS disallows it, just as people might type in numerals where the MOS says to spell the number out or might use US units without converting them. Nobody is organising witch hunts for MOS rule breakers. I'm saying let us be allowed to go and improve the article by converting to dmy or mdy. Should I not be allowed to make a table more readable? The current guideline says I am not. Jimp 10:56, 20 August 2013 (UTC)

The MOS doesn't allow me to make all sorts of edits that I think would improve an article (using single quotes for scare quotes for example). But the point is that Wikipedia is an international cooperative enterprise, and so requires compromise and tolerance of variation. YYYY-MM-DD is a legitimate style and should be allowed in appropriate contexts. Peter coxhead (talk) 13:04, 20 August 2013 (UTC)
(Edit conflict)
While I do agree that we should avoid to use the YYYY-MM-DD format in normal prose in the article body (as it may still disturb some readers' flow), I do not agree with disallowing it in tables, lists and references.
First of all, there are many places in Wikipedia, where the YYYY-MM-DD format is presently used in tables, lists and references, so, obviously, many editors and readers are accustomed to it.
The format is not intrinsically more difficult to parse or spell than one of the other formats - that's just a matter of personal preferences and what someone is used to. As an European (being taught the "dmy" format), I have learnt to parse and spell both, the "US" format as well as the "ISO" format. Personally, I still find the "mdy" format totally illogical and impractial and always wonder how/why someone came up with it in the first place - but things happen and we get used to them. ;-) If I would have to ditch one date format from Wikipedia, it would certainly be "mdy" in all its forms. (No, I'm not proposing this - it's about tolerance - and as I wrote, one gets used to it.)
As for parsability, I think the ISO format is even easier to parse and understand for humans that other forms. Many people have some (mild) difficulties associating month names with their actual numbers (in particular for "May", "Jun" and "Jul"); there's always an extra step necessary to "translate" those mnemonics into the actual numerical dates, which can then be used for calculations. (What's the span between "Nov" and "Jun" or between "Sep" and "Jul"? versus: "11-6" or "9-7"?) Also, for people, who's first language isn't English, there's another "translation" process involved for text formats. Nothing difficult, but it's there and it presents a potential risk to mix up a date accidently - a risk we can reduce or even avoid. We all know, that this is not hypothetical, this was a real and quite common problem in international communications before the shift towards the ISO format.
That's why numerical date and time formats are much preferable over text formats in anything but prose, in particular in tables, lists and references. There's no translation needed. However, since the other two common numerical formats DD.MM.YYYY and MM/DD/YYYY are highly ambiguous in an international context, we have, for very good reasons, settled for the third one, YYYY-MM-DD, which is not some obscure format (as some try to put it), but follows a long established international standard (ISO 8601 and its predecessors) and, besides being per se unambiguous and easily understandable by both, machines and humans, it also has a number of other benefits: A compact and stringent format without any unnecessary syntactical clutter and with digits aligned as per their corresponding weights, it also has the inherent advantage that the digits are ordered as we write numbers naturally (useful for calculations and for possible expansion on both ends of the number/date), and that dates sorted alphabetically will be presented in chronological order automatically. This makes manual searching, comparing and sorting dates in lists and tables much more easy than using text formats, in particular, if full dates are mixed with incomplete dates (that is, dates with only the year, or only the year and month given - see example 2). As pointed out already, it also makes international communication and information exchange much easier and reduces the risk of errors in the transmission (Wikipedia is an international project).
  • Example 1 (full dates, sorted):
2013-01-07 10 Aug 2013 Apr 3, 2013
2013-04-03 3 Apr 2013 Aug 10, 2013
2013-08-10 7 Jan 2013 Jan 7, 2013
  • Example 2 (incomplete dates, sorted):
2012-01-07 10 Aug 2013 2013
2013 2013 Apr 2013
2013-04 3 Apr 2013 Apr 3, 2013
2013-04-03 7 Jan 2012 Aug 10, 2013
2013-08-10 Apr 2013 Jan 7, 2012
"Sortable tables" are a nice goodie, but they are no solution here, as they only work with JavaScript enabled. Many people have JavaScript disabled for security/privacy reasons, or simply because their browsers don't support it at all. Enforcing JavaScript on readers is considered "impolite" and "unprofessional", therefore Wikipedia shouldn't attempt it.
Regarding templates, it's good that we have them (for other purposes), but I don't consider them a solution here as well, unless the templates would support the YYYY-MM-DD format as *output* as well, and the users could define their desired output format in their preferences.
--Matthiaspaul (talk) 14:18, 20 August 2013 (UTC)

In South Africa YYYY-MM-DD is widely used. In accordance with WP:ENGVAR any prohibition of the use of YYYY-MM-DD comes into conflict with WP:ENGVAR. Martinvl (talk) 09:17, 21 August 2013 (UTC)

Yes, according to our Date format by country article yyyy/mm/dd is common in South Africa. Note, however, the slashes as opposed to hyphens making it not quite yyyy-mm-dd. Also, there is a bit of a problem with this: the refs for this are broken external links. On the other hand, Date and time notation in South Africa claims that South Africa signed up to use ISO 8601 but being one of the original seventeen signatory nations to the Metre Convention the United States has technically adopted the metric system. I wonder whether South Africans really do use ymd in everyday life. Note also that the 2011 census found that English was spoken at home by only 9.6% of South Africans. So I wonder whether YYYY-MM-DD is widely used amongst South African speakers of English. Jimp 09:38, 2 September 2013 (UTC)
Date format is unrelated to the metric system (unless Jimp just means that government endorsement of a standard or system does not necessarily mean it will be used in everyday life). I note that the Mail & Guardian (Johannesburg, online version) uses the format "02 Sep 2013". Jc3s5h (talk) 12:14, 2 September 2013 (UTC)
Yes, that is what I meant. Jimp 03:53, 3 September 2013 (UTC)

Request for rule interpretation: WP:ERA

The guidelines at WP:ERA were rewritten last year following lengthy discussions on this page that wrapped up in mid-June 2012. The aims of the project included reducing the amount of edit warring occurring over era-dating style and discouraging casual changes from being made unilaterally, by requiring consensus. An anonymous editor, using two IP addresses, recently forced an era-dating style change into the article Judea—see edit history for 5-6 August 2013—on the basis that the article’s original 2002 style was changed in 2006 without consensus. I argued that a new consensus would be needed based on the current guideline. Any reference at WP:ERA to retaining the adopted style of an article’s original editor was dropped years ago. The style in this article (BCE/CE) had been stable for seven years. No content-related justification was given for changing it now. I called in vain for consensus to be sought through discussion. After two rounds of reverting I stepped aside lest I be accused of edit warring.

I should think that seven years is long enough for the style in the article to become "established". Consistent with the present text and meaning of WP:ERA, who is correct, and what should be done? If enforcement should be necessary, what is the proper channel? Hertz1888 (talk) 03:47, 22 August 2013 (UTC)

I agree completely that we need more specific guidance. I've reverted back. With the IP's interpretation and article could have been created in 2002 with BC or BCE, changed the next day with a 2nd edit, but reverted today on the grounds there was no discussion over the 2nd edit. With an IP hopper you can only semi-protect. With others, it would depend partially on their edit pattern. Dougweller (talk) 07:05, 22 August 2013 (UTC)
No diff provided? Tony (talk) 07:52, 22 August 2013 (UTC)
Looks more like 2004[4]. A quick check shows a couple of BC's or AD's in later versions and one edit that made it all AD/BC but this randomly chosen edit it late 2006 [5] is all CE/BCE. Dougweller (talk) 09:47, 22 August 2013 (UTC)
The reversion on 22 August didn't last long before IP attack resumed. Consequently, the article was semi-protected for two weeks (expiring 5 Sept.). Continued vigilance will be needed for that particular article; perhaps renewed protection. For general purposes, I would like to see that "more specific guidance" written into WP:ERA. The present text there is skimpy and leaves too much unsaid and ambiguous. Putting more substance into it would provide much-needed clarity usable in resolving (or avoiding) disputes. Hertz1888 (talk) 01:17, 1 September 2013 (UTC)
Please take the foregoing as an invitation to discuss enhancements of the stated policy. How should such additions or changes be worded? Hertz1888 (talk) 06:44, 1 September 2013 (UTC)

Does DATERET apply to body copy only or reference dates as well?

An editor has decided to apply DATERET to references. In October 2012, I applied User:Ohconfucius/script/MOSNUM dates' script to and article and applied Month dd, YYYY. No other editors complained. A few weeks ago, the editor removed the formatting for references and changed the references dates back to ISO 8601 format claiming that an edit made on March 21, 2009 set the precedent for all of the article's references. I opened a discussion after a brief interchange today. The editor claims that this guideline, WP:DATERET, along with MOS:DATEUNIFY and WP:STRONGNAT make it mandatory to retain the first reference date format. The way I read them, it applies only to dates in the body copy. The only unrelated editor to the discussion indicates that keeping a date format uniform in the article and the references makes more sense and finds the Month dd, YYYY more readable. Could we clarify the guideline to confirm one of these opinions? Walter Görlitz (talk) 07:19, 9 August 2013 (UTC)

Does DATERET apply to body copy only or reference dates as well? It would be good to get an answer to this. Walter Görlitz (talk) 17:04, 10 August 2013 (UTC)
It seems impossible to form a consensus about whether citations are controlled by WP:MOS or by WP:CITE. But in this case, it doesn't matter; WP:CITEVAR also says to retain the existing citation style. Jc3s5h (talk) 17:14, 10 August 2013 (UTC)
CITEVAR is about styles. Are you suggesting that date is just a style? Walter Görlitz (talk) 20:25, 10 August 2013 (UTC)
The way a date is set out is clearly a style which is part of the citation. If e.g. the accessdates use a particular style they should be left that way, or made consistent with the first established style if not consistent. Peter coxhead (talk) 08:12, 11 August 2013 (UTC)
I agree with Peter coxhead; the way a date is written is a matter of style. And this guideline, "Manual of Style/Dates and numbers" is all about style. The other guideline, "Citing sources", is mostly about substance (when to cite and what information to include) with less emphasis on style. Jc3s5h (talk) 11:02, 11 August 2013 (UTC)

What if the first established format dates back to the time when the citation template required YYYY-MM-DD? Jimp 10:06, 12 August 2013 (UTC)

  • That's quite possible because it was commonplace during the time of Date Autoformatting. Now, humans have to be able to parse those wretched machine-dates. -- Ohc ¡digame!¿que pasa? 12:53, 12 August 2013 (UTC)
If one thinks the choice of date formats was not a true choice, because the cite templates once required or recommended the YYYY-MM-DD format, one should discuss what format to use on the talk page. Jc3s5h (talk) 13:54, 12 August 2013 (UTC)
I think WP:BRD would be much more practical and can surely be applied to such instances. -- Ohc ¡digame!¿que pasa? 14:31, 12 August 2013 (UTC)
I also think that DATERET should not be applied to references if consensus for that article are to change. Walter Görlitz (talk) 19:27, 12 August 2013 (UTC)
The guideline indicates to discuss changes to date format first; WP:BRD does not apply. I suspect anyone who uses WP:BRD to justify large numbers of automated or semi-automated changes will be shown the door. If someone wants to claim the citation date format for a particular article is a legacy from the days when templates required all-numeric dates, the editor would be expected to explain on the talk page how they know when citation templates required all-numeric dates, and when the citation date format for the article was established.
If Walter Görlitz means that if a consensus is reached on the talk page to change the date format of the text, the citations could be changed to the agreed-upon format at the same time, that might be OK, although it would be better to mention explicitly if the citation date format differs from the text date format. Jc3s5h (talk) 19:54, 12 August 2013 (UTC)
I am seeking an explicit exclusion of citation date formats. Walter Görlitz (talk) 14:24, 22 August 2013 (UTC)
Dates in citations can be different from the dates in the prose, though consistency within citations, and consistency within prose is expected to be there. Mind you, if use are using dmy or mdy dates in citations, this must be consistent with the body of the article's choie of dmy or mdy. But ISO dates can be used in citations against dmy/mdy in prose. Mind you, which date format to use in citations is one set by the first editor or through subsequent consensus to change. --MASEM (t) 14:31, 22 August 2013 (UTC)
Walter Görlitz wrote "I am seeking an explicit exclusion of citation date formats." I don't understand? Exclusion of date formats from what? Who do you think can give you this exclusion, other than the editors active on the talk page of the article to be changed?
If you think you can obtain this exclusion (whatever that means) on this talk page, you are going about it the wrong way. First, there is no consensus about whether citation date style is governed by WP:MOSNUM or WP:CITE. Secondly, because of the past controversy, no change to either WP:MOSNUM or WP:CITE on this topic could be entertained without a well-advertised RFC. Jc3s5h (talk) 15:06, 22 August 2013 (UTC)

Personally, I wish WP:STRONGNAT would die a violent death. As an American who lived overseas, who was raised with and likes the aesthetic of dmy (that comma needed in mdy is a wasted space), I get ticked when some drive-by editor decides to switch all the reference and dates on an article I've spent a lot of time on and still have a shitload of work to go. Some editors just like to break your stride...and I wish they could find something more productive than being a one man task force raiding the ghetto on a WP:STRONGNAT power trip (like Canuckian89) --ColonelHenry (talk) 21:54, 10 September 2013 (UTC)

  • can we get a "this article is a WP:STRONGNAT-free zone" template. I'd love that. Thanks.--ColonelHenry (talk) 21:57, 10 September 2013 (UTC)

numbers as figures

Could someone give an example of this problem? I assume that in this context "since" means "because". But it is not obvious ho this ambiguity could arise. For example, if I write There were 1200. 700 would have been sufficient., how could this be misread as There were 1200.700 would have been sufficient.? 75.210.21.191 (talk) 04:45, 31 August 2013 (UTC)

Most people in developed countries educated after about 1990 do not put two spaces after periods. Even if they do, Wikipedia presents it as a single space. People have several windows open on a typical computer screen, and a few moments ago may have been looking at a monospaced font that doesn't do a particularly good job of centering periods between the adjacent characters. So I do believe there is a potential for ambiguity. Jc3s5h (talk) 13:02, 31 August 2013 (UTC)
I think it’s worth pointing out that the risk of ambiguity should be considered broadly in this context, meaning anything that might cause a reader to stumble, however briefly. That a careful parsing of the sentence(s) allows for only one sensible interpretation is no excuse for leaving potential obstacles or ‘red herrings’ in the path; the best style is transparent, minimizing the effort required to extract the sense of the writing. If the spelled-out number is unwieldy (“Seven hundred“ being less so than e.g. “Seven hundred and forty-six“), there’s always the option to recast such that the figure appears elsewhere than the beginning of the sentence.—Odysseus1479 20:06, 31 August 2013 (UTC)
This is addressed in just about any style guide you care to name (Chicago, Strunk & White, etc.). It's usually awkward to have a number as the subject of the sentence anyway. Re-cast the sentence if necessary. Kortoso (talk) 23:31, 3 September 2013 (UTC)

Script-assisted conversion of Retrieved YYYY-MM-DD

User:Ohconfucius converts YYYY-MM-DD to dmy or mdy without regard to previous usage and the Archived or Retrieved context. Yesterday I restored Black Ships Before Troy, Double Act (novel), and Elidor. Just now I restored Over Sea, Under Stone and Northern Lights (novel).

Judging by the current report of Ohconfucius contributions I suppose that the abuse is massive. Those five articles were 3 of 4 and 2 of 3 among (only) seven script-assisted conversions by Ohconfucius on my watchlist these two days.

2013-09-10. Today there were 12 script-assisted revisions by Ohconfucius on my watchlist, 9 including the abuse of MOS:NUM discussed here. (continued with repetition and outdent far below -P64)

I restored manually, rather than revert, because the new versions include other changes, some welcome and more important, such as undoing the mix of '-is-' and '-iz-' spellings is certainly welcome. But I am concerned by the massive unlinking of terms such as children's book and fantasy from {{infobox book}} or {{infobox writer}} and from lead sentences. This is now hotly debated at Wikipedia talk:Manual of Style/Linking#Overlinking overdone. (The five cases reported here are book articles on successful British children's novels and the last three named are fantasy.)

"Script-assisted fixes per WP:TIES, MOS:NUM, MOS:CAPS, MOS:LINK" is the Edit summary used by Ohconfucius, automatically, I infer. Evidently the four references cover what has been checked on every page of the run.
Initially I thought GoingBatty was the owner of a robot, or whatever, and the revision discussed below was fully automated. (Edit summary: "date formats per WP:MOSNUM by script"). In the diffs I saw nothing but 50-odd date-format conversions and the insertion of dated template {{mdy}} on line one.) --P64 (talk) 18:37, 7 September 2013 (UTC)

User:GoingBatty converted all YYYY-MM-DD to mdy in our biography Frederick Pohl (timely version) a few days ago, probably more than 50 including dozens of retrieved dates. I simply reverted with summary requesting restriction to publication and vital dates, not Retrieved/accessdate. I will notify that use because the edit summary was promptly buried and its content is important.

--P64 (talk) 16:31, 6 September 2013 (UTC)

An early (February 2007) version of the "Fredrik Pohl" article brings up an interesting question. Since the article had mixed usage in the citations when GoingBatty converted it to mdy, it makes sense to try to find the earliest established usage. The February 2007 version has one reference, dated October 2000. Is it appropriate to mix publication dates consisting of a spelled out month and a year with YYYY-MM-DD formatted publication dates? It looks uncouth to me. Jc3s5h (talk) 18:31, 6 September 2013 (UTC)

This would be the type of case where if one or more publication dates cannot be put into the YYYY-MM-DD format, then all other pub dates (NOT accessdates) should be converted to the mdy/dmy style that is being used otherwise. "October 2000" works in either of those systems, but there's no "iso-like" equivalent (one could argue that this would be "2000-10" but that's really vague comared to YYYY-MM-DD.) --MASEM (t) 19:50, 6 September 2013 (UTC)
The reference section of Frederik Pohl has dates in three different formats. If they were all consistent, I would not have edited the article at all. I hope you'll pick the format you like best for this article per MOS:DATEUNIFY and make the date formats consistent. Happy editing! GoingBatty (talk) 02:24, 7 September 2013 (UTC)
The publication dates are very much inconsistent (and missing in several cases) so that's a point to unify but it also appears you edited the accessdates which are universally YYYY-MM-DD here, and shouldn't have been touched. That's the danger with using scripts that don't distinguish between these two. --MASEM (t) 05:05, 7 September 2013 (UTC)
FYI, the accessdates on references 41-45 are in mdy format. GoingBatty (talk) 13:48, 7 September 2013 (UTC)
In fact there were not five in the timely version (which I now also link above), merely 2 of 30 retrieved dates, both one-day-old work by User:Drbogdan (diffs -09-03 18:07). Drbogdan returned some time after my restoration and converted five in the course of other "refs adjs" (diffs -09-05 16:43).
FWIW - please understand that, thanks to P64, I'm only now aware of this discussion - ie, I was not aware of the issue at the time of my referenced edits above in the Frederick Pohl article - please understand, as well, that I'm fully supportive of the present efforts to improve Wikipedia - Enjoy! :) Drbogdan (talk) 16:47, 7 September 2013 (UTC)
Last weekend there were perhaps 40 references and 25 retrieved dates, all YYYY-MM-DD.
Pohl died Monday -09-02, now five days ago, and much activity promptly followed here, including next day insertion of two references with "September 3, 2013" retrieved dates. Next day -09-04, the robot converted the other 30 to mdy.
After reverting the mass change, far too much to do manually, I provided an Edit summary suggesting that the robot re-consider the publication and vital dates alone, for I had reconciled the two new retrieved dates manually.
(As I have now reconciled the five manually.) --P64 (talk) 15:07, 7 September 2013 (UTC)
FYI, I'm not a robot. :-) GoingBatty (talk) 17:27, 7 September 2013 (UTC)
Sorry about that. See you at the biography talk.
Thanks for the oily-on-troubled-waters words, Drbogdan. --P64 (talk) 18:37, 7 September 2013 (UTC)
I tried to be *entirely* ok in my post - I apologize if I inadvertently, perhaps by being very new to the issue discussed, presented something that could have been better - it was not at all intended - in any case - Enjoy! :) Drbogdan (talk) 20:57, 7 September 2013 (UTC)

Refer to my first two paragraphs at the top.

Today there were 12 script-assisted revisions by Ohconfucius on my watchlist, 9 including the abuse of MOS:NUM discussed here. I fixed seven manually (restored YMD) and reverted two that were massive in scale (The Dark is Rising Sequence, The Graveyard Book). It's a pace I can't maintain.

The other changes, associated with conversion of Retrieved dates are generally welcome of course, presuming that the script and its user are sound on Engvar details. --P64 (talk) 20:40, 10 September 2013 (UTC)

I wasn't going to bring this up, but it appears that if I don't, these MOS problems will persist. User:Ohconfucius and his edits, were the subject of a different discussion last week at Wikipedia talk:WikiProject Film. Although he began the thread, the problem was that he was changing the date formats and spellings of films made through US production companies to DMY dates and British spellings, based solely on the fact that the director happened to be British. See the edit history of A Chorus Line (film) for partial evidence. Although he never agreed to stop making the changes I made it clear that if he continued to change dates and spellings on articles against Wikipedia guidelines such as WP:RETAIN and WP:DATERET, I would make a report at WP:ANI and perhaps ask for a formal topic ban. He has made two such changes since then, that I am aware of. I think that with that problem plus this one, we may need to discuss this as an incident with administrators, since he is obviously unwilling to stop. JOJ Hutton 21:27, 10 September 2013 (UTC)
I will note that while this strictly does not fall into the context of Wikipedia:Requests for arbitration/Date delinking (which was about removing linking of dates), we are talking about similar behavior that OC was noted for in that case. And I know he's been warned before (I've done it once) about careless use of his script to convert dates claiming "normalization". ANI is possibly the right direction. --MASEM (t) 21:47, 10 September 2013 (UTC)
Being a proponent of allowing wider YMD usage, I would support any effort to stop such date changes described above executed by the offending editor in question and/or their robot. Startswithj (talk) 01:16, 11 September 2013 (UTC)

Spelling

I've noticed that the words metre/meter and kilometre/kilometer are spelt both ways in the policy. Should we make the spelling consistent or let sleeping dogs lie? Michael Glass (talk) 15:07, 16 August 2013 (UTC)

The find function reveals the following:
  • metre, 12 matches; meter, 5 matches [excludes one reference to "meter" being the American spelling]
  • kilometre, 4 matches; kilometer 1 match Michael Glass (talk) 15:14, 17 August 2013 (UTC)
  • favour 1 match

As "consistency should be maintained within an article unless there is a good reason to do otherwise" I propose to change the other spellings to metre and kilometre. Please let me know if this raises any concern. Michael Glass (talk) 07:08, 21 August 2013 (UTC)

I'm pretty sure AmEng was the traditional variety for MOSNUM. -re might have crept in. I do think it should be regularised to -er. A note about the different spellings would be in order at the top of the units section, yes? Tony (talk) 08:05, 21 August 2013 (UTC)
I checked the earliest versions of MOSNUM - the American spelling "meter" was used. However care should be taken in making a blanket conversion to US spelling-
  • The text "the Murray River is 2,375 kilometres (1,476 mi) long" should remain as it is because it is an Australian example
  • The text "the Moon is 380,000 kilometres (240,000 mi) from Earth" should use the spelling of the article and if it is agreed that the default spelling should be American, then this item should be changed.
However before making any changes, lets see what the consensus is and once that consensus has been reached, write it to the Talk Page and, as suggested by Tony, a note at the top of the page. For my part, I am not going to oppose this page using US spelling as the default, but I am not going to do any of the work of the conversion. Martinvl (talk) 09:01, 21 August 2013 (UTC)

I have no problem in principle if we regularise the spelling one way or the other. However, Martin has pointed out one case where there would be a break in style if we regularise on US spellings. I know that the manual of style uses mainly US spellings and I don't see any harm in MOS having US spellings and MOSNUM with the alternative. In fact it would demonstrate that Wikipedia does not take sides in matters of spelling. I think we need to get consensus before making a change. If consensus cannot be reached, then I guess we would have to let sleeping dogs lie. Michael Glass (talk) 09:45, 21 August 2013 (UTC)

"the Murray River is 2,375 kilometres (1,476 mi) long"—I'd choose another example if it grates. But the clause could come from an article written in AmEng on river lengths worldwide. Tony (talk) 09:53, 21 August 2013 (UTC)
This guide covers an encyclopedia that accepts various national varieties of English on an article-by-article basis. So we could decide upon American or British spelling. But even if we did, any example, even a made-up example, could be imagined as an example from an American English article, or a British English article. So if we decide on a variety of English for this article, I think we should leave all examples as they are. Jc3s5h (talk) 09:55, 21 August 2013 (UTC)
The idea that this guideline should be "consistent" in its selection of ENGVAR seems to hinge on viewing it as an "article", which it clearly is not. There might be an case for explicitly noting which ENGVAR is illustrated in each example used. I notice also that template:convert/doc indicates that both variants are supported by that template. LeadSongDog come howl! 12:35, 21 August 2013 (UTC)
Murray River ... rethink ... it's a quote, isn't it. So there's no need for it to be in any other variety than AusEng. Tony (talk) 14:04, 21 August 2013 (UTC)

As far as I can see, there appears to be no consensus on what to do about the inconsistency in spelling I've pointed out. I've suggested British spelling, two others have suggested American spelling, one has said that the examples of usage can use any spelling and one has argued that the policy on consistency doesn't apply as this isn't an article. (I think that was the intended meaning.) At this point I'm not sure what to do. I don't feel that it's appropriate to leave the article as it is but I certainly don't feel that if I regularised it to either British or American spelling that this would satisfy all. Perhaps someone else could come up with a proposal that might gain support. Michael Glass (talk) 02:50, 24 August 2013 (UTC)

I think the body text should be consistent with the rest of the MoS, but I‘d just as soon leave the heterogenous examples; for one thing, they serve as a reminder that the guidance is applicable to both/all varieties of English.—Odysseus1479 07:23, 2 September 2013 (UTC)

That sounds like an opinion in support of applying American spelling. Is that right? Michael Glass (talk) 12:30, 9 September 2013 (UTC)
Yes concerning the body text, presuming that’s normal for MoS pages in general and despite my personal preference; not necessarily in examples, especially if they’re drawn from Br/Can/AusE articles, as if they were quotations; No in the table where SI unit names are presented in both international and US spellings.—Odysseus1479 01:57, 10 September 2013 (UTC)

Revised proposal

In the light of the discussion above, would it be acceptable to regularise MOSNUM to American spellings (except for examples of other usage) or would editors prefer leaving the spelling as it is (a mixture of spellings, predominantly non-US)? Michael Glass (talk) 03:27, 22 September 2013 (UTC)

It's not worth the trouble to have and enforce a dialect guideline/policy for the page. Maybe it would work if there was a guideline/policy for all MOS pages, but I'm certain that proposing such a guideline wouldn't go over especially well in the wider community. Besides, particularly with respect to metre/meter & litre/liter, American usage is deviant compared to everywhere else, in English and in general. That's probably the worst instance from which to craft a general rule. TheFeds 04:22, 22 September 2013 (UTC)
Leave it be. RGloucester — ☎ 12:40, 2 October 2013 (UTC)

YYYY-MMM-DD Format

I'd like to suggest adding year-month-day format—with the month spelled as its three-letter abbreviation—to the list of acceptable, non-prose usages. This option has an advantage of being even less ambiguous than using numbers for months. It also aligns well if listing dates, due to the uniform length of abbreviations and digits. Its listing might also prevent a confusion I myself had earlier in the conversation above.

Cursorily I can point to:

Thank you, Startswithj (talk) 23:01, 7 September 2013 (UTC)

I do not support additional formats for dates that are not part of citations; we have enough, and the ones we have are the most natural for English-speaking people.
However, WP:CITE allows one to follow printed style guides, several of which are named. Some of these call for other date formats in particular situations, including APA Style's endorsement of "2013, September 7" for publication date; I am unaware of any citation style guide that would call for the format suggested by Startswithj. I believe following established style guides should be allowed to facilitate the use of citation management software that supports these styles. (An RfC trying to determine whether date format in citations is controlled by WP:CITE or WP:MOSDATE was inconclusive.) Jc3s5h (talk) 23:43, 7 September 2013 (UTC)
Such a format would be very rare in Canada. East Asia is irrelevant. I would not support allowing this format. Jimp 10:52, 13 September 2013 (UTC)

Falklands units

Kindly take note that there is currently a discussion at Wikipedia:Miscellany for deletion/Wikipedia:WikiProject South America/Falkland Islands work group/Units. -- Ohc ¡digame!¿que pasa? 09:42, 17 September 2013 (UTC)

There is a similar discussion on the Falkland Islands talk page. Michael Glass (talk) 13:43, 17 September 2013 (UTC)

kB (or kbit/s) or KB is not ambigious

For purposes of writing English Wikipedia articles, does ambiguity exist about whether kB means 1000 bytes and KB means 1024 bytes? 16:35, 17 September 2013 (UTC)

See recent revert of my edit: https://en.wikipedia.org/w/index.php?title=Wikipedia%3AManual_of_Style%2FDates_and_numbers&diff=573344515&oldid=573336953 "BINARY PREFIXES ARE CONTROVERSIAL; I DEMAND RFC BEFORE THIS IS CHANGED"

I think I'm following protocol, not sure if there is another one for WP namespace. If he means RFC=Request for Comments then feel free to share your opinion. If people take a deep breath and read the section as I changed it, and Kilobyte and maybe the discussion on my talk-page:

https://en.wikipedia.org/wiki/User_talk:Comp.arch#kB_vs_KB

They will see that it is a good change. I know kilobyte is ambigious and megabyte, but written down, just as kbit/s = 1,000 b/s, and KB = 1024 B and the recent change to decimal kilobytes mandated kB=1000 B. The binary prefixes are only "controversial" for MB and up. comp.arch (talk) 16:30, 17 September 2013 (UTC)

I consider kB and KB to be ambiguous because the main standard that serious, academically-oriented organizations refer to, IEC 60027, has not been widely accepted by the popular media, popular software, or manufacturers. Thus there is a vacuum for authoritative statements on this matter.
Also, when statements are made concerning disk files, sometimes base 10 is used and other times binary-related sizes are used, making it hard to tell from context which is intended.
I have not found a quality source that has performed a survey of current use of these terms and can make a definite statement about how these terms are generally used. I must say I discount all positive statements made by editors who have not provided impressive sources to back them up. Measurements are fraught with ambiguity. Jc3s5h (talk) 17:01, 17 September 2013 (UTC)
Considering kB to be ambiguous is rather contrived, but KB most definitely is ambiguous. So changing kB to KB where 1024 B is meant seems justified, but changing the MOS as proposed is not. −Woodstone (talk) 17:21, 17 September 2013 (UTC)
I didn't use a should and mentioned "They are however sometimes mixed up but need not be." But if I know 1000 bytes is meant or 1024 bytes is meant, what should I you do? I see nothing wrong with pointing people to kB and KB (or KiB, it's just not recommented) - if they are not ambigious, as I thought. I think all OSs have changed to kB and decimal now (or use KB for binary). No one officially mixes this up right? comp.arch (talk) 17:58, 17 September 2013 (UTC)
k/K is ambiguous. Enough said.Headbomb {talk / contribs / physics / books} 19:23, 17 September 2013 (UTC)
See, Kilobyte, I and DrSeehas (thanks) recently edited it, and I tried to make it clear that people mix it up (especially when it always meant KB (1024), but just as people mix up mHz and MHz and are wrong, we should not say that it is ambigious when people are just wrong (and the JEDEC standard and IEC never use k with binary or K with decimal). WP:COMPUNIT should use a should in my opinion, but I didn't even dare to go there only not mislead people into thinking they are ambigious, see the edit. comp.arch (talk) 22:00, 17 September 2013 (UTC)
"statements are made concerning disk files", I don't worry to much about accuracy there. I just hate seeing kB in hardware context, such as CPU cache sizes. It is just wrong there and nothing wrong with using kB only in decimal context. comp.arch (talk) 22:24, 17 September 2013 (UTC)
At present, the MOS explicitly recommends to use a capital "K" prefix for binary units (1024), as this is what is meant most of the time when someone writes "KB" (probably because this is what is typically used in operating system messages dealing with memory or file sizes rather than speeds). It is also standardized in JEDEC. (Alternatively, the IEC "Ki" prefix can be used for binary units, but since this form is not widely used outside sciences we allow it only in certain rather specific scenarios as detailed in the MOS.) So far, so good.
What is still missing - and we should therefore add it - is the opposite recommendation to use a lower-case "k" prefix when the decimal unit (1000) is meant. While this won't solve the potential ambiguity and we cannot enforce it, it would at least provide some guidance to editors running into the problem and having to make a decision. They may implicitly make this decision already given that we recommend a capital "K" for 1024, but I think it would be better, if we'd recommend it explicitly.
In the long run, this would help reduce the number of occurances where "kB" was used for binary units and "KB" for decimal units and the correct type cannot be determined out of the context of the article.
Such a recommendation wouldn't help the case for "M", "G", "T" etc (unless we would allow the IEC prefixes to be used for binary units more often), but since it wouldn't introduce any new inconsistencies either, let's at least improve the situation for "k"/"K" somewhat.
--Matthiaspaul (talk) 20:28, 17 September 2013 (UTC)
I am not advocationg changing anything about the other SI prefixes (binary prefixes in general), and agree to everything you say. I'm not sure what to do there or recommend. Maybe this is just a lost cause and I should not correct kB->KB where I think appropriate. People have reverted (or commented) and pointed to COMPUNITS. comp.arch (talk) 22:10, 17 September 2013 (UTC)
The MOS currently states:
[...]
Follow these recommendations when using these prefixes in Wikipedia articles:
  • Specify if the binary or decimal meanings of K, M, G, etc. are intended as the primary meaning. Consistency within each article is desirable, but the need for consistency may be balanced with other considerations.
[...]
  • A capital K can be used for "kilo-" when it means 1024 in computing contexts.
[...]
What, if we make this the first item in the list and change it as follows:
[...]
Follow these recommendations when using these prefixes in Wikipedia articles:
  • Following the SI standard, a lower-case k should be used for "kilo-" whenever it means 1000 in computing contexts, whereas a capital K should be used instead to indicate the binary prefix for 1024 according to JEDEC. (If, under the exceptions detailed further below, the article otherwise uses IEC prefixes for binary units, use Ki instead).
  • Do not assume that the binary or decimal meaning of prefixes will be obvious to everyone, therefore explicitly specify the meaning of k and K as well as the primary meaning of M, G, etc. in an article. Consistency within each article is desirable, but the need for consistency may be balanced with other considerations.
[...]
--Matthiaspaul (talk) 23:58, 17 September 2013 (UTC)
I think I can live with this suggestion since the MoS is supposed to be "best practices" but I think we all know that "therefore explicitly specify the meaning of k and K as well".. will not be followed be people, however I see no good solution. In articles like Apple A7 and similar I see KB signaling binary kilobyte (the kibibyte) and I even liked to kibibyte and not kilobyte. See edit: https://en.wikipedia.org/w/index.php?title=Apple_A7&diff=574076414&oldid=574041777 I linked MB to Mebibyte (and similar for GB) also to signify that I do not mean 1,000,000 bytes. Maybe you view these links as fulfilling the MoS guidelines. For people in the know they already know that binary must be intended in this context anyway but for others they can click KB if they find it peculiar that kB is not used.. This is the first time I'm involved in (MoS) vote. Should it happen soon? The discussion seems to have died. comp.arch (talk) 18:47, 22 September 2013 (UTC)
Since this is just a minor refinement or clarification of what was already stated in the MOS implicitly and it does not negate anything previously stated there (and therefore it won't have any huge impact on existing articles, hopefully just give slightly better directions for future edits), I just edited it accordingly. Nothing is hammered in stone, and if someone objects, we'll further refine it, seeking for the best-most possible solution as we always do. --Matthiaspaul (talk) 21:35, 22 September 2013 (UTC)

* Comment Some things justify a fixed standard only on the principle of "voteffer iss not specifically permitted iss verboten; voteffer is specifically permitted iss compulsory." A healthy dose of common sense commonly proves fatal to uninured constitutions. There decidedly should be no standard here:

  • partly because there is no universal standard,
  • partly because if there were such a standard and it were widely observed it would be confusing and a source of error,
  • partly because it hardly ever makes a material difference in everyday usage (error of less than one part in 40, too little to matter in typical calculations of disk space etc), and
  • partly because in the rare circumstances where it does matter, its justification would require that it must matter enough to justify explicitly and conspicuously stating the convention being observed, as well as its application. If it does not matter even that much, it is decidedly better not to waste reader time and bandwidth on such trivialities.
The whole thing in any case is not worth MoS wars on such pseudoconcerns. Any sane standard would require that if omission of an explicit standard is practical, it should be omitted accordingly, and that where in exceptional cases some explicit convention proves desirable, the convention be stated in context. JonRichfield (talk) 12:39, 2 October 2013 (UTC)

Comment It will always technically be ambiguous, and that's ok. People understand what is needed from context. If I send someone out to get "4 gig of parity memory for a PC", they come back with memory totaling 232 × 9 bits. If I'm getting "33.75 Mbps download speed on my internet connection", it means I'm receiving at a rate of 33,750,000 bits (4,218,750 bytes) per second. If I order "a key of sugar" for a baking party, I'll be expecting a 1000 g brick. If you happen to want, specifically, the disk drive with a capacity of 40,000,000,000 bytes, and not the one that's 10 × 232 bytes (for some reason), then you had better spell that out, and not rely on anyone to interpret the nuance of letter-case or strange new prefix names.

I tried to find the date of this "K for 1024" JEDEC standard and was unable to, but I know that the only prefix near 1000 when I went to school 30 years ago was emphatically lower-case "k". The only place it meant 1024 was in the computer realm, when speaking of memory and disk space. An upper-case K attracted the more nit-picky instructor's red pen. In practice, when I've seen someone write KB instead of kB (or even Kb or kb in a context where bits don't make sense), I just assume it's a mistake, not an attempt to mean KiB. Until/unless a whole generation of students is taught and uses the K=1024 standard (and figures out what to do with the more important M, G, and T), it's hard to imagine it will be widespread enough to be unambiguous. —[AlanM1(talk)]— 23:45, 2 October 2013 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Manual_of_Style/Dates_and_numbers/Archive_140&oldid=1144427607"