Jump to content

Wikipedia talk:Manual of Style/Dates and numbers: Difference between revisions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Content deleted Content added
Line 1,383: Line 1,383:


:Anyway, I think the examples you provided are perfectly acceptable. It's a shame that the examples given in WP:DATERANGE ("{{xt|They travelled June{{nbsp}}3{{nbsp}}{{ndash}} August{{nbsp}}18 of that year}};{{nbsp}} {{xt|They travelled 3{{nbsp}}June{{nbsp}}{{ndash}} 18{{nbsp}}August}}") do not include actual years. I don't think we necessarily need ''additional'' examples ([[WP:CREEP]]), but perhaps we could revise these examples ({{xt|They travelled June{{nbsp}}3{{nbsp}}{{ndash}} August{{nbsp}}18, 2001}};{{nbsp}} {{xt|They travelled 3{{nbsp}}June{{nbsp}}{{ndash}} 18{{nbsp}}August 2001}}) for the sake of clarity? <small>—'''[[User:sroc|sroc]]'''&nbsp;[[User talk:sroc|&#x1F4AC;]]</small> 11:47, 8 March 2014 (UTC)
:Anyway, I think the examples you provided are perfectly acceptable. It's a shame that the examples given in WP:DATERANGE ("{{xt|They travelled June{{nbsp}}3{{nbsp}}{{ndash}} August{{nbsp}}18 of that year}};{{nbsp}} {{xt|They travelled 3{{nbsp}}June{{nbsp}}{{ndash}} 18{{nbsp}}August}}") do not include actual years. I don't think we necessarily need ''additional'' examples ([[WP:CREEP]]), but perhaps we could revise these examples ({{xt|They travelled June{{nbsp}}3{{nbsp}}{{ndash}} August{{nbsp}}18, 2001}};{{nbsp}} {{xt|They travelled 3{{nbsp}}June{{nbsp}}{{ndash}} 18{{nbsp}}August 2001}}) for the sake of clarity? <small>—'''[[User:sroc|sroc]]'''&nbsp;[[User talk:sroc|&#x1F4AC;]]</small> 11:47, 8 March 2014 (UTC)

== UK horses' heights ==

At the moment MOSNUM says that horses and other equines are measured in hands. This may be true, but it doesn't seem to be the whole truth.

Equine World UK says:
:The term used for height measurement of a horse is "hands high" or "hh". Often the height is just over a number of hands eg 16 hands and 2 inches and the height is therefore referred to as 16.2 hh. With Europeanisation horses are also now being measured in centimetres, particularly small ponies. See conversion table for horse's height in hh and cm. [http://www.equine-world.co.uk/about_horses/horse_height.asp]

The Joint Measurement Board website doesn't appear to mention hands but its references to measurements seem to be centimetres first.
:7. The animal must be positioned for measurement with the front legs parallel and perpendicular; the toes of the front feet should be in line, allowing not more than 1.5 cm (½ in) difference. Both hind- feet must be taking weight and as near perpendicular as possible; the toes of the hind feet should be not more than 15 cm (6 in) out of line with each other.

:8. The animal’s head must be in its natural position in relation to its neck, positioned so that the eye is neither more than 8 cm (3in) below, nor more than 8 cm (3 in) above the highest point of the withers.

British Showjumping has this question and answer on its website:

:If a pony (148cms or smaller) has been registered as a horse can it be registered back as a pony?
::Yes, however the request must be sent to the British Showjumping office in writing and must be accompanied by a valid up to date JMB Height Certificate stating that the animal is 148cms or below.

On the other hand, Blue Cross uses hands. Even when it appears to use kilograms for their weights (but they work it out with a weight tape in inches that works out an approximate weight in pounds that is divided by 2.2 to give you kilograms!) see [http://www.bluecross.org.uk/80161-80956/how-to-check-the-weight-of-your-horse.html]

Scottish Horse had this headline: Measuring Horses and Ponies - ongoing controversies [http://www.scottishhorse.co.uk/horsecare/veterinary/measuring-horses-and-ponies-ongoing-controversies.10329857]

Here were some problems:
*...it is the inescapable fact that there is no rigid anatomical connection between the withers and the feet that touch the ground. *...simply allowing an excited pony to stand and relaxed can, in my experience, cause the height to drop by as much as 6cm. *...Measurements are taken without shoes and simply trimming the heels and leaving the toes long can reduce height by more than cm. (sic)
*Lowering the head to the ground can significantly reduce the height at the withers – by nearly 2cm – whereas raising the head can increase height by over 2cm.

Then there was this passage:

:I distinctly remember, in the line of ponies waiting to be measured at Avenches, Switzerland in 2008, a grey horse that looked at least 15.2hh. Fearful of creating an international incident I anxiously awaited its arrival at my station. It settled into the stable and when I put the stick onto its withers the horizontal bar read over 156cm. But the withers instantly started to shrink under the bar – as if contact with the stick had triggered a reflex – and kept sinking until, within a couple of minutes, the pony measured 151.5cm. Many of the ponies at this year’s championships showed similar reactions, no doubt the results of months of training at home. Why go to all that effort? Putting it bluntly, a European team pony might be worth several hundred thousand Euros, whereas a pony that won’t measure 151cm is practically worthless.

There is no way that I can be dogmatic about ponies and horses. However, it would seem that "Hands for horses and other equines" is perhaps an over-simplification. [[User:Michael Glass|Michael Glass]] ([[User talk:Michael Glass|talk]]) 13:52, 8 March 2014 (UTC)

Revision as of 13:52, 8 March 2014

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

Rfc: Is YYYY-MM an acceptable date format? Part 4

Continuing on from Part 2 and Part 3 above, I will restate it so that contributors brought in for the RFC can see the problem.

The recent (29 Nov 2013) banning of the yyyy-mm format brings about a conflict between parts of MOS but also highlights that the conflict was waiting in the wings as an unknown consequence. The guidelines state:

  1. WP:DATEFORMAT - various formats with spelt out months are allowed (no problem). yyyy-mm-dd (all numbers) is allowed in tables, references and similar places where conciseness is needed. No mention of year and month combos (ie no day of month) at all. It points to Wikipedia:Citing Sources § Citation style, which explicitly allows yyyy-mm-dd.
  2. WP:BADDATEFORMAT - lists various bad formats and the recommended replacement. yyyy-mm was unobtrusively added to the list on 29 Nov 2013 as a single line in a table with no reasoning or rationale given.
  3. MOS:DATEUNIFY - states that only a single format is to be used within an article (some reading between the lines allows the main text to use spelt out months and tables/references/etc to use yyyy-mm-dd.

Articles are free to use references in the yyyy-mm-dd format. This is explicitly allowed. The conflict comes when we get a reference that has only year and month (typical of magazine references). Since BADDATEFORMAT disallows yyyy-mm, we must replace it with a spelt out format such as Dec 2013. But then this causes a conflict with DATEUNIFY, which forces us to replace each and every reference with a spelt out format. In effect, that single line disallowing yyyy-mm means that every article using yyyy-mm-dd in references has a very good probability of being forced to change to a spelt out format. That's a wide ranging effect for a single sentence fragment with no rationale given in the guideline. The rationale given on the talk page is that it can be confused with the date ranges like 2002-03 (ie from 2002 to 2003).

The talk page discussion was only among a small set of contributors over a short period of time, so the repercussions were not obvious and were not thrashed out. After two months of looking for acceptable solutions, none of the solutions presented in Part 2 found consensus and only the following were found to have any followers:

  1. Ban yyyy-mm-dd altogether. Some editors were very much in favour of this and some were very much against it. Unlikely to gain consensus.
  2. Ban yyyy-mm but allow yyyy-mm-dd. Needs an explanation that all yyyy-mm-dd references are allowed but will need to be changed to spelt out dates (eg 7 January 2012 or January 7, 2012) as soon as the first year+month combo is added.
  3. Allow yyyy-mm and hope that readers can use context to understand that it is year and month, not a year range.

Since the December 2013 addition of the banning of yyyy-mm triggered the conflict, I will hide that in the guideline until a result is found.  Stepho  talk  23:06, 3 February 2014 (UTC)[reply]

Survey

Note: 'Support' and 'Oppose' don't work for a 3 way choice; please specify 'Ban yyyy-mm-dd', 'Ban yyyy-mm' or 'Context'

  • Context Most readers that care enough about the date can figure it out without too much stress.  Stepho  talk  23:06, 3 February 2014 (UTC)[reply]
  • Ban yyyy-mm. A reader may not bring the entire article to the library when following up a citation; (s)he may just write down what the reader thinks the date means, for example, write 2010-11 as Nov. 2010. When the issue written down does not exist, reader may have difficulty figuring out the reason for the error. Jc3s5h (talk) 23:22, 3 February 2014 (UTC)[reply]
  • Ban yyyy-mm. We are supposed to be writing articles which are clear and unambiguous, this is not clear and is certainly not unambiguous. People should not have to read the MOS to find out the meaning of something in an article it should be obvious. For similar reasons I would also support a Ban yyyy-mm-dd. Keith D (talk) 01:42, 4 February 2014 (UTC)[reply]
  • Ban yyyy-mm. and any format where the month is not clear and unambiguously represented by its proper name (and not some notional number) -- Ohc ¡digame! 02:07, 4 February 2014 (UTC)[reply]
  • Ban yyyy-mm. It's just too ambiguous and prone to confusion with yyyy-yy (a year range). I can see why people are opposed to yyyy-mm-dd as needing to be interpreted and as more ambiguous than dd mmm yyyy, but I can't work up adequate passion against it. – Jonesey95 (talk) 05:15, 4 February 2014 (UTC)[reply]
  • What is the problem that needs to be solved?  As per Wikipedia:MOSNUM#Ranges, yyyy–yy uses an en dash.  I checked http://reftag.appspot.com/, and curiously it has two different modes (possibly a bug) when asked to convert July 2009 into y-m-d format.  One is "July 2009" and the other is "2009-07".  I also recall contexts in which software deems "July 2009" to occur on the first day of the month.  Since it doesn't seem to be clear, I'd recommend specifying that mmm yyyy format is acceptable in the yyyy-mm-dd context.  Unscintillating (talk) 03:03, 6 February 2014 (UTC)[reply]
  • YYYY-yy should be banned, it causes confusion with YYYY-MM, and that format is used in the world at large. We shouldn't engender confusion just because we are Wikipedia. We can avoid confusion by using YYYY-YYYY. -- 70.24.244.161 (talk) 12:24, 11 February 2014 (UTC)[reply]
  • Context – If the area in question previously uses YYYY-MM-DD especially, or if the prose speaks of months not year-ranges, the reader will be able to infer the correct meaning. If anything should be banned, it would be YYYY–YY, which is purposeless and easily avoided by YYYY–YYYY. Also en dashes are not hyphens. startswithj (talk) 00:36, 13 February 2014 (UTC)[reply]
  • Allow YYYY-MM and ban YYYY-YY. Year ranges should not be using a hyphen, anyway. YYYY-MM is the standard way of representing years and months, as specified by the ISO 8601 international standard, and its national variants. In the case of conflicts, YYYY-MM and YYYY-MM-DD date formats should be preferred. --Joshua Issac (talk) 11:41, 6 March 2014 (UTC)[reply]

Threaded discussion

  • The most likely place for the problem to occur is in references. A date like 2003-08 is unlikely to mean a publication covering multiple years. A date like 2003-04 could mean April 2003 or an anniversary issue covering 2003-2004 but it is usually clear from the context which it is. The majority of readers won't care anyway and for the few that want to look it up it will become obvious quite quickly. For the few times where it does represent a problem (eg the magazine had both an April 2003 issue and a 2003-2004 anniversary issue), then that article can choose one of the other date formats.  Stepho  talk  23:06, 3 February 2014 (UTC)[reply]
  • I know this is a personal opinion, but to my eye, "2003-08" just looks like a typo. My eye comes to a complete halt and my brain is forced to wonder if someone simply made a mistake of some sort. Did they mean "2003-04"? "2007-08"? Did they forget the day (or the second half of the year) in a YYYY-MM-DD date, like "2001-03-08"? I don't have a grammar or style argument here, it's just a visceral thing that happens when I encounter one of these odd creatures. – Jonesey95 (talk) 05:20, 4 February 2014 (UTC)[reply]
(This appears to be the freshest part of the discussions, feel free to move my comment to a better place.) Thanks to Trappist_the_monk for the pointer on Category talk:CS1 errors: dates, I haven't looked into any MOS pages for ages, replacing GB by GiBi gibberish would annoy me; and some ISO "standards" are certainly crap. However, RFC 3339 and the 1997-09 note published by the W3C are no nonsense, and it's the job of the MediaWiki software to display YYYY-MM-DD or YYYY-MM in the form chosen in the preferences or some default chosen by the site admins for editors without an account or preferring to edit without logging in. It's not the job of MOS guidelines. My 0,02€ –Be..anyone (talk) 14:18, 5 February 2014 (UTC)[reply]
Date autoformatting has been resoundingly rejected by the community for many reasons, see footnote 7 of MOSNUM. One of the reasons is you can't get the commas right. Consider "the meeting is set for July 22, 2014, at Grand Central Terminal." If "22 July 2014" is substituted for "July 22, 2014" there will be an incorrect comma. Jc3s5h (talk) 14:43, 5 February 2014 (UTC)[reply]
What is incorrect about the comma in the clause "the meeting is set for 22 July 2014, at Grand Central Terminal"? --Joshua Issac (talk) 12:17, 6 March 2014 (UTC)[reply]
  • Seems like the yyyy-mm-dd haters have all chimed in for 'Ban yyyy-mm'. So be it. Now we are back to where we were 2 months ago. What do we do when we want to add a month magazine as a reference in an article chock full of yyyy-mm-dd references? Since yyyy-mm is not allowed then we are forced to use mmm yyyy. MOS:DATEUNIFY then forces us to change each and every other reference over to a spelt out form. That's a rather radical change that is not obvious from the current text of the guideline. Two solutions are:
    • Add text in the guideline to make it clear that yyyy-mm-dd dates are okay only until the first year+month reference is added, then they become illegal due to MOS:DATEUNIFY.
    • Relax MOS:DATEUNIFY so that July 2006 and 2006-06-01 can sit side-by-side.
Both of these solutions were proposed in Part 2 and neither found favour. But since yyyy-mm is banned, we have to select one of them.  Stepho  talk  23:02, 6 February 2014 (UTC)[reply]

History

Our use of YYYY-MM-DD dates is pretty much an accident. In the early days of Wikipedia, the concept was to use YYYY-MM-DD dates and link them— the user date preference would then show them in the users desired format. As early as 2006, it was realized that readers who were not logged in would see dates in the YYYY-MM-DD format. In late 2008, the consensus was to stop linking dates— dates were delinked and sometimes reformatted, but no changes to the MoS was made as to formats. There have been several discussions about YYYY-MM-DD date formatting over the years, with little or no result.

For discussions on date formats, mainly in the context of citation templates, see User:Gadget850/FAQ/YYYY-MM-DD dates. --  Gadget850 talk 20:45, 27 February 2014 (UTC)[reply]

RFC: Connection between ISO 8601 standard and YYYY-MM-DD date format

The international standard ISO 8601 describes the date format YYYY-MM-DD (for example, 20 May 1875 would be written 1875-05-20). The Wikipedia:Manual of Style/Dates and numbers allows this format in articles in situations where conciseness is important, and also recognizes the restriction contained in ISO 8601:

  • that dates in the format must be Gregorian calendar dates, and
  • that the year must be at least 1583.

(See the table here, left column, fifth row).

Should these restrictions be removed, so that the format could also be used for Julian calendar dates (for example the birth date of Gregory XII could be written 1503-01-07)?

Jc3s5h (talk) 19:05, 26 January 2014 (UTC)[reply]

Discussion of ISO 8601 and YYYY-MM-DD

As the originator of the RFC, I oppose this change, on the grounds that ISO 8601 and the YYYY-MM-DD have been mentioned together in the "Manual of Style/Dates and numbers" since 2003 (although I don't think there has ever been a well-thought-out adoption of the standard, with consideration of all the complications in articles containing old dates). I also oppose the change because I cannot find any reliable source that describes the YYYY-MM-DD format without also mentioning that it is part of ISO 8601 and that the dates must be Gregorian (except some brief sources such as ISO's capsule description). It would novel for Wikipedia to create a parallel meaning for this format that allows the format to represent Julian calendar dates. Jc3s5h (talk) 23:28, 25 January 2014 (UTC)[reply]

RFCs consume a great deal of community time and energy, especially with multiple related RFCs going on already. It would have shown respect for other editors involved in the current discussion on this very topic to have discussed with them whether to start an RfC, and if so, how to word it. Earlier today I explained ([[#noISOrfc|see prior section) why I think an RFC isn't required, and instead of answering that, you pull everyone further into this vortex of pointlessness by doing this.
You say, "I cannot find any reliable source that describes the YYYY-MM-DD format without also mentioning that it is part of ISO 8601 and that the dates must be Gregorian." It doesn't matter whether there are sources "describing" the format that don't mention Gregorian etc. I've got something better -- a bunch of sources using the YYYY-MM-DD format: [1] [2] [3] [4] [5] [6] [7] [8]. These are from the 1970s, proving that people were using YYYY-MM-DD, with no thought of 8601 or it restrictions, long before 8601 even existed. EEng (talk) 05:22, 26 January 2014 (UTC)[reply]
Thank you for this list of sources; I have made a copy of the list for future reference. I felt sure the use of the YYYY-MM-DD format would have arisen spontaneously due to its obvious advantages in computer sorting, but I had not come across any pre-1988 sources that used it. I would point out that the source numbered 20 does not use the format. Jc3s5h (talk) 14:02, 26 January 2014 (UTC)[reply]
I found those by searching Googlebooks for one or two specific dates, in quotes, such as "1974-08-23". Obviously there are tens of thousands more for different specific dates, if not more. The fact that you seem to feel this is an accomplishment worth saving for future reference brings into serious doubt the breadth of your experience in real-world usage. EEng (talk) 15:18, 26 January 2014 (UTC)[reply]

Let me point out the discussion above in section Is YYYY-MM an acceptable date format? Part 2. Three editors specifically support not just the YYYY-MM-DD format, but ISO 8601. (You'd have to ask them whether they had thought about the Julian/Gregorian issue.) The edits may be found at:
Startswithj (talk) 03:32, 13 January 2014 (UTC)
TrevorD (talk) 01:18, 21 January 2014 (UTC)
Zanhe (talk) 00:49, 26 January 2014 (UTC)

Additional statements to that effect may be found at Wikipedia:Mosnum/proposal on YYYY-MM-DD numerical dates. I have not noticed any editors, except EEng, propose that we set up our own YYYY-MM-DD format with rules different from the ISO 8601 rules. Jc3s5h (talk) 14:20, 26 January 2014 (UTC)[reply]

Jc3s5h (talk) 14:20, 26 January 2014 (UTC)[reply]

As stated earlier people who hang around MOS aren't normal readers. Normal readers don't give a shit about 8601 -- don't even know about it. This is a complete waste of time. EEng (talk) 15:18, 26 January 2014 (UTC)[reply]

Can someone please explain, in clear English, the reason we should care about Gregorian v. Julian dates with respect to the YYYY-MM-DD format? When I see YYYY-MM-DD, my (American) brain says "Oh, that's MMMM DD, YYYY." Is that wrong? Am I doing something wrong in reading 1309-12-24 as December 24, 1309? The only difference I know of between Julian and Gregorian dating is that a couple of weeks once went missing. Are there different month names? A different number of months? Help me understand why I should care about the distinction. Thanks.

Also, if possible, please supply actual examples from actual articles of the use of YYYY-MM-DD that may be confusing because of the difference between Julian and Gregorian dating. That would help too. – Jonesey95 (talk) 15:42, 26 January 2014 (UTC)[reply]

You have it exactly right. 1776-07-04 means July 4, 1776. Now, that may still leave the question of whether that's meant to be interpreted as Julian vs. Gregorian, and maybe Wikipedia has good rules or bad rules for how articles are to clarify that, but the situation is exactly the same regardless of whether the date was expressed as 1776-07-04 or as July 4, 1776. That's it. End of story. Everything Jc and
Some of the other discussions I have pointed to advocate the YYYY-MM-DD date for all dates in citations. In the article George III of the United Kingdom we see citations (footnote no. 124) to the London Gazette for seven specific dates beginning 1748 and ending 1750; these dates are in the Julian calendar. If the YYYY-MM-DD format were allowed for these dates, they might have been expressed in that format.
As for your example of 1309-12-24, if you see it in Wikipedia, it's an error (for now). If it's someplace else, and you didn't agree with the person who wrote the date to allow dates that early, then it isn't in conformance with ISO 8601. So you would have to determine from context and whatever you know about the author whether it's intended to be a Gregorian or a Julian date. (If it's Gregorian, the corresponding Julian date is 16 December 1309, or if it's Julian, the corresponding Gregorian date is 1 January 1310.) Maybe the author thinks you consented to use ISO 8601 for such an early date, but you didn't. Maybe the author is using RFC 3339, a simplified ISO 8609, which retains the Gregorian calendar restriction but allows years "between 0000AD and 9999AD" [sic]. Jc3s5h (talk) 16:31, 26 January 2014 (UTC)[reply]
An example of a potentially confusing use of a Julian date in the YYYY-MM-DD format is footnote 6 in Capacitor, which refers to a letter of Benjamin Franklin dated "1749-04-29". As long as the website linked to is still around, one can work out that this is actually a Julian date. But if the website stopped working and one had to look for the letter elsewhere, and imagined the editor had followed the rules, one would be looking for the wrong date. Of course, one would eventually figure it out, but it would make it a little harder. Jc3s5h (talk) 18:27, 26 January 2014 (UTC)[reply]
You haven't answered Jonesey's question: How does the fact that the date is given as 1749-04-29, instead of as April 29, 1749, affect anything? The answer is that it doesn't. As always, the reader has to look elsewhere to know whether this is a J date or a G date, and that's true no matter what format it's given in. You may as well argue that if the date is printed in Arial font that somehow means something different than if it's printed in Courier. It's absurd. EEng (talk) 02:41, 27 January 2014 (UTC)[reply]
Perhaps in terms of explanation, it might makes sense to point out Conversion between Julian and Gregorian calendars. The format of the calendars is the same, except that the Julian calendar includes leap years on all multiples of 4, whereas the Gregorian calendar skips them in century years not divisible by 400. The calendars are the same between 200 AD and 300 AD, and move out of sync by 3 days every 400 years.
The ISO standard requires the use of dates using the Gregorian Calendar, and does not allow dates before October 1582 (when the first countries made the switch). The reason is that, for the purposes that ISO standards are generally used for, absolute precision is necessary. If you don't know what calendar you're using, you could be several days out. If you use dates before 1582, you're using dates that were never rendered as such at the time.
Wikipedia has never adopted the ISO standard, and has somewhat different needs: we need to render dates prior to 1582 and there's also the problem that not all countries switched in 1582. The British Empire (including the 13 Colonies) did not switch calendars until 1752, for example, and Greece didn't switch until 1923. Insisting on Gregorian dates may be at odds with the historical practice in many countries, and culturally significant dates (e.g. Fifth of November) were not necessarily converted - possibly causing strange results.
The concern is that someone who knows the ISO standard will interpret 1515-06-20 as being 20 June 1515 Gregorian (10 June 1515 Julian), whereas the author intended it to mean 20 June 1515 Julian (30 June 1515 Gregorian). Kahastok talk 17:14, 26 January 2014 (UTC)[reply]
Like all standards, 8601 says it only applies if the everyone involved agrees it implies. Anyone who knows the standard will know that, and know therefore that it doesn't apply. This is an absurd concern. EEng (talk) 02:41, 27 January 2014 (UTC)[reply]
Maybe it is. I don't believe I've expressed an opinion on the matter (other than that all YYYY-MM-DD dates should be dropped entirely). I actually think the proportion of readers who know the standard is likely to be minuscule, and thus that the fact that a date like 1605-11-15 in England is formally unambiguous does not mean that it is not ambiguous in practice. Kahastok talk 18:43, 28 January 2014 (UTC)[reply]
It is ambiguous in practice! Dates in the 1500s, 1600s, and 1700s (and even later, in a few countries) are, in general, subject to potential confusion about whether they're G or J -- the reader has to know what calendar was in use in the country under discussion, and of course a good article will explain that to him. The rules are at WP:JG.
But however good or bad are the provisions for helping readers understand the J/G issue, one thing's for sure: the date 1623-05-23 is no more nor less subject to such confusion on that than is May 23, 1623. So there's no reason to special restrict YYYY-MM-DD to Gregorian dates only.
The idea that they should be so restricted stems from the concern that maybe some readers will know about ISO 8601, which wants YYYY-MM-DD to be used only for G dates -- so maybe the reader will assume that 1623-05-23 must be G, instead of looking around in the article to find out whether it's G or J, as he has to anyway if he'd read May 23, 1623 instead. But as you say, a miniscule number of readers know about 8601, so this is a false concern.
EEng (talk) 23:58, 28 January 2014 (UTC)[reply]

Remove these silly restriction

There seem to be two reasons given for these restrictions:

  • (1) the idea that somewhere it was decided that when dates in this format are used in WP, they should adhere to 8601 -- and 8601 has these restrictions. And --
  • (2) the idea that even if 8601 doesn't actually apply, people might think it applies, and assume that amy date in YYYY-MM-DD format is Gregorian. Therefore, we have to cater to that mistaken assumption by only putting Gregorian dates in YYYY-MM-DD format, lest people be misled.

No one seems to be able to point to where (1) was decided on, and (2) assumes that more than a tiny fraction of readers have any notion of 8601 and that that those who do know about it are blind to its provision that you mustn't assume it applies in a given situation unless you're told it does.

I'll repeat what I said above:

To any sensible reader 1700-01-01 means January 1, 1700 -- nothing more nor less, with no implication of Gregorian vs. Julian. That leaves the reader exactly where he should be, which is exactly where he'd have been had the article said January 1, 1700 -- he needs to read WP:Manual_of_Style/Dates_and_numbers#Julian_and_Gregorian_calendars, read the article's footnotes, or whatever, to decide the Julian/Gregorian question (assuming he cares).

If a reader's dumb enough to write to us thus:

Dear Wikipedia: The article on Alexander II says he was assassinated on 1888-03-13. That looks like 8601 so I just assumed it is without further inquiry and without reading what the article says about its use of New Style / Old Style. Because I put that down on the final exam in a course I was taking on Tsarist Russia, I failed the class. I'm gonna sue you!

-- then we'll write back thus:

Dear Reader: You are an idiot. If you know enough about standards and such to know about ISO 8601, you should also have known enough not to make an assumption like that. Go suck eggs.

I therefore propose that, at the point in MOS where the YYYY-MM-DD format is explained, the current must-be-Gregorian restrictions be removed and the following substituted:

A date in YYYY-MM-DD format should not be assumed to conform to ISO 8601 nor assumed to be in any particular calendar system (e.g. Julian or Gregorian).

Then we can all get back to building actual content. EEng (talk) 04:48, 26 January 2014 (UTC)[reply]

Damn! This discussion seems to fragment at a moments notice, making it hard to keep a contiguous train of thought. My reply seemed to be better placed in the #ISO 8601 section above as a reply to other comments. It is dated 09:17, 26 January 2014 (UTC).  Stepho  talk  09:27, 26 January 2014 (UTC)[reply]
Is that 26 January Gregorian, or Julian? EEng (talk) 09:57, 26 January 2014 (UTC)[reply]
The proposal is inadequate. If carried out as stated, the cell in the "Acceptable date formats" table would change:
Full year, hyphen, two-digit month, hyphen, two-digit day; use only with Gregorian dates between 1583 and 9999[3].
Presumably the footnote would be changed to read 3A date in YYYY-MM-DD format should not be assumed to conform to ISO 8601 nor assumed to be in any particular calendar system (e.g. Julian or Gregorian).
Taken in conjunction with the instruction 'Do not "zero-pad" month and day, except in all-numeric (yyyy-mm-dd) format', this means the proper format for 19 August 14 AD would be 19-08-14. Also, there would be no prescription against expressing the first day of the Julian calendar as 45-01-01 BC. Jc3s5h (talk) 14:33, 26 January 2014 (UTC)[reply]
To Jc3s5h. Yes, amending MOS would require changing the text/tables in MOS. Remove all mention of ISO 8601 in MOS and put in my proposed rule that says how to interpret a date to be in which of the 3 eras (Julian, illegal, Gregorian). Your zero pad argument is an argument about whether yyyy-mm-dd is to be used at all and is not relevnent my proposal of how to disamgiuate date formats between the Julian and Gregorian calendars (which is a problem for all date formats). If you raise that argument in a different section then I will be happy to give answers to your argument.  Stepho  talk  00:43, 27 January 2014 (UTC)[reply]

You make yourself ridiculous by raising trivially solvable issues as if they're fundamentally fatal flaws. I believe this would address your concerns:

Use YYYY-MM-DD (all-numeric) format only for AD dates; zero-pad the year to four digits and the month and year each to two digits. Editors should not use this format to imply conformance with ISO 8601, or that the date represented is to be interpreted in any particular calendar system (e.g. Julian or Gregorian); nor should readers assume such conformance or infer any such interpretation. [restated in a section below]

You'd better look up prescription and proscription in a dictionary. EEng (talk) 16:02, 26 January 2014 (UTC)[reply]

I don't think we're in a position to be telling readers how to interpret dates, because very few readers will ever come to this page. If we feel the need to explain what our dates mean, it probably means that the format is unsuitable.
My own view is that we should deprecate all formats of all-numeric dates, regardless of circumstance, because of the potential for them to be misunderstood and because they are relatively difficult to parse. I note in particular usages in tables such as on Enlargement of the European Union, where the presentation of key dates is practically impenetrable. I see no significant reader benefit in using all-numeric dates over short-form text dates (e.g. "16 Jun 1995"). Kahastok talk 20:16, 26 January 2014 (UTC)[reply]
I agree with Kahastok that avoiding all-numeric dates would be best in the context of an encyclopedia, but in view of this failed proposal, I don't think that's going to happen. Jc3s5h (talk) 20:49, 26 January 2014 (UTC)[reply]
To Jc3s5h. I looked at Enlargement of the European Union and did not find any impenetrable presentation of dates (with one exception which I will return to). I saw a number of tables using yyyy-mm-dd. Given that the user knows they are dates (the table heading could be a little clearer to say 'Date issued'), the user must sure be able to work out that the 4 digit numbers are years. After that, the user can easily see that the last field has numbers that can be months (eg contains 31). Which leaves the middle field as months (which only contains the numbers 01-12). To me this is similar to spelling 'centre' and 'center'. It may not be in the form that some readers like but it is not impenetrable. And like many things, it also becomes easier the more you use it.
Since we're here, I will also answer your earlier comment about 19-08-14. If it was in isolation then yes, it would cause trouble with somebody not familiar with MOS. However, it is not likely to appear in isolation. Its use is not allowed in prose. It is most likely to appear in references or tables. In both cases there will be many other dates to compare it to and the reader is then able to compare them in the manner I showed in the previous paragraph. In the very rare case where all references or the entire table have 2 digit years then it would be wiser for the editor to use some judgement and not use yy-mm-dd for that article. This rare case is not a reason to outlaw it for all articles.  Stepho  talk  00:43, 27 January 2014 (UTC)[reply]
Stepho-wrs, the problem with the number of digits in the year has been resolved by EEng's rewrite of his proposal (although whether to allow negative years, the year 0, or the BC prefix could use further clarification). Of course, in my example of "19-08-14", this means the fourteenth day of August in the year of our Lord nineteen, since both the old and new proposal require a full year. Jc3s5h (talk) 13:43, 27 January 2014 (UTC)[reply]
Given that the user knows they are dates..., the user must sure be able to work out...
And that's where I stop you.
If the user is having to "work out" what the date is, then we're doing it wrong. There is nowhere in the world where native English speakers would have to do any working out to understand "28 Apr 2008" or "Apr 28, 2008". Any date format that involves the reader having to work anything out is a problem. And in this case, part of the problem is that if you spend time working out the dates, you lose the wider points that the dates are being used to make. This is a bad thing, and there's no need nor benefit in it. Kahastok talk 18:43, 28 January 2014 (UTC)[reply]
I was just about to say something along the lines of what Kahastok has just mentioned. Stepho, you've just given us a paragraph on how we could easily figure out what these strings of digits and dashes mean. Consider, though, how long an explanation you'd need if the dates were in dmy format (like the rest of the article). This article is a good example of why we should ditch these ymd dates altogether. Were the dates in a normal format it would be much easier to digest (no figuring out required). Jimp 09:34, 29 January 2014 (UTC)[reply]
I wish we could ditch the YYYY-MM-DD format, but previous attempts indicate we can't. Jimp, you haven't expressed an opinion of whether it is better to decide following the ISO 8601 restrictions is unrealistic; if we discard the restrictions, we would become the only publication I know of that explicitly says it's OK to use the YYYY-MM-DD format to express Julian calendar dates. Jc3s5h (talk) 10:20, 29 January 2014 (UTC)[reply]
Do you know of any publication (book, magazine, journal, newspaper -- not some data interchange standard) which says anything either way about that? I predict the answer is no, because it would never occur to anyone to bother. The only reason I included the language explicitly allowing Julian dates is for the avoidance of doubt, given that we've had the language rejecting them for so long. EEng (talk) 01:39, 30 January 2014 (UTC)[reply]
Let's not give up hope on ditching this eye-sore. I agree that allowing YYYY-MM-DD without the restrictions is likely to make things even more confusing. Jimp 08:38, 3 February 2014 (UTC)[reply]
But that's not this discussion. Can we agree on the rules for YYYY-MM-DD assuming they will exist? Please? I've worked so hard on this. <whimper> Take pity. EEng (talk) 09:04, 3 February 2014 (UTC)[reply]
No, that's not this discussion, I just thought I'd mention my opposition to YYYY-MM-DD ... (again, in case it hadn't been noticed). Of course, we can't agree on the rules for YYYY-MM-DD assuming they will exist. When do people ever agree on things on this page? Jimp 09:50, 3 February 2014 (UTC)[reply]
Never. It's a special circle of hell -- worse than the one where you stand on tippu-toe in raw sewage up to your nose, but not as bad as the one in which you're forced to was the Indy 500 for eternity. <Zoooooooouum><Zooooooooooooum><Zoooooooooooooooooooooooooooom> EEng (talk) 13:48, 3 February 2014 (UTC)[reply]

Use of YYYY-MM-DD for years prior to 1583 CE

(adding subsection for ease of access and to discontinue characterization of any position as "silly")

The case that ISO 8601 might require conversion of Julian (or old style) dates to proleptic Gregorian dates hadn't occurred to me, and I'm unsure why the ISO made this requirement. However, I would guess the average user likely sees YYYY-MM-DD as simply a rearrangement of DD-MM-YYYY or MM-DD-YYYY. Therefore, I would support extension of YYYY-MM-DD to earlier dates, perhaps also with stipulation that they be accompanied by "O.S." or "Julian" (as we already commonly do in similar case, such as Bach's birthday). startswithj (talk) 19:55, 26 January 2014 (UTC)[reply]

The digital copy of the standard that I downloaded before it became hard to find has an introduction, which indicates some of the goals were preventing ambiguity and confusion in multi-national environments. There is no mention of it being easy to sort dates on a computer with off-the-shelf features of the operating system or software, but informal descriptions of the standard often emphasize this point. I don't think you could use off-the-shelf sorting features and sort Julian and Gregorian calendar dates into their proper chronological order. Jc3s5h (talk) 20:25, 26 January 2014 (UTC)[reply]
There's no mentioning of grass being green, either. — Dsimic (talk | contribs) 20:32, 26 January 2014 (UTC)[reply]
Well said. Anyone who can say with a straight face that no part of the motivation for adopting YYYY-MM-DD dates is that they are easy to sort, obviously has no idea what he's talking about. EEng (talk) 03:36, 27 January 2014 (UTC)[reply]

Proposed new text for MOS:DATEFORMAT re YYYY-MM-DD dates

In an earlier section I advocated removing the old restrictions, but didn't say what should replace them. Here's a concrete proposal. Remove the current text, which reads

(Where used: Only in references, tables, lists or areas where conciseness is needed -- see Wikipedia:Citing Sources § Citation style) YYYY-MM-DD: use only with Gregorian dates between 1583 and 9999. (Note: The year restriction on YYYY-MM-DD dates stems from the possibility they will be assumed to follow the ISO 8601 standard, which mandates the Gregorian calendar.)

In its place put the following:

earlier versions
(Where used: Only in references, tables, lists or areas where conciseness is needed -- see Wikipedia:Citing Sources § Citation style) Use YYYY-MM-DD (all-numeric) format only for A.D. dates; zero-pad year to four digits, and month and year each to two digits. Editors should not use this format to imply conformance with ISO 8601, nor to imply that the date represented is to be interpreted in any particular calendar system (e.g. Julian calendar or Gregorian calendar). Nor should readers assume such conformance or infer any such interpretation.
(Where used: Only in references, tables, lists or areas where conciseness is needed -- see Wikipedia:Citing Sources § Citation style) Use YYYY-MM-DD (all-numeric) format only for A.D. dates (though A.D. or AD should not be specified – 1776-07-04 not 1776-07-4 AD). Zero-pad year to four digits, and month and day each to two digits. Editors should not use this format to imply conformance with ISO 8601, nor to imply that the date represented is to be interpreted in any particular calendar system (e.g. Julian calendar or Gregorian calendar). Nor should readers assume such conformance or infer any such interpretation.
[Minor fixes per comments] -- EEng (talk) 16:46, 27 January 2014 (UTC)[reply]
(Where used: Only in references, tables, lists or areas where conciseness is needed -- see Wikipedia:Citing Sources § Citation style) Use YYYY-MM-DD (all-numeric) format only for years 1 AD and later (though A.D. or AD should not be specified – 1776-07-04 not 1776-07-4 AD). Zero-pad year to four digits, and month and day each to two digits. Editors should not use this format to imply conformance with ISO 8601, nor to imply that the date represented is to be interpreted in any particular calendar system (e.g. Julian calendar or Gregorian calendar). Nor should readers assume such conformance or infer any such interpretation.
[More minor changes] -- EEng (talk) 21:43, 27 January 2014 (UTC)[reply]
(Where used: Only in references, tables, lists or areas where conciseness is needed -- see Wikipedia:Citing Sources § Citation style) Use YYYY-MM-DD (all-numeric) format only for years 1 AD/CE and later (though AD or CE should not be specified: 1776-07-04 not 1776-07-4 AD or 1776-07-4 CE). Zero-pad year to four digits, and month and day each to two digits. Editors should not use this format to imply conformance with ISO 8601, nor to imply that the date represented is to be interpreted in any particular calendar system (e.g. Julian calendar or Gregorian calendar). Nor should readers assume such conformance or infer any such interpretation.
EEng (talk) 23:28, 29 January 2014 (UTC)[reply]
Replaced {{snd}} with colon; deleted extraneous close paren. —Trappist the monk (talk) 23:40, 29 January 2014 (UTC)[reply]

And, in a nutshell, here's my reasoning: To any sensible reader 1700-01-01 means January 1, 1700 -- nothing more nor less, with no implication of Gregorian vs. Julian. That leaves the reader exactly where he should be, which is exactly where he'd be had the article said January 1, 1700 in the first place -- he needs to read WP:Manual_of_Style/Dates_and_numbers#Julian_and_Gregorian_calendars, or read the article's footnotes, or whatever, to find out whether the date given is Julian or Gregorian. Maybe Wikipedia's way of telling readers whether an article uses G or J dates is good, or maybe it's bad, but whether those dates are expresses as 1700-01-01 or as January 1, 1700 has nothing to do with it.

The fact that ISO 8601 dates are always supposed to be Gregorian iis irrelevant because there's been no decision to adopt 8601 for use in Wikipedia. And talk of how we ought to act as if we've adopted 8601 (because maybe some readers will assume we've adopted 8601) is silly, because normal people don't know anything about 8601, much less assume it applies to something they're reading.

Can we have clear, reasoned supports and opposes for this, please?

EEng (talk) 04:25, 27 January 2014 (UTC)[reply]

  • Support, obviously. EEng (talk) 04:25, 27 January 2014 (UTC)[reply]
  • Weak oppose. This proposal essentially admits defeat about enforcing the Gregorian for pre-19th century dates, which is perhaps the more realistic position. But Wikipedia should not be the only publication to say Julian dates are OK in this format, and I give greater weight to that concern. If it is adopted, it should be modified to more clearly state whether negative years and the year 0 are allowed. Also I presume the era notations AD, CE, BC, and BCE are disallowed, but this should be explicit. Jc3s5h (talk) 13:33, 27 January 2014 (UTC)[reply]
What do you mean by "admits defeat about enforcing the Gregorian for pre-19th century dates"? This has nothing to do at all with whether an article gives a G date or J date -- the rules for that are at WP:JG, and this proposal doesn't change any of that. All that's being proposed is to allow all dates to be presented in YYYY-MM-DD format, whereas now certain dates (i.e. J dates) are forced to be presented in "July 4, 1776 / 4 July 1776"-type format only.
I see no need to say years must be nonzero and nonnegative -- that's implied by "AD-only" provision. EEng (talk) 16:46, 27 January 2014 (UTC)[reply]
By "admits defeat about enforcing the Gregorian for pre-19th century dates" I meant that many editors have never read this page, and although they might have heard of ISO 8601, they've never read it, so they use the YYYY-MM-DD format for Julian dates even though, at present, they shouldn't. It is a difficult rule to enforce.
As for the need to indicate that years less than 1 are not allowed in this format, "AD" does not necessarily imply that. When AD is written immediately before or after a year number, it certainly means the year is a positive year, but when it is not next to a year number, it might be thought to refer to the general concept of numbering years from the Incarnation of Jesus (as estimated by Dionysius Exiguus). Most people would that goes without saying, but someone might regard it as an unnecessary flourish rather than a prohibition of 0, BC, or negative years. The new wording gives a stronger implication for the minimum year being 1, but a specific statement that the first possible date is 0001-01-01 would be shorter and more certain. Jc3s5h (talk) 19:27, 27 January 2014 (UTC)[reply]
You just don't get it. The proposal isn't an "admission of defeat" in enforcement of this "difficult rule to enforce" (i.e. the restriction of YYYY-MM-DD dates to Gregorian only). It's a recognition that the restriction solves an imaginary problem, is illogical and undesirable, and never should have been instituted in the first place.
I've modified the proposal yet again to address your concerns re AD, Dionysius Exiguus, etc. -- how erudite you are!
EEng (talk) 21:43, 27 January 2014 (UTC)[reply]
As suggested by someone privately: The repeat of Prohibition was not an admission of defeat in the campaign to stop Americans from drinking alcohol. It reflected a realization that banning alcohol was a bad idea in the first place. EEng (talk) 05:33, 30 January 2014 (UTC)[reply]
  • Comment: Shouldn't the clause zero-pad year to four digits, and month and year each to two digits read: zero-pad year to four digits, and month and day each to two digits? —Trappist the monk (talk) 13:56, 27 January 2014 (UTC)[reply]
Fixed, thanks. EEng (talk) 16:46, 27 January 2014 (UTC)[reply]
  • Oppose - this looks like a solution in search of a problem, being engineered (or attempted) by literally a handful of people, more or less behind the backs of millions of others who don't even know what you are discussing here on their behalf.
Til Eulenspiegel /talk/ 13:59, 27 January 2014 (UTC)[reply]
  • This is an RFC (though I think it was unnecessary, and I didn't initiate it) so nothing's happening behind anyone's back.
  • You have it backwards. The existing text's restrictions were a "solution" to a nonexistent "problem"; the proposal removes those restrictions, and for the avoidance of doubt explicitly repudiates them.
Does that make sense? EEng (talk) 16:46, 27 January 2014 (UTC)[reply]
<bump> EEng (talk) 23:28, 29 January 2014 (UTC)[reply]
  • Comment – Why would we use restrictive/regressive/religious "AD" (Anno Domini) rather than inclusive/progressive/scientific "CE" (Common Era) for YYYY-MM-DD, which is arguably more relatable to the latter stance than the former? Thank you, startswithj (talk) 18:59, 29 January 2014 (UTC)[reply]
Reply - this has been a contentious issue for years on Wikipedia with an activist minority promoting the newer, more awkward, and less familiar BCE/CE notation, and a majority opposing this gratuitous change for various reasons, not a few finding BCE/CE more offensive than the standard notations. The debating over this involved several hundreds of editors and seemed endless. Finally wikipedia arbitrated a compromise along the lines of the British vs US English and similar disputes: Both forms shall be acceptable on wikipedia, articles must be consistent internally and go with whatever format was introduced first, unless local consensus (on the article's talkpage) agrees to change it. Til Eulenspiegel /talk/ 19:23, 29 January 2014 (UTC)[reply]
This is a project page and not an article, so the guidance for articles doesn't apply. Since this is one of two pages that sets out the guidance on this, I think this page should the more widely understood term, with an intra-page link to the section that sets out the guidance. Jc3s5h (talk) 20:06, 29 January 2014 (UTC)[reply]
It still leaves the impression that Wikipedia prefers AD. And the compromise was not that the first format trumps, but that the established format would need consensus to change it - with no definition of established. Til forgets that quite a few people find AD/BC offensive. And denigrates it by calling it 'gratuitous' and calling it more awkward. Back to the point, why can't we at least have AD/CE in the wording. Dougweller (talk) 21:29, 29 January 2014 (UTC)[reply]
Either way, the point is local consensus rules on articles, so I agree that this MOS should reflect both styles and maybe link WP:ERAS. Startswithj came in openly speaking the language of denigration, "restrictive/regressive/religious AD" and I just replied in kind with my own contrary perspective, as one who flags to everyone what his biases are should perhaps not expect a perfectly neutral reply. Til Eulenspiegel /talk/ 22:18, 29 January 2014 (UTC)[reply]
Jesus Christ! (If the choice of words may be pardoned...) Can you fight about this if and when the new text is in place? It's really not germane to the main question. I've modified to, I hope, please everyone on this. EEng (talk) 23:28, 29 January 2014 (UTC)[reply]
Not sure which of those three words raised offense (perhaps I should have said, "exclusive/traditional/religious"), but regardless I apologize, Til Eulenspiegel. startswithj (talk) 02:52, 30 January 2014 (UTC)[reply]
  • Support. It's an unnecessary restriction that artificially entrenches ISO 8601 within these walls. Retaining the mention would be meaningless as we don't adopt any of its features other than the big-endian sequence. In practical terms, it will make no difference as I have never seen such a sequence used for pre-1583 dates; nor is that ever likely unless someone is trying to prove a point. Furthermore, it will remove the "is-it:isn't-it" dilemma. -- Ohc ¡digame! 02:17, 30 January 2014 (UTC)[reply]
  • Support for reasons stated by others and myself above. startswithj (talk) 02:55, 30 January 2014 (UTC)[reply]
Good, gooooood!! My plan is working puhrrrrfectly! <Rubs hands diabolically.> EEng (talk)
  • If we feel the need to say, "[n]or should readers assume such conformance or infer any such interpretation", that probably means that we're doing something that is likely to be misunderstood. We need to remember that the proportion of readers who are going to see this instruction is negligible, and the format of our dates should be obvious without need for instruction. I would oppose this wording on that basis.
I noted above that I oppose the use of YYYY-MM-DD format entirely, because it is harder to understand than the alternatives (e.g. 1 Feb 2014) and has no significant benefit over them in an English-language encyclopædia. In that light, increasing the range of circumstances in which YYYY-MM-DD can be used seems to me to be a bad idea. But I'd add to that that IMO removing these restrictions makes the existing problems worse. Dates such as 0562-12-23, 0871-01-08 and the aforementioned 0014-08-19 will be even harder to parse than normal YYYY-MM-DD dates because no other major source allows zero-padded years. While I accept that other limitations will reduce the frequency of zero-padded dates to near-zero, it would be better if they just weren't possible.
All that said, I accept the premise of the change here, that the vast majority of readers and editors are unlikely to even be aware of ISO 8601, let alone the requirement that ISO 8601-conformant dates use the Gregorian calendar only, so enforcing Gregorian dates and post-1583 does not resolve any ambiguity. Kahastok talk 18:03, 1 February 2014 (UTC)[reply]
Oppose It is true that ISO 8601 has not been adopted at WP, I don't believe it should be (regardless of whether we keep YYYY-MM-DD) nor do I see it as being a practical possibility. I also agree that editors should not use this format to imply conformance with ISO 8601 or to imply that the date represented is to be interpreted in any particular calendar system. However, does this make the ISO 8601 restrictions simply irrelevant? The suggested "Nor should readers assume such conformance or infer any such interpretation." is somewhat problematic. Now we're proposing that the MOS instruct readers how to read WP, are we? Generally a manual of style is there to instruct writers how to write. Do we now expect readers to visit the MOS to interpret what they read? No, fair enough, normal people don't know anything about 8601; normal people aren't even familiar with YYYY-MM-DD. To most sensible readers 1700-01-01 is gibberish. It's not that far-fetched to suppose that amongst the hand-full of people who actually like this format (or even get it) a number of them might assume ISO 8601 applies. Also by tossing the not-before-1583 clause we've created the need for zero padding thus opening the door so some quite absurd looking dates. When you see 0012-06-24 do you think "24 June 12 AD" ... really? Open a door and some fool is bound to walk through. Jimp 09:50, 3 February 2014 (UTC)[reply]

How about dropping the not-8601 text? (Prior Supports, we'd need your opinion here)

Not your fault, but we're now in a Catch-22. Some editors say, "People might think 8601 applies"; I think that's nuts but nonetheless added text making clear that 8601 doesn't apply. Now you, who agree almost no one would have heard of 8601, say, "If we need text making it clear 8601 doesn't apply, it must be because somehow people are likely to be think it does anyway, and since no one will read the new text here the new text doesn't help"; thus you seem to want to keep the old text here, which presumably also is read by no one and so it doesn't help anything either.

Since you accept the premise of the change, and don't think that retaining the Grogorian/post-1583 requirement resolves anything, is there any new text you would support? I put in the it's-not-8601 text to allay the worries of certain editors, but since they don't support the change anyway, I'm happy to drop all the not-8601 text, like this:

Extended content
(Where used: Only in references, tables, lists or areas where conciseness is needed -- see Wikipedia:Citing Sources § Citation style) Use YYYY-MM-DD (all-numeric) format only for years 1 AD/CE and later (though AD or CE should not be specified: 1776-07-04 not 1776-07-4 AD or 1776-07-4 CE). Zero-pad year to four digits, and month and day each to two digits.

I agree 0014-08-19 looks weird but perhaps you can get past that in the interest of decluttering MOS and striking a tiny blow against WP:CREEP. If you find that acceptable we can then hear from the other Supports about whether they do too.

EEng (talk) 19:23, 1 February 2014 (UTC)[reply]

There is probably no wording that supports YYYY-MM-DD that I could unequivocally support, because of my separate concerns with the format. But I believe I could accept this text, or the same text with the additional instruction to editors (i.e. without Nor should readers assume such conformance or infer any such interpretation.) for the purposes of consensus. Kahastok talk 20:45, 1 February 2014 (UTC)[reply]
What wording would you -- in your secret heart of hearts if you were All-Powerful High Emperor of the Known Universe and Grand Poohbah of MOS As Well -- desire to see (on the assumption that some even-higher power has decreed that YYYY-MM-DD dates are here to stay)? EEng (talk) 23:27, 1 February 2014 (UTC)[reply]
Working under these conditions, I believe I would put the start date at 1000 AD to avoid the question of zero-padding. Chances are the number of cases affected by such a change 1000 AD will be negligible anyway, so I don't see why we should feel the need to go there. This also reduces the need for the comment on era style (because most dates post-1000 will be unambiguous with respect to era). So instead of:
use only with Gregorian dates between 1583 and 9999 (ref) The year restriction on YYYY-MM-DD dates stems from the possibility they will be assumed to follow the ISO 8601 standard, which mandates the Gregorian calendar (/ref)
I would put:
use only with dates between 1000 and 9999
If we felt the need, we could then put in a reference something like This style is similar to that used in standard ISO 8601 - but don't imply that the dates actually use ISO 8601 and apply WP:JG as normal. - but in context I don't think we necessarily need it because I think very few people will be aware of ISO 8601. Kahastok talk 22:44, 2 February 2014 (UTC)[reply]
I would support YYYY-MM-DD usage in any non-prose place for any date. I would also generally favor succinctness. startswithj (talk) 21:56, 2 February 2014 (UTC)[reply]
I can live with that. So how about:
(Where used: Only in references, tables, lists or areas where conciseness is needed -- see Wikipedia:Citing Sources § Citation style) Use this format only for years 1000–9999 AD/CE (though AD or CE should not be specified: 1776-07-04 not 1776-07-4 AD or 1776-07-4 CE). Zero-pad month and day to two digits.
All in favor? EEng (talk) 09:12, 3 February 2014 (UTC)[reply]
I would prefer the version without the not-8601 text, I would also prefer the suggested 1000-to-9999 restriction to avoid the very strange-looking zero padding which is being proposed but, for the reasons mentioned above, I still oppose the change. Of course, I would prefer we got rid of YYYY-MM-DD altogether but, anyhow, whilst on the subject of trimming, how about the ridiculous "areas where conciseness is needed" bit? Conciseness is a completely false excuse for employing this unfamiliar format: just abbreviate the month. Jimp 09:50, 3 February 2014 (UTC)[reply]
The "conciseness" language is existing language applying to YYYY-DD-MM along with e.g. 13 Sep and Sep 13 i.e. formats using shortened month names. I've been carrying it along in the succession of proposals during this discussion only for completeness -- it's actually a column heading / footnote in the table. Does that help, O desperately solicited holdout? EEng (talk) 13:48, 3 February 2014 (UTC)[reply]
I would accept this or its equivalent in the new system (given my reservations re: YYYY-MM-DD dates in general as previously expressed). Kahastok talk 18:49, 4 February 2014 (UTC)[reply]
  • Oppose (responding to the notice of an RfC and to the proposal at the top of this section).  It doesn't make sense to document an ambiguous machine-friendly format for dates before 1583.  The fix may be to have additional syntax as part of the format, so that there is no ambiguity to either a human or a machine regarding if the date is Julian or Gregorian.  Unscintillating (talk) 04:20, 17 February 2014 (UTC)[reply]
  • Support the proposal with or without mention of ISO-8601. Heart of the matter is a format (as in use in the real world) not a whole definition of a time scale. −Woodstone (talk) 07:59, 17 February 2014 (UTC)[reply]

Quantitative usage info

After this discussion began I learned how to use the AutoWikiBot database scanner. I scanned a dump of the English Wikipedia articles from January 2, 2014, for dates written in the YYYY-MM-DD format, dated from January 1, 1 BC, to December 31, 1599. There were 567 articles that fit the criteria, after eliminating articles that I knew to contain sortable tables where the YYYY-MM-DD format was hidden. The list of articles (including false positives, typos, etc.) is at User:Jc3s5h/YYYY-MM-DD articles.

I examined the first 50 articles on the list. If usage in all the articles is proportional to the first 50, I'd estimate there are 147 articles that contain pre-1600 dates in the YYYY-MM-DD format; the rest are false positives, typos, etc. Of these, about 38% of the dates are Julian calendar dates; the remaining 62% would require research to identify as Julian or Gregorian. Jc3s5h (talk) 18:13, 3 February 2014 (UTC)[reply]

ISO 8601 is garbage

The standard ISO 8601 is garbage, because it turns would-be users into liars. (But I have no particular objection to Wikipedia's article about the standard). The International Standards Organization has written a reprehensible web page that is a trapping pit just waiting to lure the unwary into writing falsehoods. This is because all ISO 8601 dates are Gregorian calendar dates, but many people who use this standard are unaware of this requirement. Jc3s5h (talk) 22:57, 23 January 2014 (UTC)[reply]

Since we're in a joking mood, try this one: http://xkcd.com/1179/ . As an added bonus, hover the pointer over the image for an additional joke.  Stepho  talk  00:22, 24 January 2014 (UTC)[reply]
How can it simultaneously be garbage and cost CHF134,00? Or is that CHF 134.00? Anyway, it seems like more of a buffalo jump than a trapping pit to me, but that's probably just my cultural hegemony talking. – Jonesey95 (talk) 04:50, 24 January 2014 (UTC)[reply]
Buffalo jumps are much bigger than trapping pits, thus they're better. :) — Dsimic (talk) 05:15, 24 January 2014 (UTC)[reply]
Is it a joke? Tony (talk) 06:29, 24 January 2014 (UTC)[reply]
  • Lots of people have heard of ISO 8601, and the ISO's web page encourage everyone to use it, but one has to shell out a relatively large amount of money to see the details. But the anonymous authors of the ISO's web page seem to have an unstated mindset that it would only be used for current events such as airline tickets or grocery receipts. It is left as a surprise for those who shell out CHF 134.00 for the official standard that one must only use it for Gregorian calendar dates, so be very careful if one is writing about Russia or Greece in the early 20th century. Also, one must obtain explicit permission among the data exchange partners (in Wikipedia's case, readers) if one intends to use the standard before the first full year the Gregorian calendar was in force anywhere (1583). So there is a large risk of false information if the standard is used for historical dates, which is something that tends to come up if one is writing an encyclopedia. This is exacerbated when dates written in other formats are silently emitted in the ISO format, as is the case with some templates such as {{start date}}. Jc3s5h (talk) 10:42, 24 January 2014 (UTC)[reply]
FWIW I have a set of paper round-the-world ticket from few years ago - in this case, nineteen sectors involving five airlines based on four continents - and they use all-numeric DDMMYY. Kahastok talk 10:16, 26 January 2014 (UTC)[reply]

Outside perspective from sroc

I couldn't think of a better title to break away with my understanding of this:

  1. ISO 8601:
    1. uses the Gregorian calendar only;
    2. only allows dates before 1582-10-15 1583 or after 9999 if agreed between parties.
  2. MOS:DATE:
    1. allows dates to "be given in any appropriate calendar, as long as the date in either the Julian or Gregorian calendars is provided" (WP:JG);
    2. only allows dates in YYYY-MM-DD format "for dates expressed in the Gregorian calendar and for the years 1583 through 9999" (MOS:YEAR).

The reason for the point in 2.2 is not because MOS:DATE explicitly allows ISO 8601 but because such dates "might be assumed to follow the ISO 8601 standard". Thus, YYYY-MM-DD may only be used for dates that also comply with ISO 8601, making no allowance for uses that may be agreed between parties.

Notably, MOS:DATE clearly does not endorse ISO 8601, or at least not completely. It does not allow dates between 1582-10-15 and 1582-12-31 which would be allowed by ISO 8601. It does not allow other formats that ISO 8601 would allow (e.g., YYYYMMDD, YYYY-MM, YYYY-Www, YYYY-Www-D, YYYY-DDD).

I am persuaded by the argument that any YYYY-MM-DD date is just as likely as any other format to be ambiguous as to whether the Julian or Gregorian calendar is being used without clarification. The fact that MOS:DATE may state that YYYY-MM-DD should only be used for Gregorian dates is no complete salvation, as an editor might innocently have entered a Julian date in YYYY-MM-DD either not realising that MOS:DATE exists or thinking that "should" (rather than "must") meant that it could be ignored, so any YYYY-MM-DD could potentially be in either calendar format despite what MOS:DATE purports to say. I think it is putting too much strain on a date format to say that it implies a particular calendar system.

WP:JG provides guidance on whether Julian or Gregorian calendars should be used in particular circumstances. I don't think the choice of date format should unnecessarily constrain that guidance.

If we consider these two separate issues:

  • Should YYYY-MM-DD only be used for dates in the Gregorian calendar? I see three options:
    1. Yes, only allow Gregorian dates (the status quo, but using "must" instead of "should")
    2. No, allow Gregorian or Julian dates, but require that Julian dates must be clearly demarcated as such (this would avoid the concern that the reader would assume the date to be in Gregorian because of ISO 8601)
    3. No, allow Gregorian or Julian dates without the need for qualification
On this issue, I tend towards option 2 because it neatly avoids the implication that YYYY-MM-DD = ISO 8601 and avoids confusion amongst anyone who would assume all YYYY-MM-DD dates are Gregorian.
  • Should YYYY-MM-DD dates be limited to 1583-9999? I see these options:
    1. Yes, because this reflects ISO 8601, although not exactly (the status quo)
    2. No, allow dates from 0001 to 9999, because we don't follow ISO 8601 and typical readers will understand what these dates mean
    3. No, allow any date range we choose, because we can say that MOS:DATE essentially forms an agreement between Wikipedia and the reader to allow dates outside this range in order to comply with ISO 8601
On this issue, I'm leaning towards option 2 again because it reflects common sense. If we adopt option 2 on both issues, then we can have dates such as 1503-05-27 provided that it is made clear that this is a Julian date. Typical readers unaware of ISO 8601 will understand what is meant and will not be confused or alarmed. Readers with an intimate knowledge of ISO 8601 will realise that it is non-compliant with ISO 8601 because it is out of range and does not use Gregorian, but this is OK because MOS:DATE will allow it and is not bound by ISO 8601.

So, what I would propose a qualifier on the use of YYYY-MM-DD something along the lines:

Use only with years between 0001 and 9999; specify the calendar used if not Gregorian

There is no need to specify that Julian calendar should be used for dates before 1582-10-15 because this is already covered by WP:JG ("Dates before the adoption of the Gregorian calendar on 15 October 1582 are normally given in the Julian calendar") and applies equally to all date formats. In fact, this will finally allow those Gregorian dates in late 1582 to be expressed in YYYY-MM-DD where they currently are not permitted by MOS:DATE (for no reason other than simplifying the rule, presumably).

That's my two cents, and, of course, I may have completely mis-judged this. I've been asked to provide my view, and having dispassionately reviewed the earlier comments after staying out of the rabble for so long, that's what I make of it. sroc 💬 12:47, 4 February 2014 (UTC)[reply]

[Revised in light of below discussion that ISO 8601 does not allow dates between 1582-10-15 and 1582-12-31 after all. sroc 💬 12:10, 6 February 2014 (UTC)][reply]
ISO 8601 sets 1583 as the minimum year that may be used without mutual agreement. Jc3s5h (talk) 17:39, 4 February 2014 (UTC)[reply]
Does it not allow dates from 1582-10-15? From ISO 8601: "…ISO calendar dates before the Convention are still compatible with the Gregorian calendar all the way back to the official introduction of the Gregorian calendar on 1582-10-15. Earlier dates, in the proleptic Gregorian calendar, may be used by mutual agreement of the partners exchanging information." sroc 💬 03:26, 5 February 2014 (UTC)[reply]
An electronic copy I downloaded before it became hard to find indicates the minimum year is 1583, in the absence of mutual agreement. Jc3s5h (talk) 04:07, 5 February 2014 (UTC)[reply]
Could you copy the exact wording from ISO 8601 for our benefit? sroc 💬 22:07, 5 February 2014 (UTC)[reply]
Sroc, I haven't been ignoring you, just distracted. I'll try to rejoin the conversation in a few days. Keep up the good work. EEng (talk)

The exact wording in the electronic copy, page 13, is

4.1.2.1 General

In expressions of calendar dates

calendar year is, unless specified otherwise, represented by four digits. Calendar years are numbered in ascending order according to the Gregorian calendar by values in the range [0000] to [9999]. Values in the range [0000] through [1582] shall only be used by mutual agreement of the partners in information interchange.

Elsewhere, there are descriptions about how, by mutual agreement, negative years and years greater than 9999 may be written. Jc3s5h (talk) 22:55, 5 February 2014 (UTC)[reply]

Thanks, Jc3s5h. So the article at ISO 8601 is technically incorrect, then. In any case, the current restriction is consistent with the section you quoted, though it doesn't mean we are obliged to follow it of course. sroc 💬 12:02, 6 February 2014 (UTC)[reply]

YYYY-MM-DD and YYYY-yy

The recommended format "yyyy-yy" is bad. It looks like a year and a month. That MOS recommendation should be removed, and we should always uses YYYY-YYYY for year ranges. That instantly solves the problem of the vastly more common YYYY-MM-DD uses. We already have to use YYYY-YYYY for date ranges spanning century breaks, so why should we be using two different formats for yeardateranges? Just use four-digit years all the time. We had this big brouhaha about Y2K for just this kind of silly 2-digit year issues. YYYY-MM-DD allows easy sorting, and if we get rid of YYYY-yy, we won't have problems confusing years with months. "1901-02" can be construed as February 1901, and is used that way in some publications; but 1901-1902 cannot. -- 70.24.244.161 (talk) 12:18, 11 February 2014 (UTC)[reply]

  • Agree that YYYY–YY is confusing and easily avoided by YYYY–YYYY. startswithj (talk) 00:30, 13 February 2014 (UTC)[reply]

Durations

How should durations such as race times be presented/notated? I came across a situation (Round the Island Race) where some older race times were in hours and minutes, and others, following the introduction of electronic timing equipment, in hours, minutes and seconds. What's the recommended way of writing those, given that 19:11 becomes ambiguous in such a context? Because I didn't know, and still don't. Justlettersandnumbers (talk) 19:48, 4 February 2014 (UTC)[reply]

Good question. That article doesn't have any times over 10 hours or under 2 hours, so there is no cause for alarm that anyone is likely to see 9:51 and think it was a blazing pace of under 10 minutes! Although it does technically leave ambiguity, I think it is reasonable to include times in a table in the format 02:52:15 for HH:MM:SS and 09:51 for HH:MM when seconds are unknown, but perhaps include a note to explain that seconds have only been recorded since more precise timing equipment has become available. Certainly a mix of 02:52:15 and 5 h 50 m is not a great look, not to mention that the latter format is not as common in English. sroc 💬 12:23, 6 February 2014 (UTC)[reply]
Ambiguity is seldom a good thing. X h Y m Z s is common enough in English, and should be clear from context. We even have a template for 2h 52m 15s format, though that's for ascension and might not be appropriate for time. (If we don't have one that's not superscripted, we can make one.) IMO we should only use HH:MM:SS or HH:MM in tables where it can be labeled so there is no possibility of confusion. In the case of that article, it's probably best to convert all to X h Y m Z s, since we can't use zeroes as placeholders for HH:MM:SS format. — kwami (talk) 18:21, 6 February 2014 (UTC)[reply]
Thanks for the replies. I agree that what I did is not a great look (I was cleaning up a copyvio, not writing on a topic that interests me). But I'm no wiser about how best to improve it - both suggestions are valid, but also mutually incompatible. Justlettersandnumbers (talk) 22:10, 11 February 2014 (UTC)[reply]
In the absence of any specific guidelines or known precedents, go with Kwamikagami's suggestion (02 h 52 m 15 s, 09 h 51 m) as it more clearly disambiguates without needing further explanation. Sorry, I'm not sure whether leading zeroes are appropriate in this format, but I'm fairly sure superscripts for "h"/"m"/"s" aren't usually used for time. Even though the format is not as common in English as HH:MM:SS or HH:MM, I wouldn't push for my suggestion over the other. sroc 💬 01:58, 12 February 2014 (UTC)[reply]
 Done [9] sroc 💬 04:43, 15 February 2014 (UTC)[reply]

stranded digits

We said,

According to ISO convention (observed by the NIST and the BIPM), it is customary to not leave a single digit at the end

However, that's not what I've found in accounts of ISO, including NIST guidelines, so I've removed the wording. They state that this applies in both directions, but only to the 4th digit, not to the 7th or 10th. Either I'm just not finding the proper sources, or someone misread this. Not that we need to follow ISO, but we shouldn't justify it that way. — kwami (talk) 14:19, 11 February 2014 (UTC)[reply]

Sorry, could you please provide a source? I'm curious. Archon 2488 (talk) 00:19, 12 February 2014 (UTC)[reply]
It depends on context. If I need consistent alignment and spacing with a more precise number, (which is so rare, I have no example,) I would want to leave the space. Sometimes, it is better to avoid a lone digit on the end. Otherwise, I don't usually care that much. —PC-XT+ 04:57, 13 February 2014 (UTC) I forgot to include this link, which I think Kwami is talking about: the Digit Spacing section (Section 10, "More on Printing and Using Symbols and Numbers in Scientific and Technical Documents" in the detailed documentation, and summarized in a section of the checklist) available at [10] in HTML or PDF. —PC-XT+ 05:12, 13 February 2014 (UTC) 05:26, 13 February 2014 (UTC)[reply]

What exacly is a "UK engineering-related article"

Is it simply any article about any UK subject where one or two of the paragraphs in the article discuss the engineering aspect of the broader topic? I ask because I believe it is unclear and open to misinterpretation. An example article which I have been involved in, and where this is the cause of unrest, is High Speed 2, where very little of the 15 sections is engineering-related, yet that MOSUM clause has been invoked. Passy2 (talk) 21:59, 11 February 2014 (UTC)[reply]

  • I think WP:RETAIN means use the variety of English the article started with, unless it has strong ties to a particular English-speaking country. The first version didn't contain any language that would vary between American and British English; the current version uses British English. So WP:TIES applies rather that WP:RETAIN. But neither of these is intended to distinguish among English as written by British engineers vs. English as written by British travelers, or anything of the sort. Jc3s5h (talk) 19:07, 17 February 2014 (UTC)[reply]
I agree that WP:RETAIN is not relevant here. Keeping whatever units the original author decided on (basically, a coin toss) is not constructive or reasonable. Archon 2488 (talk) 22:05, 17 February 2014 (UTC)[reply]

NB Passy2 is a suspected sockpuppet of the banned user, DeFacto. It has been blocked indefinitely. See [11]Michael Glass (talk) 13:11, 21 February 2014 (UTC)[reply]

Proposal

Doesn't anyone here know what is meant by the term, and whether it was meant to include ALL articles which mention an engineering project anywhere amongst their content? I suspect that this clause is being widely gamed, and used as an excuse by some editors who "prefer the metric system" to fully metrify/metricate UK-related articles against the spirit of these guidelines. For that reason, I propose either removing the exception on engineering related articles or tightening it to define just how much engineering content an engineering-related article is expected to have. Passy2 (talk) 07:32, 17 February 2014 (UTC)[reply]
The argument that the HS2 article isn't "sufficiently engineering-related" because not all of it is about engineering strikes me as committing the fallacy of division. It is in any case the only article on Wikipedia about what is indisputedly an engineering-related topic. Or should we venture into angels-on-pinheads territory and say that certain articles on engineering-related topics are not, in fact, engineering-related? What would be the point of this? "Give precedence to the original units" is a generally-sensible rule, it was all that came out of the last unpleasant imperial/metric discussion, and I have not argued against the use of imperial where there is a genuine historical warrant for it. Or perhaps we should berate modern engineers for "preferring the metric system" and putting signs like this all over things that, for apparently political reasons, we are not allowed to call engineering projects, and are not allowed to describe in terms of those same metric units? Does Wikipedia "know better" than the engineers which system of units to use? I'm searching in vain for a rational argument here. At what point does it become acceptable to ignore the units that are actually used in the real world, and impose our own bizarre harlequin mixture of metric and imperial, which doesn't reflect the real world so much as a compromise between different factions of Wikipedia editors circa 2014? For what purpose? Archon 2488 (talk) 14:59, 17 February 2014 (UTC)[reply]
Engineering-related articles are articles that primarily discuss engineering-related aspects of the article's topic. An article that focuses on destinations served, cost, political acceptability, and the like, is not an engineering-related article. Jc3s5h (talk) 19:10, 17 February 2014 (UTC)[reply]
I guess that's easy enough to say, but then what does "primarily" mean? What does it mean to say that an article "focuses on" X at the expense of Y? What if that focus changes as the article evolves? These seem like weasel words to me. The problem with what you are suggesting is that, as a rule, it would imply that if an article started life as a few paragraphs on engineering-related topics, then was expanded to encompass broader information, it would pass some critical threshold and cease to be officially "engineering-related" as an article. This would then imply, by the utterly Byzantine rules of WP:METRIC, that editors would no longer be allowed to use consistently the units which are used in real life, but would need to follow the somewhat-arbitrary WP convention for generic British articles.
I think that this question of where that critical point lies is an unanswerable one, and the distinction is pedantic and unnecessary. Once again, what actual purpose does it serve? Why should Wikipedia have an "engineering hat" which it puts on to speak in metric, then in some cases takes off to speak in imperial? Archon 2488 (talk) 22:05, 17 February 2014 (UTC)[reply]
You seem to be arguing that we should use "the units which are used in real life" - but then rejecting the units used in real life when they happen to be imperial. Note that WP:UNITS deliberately prefers imperial units only in cases where they are overwhelmingly more common in real-life UK usage.
The engineering exception very clearly does not specify metric-first, it specifies the units of design first. In many cases this will actually be imperial.
The article High Speed 2 is not engineering-related, so far as I can see, so WP:UNITS would apply as normal - but the determination is ultimately left to local consensus on the article talk page. I don't see a compelling reason here to change that. Kahastok talk 22:20, 17 February 2014 (UTC)[reply]

> You seem to be arguing that we should use "the units which are used in real life" - but then rejecting the units used in real life when they happen to be imperial.

Nope. Please read what I said. Specifically, "I have not argued against the use of imperial where there is a genuine historical warrant for it" (of course I'd extend that to cases where nominal values are given in imperial, such as speed limits in mph). If you try to argue that a railway which measures speeds in km/h may not be described using that unit then you are guilty of exactly this offence. To carry this to its absurd conclusion, we'd be stuck with 3.1-mile or 6.2-mile races, because km are "disallowed" by WP:UNITS.

> The engineering exception very clearly does not specify metric-first, it specifies the units of design first.

Again, closer reading will pay dividends. I am quite aware of this, and I have repeatedly said that using imperial-first in the context of, say, Brunel is OK. Doing it for HS2 is anachronistic in the extreme, and would in effect mean that Wikipedia would be undeniably falling behind metrication in the UK. Your "many cases [where the original units] will be imperial" do of course exist, but they are almost entirely older infrastructure.

> WP:UNITS deliberately prefers imperial units only in cases where they are overwhelmingly more common in real-life UK usage

That's a bit simplistic. There are lots of cases where kilometres are the normal unit of distance, such as in many kinds of outdoor activities. My running club measures all jog lengths in km. Trail lengths for hiking or biking (or pistes in Scottish ski resorts) are commonly given in km. My orienteering compass doesn't even have imperial units on it, because OS maps haven't used inch-mile scales for decades. It's now policy that the old miles and chains will be phased out and replaced with kilometres on the mainline railways; newer infrastructure tends to use metric units throughout. This is undeniably objective NPOV information about the units that are used in Britain, but the existing rule is so broad-brushed that it just sweeps over it.

> the determination is ultimately left to local consensus on the article talk page. I don't see a compelling reason here to change that

Thank you. On one thing, at least, we agree. This entire discussion was started simply because, at the end of a discussion on the HS2 talk page, one particular editor didn't get his way. Archon 2488 (talk) 22:57, 17 February 2014 (UTC)[reply]

I think that the HS2 article is clearly "engineering related." I cannot understand how anyone can seriously argue that it isn't. If a proposal to build a railway isn't related to engineering, what is? Therefore we need to find out what were the units of design for the HS2 proposal and run with that. Michael Glass (talk) 22:29, 17 February 2014 (UTC)[reply]
Michael Glass, I moved your comment so it's in a more logical position — hope you don't mind.
I'd suggest looking at the categories in which the article is included, such as "High-speed railway lines in the United Kingdom" and "Proposed transport projects in London". It seems clear to me that inclusion in these categories suggests that the article relates to engineering and infrastructure. Merely discussing other topics doesn't change this fact. By the same token, an article on a proposed bridge, ocean liner or supertall building would clearly be engineering-related. Just think how Wikipedia typically classifies such articles — also in terms of WikiProjects. These are emergent, natural and intuitive classifications which people do not find controversial in practice. The article on the Titanic is engineering-related, so it can give dimensions in feet and inches per the original design, although obviously much of the article is about the sinking and the cultural impact rather than the engineering as such. Archon 2488 (talk) 23:44, 17 February 2014 (UTC)[reply]
I cannot believe that another hang-up has resulted here. It is quite clear that the High Speed 2 article is an "engineering-related article". It is exactly the type of article the exception was designed to serve. There is no doubt that the railway has been designed in metric, therefore, measurements pertaining to the railway should be in metric. RGloucester 00:04, 18 February 2014 (UTC)[reply]
I agree with Jc3 that this is not "Engineering" within the meaning of the wording. By merely asserting that HS2 is Engineering, like shouting loudly over the rooftops, doesn't make it so. The project is too macroscopic for it to be usurped as "Engineering" for MOSNUM purposes, to be used as part of of the Wikipedian "Metric vs Imperial" battleground. It's fundamentally an Economics article, based on the perceived need to build high speed links to the extreme parts of the UK. It's served by major investment in a transportation project; I'd argue that the primary drivers are geographical and political factors. Transport is a major component, of which Engineering is only the enabler in this. This is no synchronous motor or cellular network – I see no scientific equations, workings or hypotheses. There are only about 60 "measurements" in the entire article. So it's probably about as Geography-related as Engineering-related. I'm not saying who's right or wrong, but depending on how you look at it, the HS2 article is only the pawn or Trojan Horse in this game being played out. -- Ohc ¡digame! 02:19, 18 February 2014 (UTC)[reply]
HS2 is a large-scale engineering project, as is any railway line. The economic angle would not exist if it were not for the engineering, that is the physical laying of the track. The exception was created so that engineering projects drawn up in metric would use metric units. This means that the length of the route should be written in metric, along with the gauge of the track and so on. It really isn't that hard to comprehend, and you are taking it much further than is necessary. I don't know if you remember from the previous discourse, but in my own head, I prefer imperial units. I am not a metricator, nor an imperialiser. I have no interest in a metric v. imperial skirmish. I compromise. To call the largest civil engineering project in Britain for a very long time "not engineering-related" is the queerest thing I've ever heard. Anyway, I have no interest in another endless discussion, I was merely here to provide my brief opinion, as I was the drafter of said exception. RGloucester 03:35, 18 February 2014 (UTC)[reply]
I completely agree with RGloucester. To claim that one of the largest civil-engineering projects in Britain is not "UK engineering-related" beggars belief. This is exactly the sort of article that the provision was intended to address: civil-engineering projects such as bridges, railways, and motorways designed and implemented in metric units, long after the use of imperial measurements for such purposes was abandoned and de facto became illegal. --Boson (talk) 12:24, 18 February 2014 (UTC)[reply]
The project is certainly engineering-related. But is the article? Look through the article: how much of it is actually discussing engineering? Most of it is actually discussing the politics, and those parts that aren't are mostly discussing the geography. As others have pointed out, there are actually very few measurements - and most of them are geographical-scale distances and speeds, precisely the sorts of units that would be frequently expressed into imperial in British usage.
But ultimately this is a matter for the article talk page. I do not see an improvement needed on the guideline. Kahastok talk 19:06, 18 February 2014 (UTC)[reply]
"But is the article?"
In my opinion: yes; the article is about an engineering project, so it is engineering-related. This does not mean that other aspects may not be discussed at length. For this reason (non-engineeering topics in engineering-related articles and vice versa), I argued, in the protracted discussion at Wikipedia talk:Manual of Style/Dates and numbers/Archive 142#Imperial measurements, that units should be dependent on the context rather than the topic of the article. It was you who rejected that and suggested

except in articles concerning civil engineering projects conceived in metric units.

--Boson (talk) 22:05, 18 February 2014 (UTC)[reply]
I agree with Kahastok that the HS2 project is certainly engineering related, but, so is the article that deals with the project. This can be seen from the article's headings: History, Route, Connection to other lines, Journey times, Planned stations, Development, Environmental impact and Alternative plans. The engineering connection is more than a tally of the number of times it refers to measurements. Nor does it cease being connected with engineering because it deals with the politics of this major project or deals with the geography through which the project is to pass.
I agree with Kahastok that this a matter for the article talk page.
I agree with Kahastok that the guideline in question does not need "improvement."
Michael Glass (talk) 22:49, 18 February 2014 (UTC)[reply]
I came here hoping for clarification as to what "UK engineering-related articles" meant in the guideline, to help with a disagreement about whether the HS2 article qualifies, or not. Judging from the replies here, it isn't clear at all, with claims both ways in equal measure. So I would suggest that the guideline does need further clarification.
My view remains that, although the HS2 article is about an engineering related topic, it itself is not actually an "engineering-related" article, agreeing with the reasons given above highlighting its broader topic content. Articles specifically about the engineering of the trains or of the track or its many bridges and tunnels would almost certainly be engineering-related, but the current HS2 article itself is more about the economics and politics than specifically the engineering. Passy2 (talk) 07:42, 19 February 2014 (UTC)[reply]

Problem is this: as construction proceeds, the content of the article will change, and might well become "more engineering-related". How exactly does one quantify just how much engineering content there needs to be in an article before it's officially engineering-related? This is the angels-on-pinheads question I've been talking about.

At any rate, trying to impose a solution from on high isn't going to work, because that would sacrifice nuance ("follow real-world usage — use those units in official use") for the sake of creating a false appearance of uniformity ("just put miles first because they're more common"). Ultimately the only solution that is workable is for the issue to be settled on the article talk page.

I'd suggest a commonsense criterion: If you can sensibly imagine the article being included in a category or project such as Wikipedia:WikiProject_Trains, then you should consider it to be engineering-related (HS1 is already in this category, for example — or is the article on HS1 engineering-related, but not the article on HS2? How many hairs need be split for that distinction to make sense?). More common sense: discussing the politics etc. attending the beginning of a new engineering project does not make it less of an engineering project, nor does it make any difference to the units in use. Archon 2488 (talk) 12:51, 19 February 2014 (UTC)[reply]

I agree that this is a matter for article talk pages, and that the guideline needs no further modification. Archon 2488 has put forth some sensible comments forward. I would direct you, Passy2, to look at the present guideline for "science-related articles". This is what the engineering exception was modeled on, and has not created any controversy. Many of the "science-related articles" could be argued to pertain to things other than science, as it happens. Nevertheless, "science" is their base. As is engineering, for this article.
If we have an article on a plant, that is a botany, or science-related article, even if one could talk about it being sold by greengrocers, and having a large economic impact on world markets. That's because, fundamentally, the article is about the subject. The implications of the subject all stem from the subject. "Engineering-related articles" are those that are based in engineering. Everything that you've mentioned that is discussed in the article is a product of the very engineering itself. One cannot talk about the economic impact of a bridge without the bridge itself, and the bridge is a piece of engineering. I would advise that you to avoid splitting hairs, and reading too much into guidelines. It serves us well on Wikipedia to be pragmatic. RGloucester 15:25, 19 February 2014 (UTC)[reply]
FWIW, to my mind, if the question is, "[h]ow exactly does one quantify just how much engineering content there needs to be in an article before it's officially engineering-related", the answer is, so long as the spirit of MOSNUM is not clearly being broken, it is engineering-related when the talk page consensus says it is.
Of course, we have to be careful of those who abuse the rules. The global consensus expressed through the letter and spirit of MOSNUM still overrides local consensus if there is a clear conflict, and we have had editors in the past that would quite happily argue that black was white if it served their POV on units. But this is not at issue here: it's a judgement call with legitimate room for disagreement, and in that case talk page consensus is the way to go. Kahastok talk 20:23, 19 February 2014 (UTC)[reply]

Formatting the MOS with a template to support that template

This is really bad form. The MOS should be formatted manually, as it has been for years. Otherwise, any time someone changes a formatting template, the MOS will change, without any discussion of that change on the MOS. We should specify here exactly what we want, and the template should conform to that, not the other way around. (I'm speaking of Headbomb's recent edit war to format the MOS with the {{val}} template, which does not conform to consensus on the MOS.) — kwami (talk) 00:18, 13 February 2014 (UTC)[reply]

I agree in principle. It's tempting to use a template, but I would prefer it at least be substituted, and only edited with consensus, so it is easier to see what the template and other forms should match. Template code can still be listed with examples, but probably not as the main MOS examples. If that is too redundant, just list the template examples on its doc page. —PC-XT+ 04:09, 13 February 2014 (UTC)[reply]
That sounds reasonable. — kwami (talk) 06:50, 13 February 2014 (UTC)[reply]
What about situations where MOS advises to use particular templates? For example, MOS:FRAC:
The templates {{frac}} (e.g. 812) and {{sfrac}} (e.g. 81/2) are available for representing common fractions.
  • Correct: A History of the World in 1012 Chapters is a novel by Julian Barnes.
  • Incorrect: A History of the World in 10 12 Chapters is a novel by Julian Barnes.
  • Unless there is sound reason to the contrary, fractional parts of metric units should be expressed as decimal fractions (5.25 mm), not vulgar fractions (514 mm). However Imperial, English, avoirdupois, and United States customary units may use either form – both (5.25 inches) and (514 inches) are acceptable, provided that there is consistency in the way that the fractions are represented.
  • In science and mathematics articles, fractions should always be written either with a horizontal fraction bar (as in or 1/2), or with a forward slash and with the baseline of the numbers aligned with the baseline of the surrounding text (as in 1/2). The use of {{frac}} (such as 12) is discouraged in these articles.
sroc 💬 12:04, 13 February 2014 (UTC)[reply]
That's a good point. Perhaps in such cases we should add a warning to the template talk page (or even better, in the edit window of the template) warning editors that it's transcluded in the MOS and so shouldn't be substantially modified without giving notice there? — kwami (talk) 21:08, 13 February 2014 (UTC)[reply]
Questions that come to my mind: Are the templates an integral part of the MOS, or does the MOS hand off these issues for the template to define? Should these templates be specially protected as MOS templates, and only edited in tandem with the MOS, or should the template follow the MOS? Should the discussion of relevant MOS changes occur here or at the template talk page, instead? Does it matter in practice? —PC-XT+ 07:55, 14 February 2014 (UTC)[reply]
I'd say, (1) neither. Formatting is defined here, and compatible templates are suggested. (2) Val claims it follows the MOS, and the MOS always takes precedence. The MOS is the guideline, templates tools to help implement it. (3) I'd say anything to bring a template into better alignment w the MOS could take place there without notice. Anything that would adversely affect article formatting that was intended to follow the MOS should at least be mentioned here. — kwami (talk) 08:58, 14 February 2014 (UTC)[reply]
Thanks for the answers. I was thinking basically the same thing. I see potential problems in a template following something that uses the same template as part of its definition, but that doesn't mean it can't be handled appropriately, as suggested here by you and sroc. —PC-XT+ 09:34, 15 February 2014 (UTC)[reply]
I like your thinking, Kwamikagami! We already have warnings such as {{high-risk}} that appear on template pages where bad edits could have unintended/catastrophic consequences, so a similar warning for templates utilised in MOS seems like it could be similarly workable. Something like {{mos-template|MOS:FRAC}} that could produce a warning that links to the relevant section(s) of MOS where the template is used, perhaps? sroc 💬 01:40, 15 February 2014 (UTC)[reply]
Something like this?
Also, isn't this a conversation for Wikipedia talk:Manual of Style, not this sub-page? sroc 💬 01:56, 15 February 2014 (UTC)[reply]
Yes, exactly. Used in the MOS or even just recommended. If we recommend a template like val, then even if it has no direct effect on the MOS, after a few years there could be many articles where it was used because it followed the MOS. Changing it could mean effectively changing the intent and consensus of many editors. I think a warning would be appropriate in such cases as well.
If the template is actually used to format the MOS, then maybe something a bit more obvious? Currently I think we have warnings for ARBCOM, 1RR, etc. that pop up in the edit window, so there's no way you can miss them. Something like that might be appropriate in cases where editing a template would have the effect of changing our guidelines without the change appearing in the watch-lists of people monitoring them.
And yes, we should move the discussion there of course. I wasn't thinking. — kwami (talk) 02:00, 15 February 2014 (UTC)[reply]
Leaping to warnings might be overblown in many cases — remember to assume good faith — but in any case I don't think that's a discussion for here. Certainly propose any changes to the wording to make the intent clear, but no need to blow this out of proportion. sroc 💬 02:05, 15 February 2014 (UTC)[reply]
Too many warnings would dilute them all. I don't think I would worry as much about recommended templates. I would tend to stick to templates used to generate MOS examples. I wouldn't tag templates used for other things on the MOS, such as styling. If the template differs from the MOS, it can be brought up-to-date or removed from the MOS. —PC-XT+ 09:34, 15 February 2014 (UTC)[reply]
You're right. And, as recommended above, we use templates as little as possible, and show how they can be used for MOS recommendations in the template documentation. — kwami (talk) 10:18, 15 February 2014 (UTC)[reply]

Julian and Gregorian calendars and Days of the Year articles

In section Julian and Gregorian calendars it says, "Dates of events in countries using the Gregorian calendar are given in the Gregorian calendar." For example, Greece did not adopt the Gregorian calendar until 1923, so events in Greece prior to 1923 are supposed to be given with the Julian date. Presumably this rule applies generally, but it does not specifically state that this rule applies in Days of the Year articles. A reader looking at a Days of the Year article (e.g. January 1) would assume that two events or births in the same year both happened the same day. This would suggest that all events, births, and deaths in Days of the Year articles should be in the Gregorian calendar starting in 1582. The downside of this would be that articles about people and events relating to countries that adopted the Gregorian calendar after 1582 would have different dates from the Days of the Year article. This could be confusing!

I think WP:Manual of Style/Dates and numbers#Julian and Gregorian calendars should be modified to clarify the application of "Dates of events in countries using the Gregorian calendar are given in the Gregorian calendar" to Days of the Year articles. Whichever way the decision goes, I would suggest that events, births and deaths after 1582 in countries that still used the Julian Calendar should have clarifications in Days of the Year articles. For example, Ioannis Kapodistrias (11 February 1776 – 9 October 1831) is listed in February 11 as

His Gregorian birthday is February 22, 1776. So if it is ruled that the use of Gregorian dates goes by country in Days of the Year articles, I would modify his listing in February 11 to something like

And if it is ruled that Days of the Year articles list Gregorian dates starting in 1582, I would suggest listing Ioannis Kapodistrias in February 22 something like

Anomalocaris (talk) 10:36, 19 February 2014 (UTC)[reply]

Well, he didn't have a particularly "Gregorian birthday" or "Julian birthday", did he? Perhaps "born February 22 in the Gregorian calendar"? sroc 💬 11:13, 19 February 2014 (UTC)[reply]

Should MOSNUM reflect this oddity of UK marketing?

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
This clearly has no chance of achieving consensus for the proposed change, I also sense a deep sense of irritation in a number of editors that the issue of metrication in the UK is once more gracing the pages here. It seems sensible to simply close it now and lance the boil. Wee Curry Monster talk 19:13, 25 February 2014 (UTC)[reply]

One of the oddities of British marketing is that milk is sold both by the pint and the litre. This can be seen for example in ASDA and Sainsburys. Indeed, of the major stores, only ALDI sells milk just by the pint.

In view of the fact that milk is sold both by the pint and the litre, should Mosnum read as follows?

  • imperial pints for draught beer/cider and most bottled milk.

I suggest the word most because milk sold by the pint is available in a greater range of container sizes and usually at a better price than the milk in 1 and 2 litre bottles. Michael Glass (talk) 00:54, 20 February 2014 (UTC)[reply]

"Most" creates ambiguity. Which ones? Not which others? And if everyone markets by pints (even if some also market by litres), then what's wrong with leaving it as pints? sroc 💬 02:41, 20 February 2014 (UTC)[reply]
It'll be a matter of time that supermarkets will shift to litres and half litres of milk, then all that's left is beer. We will be able to change the guideline accordingly when that happens, but not before. Give it another couple of years. -- Ohc ¡digame! 02:54, 20 February 2014 (UTC)[reply]
It makes sense but I agree that "most" is vague. Something like "imperial pints for draught beer/cider and milk if bottled according to imperial standards" would be better. Jimp 08:06, 20 February 2014 (UTC)[reply]
The problem is that the text of the guideline is confusing and needs clarification. It is supposed to describe usage in Wikipedia articles, not usage in British shops (they may, of course, sometimes be the same but Wikipedia does not prescribe adherence to any particular British usage, e.g. marketing usage). The sense in which "used" is employed seems to change in the middle of the sentence. It starts off describing usage on Wikipedia
  • "In non-science and non-engineering UK-related articles: the main quantity is generally expressed in metric units . . . "
but continues
  • ". . . but imperial units are still used as the main units in some contexts, including: . . .imperial pints for draught beer/cider and bottled milk",
which appears to be describing usage in shops etc. and thus belongs in an article on metrication, not in the guideline.
That, at least, seems to be the general understanding here. I suppose it could be interpreted as a guideline for articles on draught beer and bottled milk, but it is formulated in a non-prescriptive way that is not helpful in the context of the Manual of Style.
So the question really is: does the guideline intend to prescribe imperial measures for draught beer and bottled milk in Wikipedia articles? Whatever the answer, the intended meaning should be expressed clearly. If the intention is to describe Wikipedia usage, "imperial pints for draught beer/cider and most bottled milk" does not really make sense, but the current text is also inadequate.
--Boson (talk) 11:50, 20 February 2014 (UTC)[reply]
The guidelines for units in UK-related articles are a dog's breakfast and have caused frustration on several occasions. They're overly general and vaguely worded — someone had the idea of using a table to clarify things (e.g. rather than just saying "use miles" it would say "use miles for X"), but for some reason that was never implemented, and the last discussion produced a very unhelpful stall. Archon 2488 (talk) 14:05, 20 February 2014 (UTC)[reply]
Does anyone really want to reopen this can of worms? It is best to leave it well alone. The current guideline, however imperfect, functions the great majority of the time. Furthermore, it is not as if articles are frequently describing bottled milk, whether in pints, quarts, drams or litres. It is merely hinting that common usage does use imperial in certain cases, which is true. There is no need for hairsplitting. RGloucester 14:54, 20 February 2014 (UTC)[reply]
Actually, the length of time between the end of the last discussion and this editor's decision to bring it up again is not particularly exceptional. 3-4 months is pretty close to the average. People wonder what the problem is, and at least a major part of it is that the same editors bring points such as this up so frequently.
The OP's premise is flawed. Most British householders do not buy their milk online. They go to the supermarket or have morning milk deliveries. We may find that supermarkets' own marketing is different than that of mysupermarket.co.uk - and not all British supermarkets have a major online presence (where's the Co-op?)
The number of instances of measures of bottled milk on Wikipedia is likely to be very small already, so splitting hairs further is unhelpful. Adding "most" is introducing the old "can is not must" argument, where every instance of measurement is construed to be an exception to the rule.

Kahastok talk 18:59, 20 February 2014 (UTC)[reply]

Kahastok, as milk is sold both by the pint and the litre, this is a "can and not must" situation. Michael Glass (talk) 22:18, 20 February 2014 (UTC)[reply]

Revised proposal

First of all, I'd like to thank editors for their comments. The website I have referred to shows that milk in the UK is sold in a variety of sizes, some metric and some Imperial. The old Times guide also mentioned this situation.

  • Yes, Most is ambiguous. We can't be sure on the evidence from My Supermarket how much milk is sold by the pint and how much is sold by the litre or which brands might be sold in other stores. All we know for sure is that milk is packed and marketed in both ways.
  • Yes, the situation might be clearer in a couple of years, but in the mean time, MOSNUM implies that all milk is sold by the pint. This is not accurate.
  • No, "imperial pints for draught beer/cider and milk if bottled according to imperial standards" could imply that selling milk by the pint was the exception. I don't think this is so.
  • Yes, there may be other problems with the wording, but let's just see if we can deal with this one.
  • Yes, the occasions when articles might need to milk containers is infinitesimal so we may not even need to mention it in MOSNUM.

The present wording implies that there is a cut and dried rule about milk. This is not true. Either MOSNUM should say that most milk is sold by the pint or all reference to milk sizes should be removed. Which do other editors prefer? Michael Glass (talk) 22:18, 20 February 2014 (UTC)[reply]

The present guideline does not state that all milk is sold by the pint. It says "imperial units are still used as the main units in some contexts". This is correct. Pints are very frequently used as the main unit for the sale of milk. Nevertheless, this is not a dairy. We are not selling milk. Leave it as it is. RGloucester 00:01, 21 February 2014 (UTC)[reply]
If pints are very frequently used as the main unit for the sale of milk then most milk is sold by the pint. The present wording implies something more. Adding just one word would clarify this point without implying anything less. Michael Glass (talk) 02:20, 21 February 2014 (UTC)[reply]
The real question is, dear fellow, why should we change it? Where has this provision ever caused a problem in the context of an article? Is someone writing an article on bottled milk? I suppose we could remove it, but I don't see why. It is one of the common exceptions to the rule, even if it is not used in articles, and it is worthwhile to note that for the reader of the guide. If you want to make it "most", that's fine with me, as it won't make a difference. We don't write about bottled milk anyway. Of course, others will disagree, because of the "can not must", nonsense, and because people here tend to like to interpret things in queer ways. RGloucester 02:47, 21 February 2014 (UTC)[reply]
Why change the wording? I believe that adding "most" makes the wording more accurate. For instance, on the My Supermarket web page for ASDA. 43 items were listed, but 4 of them were for litres of goat's milk and one was for 250g of buttermilk. Of the 38 remaining items, 17 were for cow's milk in litre or 2 litre containers. [12] Most milk is sold in pints, even though a substantial minority of items were in metric containers. It might be a small point, but I think it's better to be accurate. Michael Glass (talk) 04:33, 21 February 2014 (UTC)[reply]
  • Leave well alone: While absolute anal accuracy may be desirable in a perfect world, it's not worth more than about 2 minutes' discussion because the number of problematic occasions likely to be encountered is so small. And I've spent my 2 minutes. ;-) -- Ohc ¡digame! 09:45, 21 February 2014 (UTC)[reply]
Ohconfucius!, why have you made the status quo the enemy of the very slightly better? Confucius says, "To see what is right and not to do it is want of courage." What has made adding one word to the policy so frightening? Michael Glass (talk) 12:44, 21 February 2014 (UTC)[reply]
To be very honest, the topic of milk containers is utterly trivial, to the extent that I don't understand why it's even mentioned in MOSNUM. Is it important enough to merit its own mention as an exception to the rule that food is generally described in metric units? Is "can is not must" really such a problem in this case? If it really mattered you'd describe the container using the most appropriate units: 4 pints, not 2.272 litres, and 2 litres rather than 3.51951 pints. This is basically covered by the rule that nominal/defined quantities should be given in the original units first, which could sensibly be understood to include round metric or imperial fill amounts. Likewise with beer: nobody is going to argue that "a couple of pints" should be rendered as "1.13652 L" any more than "a couple of bottles of wine" should be replaced with "1.5 litres of wine". All that being said, Wikipedia isn't a dairy, a bar or a recipe book, so I can't imagine why this would ever be an issue. Archon 2488 (talk) 13:38, 21 February 2014 (UTC)[reply]
I agree that it is not worth opening up this can of worms at present. I suppose we need the wisdom to distinguish between that which cannot be changed and that which can be changed, regardless of what 'should' be changed. I can't see a sensible solution emerging without an inordinate amount of effort as long as greater tolerance of editorial disretion ("can not must") is rejected by at least one editor with strong views on the subject. However, I think it would be worth noting for future reference (when this section of the MoS is next reviewed) that the wording needs to be revised to clarify exactly what usage is prescribed (or otherwise) by the MoS and remove any (of necessity over-simplified) pronouncements about actual usage by the general public. Discussion of actual usage belongs on the talk page (or at most in footnotes). Greengrocers' and other shopkeepers' usage is largely irrelevant to Wikipedia style. Wikipedia usage should follow the usage of non-fiction prose, giving a little weight to journalistic usage and scholarly usage but most weight to usage demonstrated by texts aimed at an educated but non-expert readership. --Boson (talk) 15:28, 21 February 2014 (UTC)[reply]
I've made it clear several times that my objection is not to "greater tolerance of editorial discretion" - though it is worth considering that the only editors who argue that there is no room for common sense interpretation of the current rules are you and the OP.
And the fact is that the OP has a long record of refusing to accept that there is any possibility of middle ground between a complete strait-jacket and a complete free-for-all. We know through over half a decade of experience that if we add any form of ambiguity to these rules, the OP will take it as license to mass-convert articles for no reason other than his personal POV. Hence: "can is not must": his argument is that the fact that MOSNUM prefers one unit becomes irrelevant if there is any potential get-out. We as editors would be exceedingly naïve to pander to such a POV push. Kahastok talk 19:32, 21 February 2014 (UTC)[reply]
I don't recall arguing that there is "no room for common sense interpretation of the current rules".
I do recall arguing that WP:IAR is best reserved for unforeseen or exceptional circumstances, not as a general excuse for sloppy formulation of guidelines that can easily be improved. Perhaps that is what you were thinking of. I see no harm in stating where we wish to explicitly allow alternatives (as we do elsewhere). --Boson (talk) 23:07, 21 February 2014 (UTC)[reply]
I do see harm in writing up the rules in a way that has been abused on an industrial scale in the past, by editors announcing that the wording gives them license to convert articles against the rules for no reason other than their own POV. Particularly when one of the main proponents of such a change (not you) has such a long history of such abuse.
I have just reviewed the text I previously suggested at User:Kahastok/Units2, and I invite you to look at it for an example of a way that we could explicitly allow editorial discretion without pandering to the "can is not must" argument - i.e. by explicitly requiring a good reason for deviating from the rule. Kahastok talk 15:21, 22 February 2014 (UTC)[reply]

This is an improvement over the existing version (almost anything would be), and I am pleased that it allows for nuance. Specifically, we need to be aware that the units in official use for many things do vary: saying that most people prefer imperial for height/weight is well enough, but in a lot of sports it's measured in metric units, and that needs to be accommodated (this is almost the only use of height/weight units for people on Wikipedia). I seem to remember that a previous proposal to this effect was shouted down for no good reason: so long as accurate NPOV information can be found to justify preferring metric units, then there should be no accusations of editorial bias. Likewise with horses etc. — if the context is horse racing and the official measurements are in hands, then fair enough, but otherwise I'm dubious as to why they should be given primacy. Outside of the context of horse racing I don't think hands are more familiar to most people than metres. As a general rule, I think that "official use" as a criterion should be preferred to "common use", because the former is less ambiguous.

"Pints for bottled milk" — OK, but you'd typically give a container size in whatever units made most sense (as I see it, already covered by the rule that nominal and defined quantities are given in the original units first). In the UK, Blue Moon beer is typically sold in 12 US fl oz bottles — that's the way it is. Anyway, this will occur so rarely that it will be a bridge that can be crossed when we come to it.

"Miles for length" is a bit strange... length of what? Runway lengths would be given in feet in imperial units, but the only people who still do that are the Americans. Lengths of road are imperial: that seems to be settled on. Rail is imperial or metric according to which line it is (a poor compromise, but necessary as the British rail system is transitioning to the use of metric units). As far as distances go, it's a bit more complicated. Generic British articles might use imperial distances, but geography-oriented articles such as Windermere should probably prefer the metric units, because those are the units used on maps of the British Isles (and the standard international geographical units), as well as the units used in hiking and most outdoor activities in the UK (this, I think, is the demographic towards which such articles should really be targeted, if anything). In any case, I would want to be sure that these points would be accepted rather than dismissed as "excuses" for the mass-conversion of articles and the ever-dreaded "can is not must". Archon 2488 (talk) 00:32, 23 February 2014 (UTC)[reply]


I must admit that I do not give much weight to the argument for formulating guidelines in a vain attempt to avoid the possibility of abuse. Rigorous enforcement of policy might have served us better. Do you have any examples of abusive mass changes of primary units for milk in returnable bottles?

I assume your reference is to the following part of your draft:

There have been many disputes on Wikipedia over unit use on UK articles and most have arisen between editors advocating the superiority of one system over another. Because the primary reason for Wikipedia's existence is to provide an online encyclopedia that is readily accessible, the following approximation to local usage (broadly based on the style guide of The Times) is applied.

The primary quantity is generally expressed in an SI unit or a non-SI unit officially accepted for use with the SI (44 kilograms (97 lb)). However, in some contexts, the primary quantity is expressed in imperial units. These include:


In articles specifically related to UK engineering, including all UK bridges and tunnels, the primary quantity is generally expressed in the units that the project was designed in, whether metric or imperial. However, the primary quantity for road distances and speeds should still be expressed in miles and miles per hour as above.

Some editors hold strong views for or against metrication in the UK. If there is disagreement about the units used for main quantities in an article, discuss the matter on the article talk page, and consult relevant WikiProjects, and/or MOSNUM. Exceptions to the above – in either direction – may be appropriate if there is a good reason; however, personal preference or alignment with the specific source cited to justify the measure are not considered good reasons.

Of course, we would have to lose the bit about editors "advocating the superiority of one system over another" and other inappropriate discussion of editors' views, behaviour or motivation, but otherwise that looks like a good starting point. The mention of The Times also adds nothing, and some adjustments might be appropriate to bring the recommendations into line with legislation. For instance, "bottled milk" should possibly be replaced by "milk in returnable bottles". A similar small adjustment to reflect the relevant law would probably also be necessary for "miles for length and distance" but, since we can probably base the wording on actual legislation, that should not be a problem; the exception from metric units mainly applies to road distances, in particular road signs, and does not apply to maps etc. All that should make the text a bit shorter, too. --Boson (talk) 01:29, 23 February 2014 (UTC)[reply]

No wholesale revision is needed. Leave the guidelines be. RGloucester 04:38, 23 February 2014 (UTC)[reply]
The vast majority of usage - particularly on Wikipedia - is in areas not covered by legislation, so I would strongly oppose any attempt to bring the advice into line with legislation. Length is useful for e.g. rivers, and the difference between distance and length is sufficiently small that trying to say that the one should be in miles and the other in kilometres is likely to cause complete chaos.
The Times remains relevant: this discussion demonstrates its relevance because we have an editor here demanding changes based on his interpretation of British usage based on an internet shopping site's interpretation of shops' milk sales. What other interpretations of British usage can we come up with based on similarly specious evidence? Wikipedians like sources, and the Times is a useful and appropriate source to base this advice on (though not to follow religiously).
But the best option is probably to leave the thing alone as per RGloucester. Kahastok talk 09:36, 23 February 2014 (UTC
Two comments:
  • I suggested two possible revisions of the present wording. Calling this a demand is a hostile misrepresentation.
  • I stated that milk cartons are sold in pints and litres. This was based on clear evidence: here [13], here [14], here [15], and here [16]. Calling this evidence specious amounts to wilful blindness.
Either milk is sold by the litre as well as the pint, or it is not. I have stated that it is, and have backed it up with clear evidence. Kahastok has denied this. Either he is right or I am right. I invite other editors to click on the link and judge for themselves who is telling the truth. Michael Glass (talk) 11:57, 23 February 2014 (UTC)[reply]



Thank you one and all. I have taken on board your advice that adding one word to the policy to bring it more in line with actual British practice is both utterly trivial and utterly subversive. However, I do challenge anyone to find one instance where clarifying the advice on milk containers could possibly lead to any mass conversion of articles. That is fanciful nonsense. Michael Glass (talk) 20:54, 21 February 2014 (UTC)[reply]

I agree in principle that more accuracy is not a bad thing, but specifying the preferred units in such minute detail is not obviously beneficial. "Most milk" is a distinction without a difference. I fail to see how milk can be a POV push in any realistic way (I mean, really?!) How many articles involving British milk bottles are there to be mass-converted? Why is milk even in MOSNUM in the first place? Archon 2488 (talk) 22:44, 21 February 2014 (UTC)[reply]
In this instance? The proposal carries zero benefit, splitting hairs in a context not likely to be well-used on Wikipedia. But in the wider case, this sort of "can is not must" argument will be used by the OP to push a POV if we give it acceptance in our guidelines, as many years' experience demonstrates. Kahastok talk 15:21, 22 February 2014 (UTC)[reply]
I have to say, the idea that milk is in any way a POV push strikes me as even more bizarre than the fact that MOSNUM bothers to mention it. It's not biased to say that "most" milk is sold in imperial containers, and I agree with it: it's a statement of fact, albeit a needlessly over-detailed and trivial one. If MOSNUM has to keep track of the minutiae of all the units in use in this country, which seems to be the road we're going down, then I guess "most milk" is more correct. Objecting to an argument just because of who happens to propose it is committing the genetic fallacy and is itself a biased argument. Switching the topic immediately to "what are X's motives" rather than "what are the units in use" is unhelpful and bound to start an unpleasant argument.
The bigger issue here is that the rules don't actually specify how to use the units, which invites misunderstandings and disagreements. And, yes, gaming. Archon 2488 (talk) 18:14, 22 February 2014 (UTC)[reply]
I've made the point several times now that we are very unlikely to measure bottled milk on a regular basis, and that creating hair-splittingly small changes in it - particularly creating such vagueness - carries no benefit to the encyclopædia. This is why I introduced my comments with "in the wider case": exactly the same arguments have been made repeatedly by this editor in other cases. Where in the past they have managed to get such wordings into the rule, this editor has abused them on an industrial scale. Kahastok talk 18:49, 22 February 2014 (UTC)[reply]
The above comment is ad hominem nonsense. A minor change in wording about milk could not possibly lead to the mass conversion of articles. It is clear that Kahastok's opposition to this proposal is based on personal animosity. Michael Glass (talk) 10:49, 24 February 2014 (UTC)[reply]
If bottled milk rarely features on Wikipedia, why is it even mentioned? If "most" is accurate, then why is it "vague"? How open is milk to POV abuses? A sense of perspective is needed. Archon 2488 (talk) 00:03, 23 February 2014 (UTC)[reply]
Well, howz about:
  • "In Britain, milk is usually stated in pints, except when it's sold in litres" or
  • "In Britain, milk in returnable 1-pint bottles is sold in pints, or it may be sold in litres"?

<just joking> ;-) -- Ohc ¡digame! 03:05, 23 February 2014 (UTC)[reply]

Did anyone notice that the premise of the OP is flawed?
[17] Sainsbury's sells milk by the pint, one exception is a proprietary lactose free product from Arla.
[18] Asda sells milk by the pint, one exception is the same proprietary lactose free product from Arla.
The assertion that the major supermarkets have switched to litres is not true. Surprise, surprise the unit of choice of all major supermarkets is still PINTS.
No change is required to WP:MOSNUM and as noted by another poster:
  • Constantly raising the issue of UK Metrication every 3-4 months is disruptive
  • A word of advice, anal nit picking detail simply annoys and makes any consensus on anything proposed highly unlikely.
  • We've already seen one editor indefinitely topic banned for constantly raising the issue of UK Metrication disruptively. I would suggest the patience of the community is being tested again and would strongly advise the OP to drop the stick and step away from the dustpile that was a dead horse about 5 years ago. Wee Curry Monster talk 12:40, 24 February 2014 (UTC)[reply]
That's a bit of a misrepresentation of what he said: "most" of the items on sale on the Sainsbury's page are imperial, but several are metric (in addition to the Arla one, the Cravendale, Taste the Difference, Yeo Valley, Flora Pro-Activ and St Helen's Farm products come in metric containers). Individual product lines are not even consistent: Tesco Pure comes in 1 pint, 1 litre and 2 litre sizes. So it's not incorrect to say "most", and it does not imply that British supermarkets have converted en masse to litres, but it's just a bit unimportant. Like I said, it's not even obvious why bottled milk (!) belongs in MOSNUM. Archon 2488 (talk) 12:58, 24 February 2014 (UTC)[reply]
The same misrepresentation is repeated in WCM's reference to ASDA. Once again, though the majority are in pints, several are metric. So we have seen that WCM's evidence is flawed on both counts. Here are some other failures on his part:
  • He has failed to note that I have already stated the following: "Thank you one and all. I have taken on board your advice that adding one word to the policy to bring it more in line with actual British practice is both utterly trivial and utterly subversive. However, I do challenge anyone to find one instance where clarifying the advice on milk containers could possibly lead to any mass conversion of articles. That is fanciful nonsense." That means I have accepted that my proposal to add a word of clarification to the policy (or to delete a couple of words) has failed. End of that story. However, I reserve the right to answer his misrepresentations.
  • My proposal was to say that most milk was sold by the pint: WCM has accused me of asserting that "that the major supermarkets have switched to litres" Once again he has got his facts wrong.
Enough said. Michael Glass (talk) 13:42, 24 February 2014 (UTC)[reply]
I see the point about anal nit picking being annoying sailed right over your heads, no matter. For the record, I violently oppose any change in wording that introduces the slightest amount of ambiguity, since bitter experience over about 5 years leads me to conclude it would simply lead to the most absurd edit wars over unit order precadence on UK related articles. Please drop the WP:STICK. Wee Curry Monster talk 14:03, 24 February 2014 (UTC)[reply]
  • Exactly. We cannot go by simply counting SKUs, and there is no way we can ascertain the volume of milk that is sold in containers using metric or imperial units. All that can be said are the trends towards metrication. But as everyone but MG seems to agree, what is being argued for is so trivial and isn't worth the time of day. Can we close this now, please? -- Ohc ¡digame! 07:29, 25 February 2014 (UTC)[reply]

> For the record, I violently oppose any change in wording that introduces the slightest amount of ambiguity

Beware of being too dogmatic and inflexible. If the real world isn't consistent, it's not generally reasonable to demand that Wikipedia should be. My main concern is that editors are forced into a straitjacket of using officially-deprecated units based on the spurious excuse that "they're more common". We also need to be aware that the units are changing, however slowly, and dismissing attempts to provide evidence of change as "anal nit picking" is unhelpful. Archon 2488 (talk) 15:01, 24 February 2014 (UTC)[reply]

  • AFAIK, our guideline remains correct. Whilst more and more milk seems to be coming to supermarkets in metric containers, bottled milk is still sold in pints. But because it's so utterly trivial, and does not affect many articles, it may be simplest to remove any mention of bottled milk from the guideline. -- Ohc ¡digame! 07:41, 25 February 2014 (UTC)[reply]
I see nothing in this discussion that would suggest that any change is needed. Suggest we close. Kahastok talk 18:50, 25 February 2014 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

"Right" date format in Wikipedia for YMD format countries (eg. Japan, China)

I refer to Date format by country for the right date format, but YMD is (usually) frowned upon in Wikipedia. Japan uses MD, but including year it's YMD and I've never seen explicitly if MDY should be used (for WP:STRONGNAT). Have seen MDY and DMY used in articles (and even both in same). Which is better (in case both are used, when trying to make consistent)? Can't strictly use either and claim WP:STRONGNAT? Should/do we recommend DMY, or MDY or allow both?

Not a problem when other format also allowed, but same problem when DMY and MDY both used (which more?). comp.arch (talk) 12:17, 24 February 2014 (UTC)[reply]

In English Wikipedia articles, we ought to use English formats, not formats that mirror those used in the countries that the articles relate to (unless those are English-speaking countries). W. P. Uzer (talk) 12:26, 24 February 2014 (UTC)[reply]
I don't really see how an international standard can be said not to be English, but in any case it is explicitly recognised as a standard by many bodies in the Anglophone world [19]. Archon 2488 (talk) 12:49, 24 February 2014 (UTC)[reply]
YMD is not endorsed by Wikipedia for general use, and with good reason. YMD is all well and good as a standard, but it's not in common usage in the English-speaking world. MOS:DATEFORMAT reflects real-world use, not an idealised version. One day, the world may change—maybe Americans will even give up the un-endian MDY format—but as of now, we don't use YMD for general prose. sroc 💬 13:03, 24 February 2014 (UTC)[reply]
(edit conflict)WP:STRONGNAT does not apply to non-English-speaking countries. YMD format is not merely "frowned upon"; it's not permitted in general prose, per MOS:DATEFORMAT. Use either DMY or MDY—both formats are equally acceptable, a consequence of having users on English-language Wikipedia from different parts of the world accustomed to different formats, rather than separate wikis for every varieties of English. Once either format is established in a given article, it should generally stick, per WP:DATERET. sroc 💬 12:59, 24 February 2014 (UTC)[reply]
This is a standard which is in real-world use for many things. Nonetheless, numeric dates should not be used in general prose at all, be they YMD or the illogical US format: the date should be written out in full per MOS:DATEFORMAT. If brevity is desirable then the YMD format may be used, which I agree with. To end up with a bizarre mixture of US and UK date formats because we don't like asking people to use sensible international standards (on an international project) is perverse and pointless. Archon 2488 (talk) 13:44, 24 February 2014 (UTC)[reply]
The standard may be "in real-world use for many things", but is not widely used in prose as far as I am aware, so adding it to prose in Wikipedia articles would spook readers more than the familiar DMY and MDY formats. In an ideal world, we would choose either DMY or MDY for general prose, but we don't live in an ideal world. Most of the world prefers DMY, but a large part of Wikipedia's readership (and editorship) uses MDY, and we don't want to irritate supporters of either one, so both are supported. Whichever format the reader prefers, they would still readily understand the other. Unless we cleave the Wikipedia in twain for different audiences, this is the compromise, for better or worse. sroc 💬 22:26, 25 February 2014 (UTC)[reply]

WP:BLP, WP:STRONGNAT and "right" date format (for non-English speaking countries)

When seeing MDY or any other than DMY in "Icelandic" (BLP) articles I've taken the liberty to change to DMY (Iceland's date format). Nobody has complained. From section above I'm told WP:STRONGNAT doesn't apply. It should, and I want to see that changed in the MOS.

Sorry for the confusion in the section above, I see now that there can be no right date format for eg. Japan related articles, both DMY and MDY could apply. When seeing a mixture of formats used, I would like to have the option of changing to DMY there also without having to search for whether MDY or DMY was first use.. (I've seen both on first use..).. comp.arch (talk) 10:55, 25 February 2014 (UTC)[reply]

My impression from MOS:DATEFORMAT was that MDY and DMY should not be used in general. The permissible numeric date format (YYYY-MM-DD only) should be restricted to references and tables, where it makes sense. In prose the date should always be written in full and will thus be unambiguous. Have I missed something? Archon 2488 (talk) 11:35, 25 February 2014 (UTC)[reply]
I assume you meant "MDY or DMY should be used in general"? That is not the issue I had. It's which one. See below, and am I allowed to change eg. MDY to DMY, (possibly when both/either is used (on first use)). comp.arch (talk) 14:19, 27 February 2014 (UTC)[reply]
I agree that one comes upon an article with mixed date formats, it is a pain in the neck to try to figure out if it once had a consistent, established date format. But that is the rule and it would require a well-advertised RFC to change it. Jc3s5h (talk) 16:12, 25 February 2014 (UTC)[reply]
I understood the previous poster to mean "MDY" and "DMY" to refer to dates being written in full. 25 Feburary 2014 is DMY, and February 25, 2014 is MDY. AFAIK Wikipedia accepts both of these formats, but doesn't encourage switching from one to the other without a reason. W. P. Uzer (talk) 15:15, 25 February 2014 (UTC)[reply]
I see. This makes more sense, but it strikes me that when it's written out in full it doesn't make the slightest bit of difference. So long as there is only one numeric format allowed, and it's used only in a few special contexts (in particular, nonsense like 2/3/14 must be completely disallowed for obvious reasons) then there's no reason for disagreement. Just pick one of the two arbitrary long formats and stick with it, which is what WP:DATERET seems to imply. I'm not even consistent in my own life as to whether I use MDY or DMY for the written date. Archon 2488 (talk) 15:53, 25 February 2014 (UTC)[reply]
We had this a while back and some editors maintained that if a nation wasn't English-speaking, there was no national variety of English and therefore whatever format the first editor used was the one the article should stick with. I think that's bizarre and that date format is like units of measurement and currency symbols - we should use whatever that nation uses. --Pete (talk) 17:22, 25 February 2014 (UTC)[reply]
I'm quite sympathetic to this suggestion. My philosophy is that the English Wikipedia shouldn't just be for native English speakers (indeed, many of our contributors and readers are not native speakers) but it should be for everyone who can speak English. An odd peculiarity of defining "English-speaking countries" is that you can't necessarily go by a) official languages (then the USA wouldn't count since it doesn't have an official language) or b) majority use (since South Africa wouldn't count, because although English is an official language and is the de facto lingua franca, it's the native language of a fairly small minority of the population).
English is perhaps unique in that it's a language with significantly more second-language speakers than first-language speakers. In particular, there are countries like Sweden and Iceland in which nearly 100% of the adult population speak English to an advanced or near-native level. It seems a bit arbitrary to exclude these people from considerations of "strong national ties" as far as writing style is concerned. Archon 2488 (talk) 22:12, 25 February 2014 (UTC)[reply]
Good point. sroc 💬 22:45, 25 February 2014 (UTC)[reply]
If we allow them, then we need to allow all, including China, Japan, Korea, Taiwan, Hungary, Mongolia, and Lithuania. They're a third of the world's population, yet the MOS disallows their YMD format. I've we're not allowed to use Lithuanian-style dates for Lithuania, then there's no good argument for using Icelandic-style dates for Iceland. — kwami (talk) 22:43, 25 February 2014 (UTC)[reply]
We don't use YMD in written English. This is the English Wikipedia. Therefore we don't use YMD in our text. Occasionally in tables, which is an acceptable usage, mainly because YMD is self-sorting. However, we use both DMY and MD,Y in written English, and I think it is just common sense and consistency to treat a nation's preferred choice of these two formats in the same way as we treat a nation's choice of units of measurement etc. --Pete (talk) 23:17, 25 February 2014 (UTC)[reply]
If we were going to consider the date format preferences of countries like India and China because they have many people who write English as a second language, we would have to discover what their preferred date format is when they are writing English. That could be tricky to find out. Jc3s5h (talk) 23:32, 25 February 2014 (UTC)[reply]
In the case of India, not at all. --Pete (talk) 00:13, 26 February 2014 (UTC)[reply]
Yes, and "screw China, they're too weird" is not a very encyclopedic approach. Either we follow countries' preferred date formats, or we don't. — kwami (talk) 00:10, 26 February 2014 (UTC)[reply]
Not necessarily - we might choose to follow countries' preferred formats if they correspond to one of the accepted English formats, but not otherwise. The Chinese use YMD, which is not an accepted English format (in ordinary prose), so we wouldn't follow it. I don't know (but someone might) what format Chinese people tend to use when writing English - if it turns out they have a clear preference for MD,Y, for example, then we could adopt that format for articles about China. Similarly, if it turns out they have a clear preference for American spellings over British ones, then we could aim to use such spellings in articles about China. Personally I don't think it really matters that much, but such criteria seem at least more logical than just randomly following the preferences of whoever started the article. W. P. Uzer (talk) 07:10, 26 February 2014 (UTC)[reply]

I agree that allowing the question to be settled by whoever happened to submit the first version of the article isn't ideal — as a rule, it will invariably produce an inconsistent mishmash of different formats, even on different articles about the same topic, related to the same country. It's a pragmatic way to break a stalemate, but not a recipe for a consistent style.

It is desirable to follow local usage if possible: nobody could argue that it's acceptable for an article about France to give distances primarily in miles, for example, using the excuse that the article was originally submitted by an American. So if, as I suspect, there were a clear preference among people from Continental Europe to use DMY (French invariably uses this format, e.g. "le 1er mai 2011" so I assume that French-speakers would find it natural to use this format in English — also German, "am 1. Mai 2011") then I think that it should generally be used in articles about that country. To my knowledge, MDY isn't very common outside the USA, so it's not obvious why it belongs in non-USA-related articles (likewise, the imperial-first unit presentation style isn't generally used for non-USA-related articles). If a particular way of writing the prose date isn't used in any recognised variety of written English then it shouldn't be used ("on 2011 May 1"). Similarly, articles on China don't typically use Chinese customary units, because they're generally not used in an English-language context. India, on the other hand, should be an easy case, because English is an official language and is very widely used in the country as a lingua franca. Same applies to most Commonwealth countries, such as Nigeria, Kenya and Singapore: in all these countries, I think, there is a preference for DMY.

Summary: per W. P. Uzer, if there's a clear national preference for DMY or MYD date style in prose, that style should be used consistently in articles about that country. It's more useful as a criterion than WP:RETAIN. Archon 2488 (talk) 08:25, 26 February 2014 (UTC)[reply]

  • Logical, and I'm not arguing that we shouldn't pursue this to create greater consistency among a series of articles (as well as within an article), but it's currently a free-for-all here at present. I agree also that most other countries and languages from Slavonic to Latin cultures are natively "one-endian". Asian cultures are the exception in that they are "the other-endian". It's a humongous mess because I often see translated texts where these native dmy, for example Cinco de Mayo, are rendered into mdy format. Just looks weird, and perhaps we ought to change it. Very big job, though. -- Ohc ¡digame! 03:55, 27 February 2014 (UTC)[reply]

End of discussion (for me if WP:RETAIN (or similar rule) doesn't apply to dateformat, and WP:DATERETAIN is not in conflict). If RETAIN doesn't "forbid" changing dateformat, then my question is kind of moot and "unless there are reasons for changing it based on strong national ties" in DATERETAIN means "strong natural ties" in the general sense, not the WP:STRONGNAT-"English" sense. I thought I would claim WP:STRONGNAT as it trumps RETAIN, but it only applies to "English-speaking country" articles. That doesn't mean it applies to Icelandic articles, but neither that it forbids changing with STRONGNAT-like argument. If there is any rule that I don't know about that prevents, or people want to make explicit I propose:

Concrete proposal: "Articles on topics with strong ties to a particular English-speaking country should generally use the more common date format for that nation. For the United States, this is month before day; for most others, it is day before month. Articles related to Canada may use either format consistently."

be change to:

"Articles on topics with strong ties to a particular country should generally use the more common date format for that nation (of the allowed date formats). .." (meaning DMY (or MDY but not YMD).

or in case you do not want a "should" for non-English (having to look up date format):

"Articles on topics with strong ties to a particular English-speaking country should generally use the more common date format for that nation. For the United States, this is month before day; for most others, it is day before month. Articles related to Canada may use either format consistently. Articles on topics with strong ties to a particular non-English-speaking country may be changed to the more common date format for that nation (of the allowed date formats)."

Good suggestion. I favour the second - "may be changed" - wording. If an article is in the "wrong" format for a nation - Mozambique (say) - it is not a big deal which format is used. Either will be understood. Not all of us wince when we see the "wrong" format being used. But for the wincers, it would be nice to have the "may" option open, if they feel like it maybe, rather than opening things up for datenazis to use that "should" as a big stick. --Pete (talk) 17:25, 27 February 2014 (UTC)[reply]
I agree - second version is good. But wording should be more precise than just "more common date format for that nation" - does it mean the more common date format used by people from that nation when writing English, or the format that more closely parallels the format used by people from that nation when writing in their language? (And in that case, which format more closely parallels the Chinese YMD: is it MDY because it puts month before day, or is it DMY because it puts M in the middle?) W. P. Uzer (talk) 21:21, 1 March 2014 (UTC)[reply]
My rule of thumb has always been to change the localisation on my computer to the nation in question and then see what date format is set as the default. Maybe that's putting too much faith in the guys from Apple or Microsoft or Linux or whatever, but they seem to be in agreement, and presumably they are aiming to make their customers in the target nation satisfied. Whatever, I see that as the right date format for that nation. For places, like China, that use a date format we can't use in written English, I think whatever the initial date format was should prevail, because if we allow open slather, style warriors are going to colonise that article and then defend their turf. --Pete (talk) 21:49, 1 March 2014 (UTC)[reply]

Another suggestion "Articles on topics with strong ties to a country should generally use the date format that is more common there. In most countries it is day before month but in the United States, it is month before day. For articles on Canada, use either format but be consistent."

I think this covers all bases, with enough wiggle room in "should generally use" to keep the date Nazis at bay. Michael Glass (talk) 02:47, 6 March 2014 (UTC)[reply]

In my proposal I was trying to include Iceland (that uses DMY) and other non-YMD countries. Your proposal would allow eg. China/Japan that use YMD. English Wikipedia doesn't allow YMD (except for eg. references). comp.arch (talk) 09:05, 6 March 2014 (UTC)[reply]

Actually I had not considered countenancing YMD as this is not used in normal English prose. I saw it as a decision between MDY and MDY. Perhaps this would be clearer:

"Articles should generally use the day month year format for almost all countries and the month day year format for United States articles. For articles on Canada, use either format but be consistent."

That might be clearer. It has the advantage of being slightly shorter again and it presents the choice as being between DMY and MDY. Michael Glass (talk) 10:55, 6 March 2014 (UTC)[reply]

12-hour vs. 24-hour clock

It seems to me that MOS:TIME is unclear on when to use which format. What exactly is meant by "[c]ontext determines whether the 12- or 24-hour clock is used"? Archon 2488 (talk) 12:03, 25 February 2014 (UTC)[reply]

(crickets)
It isn't abundantly clear, but I suspect this refers to which format is used relevant to a particular location. For example, the UK uses 24-hour time, so articles about the UK should probably use this format. I think the same guidance for DMY or MDY date formats could apply here: unless there is a reason attached to a particular country, follow whichever format is used by the first editor. sroc 💬 22:58, 27 February 2014 (UTC)[reply]
That's what I thought. So I guess the rule should be the same as for dates: try to follow national usage where possible. I think a strong preference for the 12-hour clock is largely an American idiosyncracy, although it is still used to varying degrees in the rest of the English-speaking world, at least informally. More formal usage outside the USA tends to prefer 24-hour, and it's easier to parse and less ambiguous, so I'd say go with that. But in any case, "context determines" is uselessly vague as a guide to which format to use, and it should be improved. Archon 2488 (talk) 19:51, 1 March 2014 (UTC)[reply]
Whether the 24-hour format is easier to parse or not depends on what you're used to. I'm more used to the 12-hour format and I'm not American. I'm not aware of any preference one way or other in terms of formality. As for ambiguity, neither is inherently ambiguous as long as you take care to avoid potential ambiguity, admittedly, though, more care is needed with the the 12-hour format. Jimp 09:02, 6 March 2014 (UTC)[reply]

Comma delimiting for four-digit numbers

Wikipedia:Manual of Style/Dates and numbers#Delimiting (grouping of digits) currently states:

  • Numbers with five or more digits to the left of the decimal point (i.e. 10,000 or greater) should be delimited into groups so they can be easily parsed, such as by using a comma (,) every three digits (e.g. 12,200, 255,200, 8,274,527). A full stop (.) should not be used to separate thousands (e.g. 12.200, 255.200) to avoid confusion with the decimal point.
  • Numbers with four digits to the left of the decimal point may or may not be delimited (e.g. 1250 or 1,250).

Apparently: "Most authorities, including The Associated Press Stylebook and The Chicago Manual of Style, recommend a comma after the first digit of a four-digit number." But that's not why I'm here.

I have previously read (in a printed style guide which I no longer have, possibly from Funk & Wagnalls) that the comma may be optional for four-digit numbers but should always be included when the number is in a list with other numbers that have the comma (e.g.., numbers with five or more digits). Thus:

  • $100, $500, $1,000 or $100, $500, $1000
  • $100, $500, $1,000, $25,000 but not $100, $500, $1000, $25,000

This seems right to me, and need not be applied only to lists, hence this edit where I added commas to "$1,000" and "$5,000" throughout the tables for consistency with "$10,000" which was used in the same tables.

I propose to add this to the second bullet point:

  • Numbers with four digits to the left of the decimal point may or may not be delimited (e.g. 1,250 or 1250). They should be delimited when used alongside other numbers that are delimited, such as in lists or tables (e.g., $500, $1,000, $5,000, $10,000 instead of $500, $1000, $5000, $10,000).

Thoughts? sroc 💬 14:12, 26 February 2014 (UTC)[reply]

Another interesting case: if there is a list of distances, for instance in running or speed skating, and the longest distance is the only one that has five digits, namely ten-thousand metres, then, with the current rules, there would be inconsistency in the use of the comma between the distances in the list, for just one distance. See for instance Category:Speed skating record progressions and Category:2013–14 ISU Speed Skating World Cup – World Cup 1.
Had the also been competitions in the 12km and 15km distances, then it probably would have been a clear-cut case, but when there is a single occurrence at the end of the range, should that occurrence have a comma, and should that then affect all four-digit occurrences?
HandsomeFella (talk) 14:26, 26 February 2014 (UTC)[reply]
The fact that you raise categories is interesting, because each title is usually shown in isolation, but they are shown together in the category. The first one (Category:Speed skating record progressions) only has one title that should have a comma but doesn't (World record progression 10000 m speed skating men). The second one (Category:2013–14 ISU Speed Skating World Cup – World Cup 1) doesn't have any distances over four digits, so it's irrelevant. I wouldn't be particularly concerned about these cases though (i.e., insisting that every "X000 m" article be renamed "X,000 m" if it is tagged in the same category as a "XX,000 m" article. I'm really only concerned with uses within a given article, so if these events were listed in an article, they should consistently have a comma if any of them have one. sroc 💬 14:46, 26 February 2014 (UTC)[reply]
For example, in an article in speed skating, I might include this list:
Note that I would include the commas in the list even though they do not appear in the article titles. sroc 💬 14:52, 26 February 2014 (UTC)[reply]
My mistake, I should have used World Cup 3 instead. See Category:2013–14 ISU Speed Skating World Cup – World Cup 3. HandsomeFella (talk) 15:01, 26 February 2014 (UTC)[reply]
Ah, yes. Same goes. 2013–14 ISU Speed Skating World Cup – World Cup 3 – Men's 10000 metres should be 2013–14 ISU Speed Skating World Cup – World Cup 3 – Men's 10,000 metres in order to comply with the guideline. Meanwhile, since World record progression 10,000 m speed skating men was erroneously moved, I've re-opened the discussion at Talk:World record progression 10000 m speed skating men#Revert move to have it put back. sroc 💬 15:17, 26 February 2014 (UTC)[reply]
Incidentally, this wouldn't be an issue if the longer events used kilometres instead, i.e.:
sroc 💬 15:21, 26 February 2014 (UTC)[reply]
The problem with 10 km is, that people generally don't say "ten-kay", they say "ten-thousand", (cf. "five-thousand") in this context. That's my experience/impression at least. Btw, I have opposed your RMs. Don't take it personally. HandsomeFella (talk) 15:35, 26 February 2014 (UTC)[reply]
Fair enough. I don't take it personally, I just don't understand your reasoning. MOS:NUMERAL says one thing, the article does the opposite. In fact, you previously cited MOS:NUMERAL to do the opposite of what MOS:NUMERAL says to do, and the only other editor to comment blindly said the same thing following another editor's proposal. What is your reasoning here? sroc 💬 15:56, 26 February 2014 (UTC)[reply]
By the way, I recognise the distinction between following MOS:NUMERAL in isolated cases with five digits (i.e., 10,000 over 10000 as in the proposed moves) and amending MOS:NUMERAL to clarify whether to delimit four-digit numbers in lists (as discussed above). These issues are not synonymous. sroc 💬 16:00, 26 February 2014 (UTC)[reply]
I would add that, as it seems most style guides favour a comma for four-digit numbers while some sources leave this as optional, if you want to avoid inconsistency in a series of numbers which include five-digits numbers (which style guides universally call for delimitation), then it only makes sense that the inconsistency be resolved by including the comma in the four-digit numbers (where some see it as optional) and not by omitting it from the five-digit numbers (where it is widely agreed to be required). sroc 💬 16:11, 26 February 2014 (UTC)[reply]
I'm unsure what article – that does "the opposite" – you are referring to. HandsomeFella (talk) 16:26, 26 February 2014 (UTC)[reply]
The simple solution to this (non?) problem is to always omit the comma where used as a decimal separator, reserving that (very useful) little character for where it is really needed, in the grammar or as a list separator. Dondervogel 2 (talk) 17:32, 26 February 2014 (UTC)[reply]
@Dondervogel 2: We are not dealing with decimal separators (and MOS:DECIMAL does not allow the comma to be used as such anyway). This concerns delimiters (grouping of every three digits). sroc 💬 00:42, 27 February 2014 (UTC)[reply]
OK, so I used the wrong term. Where I wrote "decimal separator", please read "delimiter". My point is that the comma does not add any new information. It just adds ambiguity because "1,234" can be read either as a single number "1234" or as two numbers "1" and "234", separated by a comma. Dondervogel 2 (talk) 08:09, 27 February 2014 (UTC)[reply]
No, it isn't ambiguous. We put spaces between numbers, too (They were aged aged 3, 15, 44, 100 and 103; not They were aged aged 3,15,44,100 and 103). All style guides endorse delimiting, a convention that is widely followed in the real world. Otherwise, it becomes very hard to read large numbers (5,000,000,000 vs 5000000000). You may prefer delimiting with non-breaking spaces over commas, but that's not the issue here. sroc 💬 08:28, 27 February 2014 (UTC)[reply]
@HandsomeFella: This is really getting off-topic, but I'm referring to this:

Remove delimiting comma per WP:NUMERAL. I have included the men's 10,000 – or 10000 – in the RM for consistency, although the guidelines say that five digits or more should include the comma, because I think it looks a little awkward in the context.
— User:HandsomeFella 17:06, 8 July 2013 (UTC)

The wording of the quoted section from WP:NUMERAL is the same as it was then, namely, that:
  • The comma is required for five-digit numbers—despite this, you lobbied to have the comma removed (10,00010000);
  • The comma "may or may not be" used for four-digit numbers—not supporting change (1,0001000) but remaining neutral, so it didn't really support a change in the status quo.
The change has ultimately gone from a case that did comply with WP:NUMERAL (10,000, 1,000) to a case that does not (10000, 1000). So you couldn't really say "per WP:NUMERAL" to justify the change. sroc 💬 00:53, 27 February 2014 (UTC)[reply]
I have no particular opinion on the use of commas in 4-digit numerals (other than always using them myself); but with regard to the OP's remembrance of a style guide's statement that they "should always be included when the number is in a list with other numbers that have the comma", I think I can offer some clarification. The style guides I'm familiar with that make such a statement are referring specifically to vertical arrangements of numerals, and the rule is to ensure that the thousands digits of 4-digit numerals align with the thousands digits of the larger numerals. Situations like
1,250,500
1500
36,400
are what they're trying to avoid, since such presentations make the interpretation (and addition) of columns of figures difficult. Deor (talk) 13:56, 27 February 2014 (UTC)[reply]
I've seen guides advising using commas w 4 digits to visually distinguish them from year dates.
Deor, that's a good argument, but the same would apply to spacing delimiters, and currently our templates group 4 digits together. It would be nice to be able to override that. I'm not sure it's what ISO intended either, but they're rather vague. — kwami (talk) 15:07, 27 February 2014 (UTC)[reply]

Binary prefixes February 2014

About 10 days ago, Dondervogel 2 changed, without discussion,

... currently favours the retention of the more familiar but ambiguous units "KB", "MB", "GB", "TB", "PB", "EB", etc. over use of IEC binary prefixes. Use 256 MB of RAM, not 256 MiB of RAM.


to

... consensus on Wikipedia in computing-related contexts currently favours the retention of the more familiar but ambiguous units "KB", "MB", "GB", "TB", "PB", "EB", etc. over use of unambiguous (but less familiar) IEC binary prefixes. Use 256 MB of RAM, not 256 MiB of RAM.

I corrected it to

... consensus on Wikipedia in computing-related contexts currently favours the retention of the more familiar but ambiguous units "KB", "MB", "GB", "TB", "PB", "EB", etc. over use of unambiguous (but less familiar and virtually unused in reliable sources) IEC binary prefixes. Use 256 MB of RAM, not 256 MiB of RAM.

After being reverted, I restored the first version, per WP:BRD. Some might think the change is required by grammar, but I feel the second version implies that the consensus is because it is less familiar, rather than because it is rarely used in the real world, which was the real version of the consensus. — Arthur Rubin (talk) 11:28, 28 February 2014 (UTC)[reply]

After a little thought, just leaving the word "unambiguous" in place, with no further commentary, might be better. However, that may also change the meaning, so I don't want to do it without consensus. — Arthur Rubin (talk) 11:33, 28 February 2014 (UTC)[reply]

If the change I made then (which followed a discussion on the talk page about how to clarify the text, but this is incidental to my point) was considered controversial, I find it very strange that no one challenged it at the time, or even mentioned it on the talk page. By contrast, Arthur Rubin's assertion that IEC prefixes are "virtually unused in reliable sources" is highly controversial, which is why I reverted it, and presumably why he tones down the claim now to "rarely used in the real world". No one disputes that use of these prefixes is rare. I strongly dispute the notion that reliable sources do not use them. On the contrary, IEC prefixes are increasingly used in scientific publications, and are the nearly universal choice of disambiguation for those who choose to disambiguate. Dondervogel 2 (talk) 13:34, 28 February 2014 (UTC)[reply]
I couldn't find a discussion, going back two archives. Still, the clarification with just "unambiguous", rather than any parenthetical remarks, seems to cover the issue better. I disagree with your assertions later in the above paragraph; I have never seen the "binary" prefixes in a scientific publication. — Arthur Rubin (talk) 19:41, 28 February 2014 (UTC)[reply]
I agree the text "but less familiar" in brackets adds little and could be removed without changing the meaning. You can find hundreds of scientific publications that use IEC prefixes here of you are interested. The strange filter is to remove lots of spurious hits you would otherwise get that happen to use the abbreviations mib (e.g., men in black) or gib (Gibraltar). Dondervogel 2 (talk) 19:55, 28 February 2014 (UTC)[reply]
I see that, in December 2010, it was determined by consensus that you were, and had said, you would stop at nothing to get the IEC prefixes into Wikipedia. Your recent actions show no change in policy, except that you are toning down your actions to avoid immediate reverts and possible topic bans. Perhaps it is time to revive the topic ban proposal from 2010. — Arthur Rubin (talk) 19:59, 28 February 2014 (UTC)[reply]
The IEC binary prefixes were proposed almost 20 years ago and have failed to be adopted by the computer industry. Dondervogel 2 has been pushing for Wikipedia to adopt these "new and improved" IEC binary prefixes since 2008. Wikipedia uses the terminology that is commonly used in the real world. -- SWTPC6800 (talk) 03:01, 1 March 2014 (UTC)[reply]
Do either of you have any interest in the substance of the discussion? This is what happened: Arthur Rubin introduced a statement that Dondervogel 2 disagreed with and reverted; Arthur Rubin then proposed a change that Dondervogel 2 agreed to and Arthur Rubin implemented. Those are the facts, and that is how things are supposed to work. Wikipedia can manage quite well without the hot air. Dondervogel 2 (talk) 08:00, 1 March 2014 (UTC)[reply]

This strikes me as rather unfair. The IEC prefixes are certainly used in the real world (for example, my Linux desktop gives information in IEC units only). Their unambiguity is a strong argument in their favour: it's not unreasonable for Wikipedia to prefer rational formats, whether "reliable sources" use them or not (bear in mind that Wikipedia does not defer to sources for unit choice). Certainly, computer-literate people (the demographic to which computer-related articles are most relevant) should be familiar with the IEC prefixes. Archon 2488 (talk) 18:58, 1 March 2014 (UTC)[reply]

Certainly seems that in situations where the precise quantity of data is considered to be significant, it would be better to use unambiguous units. If it's just a ballpark figure, then the more familiar units will do. W. P. Uzer (talk) 21:14, 1 March 2014 (UTC)[reply]
The computer industry has not adopted the IEC prefixes. I just looked at Mainframes on the IBM site. This is from the zEnterprise EC12 (zEC12) Data sheet.
"All five models of the zEC12 are machine type 2827. The server supports up to a total of 3 terabytes (TB) of real memory. Beyond the customer-purchased memory, the zEC12 has doubled the amount of memory—32 gigabytes (GB) for the Hardware System Area (HSA) which holds the I/O configuration data for the server."
It doesn't matter if some professor from Sweden uses gibibyte, the computer industry doesn't. The vast majority of readers have never seen this notation. Wikipedia is not a crystal ball; it used the terminology found in the real world today. -- SWTPC6800 (talk) 01:58, 2 March 2014 (UTC)[reply]
Not universally adopted, perhaps, but nonetheless it is used — perhaps more by software engineers than by the electrical engineers who design the hardware. Marketing would generally prefer the decimal prefixes because they make storage devices sound bigger. My operating system tells me that my 4 TB external HDD has a capacity of "3.6 TiB", for example.
Suggested compromise: use the decimal notation in contexts where precision is not so important, but allow the binary prefixes in more technical computing-related articles where they might be useful for disambiguation. It might be useful to recommend linking to the article on IEC prefixes with the first use of a binary unit (this is general practice for generally-unfamiliar units used in certain specialist contexts such as megaparsecs, femtobarns, GeV or AU). Another option is to expand the convert template to allow conversion between decimal and binary notation, and simply show both. Perhaps this would ultimately be most useful. Archon 2488 (talk) 02:30, 2 March 2014 (UTC)[reply]
And my OS tells me my capacity in GB which shows that some OS versions use what we tend to use. So, in the end, which if any can be said to be right? Vegaswikian (talk) 03:43, 2 March 2014 (UTC)[reply]
The Software industry doesn't use the IEC binary prefixes either. The Adobe Photoshop Lightroom Tech Spec for Mac and PC states:
2GB of RAM (4GB recommended)
2GB of available hard-disk space
The IEC binary prefixes were proposed before Windows 95 was released; it is a dead letter technical specification. -- SWTPC6800 (talk) 05:23, 2 March 2014 (UTC)[reply]
Evidence cited above seems to contradict you - exhibiting one case in which something is not used does not constitute an argument that it is not used at all. W. P. Uzer (talk) 10:18, 2 March 2014 (UTC)[reply]
Not being universally used isn't equivalent to not being used. In this case (with RAM) I think what's happening is that the binary units are being used, but with decimal prefixes (this is exactly the kind of ambiguity we are talking about). So 2 GB of RAM means 2*(1024^3) B of RAM, not 2*(10^9) B. All we are suggesting is that it is generally helpful to show the binary and decimal quantities as different things, because they are. Like I say, the convert template already exists, and could be adapted to this purpose (bearing in mind that the conversion is somewhat non-trivial). Archon 2488 (talk) 13:05, 2 March 2014 (UTC)[reply]
Differences in the bytes can be can be shown without using IEC prefixes. Use the number written out long-hand or use power notation for example and are perfectly acceptable. Using IEC prefixes pushes a point of view that is contrary to commonly accepted and used terminology in the field. Fnagaton 13:35, 6 March 2014 (UTC)[reply]

Clarification of wording in the first paragraph.

At the moment, part of the introductory paragraph reads as follows:

Try to write so the text cannot be misunderstood, and take account of what is likely to be familiar to readers—the less they have to look up definitions, the easier it is to be understood.

The last clause appears to have it the wrong way around. The text needs to be clear so that the reader can understand it. The reader does not have to be understood. I also suggest a few other changes so that the text cannot be misunderstood.

Try to write so the text cannot be misunderstood, and take account of what is likely to be familiar to readers. The less that readers have to look up definitions, the easier the text will be to understand.

I believe that this is easier to understand and less likely to be misunderstood. Any comments, suggestions or improvements? Michael Glass (talk) 12:24, 28 February 2014 (UTC)[reply]

I agree that this is less ambiguous and grammatically better. No change in substance so it should be uncontroversial. Archon 2488 (talk) 19:11, 1 March 2014 (UTC)[reply]
Yeah it's fine. Both versions are grammatically correct ("the easier it is to be understood" clearly implies "the easier it is for you to be understood by them" and there's no implication of the reverse). But it's no worse and maybe a bit better so go for it, and thanks for asking first. Herostratus (talk) 19:18, 1 March 2014 (UTC)[reply]
Thanks for the feedback. I've made the change as proposed.Michael Glass (talk) 22:44, 1 March 2014 (UTC)[reply]

UT vs GMT for pre-1961 occurences

An editor changed this:

the term "UTC" is not appropriate for dates before this system was adopted in 1961; Greenwich Mean Time (GMT) was used before this since the 1800s

to

the term "UTC" is not appropriate for dates before this system was adopted in 1961; Universal Time (UT) is the appropriate term for the mean time at the prime meridian (Greenwich) when it is unnecessary to specify the precise definition of the time scale

which I gather means we would formerly have said "He died at precisely 2:23 GMT on January 17 1910" and now we would say "He died at precisely 2:23 UT on January 17 1910". The reason for the change given was "Avoid the highly ambiguous term Greenwich Mean Time." I'm not sure it's that simple but maybe it is, but rather than just letting it pass unremarked I thought I'd just highlight the change. Herostratus (talk) 18:57, 1 March 2014 (UTC)[reply]

Note that the previous stable version stated:

If [sic] some cases the best solution may be to give the date and time in UTC (before approximately 1962 give UT).

No link or explanation of "UT" was given. A series of edits by Fnlayson (removing reference to "UT"), Jc3s5h (replacing "UTC" with "UT" but leaving orphaned references to "UTC"), myself (restoring "UTC" and including separate note to "GMT") and a partial reversion by Jc3s5h (here) led to the current version. This has also been the subject of discussion on my talk page (User talk:sroc#Your edit to "Manual of Style/Dates and Numbers"). sroc 💬 09:04, 2 March 2014 (UTC)[reply]
Timekeeping terminology has been a problem since the invention of clocks. Since around 1675 when the Royal Observatory, Greenwich was founded, the observers there kept time with days starting at noon, so Greenwich Mean Time would change from March 1 to March 2 at noon. This way the observers didn't have to change the date in the middle of their observations. Beginning in the late 1800s when the world agreed that 0° longitude would pass through the Royal Observatory, non-astronomers began to combine the term Greenwich Mean Time with a day that started at midnight. It wasn't until 1925 that the astronomers finally acquiesced to this usage. In the early 1900s the term "Universal Time" was suggested as a natural extension of the "universal day" defined at the International Meridian Conference in 1884, to replace the term Greenwich Mean Time, because some considered the noon vs. midnight issue to have made GMT hopelessly ambiguous (and it still is, for events before 1925). Universal Time is the time used by the scientific and technical community for the mean time at Greenwich, when subtle differences in definition are not important, or where the document being considered does not state the precise definition of the time scale used in the document.
UTC wasn't defined until about 1962. That was the point at which the US and UK synchronized their radio time broadcasts as closely as the technology allowed. Gradually all the major national time services in the world joined in. So the term is undefined before then. Jc3s5h (talk) 11:43, 2 March 2014 (UTC)[reply]
For the record, it looks like this edit on 28 July 2012 by Jc3s5h introduced the text: "before approximately 1962 indicate UT." Unhelpfully, no explanation for "UT" was given, nor were any pertinent examples given or links for further information. It does not appear that this edit was challenged, nor can I find any discussion on it on the talk archives. Aside from the fact that this addition has gone unquestioned, is there anything to indicate that the use of UT (rather than GMT or any other alternatives) has gained consensus?
In any case, if there is potential ambiguity with both GMT (which originally reckoned the beginning of the day at noon) and UT (which has several iterations), and if GMT was initially adopted in 1847 whereas the term Universal Time was only recommended in 1935, which is preferable for use on Wikipedia for events prior to the introduction of UTC? For that matter, what of events before either GMT or UT were adopted? Would it be better simply to use the terminology that would have been used at the time (e.g., The Supply anchored in Sydney Cove at 11:30 a.m. Sydney time on 26 January 1788 or The Armistice at Compiègne went into effect at 11 a.m. Paris time (GMT +1) on 11 November 1918)? sroc 💬 13:12, 2 March 2014 (UTC)[reply]
I certainly think the contemporary time used at the place discussed by the article should be the first choice. For events before the early 1800s this is likely to be apparent solar time, as would be kept by a sundial. If there are only two places discussed in an article, then the time in both places could be given when necessary. But if the article does not relate to any particular place, or if there are a multitude of places, UT could be the best choice.
I have found instances of UT (and UT1, a particular way to measure UT) being used for times before it was first recommended. For example, McCarthy and Seidelmann, TIME – From Earth Rotation to Atomic Physics (2009) on pages 54 and 55 give graphs involving UT1 beginning in 1650, and state on page 17 "the use of the term 'Greenwich Mean Time' or its abbreviation 'GMT' remains a source of confusion today..." and go on to summarize recommendations against the term "Greenwich Mean Time" and in favor of "Universal Time" since 1928.
In The Astronomical Almanac for the Year 2011 pages K8-9, on reduction of time scales, the term "UT" is applied to years beginning 1620 to and including 2014.
In summary, "Universal Time" is preferable to "Greenwich Mean Time" because there have never been contradictory definitions of "Universal Time". Yes, there are different versions of UT that may differ by a few seconds, but because the term is a member of a family of terms (UT0, UT1, UT2, UTC, and a few others) using UT is a statement by the author that the distinction between the different family members does not matter for the purpose at hand. Jc3s5h (talk) 16:30, 2 March 2014 (UTC)[reply]

A better link (UK units)

A footnote in the policy refers to the Times Style Guide, but the link only goes to the general page. This is a more specific link (which can only be accessed by subscription): [20] The part that is accessible to non subscribers reads in part:

One of the longest entries in the Times Style Guide is headed, simply, “metric”. The heading is more or less the only simple thing in the entry, as is hinted at in the opening advice: “The Times should keep abreast of the trend in the UK to move gradually towards all-metric use, but given the wide age range and geographical distribution of our readers, some continuing use of imperial measurements is necessary.”

I propose replacing the general link with this more specific link. Any comments, criticisms or concerns? Michael Glass (talk) 13:58, 5 March 2014 (UTC)[reply]

UK Metrication again? Does anyone have the appetite to discuss this again? Drop the WP:STICK please. Wee Curry Monster talk 14:33, 5 March 2014 (UTC)[reply]
A word of advice after McCartney: Listen to What the Monster Said. -- Ohc ¡digame! 15:11, 5 March 2014 (UTC)[reply]
Steady on guys, he only asked a reasonable question. For me, the present link just leads to the Times Online main page, which is of no relevance whatever, so certainly the other proposed link would be an improvement (though I would question whether we need such a link at all - isn't this page supposed to be Wikipedia's own style guide?) W. P. Uzer (talk) 15:54, 5 March 2014 (UTC)[reply]
I agree that this has become somewhat of a toxic issue. Best not to discuss again until we have something of substance to discuss. I don't think the Times reference is massively relevant, but it makes little difference either way. Archon 2488 (talk) 16:15, 5 March 2014 (UTC)[reply]
I agree with the others. I think W. P. Uzer would see why we say this if s/he had seen as much of this as the rest of us had.
I have changed the section heading to make it more descriptive. Kahastok talk 18:47, 5 March 2014 (UTC)[reply]
As much of what? Editors pointing out deficiencies in the guideline and ways they might be improved? Sounds to be something we ought to encourage rather. What I have seen far too much of on Wikipedia is people bullying to preserve a particular version of a page or section, and using irrelevant arguments or personal insults (coupled with reverts, if necessary) to suppress any criticism of that version, even when entirely well-founded. Seems, unfortunately, that the same thing is happening here. If you're tired of discussing a particular issue (though I can't believe this link has really been the subject of a great deal of discussion before this), then you have a simple solution - let others discuss it while you go and do something else that interests you. W. P. Uzer (talk) 08:49, 6 March 2014 (UTC)[reply]
I believe the last main discussion on the link to The Times Style Guide was at
To bring you up to speed, the issues I remember discussing (there or, possibly, elsewhere) were:
  1. whether we should refer editors to somebody else's style guide at all (as opposed to referencing article sources for verification of statements)
  2. whether we should retain a dead link that was automatically redirected to today's news at http://www.thetimes.co.uk/tto/news/ (which currently features the situation in Ukraine)
  3. whether we should refer editors to an online style guide that is no longer made freely available online, having been first placed behind a paywall and then, apparently removed (I do not know the current status of the online version of the style guide.)
  4. whether it would be appropriate to point readers to an unauthorized archived version of copyright material since placed behind a paywall
  5. whether the text of this section of the archived page was the same as the printed version (ISBN: 0007145055; it is).
  6. whether the text of the style guide was actually available behind the paywall at the address given (apparently, it wasn't).
If anyone has more up-to-date information, please provide it. The current discussion, as I understand it, seems to be about whether to replace the deadlink with a link not to any version of the style guide but to Rose Wild's comment on the style guide – most of that comment being behind a paywall – in the Feedback section. It doesn't look particularly useful to me, though it is, of course, much better than a link to the front page, which currently has absolutely nothing about imperial units (unless you are thinking of Russian military units in Ukraine!). --Boson (talk) 16:45, 6 March 2014 (UTC)[reply]
The proposal was to replace a poor link with a better link. The offensive comments above reflect badly on those who made them. At least W. P. Uzer actually read and understood what I proposed. However, as he questioned the relevance of having the link at all there is no point in pursuing the matter any further. Michael Glass (talk) 23:07, 5 March 2014 (UTC)[reply]
  • There's no practical difference between "useless" and "next to useless". ;-) -- Ohc ¡digame! 16:13, 6 March 2014 (UTC)[reply]

Would anyone oppose removing the link? --Joshua Issac (talk) 14:24, 6 March 2014 (UTC)[reply]

Yes, a style guide to follow is necessary to stop the continuous gaming of the system by those whose editing follows an agenda to promote one system of units over another. I would strongly oppose removal of a guideline as it will promote edit warring among the idiots arguing the superiority of one systen over another, while the rest of us would just like to edit in peace. If you had seen the sheer stupidity of the arguments between the different camps you wouldn't even think of suggesting it. Wee Curry Monster talk 14:36, 6 March 2014 (UTC)[reply]
  • I don't see how that link to the Times solves the problem you evoked. The links (old and new) are pretty pointless and should be removed. Everything of use is behind a paywall, so it can still be gamed unless you want us all to subscribe to a copy to be able to say for sure something is definitive per the guide. The alternative is to read The Times online or keep a recent paper version handy to reverse engineer their usage of their different measures. The only ironclad way is to stipulate either Imperial only or metric only, but not many will agree to that. -- Ohc ¡digame! 16:02, 6 March 2014 (UTC)[reply]
  • But that's a bit sad, like refusing to let go a dearly departed loved one... It will have undoubtedly changed since that version of the style guide was published, and it will change again for sure three years from now. And as we're not slaves to external style guides, let's take it off the pedestal. -- Ohc ¡digame! 09:22, 7 March 2014 (UTC)[reply]
  • I would strongly support removing the link completely. For one thing, The Times Style Guide, contradicts our own recommendations and thus contributes to the confusion and ill-feeling. The reference does nothing to stop any alleged "continuous gaming of the system". Can someone actually please confirm whether there any style guidelines somewhere behind that paywall? They were put behind a paywall, but my understanding was that they had since been removed altogether. Even if they have been put back again, it would be pretty pointless pointing editors to an address and telling them to follow the advice given there when most people do not have access – even if it did not contradict our own guidelines. --Boson (talk) 16:55, 6 March 2014 (UTC)[reply]
Wikipedians like sources. Making note of the fact that we are basing our guidance on the style guide of the Times (loosely - with common sense and Wikipedia norms applied), a source that is trying to do pretty much exactly the same thing as we are doing, is fundamentally useful both to the user of the guide and to us as editors. In both cases it demonstrates that the compromise that we have is not some made-up nonsense but an accurate reflection of usage as it stands, based on an existing source that does the same thing.
The last time we did the whole UK units thing wasn't Boson's link. It was this, two weeks ago. With the same OP. Do we really have to do it over and over at this frequency? I don't see we should. But it is fact that we have people continually bringing this up to push a POV on this point, and when they do it is very useful to have an outside point of reference that we can point at and say, this is what someone else has done when doing exactly what we're trying to do, this is what we've agreed to base this advice on, this is an accurate approximation of British usage. I would strongly oppose removing it on that basis. Kahastok talk 19:06, 6 March 2014 (UTC)[reply]
I think you are lumping too many things together, which is a familiar problem with previous discussions on the subject of imperial units.
We need to stick to one thing at a time, and this issue (removal of the Times link, in case anyone's forgotten) is very simple. As I noted, I was replying to "I can't believe this link has really been the subject of a great deal of discussion before this", and I believe my link does refer to the last "great deal of discussion" on the (dead) link to the Times style guide.
I do not agree that The Times is " doing exactly what we're trying to do", unless you define that in such broad terms as to be practically useless. The Times is a quintessentially British newspaper writing for a largely British readership. It is therefore quite appropriate for them to recommend using miles for all distances globally. We do not do this, so recommending following the Times style merely adds to the confusion. You write "loosely - with common sense and Wikipedia norms applied" but, to make any sense, that must actually be taken to mean "so loosely as to interpret it as stating something completely different".
We do - as you say – like sources, but I think you may be conflating citations (which are used merely to verify statements or quotations) and links to rules that editors need to read and observe (or, in this case: read and observe/ignore unspecified parts of). --Boson (talk) 23:34, 6 March 2014 (UTC)[reply]
The Times also uses mdy dates. -- Ohc ¡digame! 09:43, 7 March 2014 (UTC)[reply]
The Times certainly trying to approximate modern British usage. And I think it is pretty obvious how the MOS reflects it. You point out that it recommends miles for distances globally. Do you really think that people are going to say, ah, the guide suggests we refer to the Times for UK-related articles, and the Times says use miles globally, so we'll go away and convert random non-UK-related articles.
We all know that within weeks of any removal of the Times, the usual suspects are going to show up and announce that we made the whole thing up and we should adopt source-based units or "can is not must" or some other proxy for the usual POV rubbish. Yes, there's a difference between an article and an MOS, but the reasons why we have sourcing in articles apply here.
There seems to be a bizarre assumption here that the Times must either be followed religiously or ignored entirely. The notion that the advice may be based on it, but with acceptance for the differences between the Times and Wikipedia, seems not to have been understood. That is what happened. We looked at it, adapted it to our needs, and adopted the adaptation. It's useful to have the source from which it was based in order to show where it came from. Kahastok talk 18:06, 7 March 2014 (UTC)[reply]

What does The Times recommend?

I think the above discussion may suffer from people not being aware of what The Times Style and Usage Guide (or the online copy) actually says. I think fair use would permit large chunks of the content concerning metric/imperial measurements to be quoted verbatim on the talk page for the purpose of critical analysis, but we are not permitted to lift large amounts for our own manual of style, which provides advice rather than critical analysis. So perhaps we can first state what the style guide says in our own words. It might make sense to actually include some of the result in the MoS – after amending the parts that contradict what we currently recommend.

As I understand it The Times Style and Usage Guide contains the recommendations or prescriptions presented below (in the section " Contents of The Times Style and Usage Guide). Please comment here, if you think I have got it wrong. --Boson (talk) 23:49, 6 March 2014 (UTC)[reply]

Contents of The Times Style and Usage Guide

General use of metric measurements
  1. Where possible, avoid mixing metric and imperial in the same article. This is a goal, not a total prohibition.
  2. Generally use metric measurements and give imperial measurements in parentheses.
  3. Use of metric measures applies explicitly to temperatures.
  4. Use of metric measures applies explicitly to areas, including hectares and square metres. However square kilometres should be avoided.
Exceptions to the general use of metric measurements
  1. Distances for all locations worldwide should be given in miles. For all countries other than the UK and the US a conversion into kilometres should be provided on the first use (but not for the UK and the US).
  2. In the UK and the US all speeds should be given in mph (no conversion). For all other countries, speeds should be given in mph first, but also converted into km/h on first use.
  3. Personal height and weight should be given in feet and inches and in stones and pounds respectively (with conversion into metres and kilograms respectively).
  4. Aircraft altitudes should be given in feet; conversion to metric (in parentheses) is permitted but not necessary.
  5. Mountain heights should be given first in metric units (feet in parentheses).
    Does anyone else see a problem here, in regard the aircraft-mountain interface? — Arthur Rubin (talk) 17:34, 7 March 2014 (UTC)[reply]
  6. Volumes should be given in metric units with the exception of pints of beer and cider.
  7. Milk is sold in pint bottles and litre containers (but no explicit recommendation).
  8. Use metric (i.e. litres) for petrol and fuel. Conversion is not required.
  9. Fuel consumption should be given in miles per gallon.
For the following topics the "overwhelming preference" is for metric
  • sport
  • foreign
  • engineering
  • scientific
  • foodstuffs and liquids in cookery

- - - end of contents - - -


Comment on the guidelines as presented above

First I would like to thank Boson for putting up this summary of the Times Style Guide. Just having this summary available is very helpful, for it shows the striking similarities and the striking differences between the Times and MOSNUM's recommendations. Here are a few that I believe we could adopt for UK articles:

  • A statement that the UK is slowly transitioning to the metric system may be of value.
  • Either stating that milk is sold in pint bottles and litre containers, or, better, removing the item entirely.
  • As well as stating that engineering and scientific articles are metric, this should be extended to sports, where appropriate.

On the other hand, there are some recommendations that we would not take up, like having speeds only in MPH, avoiding the use of square kilometres or permitting aircraft altitudes just in feet. Michael Glass (talk) 03:12, 7 March 2014 (UTC)[reply]

Proposal to remove the link to The Times Style Guide
  • Glad to see this issue is now being discussed on its merits, but can we do one simple thing right away - everyone seems to agree that the present "link" serves no purpose as it doesn't take you anywhere near any Times Style Guide, so is just going to annoy people who (like me) click on it and wonder WTF. If there is no immediate consensus on whether and what link should replace it, would there be any objection to just removing the present link (without altering the overlying text, although I don't particularly see why the Times guide should be singled out - are other such guides not also available?) W. P. Uzer (talk) 07:35, 7 March 2014 (UTC)[reply]
    • Support removal. My rationale above. -- Ohc ¡digame! 09:31, 7 March 2014 (UTC)[reply]
    • Support removal of the dead link as proposed by W. P. Uzer. Michael Glass (talk) 10:06, 7 March 2014 (UTC)[reply]
    • Support removal of the link as proposed by W. P. Uzer (per my detailed explanation above and without prejudice to later removal of the explicit verbal reference to The Times Style Guide). --Boson (talk) 10:49, 7 March 2014 (UTC)[reply]
      • PS: Oppose temporary link to the archived copy because it is unnecessary and would possibly violate copyright policy. --Boson (talk) 13:26, 7 March 2014 (UTC)[reply]
    • Support replacement with the archived version in the Wayback Machine that Wee Curry Monster has mentioned. As for directing people to the Times style guide, since certain Times style guidelines contradict Wikipedia's own ones, as Boston and Michael Glass have demonstrated above, we should explicitly say which parts of the Times guide should be used when editing Wikipedia; or better, we should have our own guideline that is sufficient for all Wikipedia articles, and use the Times, Oxford and/or other relevant guidelines as sources. But this is a separate issue from removing or replacing a dead link. --Joshua Issac (talk) 11:53, 7 March 2014 (UTC)[reply]
    • Oppose User:Michael Glass has a track record of editing against consensus to favour the metric system on UK related topics in direct contravention of WP:MOSNUM. The subject of UK units is constantly being raised by that editor, in almost all cases arguing over trivia in an effort to portray the UK as more metric than it is. If that editor wants UK articles to go down the wholly metric route, raise an RFC and convince the community on the basis of the strength of their argument. But the method adopted of a war of attrition raising the topic ad nauseum to try and chip away at the policy guidelines is simply irritating and is entrenching attitudes against them. We need a guideline because editors like this will game the system, they have a track record of gaming the system and using wikilawyering to edit against consensus. I oppose any weakening of policy recommendations because experience over a number of years demonstrates they simply cannot be trusted to edit in line with policy and consensus and the slightest chink in policy will be exploited to edit in a manner that is disruptive and leading to numerous edit wars. Wee Curry Monster talk 12:09, 7 March 2014 (UTC)[reply]
WCM has apparently forgotten his own chequered history on Wikipedia. In any case, his ad hominem attack is irrelevant to the question at issue, which is whether or not to remove a dead link. Michael Glass (talk) 09:50, 8 March 2014 (UTC)[reply]
      • @Wee Curry Monster:But none of the above argumentation indicates, suggests or explains how or why the link is of any practical use except as some symbolic line in the sand against the evil and devious Mr. Glass. The biggest problems with it have been stated above; plus the link is nearly ten years old and is surely obsolete. It's you lot that are hanging on to nostalgia. Please deal with the substance and come to 2014. -- Ohc ¡digame! 12:53, 7 March 2014 (UTC)[reply]
        • Historically, the Times style guide was chosen as it best represented UK usage and still does. Its a style guide adopted as best approximating appropriate use in the UK. Wee Curry Monster talk 13:08, 7 March 2014 (UTC)[reply]
          • It has nothing to do with nostalgia and it is not obsolete, the UK has not fundamentally changed in the last ten years in this area. As I have repeatedly pointed out, as a professional engineer I use the metric system exclusively and as an engineer I would prefer to see its use. The reason I don't endorse wholesale metrication of UK metric articles on wikipedia is simply because we should reflect unit choices that makes articles easier for readers to understand, which in certain limited circumstances means we give preference to the unit most commonly used. If you want it to be different, convince other editors to change policy but being patronising about it won't help your case. Wee Curry Monster talk 15:30, 7 March 2014 (UTC)[reply]
            • My comment was addressing the use of the link as a function of time. Sure some things change and others don't – I know that beer is still served in pints in pubs, but not any more for the tinned variety; a bit like milk. That things haven't fundamentally changed is your assertion. If you are resisting metrication, it's in your interest to hang on to that Times link for as long as you can. In ten years, we will still be stuck in a time warp if no free style guide on UK measurements is available. But unless we do a comprehensive study in a proper and transparent manner from time to time, there is no way of reliably establishing actual practice at regular intervals. So talking about nostalgia isn't being patronising but about being practical because reflecting "actual practice" is the name of the game as I understand how you peeps want to play it. Using the link is a humongous red herring. -- Ohc ¡digame! 17:30, 7 March 2014 (UTC)[reply]
            • As far as I can recall, the Times was sort of referred to because it was the only UK one we could lay our hands on for free, and was acceptable because all we were looking for was an approximation of actual practice at the time. -- Ohc ¡digame! 17:43, 7 March 2014 (UTC)[reply]
              • @Wee Curry Monster:How can it be not easy for readers to understand when our rules requires a conversion into the other (in parentheses) when either a metric or an imperial measure is used? The only danger is if our reader comes from a civilisation that cannot relate to either. I wonder if they have the same bickering over the "imperial tael" and the "metric tael" (ditto the catty) over at zh.wp? -- Ohc ¡digame! 13:45, 8 March 2014 (UTC)[reply]
  • Support removal of the Time style guide. The use of an archived link is tenuous at best. As I've said previously, I do not think that the Times style guide should be referenced to the exclusion of other British style guides. I figure that, if we are to link them, we should link a variety, or cite printed versions. I do not see the removal of this link as opening up a wave of metrication. Our style guide will still stand. In the event that more arguments are had about changing various items in our style guide, other style guides can be referenced in said debate. In other words, the text of the style guide should still ask the reader to "consult major British style guides" for information on appropriate usage. However, it should not send them to a dead/archived link to one style guide. RGloucester 15:52, 7 March 2014 (UTC)[reply]
  • Strong oppose removal of the Times. There is clear benefit to referencing an outside style guide that is trying to approximate British usage, exactly as we are trying to do.
Let us not pretend we do not know from many years of experience what will happen if we remove it. We will be told, within weeks, that we made the whole thing up. We will be told, within weeks, that the current guidance is unsourced and that the fact that that editor can find one website that gives distances in kilometres means that the British all use kilometres really and just put miles on the road signs to confuse foreigners. It's happened before. Many times.
The use of sources here is a good idea for exactly the same reasons as it is a good idea on articles. We don't use sources on articles just because WP:V tells us to. We use them so that our facts can be checked as needed by readers. Exactly the same benefit is available here by citing the source that our advice is based on. Kahastok talk 18:06, 7 March 2014 (UTC)[reply]
It should not be this difficult to remove a dead link that sends readers on a wild-goose chase looking for an eleven-year old style guide that we don't even agree with. We are telling readers to go and look at a style guide while actually sending them to the front page of The Times. We are not just citing it, and if we were citing it, as in an article, it would probably deserve a {{Failed verification}} tag. —Boson (talk) 18:46, 7 March 2014 (UTC)[reply]
In fact, the Guardian's style guide is more in line with ours than that of the Times. RGloucester 19:00, 7 March 2014 (UTC)[reply]
No, we don't. The Guardian advises that we measure all liquids in pints. Quite rightly, we don't come anywhere near that.
There seems to be some pushing on this spurious argument that it must be everything or nothing. There is room in the middle ground between following the Times religiously and ignoring it entirely. That's what we do here. The advice is our own, based on the Times, but adapted to our own needs. And it is sensible that we actually demonstrate that it has some basis in usage. Kahastok talk 19:30, 7 March 2014 (UTC)[reply]
The Guardian DOES NOT advise that all liquids be measured in pints. It does not, as you said in your edit summary, advise that petrol be measured in pints. It says that miles and pints are acceptable units to use in certain circumstances. Regardless, the fundamental problem with the Times link is that it isn't easily accessible or current. If someone can provide a present printed copy to verify, then scan it up and let's see it. RGloucester 19:51, 7 March 2014 (UTC)[reply]
It says, "We use the metric system for weights and measures; exceptions are the mile and the pint." That doesn't say that the mile and pint are merely "acceptable units to use in certain circumstances". There is no get-out or middle ground. It says - without any form of qualification whatsoever - that miles and pints are exceptions to metrication. You have to do some pretty serious inference to suggest that they advise anything other than the pint for petrol.
The fact remains that it is useful to cite the source for the advice, for the reasons I have given. And I remain opposed to the attempt to remove it. Kahastok talk 20:21, 7 March 2014 (UTC)[reply]
"Serious inference" or common sense? The Guardian's style guide assumes that the reader is capable of common sense, as should we here. If one reads the whole damn thing, it is quite clear that it is not asking one to use pints for petrol. Petrol isn't sold by the pint. It isn't quoted by the pint. Search for Guardian articles on petrol prices, and one will quickly see that they use litres for reference to petrol. What a surprise! RGloucester 23:01, 7 March 2014 (UTC)[reply]
Now you're inferring a policy from individual instances of usage. People don't always follow their own style guides. We have the official Guardian policy, and it calls for the use of pints as an exception to metrication, without any form of qualification or conditionality whatsoever in any part of the guide. If a Guardian article uses litres for petrol, they're breaking their own style guide.
And there is a wider point here. The argument above, that you seemed to endorse, is that if we base our rules the Times, we must use all of the rules in the Times, applied absolutely religiously, regardless of common sense or Wikipedia norms. And yet the same does not seem to apply to the Guardian! The Guardian's guide we are allowed to adapt and interpret, but that is absolutely forbidden for the Times. I see no reason why common sense should be allowed to apply to one but not the other. Kahastok talk 23:24, 7 March 2014 (UTC)[reply]
I do not agree with the argument that if the Times is used, it must be solely used as the basis of our rules. I merely do not like the Times as a source, as no current link to the present guide is available. The Guardian's guide is accessible, and is mostly in line with our guidelines.
I'm sure when reading that style guide, you do not feel that it meant that "pints" were the only liquid unit of measurement that is acceptable? It merely meant that the only acceptable non-SI units that could be used were "miles and pints". But never mind.
If we must have basis for the style guide, as you say, in "sources", then the sources need be easily accessible and current. I'm not so sure we even need "sources", as this is our style guide, and we get to make it however we choose. We could say: "All measurements of length must take place using the barleycorn". Nevertheless, if we MUST have sources, then our sources mustn't be as mucky as the Times. RGloucester 00:48, 8 March 2014 (UTC)[reply]
  • Exactly. Style guides are not a statement of fact but of editorial preference, and we shouldn't confuse the two. We don't need to rely on a duff Times link, and it's clear that we don't even base ourselves on any version of "Ye Times Stile Gyde", let alone one that's a decade old. Talking about "official Guardian policy [calling] for the use of pints for all liquids without any form of qualification" is picking at hairs because there's a lot more in the Times guide that we don't follow, and I that RG brought up The Guardian as a closer approximation to our practice is perfectly reasonable suggestion. Although it's not the "rigidity" that some may prefer. Some claim that we are basing usage on The Times, so we're still capable of picking and choosing. Why not pick and choose from a buffet that's closer to our tastes?

    Our MOS has never been prescriptive, as such an approach is usually frowned upon as instruction creep, but seems to exist here as an anomaly. Kahastok and WCM seem to want the MOS to be ultra-rigid, to protect Wikipedia against one evil and devious editor. But this is the tail wagging the dog. The way to deal with disruptive editors is not to pile on a mountain of rules, but to have the disrupter(s) banned or blocked for their disruption. -- Ohc ¡digame! 02:39, 8 March 2014 (UTC)[reply]

Ohconfucius, Please don't take Kahastok and WCM's threats at face value. They've been making the same threat for at least a year. The threats, the bullying and the rest are just a ploy to derail any discussion about changing MOSNUM in a direction they don't like. It's disruptive but it has helped derail any change in MOSNUM for years. It's last triumph was to derail my proposal to provide a better link to their beloved Times Style Guide' on the ground that because I proposed it it must be wrong. Michael Glass (talk) 10:34, 8 March 2014 (UTC)[reply]
You mean you're not evil? ;-) We have not always seen eye to eye, but I know what a useless link is. I think most people will also see that's the case, even if some editors refuse to admit it. Such intransigence and rhetoric in the face of the obvious is regrettable, and not removing a bad link (or rather, deliberately leaving it there) reflects poorly on us collectively. -- Ohc ¡digame! 11:10, 8 March 2014 (UTC)[reply]
Actually, I've never argued that these rules should be "ultra-rigid", nor applied them ultra-rigidly. That's a bit of a caricature that originated from an editor who insists that the rules can either be a strait-jacket or a free-for-all, and that there can be nothing in between.
My view has always been that variation is good and proper - if there is a good reason for it. I included such flexibility explicitly in this rule in my suggestion at User:Kahastok/Units2. But what is so frequently proposed - the "can is not must" proposals - is wordings that we know will be interpreted as allowing variation even if the only reason is a single editor's personal preference.
We don't allow people to switch from AD to CE purely for reasons of personal preference. We don't allow people to switch from MDY to DMY without good reason. Personal preference should not be an acceptable reason to vary from this rule either.
The choice of units we use is based on the Times, not the Guardian. Of course we include conversions, and of course we don't use it as a reason to use miles globally. It would be very odd if we allowed our measure of British usage to dictate usage everywhere or to override other rules in this section. That does not change the fact that the choice is based on the Times. If the Guardian is similar, again, that's all well and good - demonstrates we're on the right track. But does not change the fact that the choice is based on the Times. Kahastok talk 10:10, 8 March 2014 (UTC)[reply]
Nobody's disputing that The Times is the one that we mention in the guideline. The fact that The Guardian is closer to our usage is related but is a separate issue, and I'm sorry I digressed. As Uzer points out, the proposal is only about removing the duff link. Full Stop. We all know The Times exists and that it has a website. We also all know that Rupert has put everything behind a paywall; the value of a link to the home page of the Times is zero. -- Ohc ¡digame! 10:21, 8 March 2014 (UTC)[reply]

I think some perspective is needed here; this is an obscure footnote on an obscure guideline we're talking about. My original proposal was just to remove a link which is dead, so that people don't waste time clicking it and wondering what's going on. Not to change the fact that we mention the Times (though someone else might want to propose that). Am I right in saying that no argument has been given for retaining the dead link, nor has anyone disputed the fact that it is dead? W. P. Uzer (talk) 09:07, 8 March 2014 (UTC)[reply]

Comment: I am amazed that this is even being discussed. A dead link has no place on Wikipedia. If I knew which link it was about I would just remove it to end this absurd discussion. Dondervogel 2 (talk) 10:19, 8 March 2014 (UTC)[reply]

We are talking about the link to http://www.timesonline.co.uk/tol/tools_and_services/specials/style_guide/article986731.ece in Footnote 9 in section Wikipedia:Manual of Style/Dates and numbers#Other articles. Since the link is dead, it automatically redirects to the front page of today's Times, which – surprisingly – has nothing about metric units. --Boson (talk) 12:55, 8 March 2014 (UTC)[reply]

Erratum in units table under "calorie"

There seems to be a small error in the table of units, under the entry for the calorie: "To avoid confusion SI units (gram calorie, kilogram calorie) should be used instead." The SI unit of energy is the joule, so the current phrasing is incorrect and confusing. I propose changing this to "To avoid confusion the gram calorie or kilogram calorie should be used instead, with an equivalent in SI units (J or kJ)." Archon 2488 (talk) 16:27, 5 March 2014 (UTC)[reply]

The row reads "not calorie (deprecated)" so it seems that it's trying to suggest avoiding either calorie i.e. "To avoid confusion SI units (joule, kilojoule) should be used instead." after all it is talking about science/technology articles. Of course, if the sources use calories, it would probably be best to follow suit (with a conversion to SI ... but that goes without saying, right). Jimp 08:49, 6 March 2014 (UTC)[reply]
The table now has an inherent contradiction, since it does not actually provide for the use of joule as a unit; it provides for calorie or Calorie, but then states in the comments to use joules instead.
Group Name Symbol Comment
Energy
gram calorie
small calorie
cal SI prefixes may be used with cal but not with Cal (kilocal but not kiloCal). The rules for common nouns apply to the calorie.[clarification needed] Write 100 calories, not 100 Calories.[clarification needed]
kilogram calorie
large calorie
Cal
not calorie (deprecated) In science and technology calorie usually refers to the gram calorie; in dietetics it may refer to the kilogram calorie. To avoid confusion SI units (joule, kilojoule) should be used instead.
Shouldn't joule be added as a separate row in the table? Also, I'm not sure we should necessarily advocate using joules over gram calories or kilogram calories to avoid the ambiguity of what "calorie" means. How about this?
Group Name Symbol Comment
Energy
joule J
gram calorie
small calorie
cal SI prefixes may be used with cal but not with Cal (kilocal, but not kiloCal). The rules for common nouns apply to the calorie (100 calories), but not to Calorie (100 Calorie, not 100 Calories).
kilogram calorie
large calorie
Cal
not calorie (deprecated) Ambiguous whether this may refer to the gram calorie (usually in science and technology) or kilogram calorie (usually in dietetics).
sroc 💬 09:31, 6 March 2014 (UTC)[reply]
The table is under the title "Specific units" by which is meant something like "units which have specific points to be made about". The joule is a plain, simple and well-behaved unit unlike the calorie with its myriad quirks and difficulties, unlike the metre with it's two different spellings, unlike the cubic centimetre with its non-standard alternative abbreviation. The table doesn't set out to list all units we're allowed to use. Thus the joule isn't there.
It seems that either you've, made some kind of typo, sroc, or whoever placed the "clarification needed" tag there was right. The line "The rules for common nouns apply to the calorie" was intended to mean that they apply to both the large and the small calorie. The link brings you to Wikipedia:Manual of Style/Dates and numbers#Unit names which has this to say.

Unit names are common nouns. Write them in lower case except where: common nouns take a capital; otherwise specified in the SI brochure; otherwise specified in this manual of style.

The recommendation is not to use a capital C for the large calorie (except where normally required, e.g. at the start of a sentence). I'd been ignoring this "clarification needed" tag because it seemed obvious enough to me that the word "calorie" (for a kilogram calorie) was a unit name and thus should be treated as a common noun as detailed in the link.
I agree that we shouldn't be advocating using joules over gram calories or kilogram calories to avoid the ambiguity. Are we though? It isn't even clear. First we give the rules of how to use them then we say not to. Banning the calorie would be akin to banning the foot or pound. However, it may be worth noting that conversions to SI are helpful here.
Group Name Symbol Comment
Energy
gram calorie
small calorie
cal SI prefixes may be used with the gram calorie but not with the kilogram calorie.
  • The term kilocalorie always refers to 1,000 gram calories.
  • kilocal is used but kiloCal is not.

The rules for common nouns apply to the both the gram and kilogram calorie. Use lower case for either except where common nouns take a capital.

  • Write 100 calories not 100 Calories.

Whether to use gram or kilogram calories is context- dependent.

  • In science and technology calorie usually refers to the gram calorie
  • In dietetics calorie may refer to the kilogram calorie.

A conversion to SI units (joule, kilojoule, etc.) is useful for avoiding ambiguity.

kilogram calorie
large calorie
Cal
Jimp 10:30, 6 March 2014 (UTC)[reply]
I see no benefit in including the terms "small calorie" and "large calorie". These are not needed and can be deprecated. Use of "gram calorie" and "kilogram calorie" should be with a link to a definition. Dondervogel 2 (talk) 11:35, 6 March 2014 (UTC)[reply]
I like the last proposed version of the table above. It's still useful to mention to terms "small calorie" and "large calorie" because they're occasionally encountered, and it makes sense to include them for the sake of completeness. An equivalent in J or kJ should always be provided to any number in (k)cal. Archon 2488 (talk) 11:54, 6 March 2014 (UTC)[reply]
@Jimp:
'The table is under the title "Specific units" by which is meant something like "units which have specific points to be made about".' Thanks for the clarification. This wasn't evident to me, since the table contains many other entries that have no special comments. Perhaps an introductory line above the table would help.
'The line "The rules for common nouns apply to the calorie" was intended to mean that they apply to both the large and the small calorie.' That's interesting because the last stable version of the table before EEng recently overhauled it said this in relation to kilogram calorie: "The regular rules for common nouns apply to the calorie. Write 100 calories not 100 Calories." No such comment was made in relation to gram calorie, so presumably it did not apply. This revision seems to materially change the status quo to say that this applies to both.
'I agree that we shouldn't be advocating using joules over gram calories or kilogram calories to avoid the ambiguity. Are we though?' The previous version that I referred to in my earlier comment said, in relation to calorie: "To avoid confusion SI units (joule, kilojoule) should be used instead." So yes, this explicitly said to use joules, not giving gram calories or kilogram calories as acceptable alternatives. The confusion is compounded by the fact that the table is not a complete list and thus does not list joule as a unit.
Additional comments regarding the revised table: please spell out "gram calorie and kilogram calorie", not "gram and kilogram calorie", to avoid confusion with "gram"; it would also be useful to clarify that "kilocal" is the abbreviation for "kilocalorie" (as distinct from "kilogram calorie"), assuming this is correct; it would also be useful to retain the explicit reference that "calorie" should not be used on its own; gram calorie and kilogram calorie should be wikilinked (to existing redirects to calorie, which details their use, not redlinks to unnecessary "definition of… articles"); the rowspan parameterss were messed up.
Group Name Symbol Comment
Energy gram calorie
small calorie
cal SI prefixes may be used with the gram calorie but not with the kilogram calorie:
  • The term kilocalorie (abbreviated kilocal) always refers to 1,000 gram calories.
  • Do not use kiloCal.

The rules for common nouns apply to the both the gram calorie and kilogram calorie. Use lower case for either except where common nouns take a capital:

  • Write 100 calories not 100 Calories.

Do not use calorie on its own, as this is ambiguous. Whether to use gram calorie or kilogram calorie is context-dependent:

  • In science and technology calorie usually refers to the gram calorie
  • In dietetics calorie may refer to the kilogram calorie.

A conversion to SI units (joule, kilojoule, etc.) is useful for avoiding ambiguity.

kilogram calorie
large calorie
Cal
sroc 💬 13:34, 6 March 2014 (UTC)[reply]
I've just noticed another contradiction. Calorie has been deprecated, but the table includes this example: "Write 100 calories not 100 Calories." Should this be: "Write 100 kilogram calories, not 100 kilogram Calories"? Or does the deprecation mean: "Specify gram calorie or kilogram calorie initially, then calorie alone can be used as shorthand for the same term provided the intended meaning is clear"? sroc 💬 13:43, 6 March 2014 (UTC)[reply]
I assume that, when the usage is obvious (e.g. in dietetics, the kilogram calorie is the normal unit) then "calorie" may be used for brevity. Still, an equivalent in kilojoules should always be provided, which is unambiguous. Archon 2488 (talk) 20:58, 6 March 2014 (UTC)[reply]
Does providing providing a conversion in joules really help to disambiguate between gram calorie and kilogram calorie? Doesn't this rely on the reader knowing what the conversion rates are and performing the calculation each time? Actually stating the full term (at least the first time) would obviously be a better way to clarify this. sroc 💬 22:08, 6 March 2014 (UTC)[reply]
The gram calorie would be converted to joules, and the kilogram calorie would be converted to kilojoules, so the order of magnitude would clarify things on its own. But I agree that for disambiguation, the unit name should be given in full the first time: articles with dietetic information should state "kilocalories" on the first use, and "kcal" subsequently. The kilogram calorie is never used with prefixes, so this is unambiguous (food labels, at least in Europe, commonly use "kcal" anyway). Archon 2488 (talk) 22:18, 6 March 2014 (UTC)[reply]
But "kcal" isn't mentioned in the table at all! Should the table give the symbol for kilogram calorie as "Cal or kcal"? sroc 💬 22:59, 6 March 2014 (UTC)[reply]
Is there a difference between kilocalorie (given in the table as kilocal) and kilogram calorie (stated in calorie as "equal to 1000 small calories or one kilocalorie" and given as kcal)? sroc 💬
The kcal and Cal are equivalent by definition, so the distinction is largely academic. In the former case, the "calorie" is defined with respect to one gram of water, then multiplied by 1000. In the latter case, the "calorie" is definied with respect to one kilogram of water. This isn't relevant to the normal use of the units, and "kcal" is unambiguous (it's also the unit that people normally mean when they say "calorie"). Archon 2488 (talk) 23:23, 6 March 2014 (UTC)[reply]
Thanks for clarifying. In other words, "kcal" = "kilocal" = "kilogram calorie". I'm working on simplifying and clarifying this section: see User:sroc/sandbox#Special units. How does this look? sroc 💬 23:29, 6 March 2014 (UTC)[reply]
  • A side comment: While I've spend a good deal of time here in recent months, in the past 6 weeks for so I just haven't been able to, and likely won't again for a while. I do want to say, though, that with the exception of a few limited points on which explicit, separate discussions were opened, it was only my intention to improve the presentation of the guidelines as they were, not to change them (though that wasn't always easy, since in many cases the guidelines seemed self-inconsistent). If something did change, it was inadvertent. Keep up the good work, everyone. EEng (talk) 15:55, 6 March 2014 (UTC)[reply]
I was not making a case for a "definition of ..." article. I just meant there is little point in linking to gram calorie unless that article contains a definition of "gram calorie". Dondervogel 2 (talk) 22:05, 6 March 2014 (UTC)[reply]
@Dondervogel 2:
Well, you did write 'Use of "gram calorie" and "kilogram calorie" should be with a link to a definition' with piped redlinks to definition of gram calorie and definition of kilogram calorie respectively. Redlinks encourage editors to create those missing pages.
Currently, gram calorie and kilogram calorie both redirect to calorie, which begins with this (footnotes omitted):
The name calorie is used for two units of energy.
  • The small calorie or gram calorie (symbol: cal) is the approximate amount of energy needed to raise the temperature of one gram of water by one degree Celsius.
  • The large calorie, kilogram calorie, dietary calorie, nutritionist's calorie, nutritional calorie, Calorie (capital C) or food calorie (symbol: Cal, equiv: kcal) is approximately the amount of energy needed to raise the temperature of one kilogram of water by one degree Celsius. The large calorie is thus equal to 1000 small calories or one kilocalorie (symbol: kcal).
The article also includes sections on "Precise definitions" and "Usage". This seems to pretty well cover it, but if you feel that information is deficient, you can go ahead and edit that article. sroc 💬 22:29, 6 March 2014 (UTC)[reply]
The section with the definitions in it (which is indeed entitled Precise definitions) mentions neither the gram calorie nor the kilogram calorie. So linking to that article in its present form for a definition is useless. I will take a look to see if it can be improved but will not spend time on it I do not have. Dondervogel 2 (talk) 17:44, 7 March 2014 (UTC)[reply]
Proposal made at calorie. Dondervogel 2 (talk) 17:50, 7 March 2014 (UTC)[reply]

Writing SI unit names

The current guidelines on pluralising unit names seem to be incomplete. I'd suggest incorporating the advice in this NIST guide, at least for metric units: thus units combined with values below 1 are considered grammatically singular (e.g. 0.25 metre, 10-3 watt). Phrasing such as "0.1 of a metre" should also be avoided.

In addition, it should be specified that numbers with unit symbols should not be hyphenated (e.g. "100-m bridge"), and periods with unit symbols ("100 m.") should be avoided — I cannot see this in the current guidance.

It might be worthwhile to emphasise that the prefixes are always attached to the unit name (never spaced or hyphenated as in "milli gram" or "kilo-pascal"), and are uncontracted except in the case of: kilohm, megohm and hectare. The plural of "henry" is written "henries" since it's considered a regular noun for English grammatical purposes. Archon 2488 (talk) 16:47, 5 March 2014 (UTC)[reply]

Or Henry's. --2 potatoe's (talk) 07:27, 6 March 2014 (UTC)[reply]
Sounds good to me. The plural of hertz (hertz) might also be worth a mention if not there already. Dondervogel 2 (talk) 18:19, 5 March 2014 (UTC)[reply]
I've added the invariant unit names to my proposal and put it in my sandbox with a couple of minor fixes. I didn't look closely enough: it already says not to use periods. Let me know what you think. Archon 2488 (talk) 21:37, 5 March 2014 (UTC)[reply]
I would oppose pluralising English words - be they units or otherwise - in a way that does not conform with English grammar. According to your proposal, it appears to me that we are to talk about zero cakes and 0.75 dollars, but zero kilogram and 0.75 kilometre. I do not believe that this would be grammatical. Kahastok talk 22:19, 5 March 2014 (UTC)[reply]
I agree in opposing this. Standard English usage would be 0.25 metres and 10-3 watts, regardless of what NIST advocates. Wikipedia follows actual use, not official standards. sroc 💬 23:26, 5 March 2014 (UTC)[reply]
This is quite a thorny question, I think. The rules of English grammar are very weird with fractions: when you use vulgar fractions you'd always use the singular: 3/4 dollar, not 3/4 dollars. Likewise, "a half litre", not "a half litres"; I suspect we instinctively don't like the sound of "0.5 litre" because the numeral next to "litre" is "5" which makes us think "plural", even if it's not really logical. Since decimal fractions are just a different way of representing the same numbers it's not obvious why they have to be treated differently, and style guides aren't consistent. The number zero is a separate case of its own: I think it should probably always take the plural (obviously 0 is neither singular nor plural, but grammar is a bit illogical), however the degree Celsius (or for what it's worth, the degree Fahrenheit) is the only unit you'd commonly use with a zero (because 0 °C is just an arbitrary temperature, not the true physical zero point of temperature). There's not too much sense in talking about "zero kilometres" because if something has no length (or mass, or whatever) then units aren't really relevant: 0 km = 0 Mpc = 0 Å. To add to the complication, it's formally permissible to write the SI unit names in the singular even when the value is greater than 1, so you'll commonly encounter strange-sounding things like "the magnetic field has a strength of 2 tesla". Absolute zero is commonly referred to as both "zero kelvin" and "zero kelvins" so it's a bit of a coin-flip really. Derived units without special names, such as kJ/(mol K), are supposed to be read as invariant singulars, but this rule is commonly ignored: most people don't say "100 kilometre per hour".
All that being said, the guidelines are just NIST's interpretation of how to say and write SI units in (American) English: they're not an intrinsic part of the SI. For the purposes of Wikipedia it might be best to pick a more simple and consistent set of rules: for all metric units, with values other than ±1, use the plural form; otherwise use the singular (so you would also write "negative/minus one degree Celsius" for example). Imperial/USC units written with vulgar fractions should use the singular: "5/16 inch", not "5/16 inches" (metric units are never written with vulgar fractions, so this rule doesn't apply to them). Opinions? Archon 2488 (talk) 23:36, 5 March 2014 (UTC)[reply]
I have modified the proposed changes in my sandbox in line with the suggestions above. I've also added a bullet point on how to write the names of units containing powers. Archon 2488 (talk) 00:26, 6 March 2014 (UTC)[reply]
I would say half a litre but .5 litres. Linguistically, it is easy to say that something is "half" or "quarter" of a whole ("a litre") because these are basic divisions, but it's not as easy to do this with decimals. If we said .5 litre, then would we also say .6 litre or .521 litre? We would not say five hundred and twenty-one thousandths of a litre in words, so as a corollary, the equivalent in numerals seems odd. sroc 💬 01:00, 6 March 2014 (UTC)[reply]

Archon, you write "Since decimal fractions are just a different way of representing the same numbers it's not obvious why they have to be treated differently". I agree, it's not obvious. However, what is obvious is that they are treated differently. It's not obvious why "I" is always capitalised whereas "he", "she", "me", etc. are not. It's not obvious why it's "himself" and "themselves" (not "hisself" and "theirselves") whereas we have "myself" and "yourself". It's not obvious why we don't spell "yacht" as "yot", "friend" as "frend", "head" as "hed", etc. Decimals and fractions may represent the same things but they are different things. When you see "34 metre" you read it as "three quarters of a litre" (just as you read "on 6 February" as "on the sixth of February") but when you see "0.75 litres" you read it as "zero point seven five litres". I suspect that it was some failure along the way to see the distinction between fractions and decimals that lead to the artificial rule that they should be treated as equivalent. Wikipedia is not bound by outside style guides (nor need it be nor even should it be). We are free to make and follow our own rules. In creating such rules it would seem that normal English usage should trump the dictates of some organisation like the US NIST. In normal English usage we don't make any special exception for metric unit names when it comes to pluralisation: they are simply treated as ordinary nouns. This is what we should follow. It is possible to combine fractions with metric units (albeit less common) just as it's possible to combine fractions with imperial/US customary units; in fact fractions and decimals can be combined with many things (not just units). You write "For the purposes of Wikipedia it might be best to pick a more simple and consistent set of rules" and I agree but the rules you suggest are more complicated and inconsistent for my liking. I suggest units be they metric, imperial, US customary or otherwise be treated as any other noun for the purpose of pluralisation and that for ±1 and fractions (but not decimals) between the noun be singular and for other numbers it be plural. Jimp 08:36, 6 March 2014 (UTC)[reply]

I've revised my proposed changes in line with other people's suggestions. Some of the NIST guidance is still useful, even if their pluralisation advice is a bit strange, and it covers some points which the existing MOSNUM version does not — I think this should be included, at least for the sake of completeness.
Metric units aren't supposed to be written with vulgar fractions in general, and this is already covered by MOSNUM:
Unless there is sound reason to the contrary, fractional parts of metric units should be expressed as decimal fractions (5.25 mm), not vulgar fractions (514 mm). However Imperial, English, avoirdupois, and United States customary units may use either form – both (5.25 inches) and (514 inches) are acceptable, provided that there is consistency in the way that the fractions are represented.
Archon 2488 (talk) 12:02, 6 March 2014 (UTC)[reply]
I'm fairly certain that, with regard to imperial, one should not write "5.25 inches" or whatever. This is contrary to how the system was designed, and how it was meant to be used. It should be "514 inches". RGloucester 16:46, 6 March 2014 (UTC)[reply]
Traditionally, you would be correct, but (at least in the USA) the convention of decimalising inches (and other such units) is well-established. American firearms are typically described in terms of their nominal caliber in decimal inches (.308 Winchester, etc.). For machining in USC units, it's common to subdivide inches into thousandths (or "mils"). There's no real contemporary guidance on how imperial/USC units should be used, so you'd just follow the use that was conventional in the relevant field, whether that be fractional or decimal inches. This is why MOSNUM allows both formats. Archon 2488 (talk) 17:48, 6 March 2014 (UTC)[reply]
I suppose so. It feels weird, however, to use a system meant to be used with vulgar fractions, but use decimalised fractions instead. RGloucester 18:07, 6 March 2014 (UTC)[reply]
I agree with it feeling "weird" every time I take a measurement with a ruler and convert 1/4 to 0.250, but I think computers have pushed us towards doing it because of not having the 1/4 and 1/2 (let alone 3/16) characters in the standard 7-bit ASCII character set or keyboards any more, the "ugliness" of having to insert a space for the fraction when not written in a smaller font (i.e. 5 1/4) and the result still not being as "clean" as 514, etc. So, we just get used to converting to 5.25 because it's easier to type, see, and store in a database. There are a few special limited circumstances that still work better retaining values as fractions, like some financial instrument pricing (and not even there for much longer, with most markets having been decimalized), and we should retain them in quotes as well.
As far as plurals, it seems the best "sounding" rules are those that follow how one would read it aloud: 14 liter, but 0.25 liters; ¾ [of an] inch, but 0.75 inches; 12 [an] acre, but 0.5 acres. —[AlanM1(talk)]— 18:54, 6 March 2014 (UTC)[reply]
The Daily Telegraph, which is quite biased in favour of Imperial units (which it calls "British units"), recommends the following:
"Fractions: use half, quarter, three quarters, third, fifth, eighth in preference to decimals in general copy. Use decimals when they aid comprehension or comparison, but not with imperial measurements: e.g. write 3ft 9in rather than 3.75 feet, or 6lb 8oz not 6.5lb. Do not use decimals and fractions in the same story except when necessary in financial copy. In money markets all dealings are in fractions. Write 2¼, but one-quarter per cent."Link
I tend to agree with recommending "3ft 9in" over "3.75 feet". RGloucester 19:05, 7 March 2014 (UTC)[reply]

Noon vs. 12 pm

I feel that "noon," "midnight," "12 pm," and "12 am," should be used interchangeably, as it looks out of place in a table, for example:
3:30 pm
6:00 pm
Noon
8:00 pm
10:00 am
etc.
Should the Manual allow this? Shorthand date formats are allowed, and I have seen several templates contain 12 pm, particularly on sports-related pages with tables concerning game/match results. Would this also fall under WP:IAR? BenYes? 00:12, 6 March 2014 (UTC)[reply]

What does it mean to say that they should be used interchangeably? There's an ambiguity here that can only really be avoided by using the 24-hour clock, but the existing guidance on this is vague. I have asked for clarification on this point in a separate section on this page. Archon 2488 (talk) 00:28, 6 March 2014 (UTC)[reply]
By "interchangeably," I mean that both "noon" and "12 pm" could be used. BenYes? 00:37, 6 March 2014 (UTC)[reply]
Obviously, noon and midnight are not interchangeable, nor are 12 pm and 12 am, as these refer to different times of day. The guidance at MOS:TIME ("Use noon and midnight rather than 12 pm and 12 am; whether midnight refers to the start or the end of a date will need to be specified unless it is clear from the context") is presumably because some people confuse 12 pm (i.e., noon) and 12 am (i.e., midnight). No such issue arises when using 24-hour time. sroc 💬 01:08, 6 March 2014 (UTC)[reply]
Problem is that there's no universally-agreed convention that they mean the same thing. "am/pm" is fundamentally ambiguous when it comes to the hour 12; you can never be sure, without contextual information, whether "12 pm" means noon or midnight. There's another ambiguity: does "midnight Saturday" mean midnight at the end of Saturday, or at the beginning? With the 24-hour clock it's all completely unambiguous: 12:00 is always noon, Saturday 00:00 is the beginning of Saturday and Saturday 24:00 is the end of Saturday. Which is why I think the 24-hour clock is generally preferable. Archon 2488 (talk) 01:12, 6 March 2014 (UTC)[reply]
I know noon and midnight aren't interchangeable, but noon is the same thing as 12 pm, as well as 1200. Personally, I do prefer the 24-hour time format, but I'm saying that 12 pm should be allowed as an equivalent alternative to Noon, so that if there is a list of times in a table, for example, it doesn't stand out, or as otherwise appropriate within the context. Because the issue of people confusing 12 am against 12 pm seems to be apparent, if it were allowed, there could be an endnote stating that 12 pm/12 am should only be used where brevity is required, in the case of tables, for example, otherwise, noon should be used. This is seen in the date formats rules. BenYes? 01:23, 6 March 2014 (UTC)[reply]
'Problem is that there's no universally-agreed convention that they mean the same thing. "am/pm" is fundamentally ambiguous when it comes to the hour 12; you can never be sure, without contextual information, whether "12 pm" means noon or midnight.' Other than by mistake, who uses "12 pm" to mean "midnight" or "12 am" to mean "noon"? Are there any cultures that do this? I've never heard of such a convention. sroc 💬 04:34, 6 March 2014 (UTC)[reply]
I personally find it confusing, probably because I'm trying to apply too much logic to it. Quoting from 12-hour clock: "a.m. (from the Latin ante meridiem, meaning 'before midday') and p.m. (post meridiem, 'after midday')". Noon and midnight are neither before nor after midday. Noon is midday and midnight is the opposite. There's a whole section at 12-hour clock#Confusion at noon and midnight which goes on in the same vein. SchreiberBike talk 05:28, 6 March 2014 (UTC)[reply]
Well, I was not aware that Japanese legal convention and former advice from the US Government Printing Office endorsed "12 am" for noon and "12 pm" for midnight, but there you go. These are, of course, not strictly relevant to current practice in the English language, but if consensus is that these "12 am" and "12 pm" are to be avoided because of the potential for confusion, then so be it.
By the way, I don't think the idea of making exceptions for confined spaces (as with the date format table) is a good idea in general when there is not a significant problem, otherwise it might be perceived as instruction creep. This is also a different situation because YYYY-MM-DD date formats are clear, albeit uncommonly used in English, so there is no harm in using them in certain contexts without clarification; conversely, "12 am" and "12 pm" apparently are ambiguous (at least to some people) so having a footnote in MOS is not going to clarify what these terms mean for someone encountering them in an article (unless you also include a footnote in the tables explaining what these times mean—in which case it's too much effort to avoid simply using unambiguous terms such as "midnight" or "noon" in the first place). sroc 💬 08:07, 6 March 2014 (UTC)[reply]

It seems to me that we should stick to disallowing "12 am" and "12 pm". There may be no convention for "12 pm" to mean "midnight" or "12 am" to mean "noon", some follow the opposite convention but it's not universally-agreed-upon. Logic, though, would have "12 am" and "12 pm" both mean "midnight" (at the start and the end of the day respectively, i.e. "12:00 am" ≡ "00:00" and "12:00 pm" ≡ "24:00") since midnight is as much before noon as it is after (noon is neither before nor after itself). The best convention, in my opinion, would be this (along with having the usual stuff like midday's being called "12 noon" and using "12 midnight" for midnight without specifying the day (or between the days)). It follows the logical implication of what "am" and "pm" stand for and solves the midnight problem too but, of course, we couldn't use it here since it's not universally accepted either (I just made it up). Without universal agreement on what "12 pm" and "12 am" are supposed to mean, though, it's best we avoid them. Jimp 07:31, 6 March 2014 (UTC)[reply]

I disagree that there is no convention. As long as I can remember, in the U.S. anyway, 12 p.m. has been noon and 12 a.m. has been midnight. As a child, I might have been confused about it for a while, but it was one of those things you just had to memorize, like which way is left. In the current computer-literate world, it's even more clearly understood, since any software that (unfortunately) uses an AM/PM format for display must use this convention to get it right. Can someone point to a current source where the convention is inverted?
Having said that, I think "noon" or "midnight" are more clear, though the latter probably should follow the AP style of including the dates being straddled. But back to what I think the original poster's point was – in a table that uses a.m./p.m. times, I think it "looks better" to use "12 p.m." than "noon". I just don't know if it's worth trading looks for possible ambiguity, however slight I may think that possibility is. —[AlanM1(talk)]— 09:17, 6 March 2014 (UTC)[reply]
A US convention is not a universal convention (although I have seen the convention in use here too). As for the table/list above we could go for this.
 3:30 pm
 6:00 pm
12:00 noon
 8:00 pm
10:00 am
Jimp 09:27, 6 March 2014 (UTC)[reply]
This seems like a reasonable proposal. Nonetheless, whenever you use the 12-hour clock, there's always more information for the reader to parse before they can be sure what is going on (be it contextual information or even the symbols "am" and "pm" after the time). The ambiguity arises because noon/midnight are neither in the am nor the pm period, so sometime you'll come across things like 11:59 pm to avoid the confusion. Archon 2488 (talk) 11:40, 6 March 2014 (UTC)[reply]
While "12 noon" looks OK above, and doesn't result in too much extra width, "12 midnight" is somewhat ugly, either by being too wide or wrapping. How about suggesting that times be shown in 24-hour format (HH:mm, with leading zero) unless 12-hour is necessary for some reason? This has the added advantage of not requiring a hidden value to sort correctly. While people may have been resistant to this format a couple generations ago, many countries now routinely use 24-hour format in travel and broadcast information and, while people may not use it routinely when speaking, I think a majority of readers can deal with it when needed. —[AlanM1(talk)]— 18:23, 6 March 2014 (UTC)[reply]
Many people in many countries have not adjusted to 24-hour times, so there's no need to foist it on editors as a blanket requirement. The choice between 12- and 24-hour times may be determined by editors based on, for example, the format commonly used in the country that is the primary subject of the article. For example, the US broadly uses 12-hour time and there may be many readers are not as familiar with 24-hour times or would have to do mental arithmetic every time, particularly for articles on a US subject. We shouldn't force all editors to use 24-hour times just because 12-hour times might look ugly in some cases. sroc 💬 22:35, 6 March 2014 (UTC)[reply]
  • How about waiting until this issue has come up as an actual problem among actual editors in an actual article, and see if how they work it out? And then, if it comes up in another article, and another, and another, then -- in light of all that experience -- we might think about whether MOS' usefulness will be enhanced by adding something on this, instead of being WP:CREEP-bloated in advance of any indicated need. EEng (talk) 18:33, 6 March 2014 (UTC)[reply]
An older edition of the Chicago Manual of Style indicated 12 AM was noon and 12 PM was midnight, although the current 16th edition (p.478) states "Except in the 24 hour system numbers should never be used to express noon or midnight (except, informally, in an expression like twelve o'clock at night)." [Cross reference omitted.] Chicago justifies this with the same ambiguity concerns expressed in this thread. I have seen articles about radio programs where I tried to fix the ambiguity, but had to give up because I just couldn't figure out whether noon or midnight was intended. Jc3s5h (talk) 23:24, 6 March 2014 (UTC)[reply]

Article should be flagged as conflicting

I propose the article be marked with Template:Contradict-other-multiple as such:

Due to direct conflict with these articles, especially in the portion WP:NUMERAL and onward. Proposal:

  1. The articles listed should be updated to conform with this page or have sections or some indication/link of exception when being used internally on Wikipedia
  2. This MoS page be updated to conform to the writing styles described within the listed articles, and all pages be maintained uniformly as a group

Particular instances of direct contradiction are abundant, so I won't list them all here. Thoughts? Penitence (talk) 09:38, 7 March 2014 (UTC)[reply]

Do not tag MOS as contradicting articles. MOS is not an article; it is a project page. Specifically, it is our Manual of Style, and we can adopt whatever style we choose, regardless of whether it is reflected in individual encyclopedic articles. Nonetheless, if you have any suggestions on how to improve either MOS or individual articles, feel free to propose them. sroc 💬 03:07, 8 March 2014 (UTC)[reply]

Date ranges

Are date ranges in the form Mmmm dd – Mmmm dd, YYYY (January 27 – February 3, 1986 or Jan 27 – Feb 3, 1986) permissible under WP:DATERANGE or other WP:DATE? If not, why not? If permissible, should this form be added to WP:DATERANGE?

Trappist the monk (talk) 11:21, 8 March 2014 (UTC)[reply]

It already does:

The Ghent Incursion (March 1822 – January 1, 1823) was ended by the New Year's Treaty.

sroc 💬 11:33, 8 March 2014 (UTC)[reply]
Sorry, wasn't thinking. That was obviously after they slashed the number of days in March. (What an odd mix of date formats, though.) sroc 💬 11:40, 8 March 2014 (UTC)[reply]
Anyway, I think the examples you provided are perfectly acceptable. It's a shame that the examples given in WP:DATERANGE ("They travelled June 3 – August 18 of that year;  They travelled 3 June – 18 August") do not include actual years. I don't think we necessarily need additional examples (WP:CREEP), but perhaps we could revise these examples (They travelled June 3 – August 18, 2001;  They travelled 3 June – 18 August 2001) for the sake of clarity? sroc 💬 11:47, 8 March 2014 (UTC)[reply]

UK horses' heights

At the moment MOSNUM says that horses and other equines are measured in hands. This may be true, but it doesn't seem to be the whole truth.

Equine World UK says:

The term used for height measurement of a horse is "hands high" or "hh". Often the height is just over a number of hands eg 16 hands and 2 inches and the height is therefore referred to as 16.2 hh. With Europeanisation horses are also now being measured in centimetres, particularly small ponies. See conversion table for horse's height in hh and cm. [21]

The Joint Measurement Board website doesn't appear to mention hands but its references to measurements seem to be centimetres first.

7. The animal must be positioned for measurement with the front legs parallel and perpendicular; the toes of the front feet should be in line, allowing not more than 1.5 cm (½ in) difference. Both hind- feet must be taking weight and as near perpendicular as possible; the toes of the hind feet should be not more than 15 cm (6 in) out of line with each other.
8. The animal’s head must be in its natural position in relation to its neck, positioned so that the eye is neither more than 8 cm (3in) below, nor more than 8 cm (3 in) above the highest point of the withers.

British Showjumping has this question and answer on its website:

If a pony (148cms or smaller) has been registered as a horse can it be registered back as a pony?
Yes, however the request must be sent to the British Showjumping office in writing and must be accompanied by a valid up to date JMB Height Certificate stating that the animal is 148cms or below.

On the other hand, Blue Cross uses hands. Even when it appears to use kilograms for their weights (but they work it out with a weight tape in inches that works out an approximate weight in pounds that is divided by 2.2 to give you kilograms!) see [22]

Scottish Horse had this headline: Measuring Horses and Ponies - ongoing controversies [23]

Here were some problems:

  • ...it is the inescapable fact that there is no rigid anatomical connection between the withers and the feet that touch the ground. *...simply allowing an excited pony to stand and relaxed can, in my experience, cause the height to drop by as much as 6cm. *...Measurements are taken without shoes and simply trimming the heels and leaving the toes long can reduce height by more than cm. (sic)
  • Lowering the head to the ground can significantly reduce the height at the withers – by nearly 2cm – whereas raising the head can increase height by over 2cm.

Then there was this passage:

I distinctly remember, in the line of ponies waiting to be measured at Avenches, Switzerland in 2008, a grey horse that looked at least 15.2hh. Fearful of creating an international incident I anxiously awaited its arrival at my station. It settled into the stable and when I put the stick onto its withers the horizontal bar read over 156cm. But the withers instantly started to shrink under the bar – as if contact with the stick had triggered a reflex – and kept sinking until, within a couple of minutes, the pony measured 151.5cm. Many of the ponies at this year’s championships showed similar reactions, no doubt the results of months of training at home. Why go to all that effort? Putting it bluntly, a European team pony might be worth several hundred thousand Euros, whereas a pony that won’t measure 151cm is practically worthless.

There is no way that I can be dogmatic about ponies and horses. However, it would seem that "Hands for horses and other equines" is perhaps an over-simplification. Michael Glass (talk) 13:52, 8 March 2014 (UTC)[reply]