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

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 155

Archive 156

Archive 157

→

Distances measured in chains

The British railway people seem to be in the midst of proposing another subject-specific exception to MOS:UNIT, allowing distances to be given in chains rather than km or miles for articles whose sources use that measure. See Wikipedia talk:WikiProject UK Railways for details. —David Eppstein (talk) 22:18, 12 July 2018 (UTC)

Yes, we are, but in very limited circumstances. The chain (unit) is in current use as a measure of distance for most of Britain's railways. The discussion only affects is use in articles on those railways, and articles on British railway stations. It also is proposing that chains are not introduced where they are not used a a measurement of a railway line, such as High Speed 1.

What we are not doing, is imposing the introduction of chains as a unit across the whole of Wikipedia. It has been long-standing practice that chains get used on UK railway/station articles, but there have been recent discussions about the practice, so the issue is being thrashed out. Mjroots (talk) 04:43, 14 July 2018 (UTC)

@David Eppstein: It's not really an exception so much as a British quirk – MOS:CONVERSIONS says Where an imperial unit is not part of the US customary system, or vice versa […] a double conversion may be appropriate. Chains are apparently still used by the British railway people who build railways in the real world. I would continue further discussion on that talk page per that guideline which discourages splitting discussions. Jc86035 (talk) 05:15, 14 July 2018 (UTC)

Tomato, tomahto. MOS:UNIT says "In non-scientific articles relating to the United Kingdom, the primary units for most quantities are metric or other internationally used units,[i] except..." This proposal would effectively add another clause to the list under the word except. In that sense it is an exception. I had no pejorative intention in using that word, only descriptive. In any case, actual opinions on whether this is a good idea would probably be better expressed over on the RFC than here. —David Eppstein (talk) 06:30, 14 July 2018 (UTC)

I see no need for change to this guideline. Mostly because this is already handled by the rule that says, "UK engineering-related articles, including those on bridges and tunnels, generally use the system of units that the topic was drawn up in." - a rule that would seem to allow for chains where appropriate in any case.

Note that in any case the MOS is intended to be applied with occasional exceptions (where there are good reasons for them). This rule does not need to ennumerate every single one of them individually. Kahastok talk 11:53, 14 July 2018 (UTC)

Yeah. The nature of the dispute over there appears to me to be that no real WP:IAR rationale can be articulated; it's a bunch of WP:ILIKEIT / WP:SSF stuff, and not a lot of listening to reason. Guideline exceptions don't apply to something wracked by controversy, and forking into five different proposals. That's a full-on lack of consensus. I did post a compromise proposal, and hopefully it'll grow some legs. — SMcCandlish ☏ ¢ 😼 14:48, 14 July 2018 (UTC)

No explicit statement that unit order should be consistent

In the railroad discussion (Wikipedia talk:WikiProject UK Railways#Chains RFC) it is suggested that the order of units should be determined by what is stated in the source supporting a statement. For example, if a source gives a distance as 1 mile 3 chains it would be given in the article as 1 mile 3 chains (1.68 km). On the other hand, if a source gave a distance as 51 km, it would be given in the article as 51 kilometres (32 mi).

I believe it's always been the consensus in this talk page that the order of units should be consistent throughout an article, but the only statement I can find that implies that is this bullet point:

Where the article's primary units differ from the units given in the source, the {{convert}} template's |order=flip flag can be used; this causes the original unit to be shown as secondary in the article, and the converted unit to be shown as primary: {{convert|200|mi|km|order=flip}} → The two cities are 320 kilometres (200 mi) apart.

A participant in the discussion is disputing the meaning of this point, stating The three preceding bullet points appear to prefer source (conversion) and the one you quote says "the ... flag can be used", not "the flag ... must be used". ~~Incidentaly the quoted middle English (not old English, that was half a millennium earlier) came straight from the Wiki page.~~

Maybe we should have an explicit statement that the order of units should be consistent throughout an article. Jc3s5h (talk) 13:24, 17 July 2018 (UTC)

I've struck out the mention of Middle and Old English, this was in reference to an earlier point in the discussion. As the participant in question I agree that Jc3s5h's portrayal of the situation in para 1 is a fair statement of the facts, but of course disagree with his final paragraph! Martin of Sheffield (talk) 14:02, 17 July 2018 (UTC)

I agree with Jc3s5h's premise that there is consensus for consistent choice of units. The few times I can recall proposals to follow sources, these have been unsuccessful precisely because of this consensus. I'm not sure we need an explicit statement saying this because it is implied by "Where this manual provides options, consistency should be maintained within an article unless there is a good reason to do otherwise" but I don't object to making it explicit if others feel it is needed. Dondervogel 2 (talk) 14:21, 17 July 2018 (UTC)

I concur as well. However, an other issue raised in that RfC is whether to ever lead with something like "1 mile 3 chains", using a unit that is meanigless to almost every reader unless they're a cricket official or a British railway engineer (and which has inconsistent actual dimensions, even in the UK, being different in Scotland). I think that RfC is a ... trainwreck, because it's presented a selection of only four options with some obvious missing ones. — SMcCandlish ☏ ¢ 😼 16:10, 17 July 2018 (UTC)

Meaningless it may be to some people, but it's not the only such case: I meet people daily who don't know what inches and ounces are - and I work in a shop in England. But our goal is to educate, not suppress, which is why the word chains should be linked on first use. --Redrose64 🌹 (talk) 20:39, 17 July 2018 (UTC)

Of course unfamiliar units should be linked on first use. Is someone suggesting otherwise? Dondervogel 2 (talk) 13:15, 18 July 2018 (UTC)

There are those - yourself included - who are saying that because chains are perceived to be an unfamiliar/archaic/obsolete/illegal unit (reasons vary between posters), they must be removed. This comes down to "I don't understand it, so I shall remove it". This in turn is WP:IDONTLIKEIT. A much better response to misunderstanding is explanation - and the easiest way of doing that is the wikilink. --Redrose64 🌹 (talk) 19:05, 18 July 2018 (UTC)

The lack of familiarity of a unit is not a reason for removing it. When have I ever argued that? Dondervogel 2 (talk) 19:48, 18 July 2018 (UTC)

This was one of them. --Redrose64 🌹 (talk) 20:35, 18 July 2018 (UTC)

I see a plea for clarity. No mention of removal. In any case this seems off topic. Let's leave the chains to UK Railways. Dondervogel 2 (talk) 21:43, 18 July 2018 (UTC)

Yes, there is consensus that units within an article should be consistent, with standard exceptions (direct quotations, definitions etc.). There is also a longstanding and repeatedly-reaffirmed (more times than I can count) consensus against adopting any system that would meet the description "the order of units should be determined by what is stated in the source supporting a statement". Kahastok talk 21:18, 17 July 2018 (UTC)

And before anyone says, if it's more times than you can count then it must have some support, first see WP:PERENNIAL, and then note that it's generally always been the same editor proposing it every time. Kahastok talk 21:22, 17 July 2018 (UTC)

In the first paragraph of this section it appears clear that first distance was actually 1 mile 3 chains (which for readers who don't understand this is 1.68 km). To reverse the statement reads that the distance as measured was 1.68 km (and for readers who don't understand this is 1 mile 3 chains). There may be an esoteric desire to ensure consistency, but to do so risks: ignoring WP:RF by misleading a reader who is unaware of deep hidden policy or getting perilously close to either WP:OR, WP:SYNTH or both. Why is it only distances that have this obsession? Perhaps all money amounts should be expressed in 2018 US$ for example "According to the Domesday Book of 1086, the Bishop of Rochester was given land valued at $2,600 (17s 4d) in Aylesford, Kent" see Rochester Castle for context. Would this assist the reader? (conversion approximate, the templates only go back to 1209). Martin of Sheffield (talk) 22:30, 17 July 2018 (UTC)

Not a comparable case, since shillings and pence aren't an unfamiliar unit to most readers, even Americans (and for other reasons). — SMcCandlish ☏ ¢ 😼 02:12, 18 July 2018 (UTC)

If exchange rates were fixed there would be an advantage in expressing values and costs in a consistent way (fixed currency), and we would no doubt have debated the pros and cons of an ENGVAR for currencies. But they're not fixed, so such a debate would lead nowhere. Dondervogel 2 (talk) 07:37, 18 July 2018 (UTC)

This is an issue in plenty of other areas, it's just that a discussion on UK railway distances is probably going to end up discussing UK railway distances.

It seems to me that what you are arguing is not that you want the units in the specific source - which would mean that if someone can find just one source in an unconventional unit, even if it's the only one in the world, they can change the source and hence the order to match that source - but for the units that are conventional in the field. Standing consensus gives significant latitude to the latter argument (airline altitudes aren't often given in metres on Wikipedia or elsewhere) and has no truck with the former. Kahastok talk 21:31, 19 July 2018 (UTC)

From NASA's style guide:

Historians of science and technology are rarely the originators of measurements. Both the original unit of measure and its mathematical value can have potential significance for historic interpretation. For example, the use of "rods" or "chains" can serve as important internal evidence for the original date and source of an otherwise unidentifiable document. Historians should not alter an original scientific or engineering notation any more than they should rewrite an original quotation. Thus, the unit of measure actually used by the originating designer, engineer, researcher, etc., should always appear first, in quotation marks if appropriate, then followed by the metric or English equivalent in parentheses. For metric measurements, use the International System of Units.

Hawkeye7 (discuss) 01:28, 21 July 2018 (UTC)

@Hawkeye7: That's the NASA style guide and it's only relevant here if you are proposing WP modify its own style guide to follow NASA on this point. Are you? Dondervogel 2 (talk) 07:06, 21 July 2018 (UTC)

NASA or not, it's good advice, and its mention of "any more than they should rewrite an original quotation" harmonises with our own advice concerning the principle of minimal change. That is what I am trying to get to here: we don't arbitrarily mess with units when we can use the original units perfectly well if we also supply an automatic conversion to something more familiar. --Redrose64 🌹 (talk) 11:16, 21 July 2018 (UTC)

I understand the logic of the NASA style guide, but (at least until now) it's not how Wikipedia works. In fact it's in direct conflict with our advice on units, which is to use metric units first except in stated exceptions. If you'd like to change that then this is the right place for the discussion. How would you like to see mosnum modified to achieve the historical accuracy you seek? Dondervogel 2 (talk) 11:22, 21 July 2018 (UTC)

The NASA style guide is not a general, or scientific, style guide; it only applies to their historians. Historians write about the past, but many Wikipedia articles are about living people, places that serve a contemporary purpose, concepts that are of current interest in society, mathematics, science, etc. Such articles about contemporary stuff are more directed to providing useful information, and our guideline of consistently listing a primary unit first for each unit of measure is consistent with writing useful articles. I think our policy is more applicable to the wide range of article subjects covered by Wikipedia than a source-units-first guideline. Jc3s5h (talk) 11:50, 21 July 2018 (UTC)

I am inclined to agree.

There have been proposals in the past that in historical contexts we should use the historical units, but this has generally failed to get consensus on the problem of obscure units. It would not serve the reader in general to measure Roman remains in ancient Roman units of measurement.

Note that the NASA guideline does not support source units first, it supports putting the original measurement first. If the railway was designed in miles and chains, but your source has given it in kilometres, the NASA guideline says to use miles and chains. Note also that for engineering projects other than roads in the UK, such a system is already endorsed by WP:UNITS. Kahastok talk 12:37, 21 July 2018 (UTC)

@Dondervogel 2: Here is what WP:UNITS says:

UK engineering-related articles, including those on bridges and tunnels, generally use the system of units that the topic was drawn up in (but road distances are given in imperial units, with a metric conversion – see next bullet);

Are you arguing that railways are not engineering-related? --Redrose64 🌹 (talk) 20:05, 21 July 2018 (UTC)

No. What units are used by British railway engineers on their engineering drawings? Dondervogel 2 (talk) 20:32, 21 July 2018 (UTC)

Miles and chains. That is why this plate says "53m 41ch". It is attached to a bridge that was built in 2014-15, so that plate indicates that chains were still in official use four years ago, probably less, since the plate will have been attached towards the end of construction. --Redrose64 🌹 (talk) 14:11, 22 July 2018 (UTC)

I find that hard to believe given that the gauge (1.435 m) is metric. Do they use metric for width and Imperial for length? That would be bizarre. Do you have any evidence to support your claim that chains are used on engineering drawings? Dondervogel 2 (talk) 14:28, 22 July 2018 (UTC)

I remember seeing here an interview with a network rail engineer from late 2017 where he does mention they officially have mile and chain usage. It implies they internally use engineering documents in this format, though I have no copy of them. Voello (talk) 17:44, 22 July 2018 (UTC)

I am despairing of you, I really am. Listen. For any NR station, I can turn up two to four recent sources that give the station's position along the line, in MILES AND CHAINS. Got that? Now, since WP:V is policy (unless you can show that it has been repealed), do you have any sources at all that give the positions of all 2,500+ stations in kilometres? I'm waiting. Until you prove that such sources exist and are reliable, I will continue to add distances in miles and chains, and I will source them. --Redrose64 🌹 (talk) 20:48, 22 July 2018 (UTC)

Redrose64 asked "Are you arguing that railways are not engineering-related?" While the question was not addressed to me, I argue that articles about tunnels and bridges are likely to focus on engineering matters, such as the equipment used to build them or the new materials that had recently been developed to allow the successful construction. But articles about rail lines are less likely to focus on engineering; the main focus may be on what connections are made, time saved compared to previously-existing lines, or social changes due to the feasibility of living in suburbs and working in cities. Jc3s5h (talk) 11:28, 23 July 2018 (UTC)

And see WP:CALC. There is no policy problem whatsoever in doing routine unit conversions to stuff that makes sense to readers and other than the factional sliver of 1% of who know what a chain is (and now that particular chain unit). It's entirely sufficient to give the chains stuff in a quote in the citations, or even give it inline in the material as long as we also give it in metric and in fractional miles (preferably decimal), without making it worse by throwing in yards. This is not difficult. People are just trying to make it difficult out of territorial stubbornness. — SMcCandlish ☏ ¢ 😼 18:47, 23 July 2018 (UTC)

I'm not trying to "throw in yards". I have not mentioned them, except to point out that the definition of a chain is 22 yards. What I am trying to do is to add content using sources that consistently give distances miles and chains, yet I am finding resistance all the way from a small number of people who are insistent that I omit all mention of chains because "they are archaic"/"nobody understands them"/"they're not metric"/"they're only used in old documents". Apart from not being metric (which is a bogus objection, given MOS:UNITS), all of them come down to WP:IDONTLIKEIT. What I am asking these objectors to provide is a source for distances along a railway line on the Network Rail system where the primary units are not miles and chains. I don't care if such sources are kilometres, or decimal miles: but nobody has yet come up with one. Stubbornness is one thing; our policy on verifiability is quite another. I stand by the latter. --Redrose64 🌹 (talk) 22:34, 23 July 2018 (UTC)

Re: Yards – I didn't mean you in particular; using them as what to convert to has been suggested by a couple of people here. I for one didn't advocate omitting chains (see proposal V at the RfC), but including them parenthetically along with the other unit, presumably fractional, decimal miles, in this context. — SMcCandlish ☏ ¢ 😼 04:53, 25 July 2018 (UTC)

There is no valid WP:V concern in converting from one unit to another. If the distance given by the source is precisely 1 mile and 18 chains it is equally verifiable to say it's 1.225 miles, or 1 mile and 396 yards, or 2156 yards, or 6468 feet, or 1971.4464 metres, or 1.9714464 kilometres. Because the only thing I'm doing in between is converting the units, a simple mathematical calculation per WP:CALC.

You can make a valid case for using chains on the basis that they are the standard units in the field. You can make a valid case for using chains on the basis that they are the units the railway was designed in. But there is no valid case to be made that a simple conversion per WP:CALC makes the measurement unverifiable - your suggestion that it does is plain wrong. Kahastok talk 21:34, 24 July 2018 (UTC)

Does nobody understand a word that I've written? The sources use miles and chains because that's what the industry has used and currently uses, from genesis to the present. Can you - or anybody else - find any sources for distances on Network Rail that are more precise than a quarter of a mile, and yet doesn't use miles and chains? --Redrose64 🌹 (talk) 22:47, 24 July 2018 (UTC)

It's kind of a "who cares?" matter. WP isn't written for British railway industry people but for a whole world of them, who mostly only grok the basic units in an overlapping combination of two system (with differing overlap in different countries). There is not WP:V/WP:OR problem with conversions, so we don't actually need chains in the main article text. It seems okay to have them, if don't lead with them; they're just extraneous trivia for something like 99.999% of our readers. — SMcCandlish ☏ ¢ 😼 05:31, 25 July 2018 (UTC)

Maybe not unverifiable, but if the original uses a particular measurement, then it will be harder to locate it in the source if the article only uses another. Otherwise, sure, use metric only. Hawkeye7 (discuss) 00:57, 25 July 2018 (UTC)

There are ways to deal with this if this is a concern - give the original measurement in the reference, for example. That's not a problem. Note that I am not arguing against using chains, only against using them on the basis that the source that happens to be being used uses them.

@Redrose64: if the reason to use chains is because "that's what the industry has used and currently uses", that's a different matter. There is a reasonable case to be made IMO that we should be using chains because that is the standard unit in use in the field. We don't insist on metres for airliner altitude, even if the plane is located in France. We expect to measure computer and TV screens in inches - everyone else does. The difference compared with your argument is that in this case we continue to use chains for distances along those railway lines conventionally measured in chains, even if the source uses kilometres.

For my part, I have no strong objection to chains on this basis on those lines where they are the conventional measurement, provided that conversions are given to both SI and decimal miles/yards, or (if there are many distances in a short space) provided that they are converted to SI and a conversion rate to miles is given. Kahastok talk 20:38, 25 July 2018 (UTC)

The key to this is "everyone else does" (measure computer monitors in inches, etc.). Everyone, besides British railway industry people and some trainspotters in the UK, does not measure anything to do with railways in chains. It is not a reader expectation. — SMcCandlish ☏ ¢ 😼 22:32, 27 July 2018 (UTC)

@SMcCandlish: In which case, please give examples of distances in the units that "everyone else" uses, with sources. I should not need to remind you that WP:V is policy. And who are we to decide what the reader expects? Provide them with information, and let them judge for themselves whether to read it or skip it. If there is a perception that the information is not understood by all, then for the love of all that is sacred, link it to an article that explains it. --Redrose64 🌹 (talk) 23:00, 27 July 2018 (UTC)

Your venting about this is getting weird and weirder, and is actually really out of character. No sources are needed whatsoever that British, Americans, Australians, etc. reckon in kilometres and metres or in miles and feet. Let's not be silly. And actually read WP:V: information has to be verifiable, not verified already unless it's controversial. There nothing even faintly controversial about what units people in the aggregate use and understand. If you really wanted sources proving that the British, say, use a mixture of metrication and reckon in both kilometers/meters and files/feet/sometimes yards, I'm sure that should be easy to find. It's a WP:YOUCANSEARCH matter. — SMcCandlish ☏ ¢ 😼 23:48, 27 July 2018 (UTC)

Weird? I'm getting exasperated here. I'm not arguing for use of miles and chains across the board. What I am asking for is a demonstration that the national railway system of Great Britain is measured in anything other than miles and chains. You could, for example, turn out a document or website that explicitly says that East Croydon station is 16.66 km from London Bridge; or that it is 10.35 miles from London Bridge; or even 10 miles and X yards. --Redrose64 🌹 (talk) 08:52, 28 July 2018 (UTC)

@Redrose64: This took a grand total of 12 seconds from opening Google in a new tab, entering a search of km "East Croydon" "London Bridge", to finding it – not counting copy-paste time to put it into this talk page: [1] Trainline, "Trains from East Croydon to London Bridge, Today at 16:04"; quote: "Distance: 9 miles (14 km)". I did mention WP:YOUCANSEARCH, right? There are pages and pages of results like this (also for maile "East Croydon" "London Bridge", and of course if you put it different destination stations). Since we can, obviously, find exactly what you say we can't find, will you please now drop this? PS: Try chains "East Croydon" "London Bridge", and not that you get barely more that 1/10 as many results, and the vast majority of them are false positives, or WP itself and re-users of our content. Pretty much no one outside of insider "train stuff" publications uses chains any longer. Most of us already knew that, of course. — SMcCandlish ☏ ¢ 😼 15:08, 29 July 2018 (UTC)

That web page does not seem particularly accurate; without decimal places, 9 miles (14 km) could mean anything from 8.5 to 9.49 miles, or 13.5 km to 14.49 km - but even so, this is significantly different from the 10 miles 28 chains (16.7 km) that reliable sources give and well outside the margin of error due to rounding. The web page also does not give the basis for the distance - I suspect, based on the aforementioned discrepancy, that it is the distance as the crow flies and not the distance along the railway, which is what we are discussing here. I therefore contend that it should not be considered a reliable source for the purposes of verifiability. --Redrose64 🌹 (talk) 16:58, 29 July 2018 (UTC)

This websiteoffers the ability to calculate as the crow flies distances within the UK Grid: it calculates the distance between London Bridge station and East Croydon station to be 14.44 km. Google Maps gives the shortest pedestrian route between the two to be about 10.2 miles. Of course, neither are in themselves reliable sources, but they do suggest that a bit more checking would have cast some doubt on the validity of the 9 miles result as a game-decider (a similar tale to the Scots chain?) Rjccumbria (talk) 18:18, 29 July 2018 (UTC)

I was not proposing that we adopt the NASA style guide (although we do use it on space-related topics); I was posting it because it puts the argument for putting the original measurements first. The argument for consistency has not been advanced so clearly. I particularly note the comparison to quotations, where our MOS demands deviation for consistency with the source. I think as an historian because I am one; the point about non-historical articles is accepted. But yes, in a Roman history article we use the Roman miles of the original text, with the usual conversion to SI units. Hawkeye7 (discuss) 21:03, 21 July 2018 (UTC)

Do you really think we should present every measurement of the Terracotta Army first in the Qin-dynasty versions of the bu and li? Are you sure about that?

The advantage of consistency is that it is jarring to the reader to have the distance from London to Edinburgh in miles first in one sentence and in kilometres first in the next. It looks unprofessional and unencylopaedic for us to start talking about the lowest 50 centimetres (20 in) of an 8-foot (2.4 m) statue. The reader is left thinking about the units and not about the topic - meaning, most likely, that such a text won't last long before someone fixes it so that it is consistent.

(And that's before we get to the editors who will declare that measurements in their preferred system are always the originals and so will flip every unit they can find to that system. Don't think it can't happen - it wouldn't be the first time.) Kahastok talk 22:30, 21 July 2018 (UTC)

Do we have (copies of) the original engineering drawings for the terra-cotta army? Or documents close to the appropriate time period? If so, it is probably best to use those units. But for measurements made (much) later, in a more current unit system, I don't see a reason to back convert. One complication with unit conversion is significant figures and uncertainty. Many values are written with an appropriate number of figures, given the uncertainty in the measurement. Conversions will often either lose precision, or imply greater precision than the original. (This happens naturally on rounding decimal values.) As to railway gauge, I suspect that it was converted, with appropriate rounding and within uncertainty, years ago. This is even done in the definition of many units, when new methods allow for increased accuracy in measurement. If the primary source uses a certain unit, and even if the data comes from a reliable secondary source, it seems reasonably to use the primary source unit, with conversions to modern units. If there is no primary source, with reported measurements being made much later, I don't see any reason to use units that might have been used at the time. Gah4 (talk) 18:28, 29 July 2018 (UTC)

Also, one should be careful when changing units, as sometimes units imply more than is obvious. Torque is measured in N m (Newton meters) and not dimensionally equivalent J (Joules). I recently found in an air museum, a jet engine with the thrust in pounds, converted to kilograms. Yes the weight of an engine in pounds converts to kilograms, but thrust converts to Newtons. (The museum agreed, and is changing the exhibit.) Not so obvious, the engines for propeller planes are rated in HP (Horsepower), converted in metric to kW. It seems that the Smithsonian has rules for units in airplane exhibits that they follow. The unit of VA (Volt Ampere) is different from the dimensionally equivalent W (Watt) as it doesn't include the power factor. Gah4 (talk) 10:55, 30 July 2018 (UTC)

@Gah4: Yours is the first sensible argument I have heard in favour of the use of chains. The question becomes a balance between familiarity and precision. That is a debate worth having, not here but at UK Railways. Dondervogel 2 (talk) 19:26, 29 July 2018 (UTC)

A lot of the time it isn't known what the original unit was because the source doesn't tell us. Or there might be two original units from different measurements made at different times. This assumes an ideal world where there is a single primary source for the measurement that is always available. Even if it's a modern measurement, generally there isn't. And in any case such a system does potentially leave us talking about the bottom 50 centimetres of an 8-foot statue because the statue was built in feet but the measurement of the bottom was made in centimetres.

Meanwhile, in the vast majority of instances the question of precision can be readily resolved without fuss. You make this out as a huge issue. It really doesn't have to be. And where we need to acknowledge the unit in the source, when it differs from the text, we can use the order=flip flag on the {{convert}} template to give consistency.

In the case of chains, for example, if you give the measure in decimal miles to 2 decimal places (i.e. to within 17.6 yards), you'll get the same kind of precision as you would if you gave it to the nearest chain (22 yards). Difficult to argue that the reader is going to be seriously misled by being told that it's 20.23 miles instead of 20 miles, 18 chains (and that's even with a deliberately awkward conversion). Kahastok talk 21:51, 29 July 2018 (UTC)

Okay, I have seen the error of my ways and have converted British logistics in the Falklands War to putting SI units first (with the proscribed exceptions) per MOS:UNIT. Hawkeye7 (discuss) 20:30, 22 July 2018 (UTC)

Given that we have WP:GS/UKU which explicitly bars systematic conversion of UK-related articles between systems (because of the history of disruption caused by people doing that en massse), and given that measurement systems on Falklands-related articles have made it on to WP:LAME, I'm not sure that was a very good idea. Kahastok talk 20:37, 22 July 2018 (UTC)

Oh. I wasn't aware of WP:GS/UKU. I'm almost the sole author of the article, which is at FAC. Hawkeye7 (discuss) 23:56, 22 July 2018 (UTC)

Zoiks. GS/UKU needs to be mentioned in the guideline, at least in a footnote. I've been here for 12+ years and wasn't aware of that either, so we can't expect the average editor to know about it. — SMcCandlish ☏ ¢ 😼 05:29, 23 July 2018 (UTC)

Done [2]. — SMcCandlish ☏ ¢ 😼 06:32, 23 July 2018 (UTC)

Probably a good idea. Kahastok talk 20:08, 23 July 2018 (UTC)

FWIW: if there's consensus at FAC for the change, go for it. If there's consensus anywhere else for the change, go for it. For my part, if I objected I'd have given you the formal warning, not a suggestion on MOSNUM talk. A major aim of the general sanctions is to prevent people going from article to article to article flipping every one to their preferred system - something that has happened on a massive scale in the past. This is clearly not what is happening here. Kahastok talk 20:08, 23 July 2018 (UTC)

NASA's so-called style guide is a profound disservice to humanity. Tony (talk) 05:01, 23 July 2018 (UTC)
Yeah, WP doesn't follow the NASA style guide, even in articles about NASA. Their advice on this particular matter is a reason to include mention of the original unit in many cases, but not to lead with it. It's written from a context of doing primary (original) research, which WP does not; the idea that unusual or obsolete units "can serve as important internal evidence for the original date and source of an otherwise unidentifiable document" doesn't apply here. We do not rely on subtle textual cues to indicate what our sourcing it, we cite it directly and explicitly. — SMcCandlish ☏ ¢ 😼 05:27, 23 July 2018 (UTC)
Expanding on  SMcCandlish's comment, if mentioning a source value that includes chains interrupts the flow of the text too much, the value can be given in the citation; this may be helpful if using endnote citations but less helpful if using parenthetical citations. Jc3s5h (talk) 11:22, 23 July 2018 (UTC)

Scottish chain and other chains

Do we have a source for the repeated claim that in Scotland the chain is 74 feet as distinct from the proposition that once upon a time(before the Weights and Measures Act of 1824?) there was a Scots chain of 74 feet? Before customary measures were standardised throughout the UK, there was indeed a Scotch chain and its length was indeed equivalent to 74 yards; but if we cannot use a modern customary unit because two hundred years ago the word used to mean something different in Scotland we hit the slight problem that in both Scotland and England there were 80 chains to the mile and the Scotch mile was longer than than the English one. Rjccumbria (talk) 17:20, 18 July 2018 (UTC)

Rowlett's Dictionary of Units defines a chain as 22 yd, 100 ft or 20 m. Whether 74 ft happens to be in use today seems a little academic, but if I were looking for a source I would try Chain (unit), where I see 55.5 ft and 20.2 m both mentioned as in "contemporary use". Assuming that article provides references for both, we would then be able to source five different values: 55.5 ft, 66 ft, 100 ft, 20 m, 20.2 m. Take your pick. Dondervogel 2 (talk) 17:46, 18 July 2018 (UTC)

I refer you to my post of 09:38, 14 July 2018 at WT:UKRAIL. --Redrose64 🌹 (talk) 19:13, 18 July 2018 (UTC)

According to Tables for converting Scottish land measures & rates into imperial compiled under the direction of the Scottish Society of Land Surveyors (Edinburgh, 1826, p. iv) there were two chains in use in Scotland, 74 ft and 74.1196 ft. Jc3s5h (talk) 19:22, 18 July 2018 (UTC)

@Dondervogel 2: That would be 100 links (of 7.92") not 100'. Martin of Sheffield (talk) 22:34, 18 July 2018 (UTC)

Verbatim text reads "American surveyors sometimes used a longer chain of 100 feet, known as the engineer's chain or Ramsden's chain". So 100 ft is claimed but in past tense. That still leaves 4 different definitions in use today. How ambiguous can you get? Dondervogel 2 (talk) 22:59, 18 July 2018 (UTC)

Considering that the discussion is about lengths on British railways it might be germane to quote the whole entry:

a unit of distance used or formerly used by surveyors. Although the unit is not often used today, measured distance along a road or railroad is commonly called chainage regardless of the units used. The traditional British surveyor's chain, also called Gunter's chain because it was introduced by the English mathematician Edmund Gunter (1581-1626) in 1620, is 4 rods [1] long: that's equal to exactly 1/80 mile, 1/10 furlong, 22 yards, or 66 feet (20.1168 meters). The traditional length of a cricket pitch is 1 chain. Gunter's chain has the useful property that an acre is exactly 10 square chains. The chain was divided into 100 links. American surveyors sometimes used a longer chain of 100 feet, known as the engineer's chain or Ramsden's chain. (However, Gunter's chain is also used in the U.S.; in fact, it is an important unit in the Public Lands Survey System.) In Texas, the vara chain of 2 varas (55.556 ft) was used in surveying Spanish land grants. In the metric world, surveyors often use a chain of 20 meters (65.617 ft). See also shackle and shot [2] for anchor chain lengths.

- there is only one relevant definition: 4 rods = 1/80 mile = 1/10 furlong = 22 yards = 66 feet, and it has been this way for 400 years. As well as railways and cricket pitches, it is part of the original definition of the acre: 1 furlong (ie furrow length) x 1 chain, or supposedly the area one man can plough in a day. It's the sort of thing I remember learning by rote at age 10 so ought not to be too difficult for our readers. Martin of Sheffield (talk) 12:49, 19 July 2018 (UTC)

You challenged my assertion that a chain can be 100 ft. I quoted the text relevant to that point. The rest of the definition is useful though because it makes clear that the metric definition of 20 m remains in use. In addition there's the engineer's chain, which is 100 ft. At the very least any use of the chain needs to distinguish between these 3 possibilities (20 m, 22 yd, 100 ft). Dondervogel 2 (talk) 14:10, 19 July 2018 (UTC)

Just for giggles, this site lists five kinds and five lengths of chains, and that doesn't include any Scottish chains. - Donald Albury 16:58, 19 July 2018 (UTC)

It's a website based in India, and so not relevant here. Only one chain is used in measuring British railways: that of 22 yards or 1/80 mile (and when {{convert}} is given the |lk=in parameter, our article chain (unit) is linked, which explains this). If you have sources which state that some other length of chain was used for railway work in the UK, please provide it. Otherwise, please stop trying to muddy the issue. --Redrose64 🌹 (talk) 20:15, 19 July 2018 (UTC)

The ambiguity in the word chain (when used as a unit) is very relevant here. Another problem is its unfamiliarity. These two reasons combined are why many editors are not comfortable with seeing chains used in preference to other units that are both more familiar AND less ambiguous. I do not object to the use of unfamiliar units in principle (on the contrary, I applaud them where they help to reduce ambiguity), and I would support a proposal that addresses both concerns. Some suggestions:

Can the ambiguity be addressed by always linking to Gunter's chain instead of Chain (unit)?
Can the unfamiliarity be addressed by citing the distance in miles (or km) first?

Dondervogel 2 (talk) 21:01, 19 July 2018 (UTC)

The first is a matter for Template talk:Convert. The second is simply untrue - we write {{convert|1|mi|23|chain|km|lk=in}} which emits 1 mile 23 chains (2.1 km) and there is no way that you can claim that I am "shoving chain into the reader's face before the mile". --Redrose64 🌹 (talk) 21:05, 19 July 2018 (UTC)

My apologies for the hasty and inappropriate choice of words (I was more careful when rephrasing as a question), but I simply don't agree that your proposal addresses either concern (and I am not alone). I can agree to something like 1.3 mi (2.1 km; 1 mile and 23 chains). The important thing is to a) start with a familiar unit (mi or km - avoid chains in primary unit) first and b) when the reader reaches the chain, make sure it is apparent that it is equal to 22 yd. Dondervogel 2 (talk)

The days of the old school yard
-E **Eng**

I think there is a misunderstanding here. To anyone of a certain age born in Britain (and we are still here!) the chain is totally familiar as part of the standard set of units of linear measure: 12 in. = 1 foot; 3 feet = 1 yard; 22 yards = 1 chain; 10 chains = 1 furlong; 8 furlongs = 1 mile. This is "the" (English at least) chain, and it is not normally known as "Gunter's". (It's also of course the length of a cricket pitch.) I do not honestly see a good rationale for "Gunter's chain" being a separate article at all - I guess this is simply the origin of the chain unit, and should be part of that article. (See Blackburn (1825) p. 5.) Imaginatorium (talk) 09:54, 21 July 2018 (UTC)

Unless you have a suggestion to improve mosnum, a better place to comment would be Wikipedia_talk:WikiProject_UK_Railways. Dondervogel 2 (talk) 10:40, 21 July 2018 (UTC)

I'm of a similar 'certain' age (50+) but born in Australia. While I know inches, feet, yards and miles (we changed to metric in the 1970s when I was a boy), chains are completely unfamiliar to me. My father would probably know but I don't. I would assume that a great many non-UK readers would be in a similar position of not knowing what a chain is or that there are multiple definitions. To me, chains are a foreign word like the Indian crore but with ambiguity. Stepho talk 10:51, 21 July 2018 (UTC)

Stepho-wrs, we must be about the same age; mine was the very last first-grade class in Victoria to learn imperial as well as metric. We only got as far as ounces, pounds and stones, and inches, feet, yards and chains, before word came down from Mt Sinai and the syllabus changed to metric only. All we learned about chains was that a cricket pitch is one chain long. But it was taught. Hawkeye7 (discuss) 20:24, 22 July 2018 (UTC)

I went to school in the UK since the education system was changed to metric. We weren't formally taught imperial units at all - but inevitably in non-technical subjects they were used informally as teachers were old enough to prefer them.

But once we got home, the sorts of things we learnt from our parents tended to be imperial. When the culture uses feet and inches to measure height, children pick them up. And when your main experience of how far things are is from road signs in miles, you tend to end up preferring miles over kilometres.

But that only applies to units that are actually common currency. I didn't know what a chain was - how long, how many to a mile - until I came across this discussion. And if you'd asked I'd have probably said something closer to 100 yards than 22. Kahastok talk 20:40, 22 July 2018 (UTC)

That is exactly why a conversion to more familiar or SI units should follw the original. Consider: '"On Ilkla Moor Baht 'at" (Standard English: On Ilkley Moor without a hat)' and compare to 22 miles 39 chains (36.2 km). In both cases an unfamiliar term is presented as the original, and then translated/converted for the benefit of those unfamiliar with the historic local usage. The only ambiguity is from those who are seeking to confuse with obscure local variants. The surveyor's chain has been standardised for around 400 years. Martin of Sheffield (talk) 19:46, 21 July 2018 (UTC)

Standardised as 66 ft, 100 ft, 20 m, 74 ft, 55.5 ft, 20.2 m or 74.1196 ft? If we not sure which standard it is then it isn't really standardised. But at least the km figures remove the ambiguity for those that want to do some arithmetic.

Regardless, the guideline says SI first, with certain nation strong ties exceptions. That seems to apply to the the entire article. So either the entire article has SI first or the entire article has SI second. I don't see why specific sentences should be different. Stepho talk 22:55, 21 July 2018 (UTC)

This is not what the text of WP:UNITS says, nor what it is intended to mean, nor how it is applied in practice. There is no earthly reason why the fact that a distance is in miles should have to mean that all the temperatures have to be in Fahrenheit. Kahastok talk 08:14, 22 July 2018 (UTC)

Standardised at 66 feet/22 yards/one-tenth of a furlong, since at least the Weights and Measures Act 1824 and probably even earlier. --Redrose64 🌹 (talk) 16:05, 22 July 2018 (UTC)

Gunter's chain of 22 yards as used for surveying until recently dates from 1620. Martin of Sheffield (talk) 20:43, 22 July 2018 (UTC)

Is there a proposal regarding chains related to this page in particular? If not, can I suggest this move to the project talk page to keep all the discussion on the whys and wherefores of chains together? Kahastok talk 21:41, 19 July 2018 (UTC)

That's where it started but David branched it here, presumably to seek views from a different set of editors with different priorities. Martin of Sheffield (talk) 21:44, 19 July 2018 (UTC)

There's no proposal specific to chains on this page. David Eppstein informed mosnum editors of the debate at UK railways and the discussion continued at UK railways. Then Jc3s5h made the more general point here out that a long-standing consensus that order of units should be maintained throughout an article had never been made explicit. That point was being debated on mosnum when the Scottish chain reared its head and the discussion went off on a tangent. The discussion would not be out of place at Chain (unit). Dondervogel 2 (talk) 23:24, 19 July 2018 (UTC)

Clean up of Chain (unit)

See Chain (unit) talk page for a new discussion on improving that specific article. Dondervogel 2 (talk) 11:32, 21 July 2018 (UTC)

And so... we are where?

? E Eng 05:40, 5 August 2018 (UTC)

Reading the above, I see consensus that the only definition of "chain" relevant to UK railways is 22 yards, and consensus that chains are relevant to UK railways. There is possibly consensus that further discussion about chains and UK railways articles should take place elsewhere but that's less certain. I don't see consensus for anything else. Thryduulf (talk) 13:18, 6 August 2018 (UTC)

There remains the open question of whether to make explicit the (perceived) consensus for a consistent order for unit conversion: If you start with distances in miles to kilometres, you stick with Imperial to metric throughout, and do not switch to metric to Imperial for the height of a tree just because the only source is a newspaper article reporting this quantity as 3.4 metres. I would support such a change myself. Dondervogel 2 (talk) 08:44, 7 August 2018 (UTC)

This is probably best in another section, but I generally agree with consistent order as default while acknowledging that there are many reasons why both orders might be used (a structure designed in imperial being replaced with one designed in metric being the first example that comes to mind; sources using different systems for different dimensions is not uncommon in the UK, e.g. quoting the dimensions of a car in metric and its top speed in mph). What we ideally want to avoid though is examples like I stumbled across at Pride Park Stadium#Construction the other day "The pitch stood at 105 metres long and 68 metres wide, meeting the requirements for an international venue, and measured five yards longer and four yards wider than the pitch at the Baseball Ground. It also came with a three-metre grass margin." I've added convert templates to the measurements, but haven't changed the order as yet nor looked for citations. Thryduulf (talk) 10:08, 7 August 2018 (UTC)

It would be cleaner to start a separate entry, but the advantage of keeping it here is to keep it together with the existing discussion initiated by Jc3s5h. Yes, there would be exceptions but a statement of the general principle would be an improvement IMO. Dondervogel 2 (talk) 10:44, 7 August 2018 (UTC)

I suggest the following underlined addition, with some of the existing material quoted to show where the addition goes:

Generally, the order of presentation should be consistent throughout an article for each physical quantity such as length, mass or pressure. Consistency between different physical quantities as to SI being first or not is not required; an article could give heights with centimeters first but give blood pressure with millimeters of mercury first.
In non-scientific articles relating to the United States, the primary units are US customary, e.g. 97 pounds (44 kg).

Jc3s5h (talk) 12:12, 7 August 2018 (UTC)

I worked for 20 years with a documentation house style which required that all significant data should be supported by a reference, and data imported from a reference should first be given in the form it appeared in the reference, conversion to the preferred units being subsequent (and explicit). (This meant that reference checking could be a simple matter of checking that number and units were as given in the reference). Perhaps because I conformed to that for so long, it strikes me as a excellent discipline for verifiability purposes. If it is thought undesirable on stylistic grounds, how is verifiability (which I would have thought of somewhat higher priority) to be ensured? The problem seems to me greatest with 'obscure' measures (especially deeply obscure, not to say downright problematical, ones like 18th century measures of quantities of coal ) Rjccumbria (talk) 13:48, 7 August 2018 (UTC)

Well said! Common sense really. Martin of Sheffield (talk) 14:31, 7 August 2018 (UTC)

No, because then you end up with a distance measured in miles in one sentence and kilometres in the next. Readers shouldn't be noticing the units.

Per WP:CALC, you don't lose verifiability just by changing the unit any more than you lose verifiability by changing the text. If it is really necessarily to know what the source said, you can use the order=flip option on {{convert}} and/or give the original measure in the reference. Kahastok talk 21:35, 7 August 2018 (UTC)

Perhaps you've overlooked the point that a conversion should follow the quoted source? Readers are not as stupid as some here seem to think, it really is a bit insulting to assume they can't compare 2 miles 4 chains (2.05 mi; 3.3 km) to 6 kilometres (3.7 mi). Rjccumbria's point was that the original unit should be quoted first, then conversion to more familiar or common units follows. To suggest that "Readers shouldn't be noticing the units" is an interesting position, what else are they forbidden to notice? Martin of Sheffield (talk) 22:26, 7 August 2018 (UTC)

I am agreeable to this addition, as {{Convert}} handles some case where verifiability is a question. Regarding the specific issue here, here is an example if you want miles and chains in the output: 8.1 kilometres (5.03 mi; 5 mi 2 ch); and here it is if you don't: 8.1 kilometres (5.03 mi). (I could also order it such that miles are outside.) Either way, all of the hullabaloo about this from a verifiability perspective really is moot. As for "source order is relevant", that is quite a bit different use from a general encyclopedia, which will have other kinds of units within the same context and physical quantity. --Izno (talk) 14:51, 7 August 2018 (UTC)

I believe a general purpose encyclopedia should use consistent unit order throughout an article. That is especially true for Wikipedia, where changes to the citation is not rare; most customs in writing academic articles comes from a tradition of publishing a fixed version of the article, and any changes are made by publishing errata in a separate, later, article or letter to the editor. That does not describe Wikipedia.

While giving the source unit first may be traditional in some fields, such as history, or any field where the main approach is to pick apart historical documents piece by piece, that isn't what we do at Wikipedia. Try reading some astronomy journal articles. Units are changed from sources with no mention; readers are presumed to be capable of checking the conversions.

If the conversion is the least bit tricky, it would be best to quote the original value in a footnote and explain how the conversion was done in the footnote. Ideally the citation style would be done in a way that the footnote itself can contain citations; that may be needed if the conversion is tricky. Jc3s5h (talk) 17:23, 7 August 2018 (UTC)

Verifiability is not just a 'hullabaloo', nor is the issue chain-specific, so please don't let positions adopted in that kerfuffle dictate responses on the more general question. As has been noted in the chain affair, we are not writing for a specialist readership, so the analogy with astronomical journals where "readers are presumed to be capable of checking the conversions" surely doesn't really work. And conversions are, as I noted above, sometimes not just tricky, but problematical. Since the point doesn't seem to have been taken , here is chapter and verse. In the West Cumbrian coalfield in the 18th century, the ton was a measure of volume, but the ton at the pithead was a different ton from that at the quayside, and that was different from the displacement ton used for ships. The 'shipping ton' was estimated in 1695 to be about 14 hundredweight but in 1735 it was estimated to be 17 hundredweight, putting the pithead ton at 21 cwt; an investigation in the 1870s by a very early industrial archaeologist put the current wagonload (traditionally nominally 2 pithead tons, although the volumetric ton had been abolished 40 years earlier) at about 44 hundredweight. Most of the coal was exported to Dublin, where there were different customary units, and one of the best accounts of the shipping operations is given in a paper read to a Dublin learned society; one of the best accounts of the mining operations was written by a visitor from Scotland (whose customary units were also different). Quite independent of the appropriateness of having 18th century writers use metric (or imperial) units which were not yet in use, it therefore becomes very difficult to identify the lead unit in which all coal quantities should be reported, since the conversion to modern units is uncertain. Regards Rjccumbria (talk) 18:38, 7 August 2018 (UTC)

If you're quoting, you preserve the quote. It sounds to me that in the context you describe, it is most useful for the user to simplify all the different measures into a single system, based on secondary sources. And you really feel that the original measure has to be somewhere because the conversion is not simple, put it in the reference. Kahastok talk 21:41, 7 August 2018 (UTC)

The problem with the proposed wording is that I read it to mean the opposite from what Izno did. If we had sources that give some lengths in chains, and some in kilometres, then I would comply with the proposed text by converting the kilometres to miles and chains so the physical units are always expressed the same units ie 5 miles 2 chains (8.1 km) and 8.1 kilometres (5 mi 3 ch). Hawkeye7 (discuss) 19:10, 7 August 2018 (UTC)

I don't think we interpreted it differently--I'm just of the opinion that we should use a more-modern unit (whether miydft or [k]m) outside the parentheses and so my examples reflected that, because it's likely that other cases of the same physical quantity will be expressed that way. I guess from that point of view the suggested revision doesn't go far enough. I guess the second sentence is trying to say that but it presumes metric units (which I don't mind but which I'm not sure is presumed elsewhere in this guideline--pretty sure it is). --Izno (talk) 20:12, 7 August 2018 (UTC)

Please don't use rhetoric that confuses further- more-modern unit- Chain is current on UK railways you can't get more modern than that. Look at all the trackside plaques- they are still being screwed up each time one is damaged (bridge strikes). miydft- is a red herring- it is not used- all non SI units require a conversion right across WP. Here it is simplicity itself- source is in miles chains, and rendered text needs a {{convert|5|mi|2|ch|km|lk=on}} such as 5 miles 2 chains (8.1 km). ClemRutter (talk) 22:18, 7 August 2018 (UTC)

I must oppose this proposal as-is.

I do not see why order needs to be kept consistent for the same physical quantity within an article except where the reader is (explicitly or implicitly) invited to compare measurements. If I measure a distance between two towns in one section, I see no special reason why that should affect the unit I use for the height of a tree five sections later when discussing a completely different aspect of the topic.

If the wording is made narrower, I would reconsider. One might say that measurements in the same context should be consistent. But, that said, they should be anyway. The system we tell people to use will nautrally result in consistent measures in any given context. Perhaps a better solution would be to broaden the rule on defined units to include measures directly compared against the defined unit.

I'd also note that I find the phrase "Consistency between different physical quantities as to SI being first or not is not required" awkward, particularly given that the example gives quantities based on centimetres and millimetres. It took a couple of goes through to work out what meaning was intended. Kahastok talk 21:58, 7 August 2018 (UTC)

I also want leeway to use the unit of measurement primarily used in the sources. Using SI units first sometimes ends up with an inaccurate or over-precise number being shown first. I recently was adding the area of a geographic unit to its article. As it happened, one source gave the area as 40,000 ha, another had 100,000 acres, obviously both rounded-off estimates. Using {{convert|40000|ha|acre}} gives 40,000 hectares (99,000 acres), which gives the impression of a more precise estimate, and does not agree with the source. I also looked at {{convert|100000|acre|ha}}, which gives 100,000 acres (40,000 ha), in agreement with both sources. I settled on {{convert|40000|ha|acre|sigfig=1}}, which yields 40,000 hectares (100,000 acres), also in agreement with both sources. I was lucky that was easy to fix. I feel that the numeric value of a unit should match what is found in a source, and converting such units to SI, and then feeding the SI result back through the convert template can give off-results. Adjusting the output number to match a source by adjusting the input number may take extra time and effort. If you skip the convert template and manually enter the number and unit from the source, someone is likely to come along and put the convert template in. - Donald Albury 15:12, 8 August 2018 (UTC)
You can't expect a convert template to summarize several values from different sources. The editor must manually figure out a way to do that. In the case of displaying acres first when the source gives hectares, the template could be written {{convert|40000|ha|acre|order=flip|sigfig=1}} which would produce 100,000 acres (40,000 ha) Jc3s5h (talk) 15:37, 8 August 2018 (UTC)
Or are we allowed to forget about using {{convert}} and just write that out manually as 100,000 acres (40,000 ha)? PamD 16:06, 8 August 2018 (UTC)
Or are we allowed to forget about this whole sorry mess, give the measurement exactly as shown in the source, indicate what our source is, and to heck with conversions. Look, I'm serious here: if anybody has a problem with me abiding by our core content policies, they can take me to WP:ANI and live with the consequences. OK? --Redrose64 🌹 (talk) 18:19, 8 August 2018 (UTC)

Well no, unless you want people to start mass-converting topics to their preferred system (including railways), because they found an inferior source that uses that system. At best, you're asking people to directly compare two measurements, in different systems. 5 seconds, no looking it up or Googling - which is larger, 4500 metres or 15000 feet?

Do you also think articles should also just use the form of English and date format directly from the source? Is that also required to maintain WP:NOR? And then we get American editors replacing every instance of "railway" on UK-related articles with "railroad", because that what they found in the source that they were using.

Let me put it another way. If you push that, and the general sanctions ever get lifted, you will spend most of your editing time re-arguing this point. Over and over again. Wait three weeks. Maybe consensus has changed now? No? Wait three weeks. What about this time? Wait three weeks. What about this time? Wait three weeks. What about this time? Wait three weeks. What about this time? Wait three weeks. What about this time? Wait three weeks. What about this time? Wait three weeks. What about this time? Wait three weeks. What about this time? Wait three weeks. What about this time? Wait three weeks. What about this time? Wait three weeks. What about this time? Wait three weeks. What about this time? Wait three weeks. What about this time? You think this is getting repetitive yet? This isn't even getting started.

I've been there. I know how persistent our metric warriors get. You don't want that? Don't push for source-based units. There are very good reasons why it's been rejected so many times here. Kahastok talk 21:03, 8 August 2018 (UTC)

When the policy on verifiability gets repealed, let me know. Until that happens, I shall abide by it. Here is an example; revert that at your peril. --Redrose64 🌹 (talk) 22:29, 8 August 2018 (UTC)

Nothing in the policy on verifiability, or anywhere else in policy, requires that you adopt the style choices of your sources. In fact, multiple policies and guideline (including WP:ENGVAR, WP:CALC and WP:UNITS) take the precise opposite view.

Not that I am not telling you - and have never told you - that you should not use chains. Only that you need a good reason to do so. There are good arguments you can make in their favour. But the argument you are actually making is utter tripe, because anyone can look at WP:CALC and see that your interpretation of policy is - unambiguously, irrefutably - wrong.

As to your change, I think it's probably a good moment to formally notify you of WP:GS/UKU on your talk page. Kahastok talk 17:21, 9 August 2018 (UTC)

Query, doubtless not the right place for it, but WP:UNITS allows for all other articles " ...such other units as are conventional in reliable-source discussions of the article topic". There is no similar phrase in the preceding section covering non-scientific articles relating to the United Kingdom. Common sense would suggest (to me at least) that there should be; is there a reason why there isn't ? Rjccumbria (talk) 17:57, 9 August 2018 (UTC)

Right back at you, Kahastok. Now, are you going to open an ANI case on me, or what? --Redrose64 🌹 (talk) 18:08, 9 August 2018 (UTC)

Why would I do that? As I've pointed out several times now, I don't have a problem with your edit. All I'm saying is that if you want to use chains you should justify them with an argument that can't be refuted with the seven characters "WP:CALC". It isn't difficult to do. But you're not doing it. Kahastok talk 18:47, 9 August 2018 (UTC)

(edit conflict)Kahastok. Are you seriously suggesting that a discussion held on Bonfire Night in 2014 has any relevance here? Do we even have a list of the participants? Are they still active? That sounds to me like passive aggression. Are you seriously suggesting that an editor who is maintaining an established standard should be have to put up with all this non-productive bureaucracy, when he is protecting high quality articles from a stream of good faith experienced editor parachuting in, who have not read the back history and propose a stream of unworkable solutions? On encountering this conumdrum I did attempt to find where the problem arose- and it appears to go back to 1620, and many of our articles reflect it. This has been discussed before. Luckily all UK rail assets have a WP:R references, and they all use the normal mi/ch format- and as my photographs show, all assets have mi/ch plaques- passive agression will not change this. We could debate whether the plaque is a primary or secondary source and whether a photograph is secondary. Could we just get on writing an encyclopedia?ClemRutter (talk) 18:56, 9 August 2018 (UTC)

I don't know which discussion you're talking about. I am certainly suggesting that editors ought to follow WP:UNITS insofar as it is appropriate to do so. Attempting to subvert the MOS by applying a completely different standard (e.g. use whatever units the particular source uses) is disruptive, but in this case (as I've pointed out about 15 times now) it's perfectly possible to get the same result with an argument that complies with the guideline. I genuinely don't understand why you are getting so worked up about that. Kahastok talk 19:34, 9 August 2018 (UTC)

Actually there is a similar wording: "or other internationally used units". But the fact that it's less clear is probably because it was rewritten so that the "all other articles" went from being a general rule that was applied with exceptions, to one of three rules to be applied depending on article. Kahastok talk 18:47, 9 August 2018 (UTC)

Mixed sources

In terms of mixed units presented in sources, I present paragraph 8 from RAIB report 11/2018 Near miss with a group of track workers at Egmanton level crossing, Nottinghamshire published today (9 August 2018):[3]

The incident occurred around 30 metres north-west of Egmanton level crossing which is located on the East Coast Main Line (ECML) at 130 miles 29 chains from London Kings Cross. The location is between Newark North Gate station to the south, and Retford station to the north.

(emphasis mine). If I were to add this to an article I would add conversions to both units but I wouldn't change the order of either. Thryduulf (talk) 18:22, 9 August 2018 (UTC)

Which is fine per the rule - because 30 metres is a distance "where miles are too large for practical use" and 130 miles 29 chains is in "the system of units that the topic was drawn up in". Kahastok talk 18:47, 9 August 2018 (UTC)

@Kahastok: You said As to your change, presumably relating to this edit. Check the page history. It was in miles before the IP altered it to kilometres only (and gave an inaccurate unsourced figure to boot) - so if you're going to template somebody for altering units, make sure that you get the right person. I initially altered it back to miles, but before saving, I decided to check the figure, and because I knew that somebody would doubtless pounce on my edit, I looked for a source for the actual distance. The sources that I have - all three of them - give the distance in miles and chains (I only added one source - I can add both of the others if you like). You clearly have a problem with me giving the distance of a station in miles and chains, but judging by your comment of 18:47, 9 August 2018 (UTC), you don't have a problem with Thryduulf (talk · contribs) giving the distance of a level crossing in precisely the same units. Where is the logic in that? Either retract the notice that you served on me, or serve the same notice on Thryduulf. See where that gets you. --Redrose64 🌹 (talk) 21:13, 9 August 2018 (UTC)

The reason I gave you a notice is that your edit summary in that edit implied that you were going to systematically start changing existing units on articles. I wanted you not to do that, because it might get you blocked. And I wanted you to know why. Would you prefer it if I'd let you start doing a mass-modification, and then you got blocked without warning because of a general sanction you weren't aware of? I mean, if you'd like to make a declaration on your talk page saying that notifications are unnecessary and you're happy just to be blocked based on decisions you haven't been told about, I'm sure admins won't mind. But personally, I prefer to have some warning.

This is not the first time I have pointed out that I don't object to chains per se. I said so in the RFC on several occasions. I've said it in most of the comments I've made here. There are perfectly good arguments that naturally lead to your project using chains under this rule. I have articulated those arguments on several occasions. I suggest you go back and reread my comments and you will see that point made, repeatedly, despite your insistence to the contrary.

There is no inconsistency between WP:UNITS and the notion of WP:UKRAIL measuring distances in chains. None. If you do it based on what WP:UNITS tells you to.

What I object to is your argument that you should somehow abandon WP:UNITS in favour of a system that has caused us an extraordinary amount of grief in the past, based on a misapprehension of WP:V that directly contradicts WP:NOR. And the reason I object is because I don't want your topic to go through the sort of shit that paralysed one of my preferred topics for half a decade. Kahastok talk 21:37, 9 August 2018 (UTC)

Enough. WP:ANI is thataway. --Redrose64 🌹 (talk) 22:53, 9 August 2018 (UTC)

Editing cooperatively

@Kahastok: You said I genuinely don't understand why you are getting so worked up about that. I wouldn't have raised it unless you had but I do believe you. I see from your last post that you have been involved in long dispute in the past- presumaly acting a white knight in an five year edit war. However that was in the past and your good intentions are causing at least three experienced editors to get very 'worked up'. Reading between the lines the end result you are seeking seems to be near identical to the consensus of the editors who have the reliable sources and have written furlongs (metres) of text on UK Railway issues.

The issue, I am afraid is your approach, threats and obscure procedures do not influence people who are working in this area. Throwing around WP:CODES, only works when the reader is nervous and cannot backup his facts. To have suggested to Redrose64 (talk · contribs) that he should get a warning, then calling his arguments utter tripe is one way to work up an editor. To call someone arguments utter tripe ten lines after pasting the text What about this time? Wait three weeks. multiple times does not display the maturity that one expects on UK Railway issues. Yes, you have seriously caused many editors to get worked up.

The issue was nearing resolution- I suggested earlier that we asked User:Redrose64 to take the lead and word a proposal, which has been done, and was done taking all policies into consideration and then tweak it is necessary. You had a minor concern, that could be considered, and if that were a genuine issue could be integrated. That of course is now in abeyance until you have reconsidered your actions and withdrawn your notice. Then, please stay around and help improve UK Railway articles, working in the manner that Wikipedia intended. ClemRutter (talk) 23:36, 9 August 2018 (UTC)

If you wish to edit cooperatively, I suggest you comment on the content, not the contributor. The above invective is not compatible with any asipiration of "editing cooperatively".

There are general community-agreed sanctions in place that affect this discussion. You seem to demand that I unilaterally withdraw the general sanctions, or else that I de-inform people of them. I can no more de-inform a user of the sanctions than I can de-inform a user of an AFD on an article that they have edited. And if I tried, it wouldn't stop a block if said user were to break the general sanctions, any more than it would stop the article deletion. Note that informing people of general sanctions explicitly does not suggest any misconduct on their part.

My aim here is to make your position at WP:UKRAIL compatible with WP:UNITS - and hence more robust, less open to future challenge and more likely to be stable, to the long-term benefit of Wikipedia overall and WP:UKRAIL in particular. You can do that by, instead of adopting "the measurement exactly as shown in the source", adopting "the system of units that the topic was drawn up in" or the units that are "conventional in reliable-source discussions of the article topic" (i.e. adopting the convention that consensus accepts exists, not necessarily the usage of the precise source) - both wordings taken directly from WP:UNITS. And both of which may well be chains.

This also has the side benefit that if and when someone comes along with a source using a different unit (say, a French source from when Channel Tunnel traffic used the standard rail network before HS1 was finished), you can cite a consensus that overrides that usage with the standard convention. I would like to engage cooperatively on this point, but so far mostly what I'm getting is posts telling me where WP:ANI is and telling me what an evil person I am. Kahastok talk 12:05, 11 August 2018 (UTC)

Clarification on using `{{convert}}` on nuclear weapons articles for yield

The Manual of Style isn't clear (and I guess this could become a new proposal) and I'm having a bit of a problem. I've noticed on some articles for nuclear weapons someone has gone in and added {{convert}} to weapon yield. The article on the WE.177 for example has "10 kilotonnes (9,842 long tons; 11,023 short tons) or 0.5 kilotonnes (492 long tons; 551 short tons)" and similar is several sections. Besides being ugly as sin, what exactly is the point? I don't think anyone calculates nuclear yield (or any other explosive yield) in long or short tons. The universal measurement is kilotons and Joules. My first instinct was to immediatly change it, but looking at the manual of style I'm not exactly sure. "In science-related articles, however, supplying such conversion is not required unless there is some special reason to do so" suggests I could, but I'm not sure if an article on a military weapon counts as science.

Perhaps we could have a new proposal to us SI units when SI is near universal? Or maybe some policy just for these pages could be created? Any suggests would be great as to what I'm supposed to do. Kylesenior (talk) 13:28, 11 August 2018 (UTC)

These conversions are utterly stupid in this context, and should be nuked. I also point out that the WE.177 article uses the word re-lifing so someone should do something about that. E Eng 13:37, 11 August 2018 (UTC)

I agree with EEng on the merits of converting here.

I think, other than the point on science-related topics that you suggest, the best advice in MOSNUM on this situation is in the first line of MOS:CONVERSIONS, emphasis mine: "Where English-speaking countries use different units for the same quantity, provide a conversion in parentheses" - the (intended) implication being that if English-speaking countries all use the same units for a given quantity, Wikipedia shouldn't provide conversions to other unused units. But we could be more explicit on this point.

I also think our current guidance could be improved at the bullet "Generally, conversions to and from metric units and US or imperial units should be provided, except". This is intended to introduce two other particular exceptions to the general rule to provide conversions, but wording it like that implies that it's an exhaustive list. I would suggest that we could replace it with: In some circumstances, conversions may be inappropriate:. Kahastok talk 13:42, 11 August 2018 (UTC)

I think a conversion is appropriate here, but to joules. Surely the solution is to tell {{convert}} that it's dealing with a unit of energy, not mass. Dondervogel 2 (talk) 15:56, 11 August 2018 (UTC)

{{convert}} could be used in this article provided the correct code for the unit to be converted is used: ktTNT. In the general case, conversions must always be performed on the fully stated unit of measure, not any sloppy shortened form commonly used. Another example is "yards" being short for "cubic yards" when discussing concrete. Jc3s5h (talk) 16:20, 11 August 2018 (UTC)

Yes, you should really use the template. I see you've put in manual conversions, but you're off by 1000. All those GJ should be TJ. Kendall-K1 (talk) 21:48, 11 August 2018 (UTC)

Ah well, what's a factor of 1000 between friends? (but thank you for pointing out the error) Dondervogel 2 (talk) 22:31, 11 August 2018 (UTC)

Kiloton of TNT is a unit of energy, not mass. This conversion is just wrong. It's like converting tons of air conditioning to kilograms, or ship tonnage to pounds, or fluid ounces to grams. Point me to those articles and I'll fix them myself. Kendall-K1 (talk) 21:40, 11 August 2018 (UTC)

While of course I accept the point that there are valid conversions here, I think it's worth considering the hypothetical nonetheless. There will be articles that use measurements that are not obviously scientific but that are the same in all English-speaking countries. I would maintain that, while we're all clear on what should happen in that case, our wording here could be improved. Kahastok talk 08:04, 12 August 2018 (UTC)

Not always the case. No English speaking country uses PS. However, car articles for Japan, Germany, France and some others still list power as kW, PS and hp.

Regardless, nuclear weapon yields have generous rounding that easily swamps the difference between short, metric and log tons, making the distinction pointless. A joules or calories conversion might still be useful though. Stepho talk 09:56, 12 August 2018 (UTC)

Should we be converting to PS if they are not used in any English-speaking country? Note that at present, I don't think MOSNUM would accept them. Kahastok talk 12:03, 12 August 2018 (UTC)

We definitely should avoid use of the abbreviation "PS" for metric horsepower. We should also avoid converting to calories for nuclear explosions - joules are just fine. Dondervogel 2 (talk) 12:37, 12 August 2018 (UTC)

Correct spelling?

The article in question now uses "kilotonne". The article TNT equivalent uses "kiloton" and does not mention any alternative spellings. Which is correct? Dondervogel 2 (talk) 22:34, 11 August 2018 (UTC)

A tonne and a long ton are very close to the same thing. But I bet you a large pepperoni pizza that the term was first used by American scientists in the 1940s and that they were thinking of US tons, not metric tonnes. I suppose a survey of the cited sources would be in order, but I'm not willing to do that myself. Kendall-K1 (talk) 01:05, 12 August 2018 (UTC)

I'm sure you're right about the original spelling, but since then almost all the English speaking world has metricated (if it wasn't already using metric units). Sure, the US hasn't, but this is a global encyclopaedia. HiLo48 (talk) 01:24, 12 August 2018 (UTC)

You win a pepperoni pizza. The Los Alamos scientists did devise it. Before the first actual nuclear detonation, the Trinity nuclear test. In fact, they detonated 100 tonnes (110 short tons) of TNT to calibrate the measuring equipment. The scientists used metric, which is why the US conventional units for fissile materials is grams and kilograms. Hawkeye7 (discuss) 10:16, 12 August 2018 (UTC)

The article should probably be using ton. Taking a look at the options for units in convert it lists kilotons and megatons. I'd suggest the SI units should be Joules. Kylesenior (talk) 04:52, 12 August 2018 (UTC)

I do not see kilotonne and kiloton as synonyms. The former is a unit of mass, while the latter is sometimes a unit of mass and sometimes of energy. IMO when talking of energy we should use kiloton, and update mosnum to say so. We should ~~also~~ find a symbol that distinguishes [a kilotonne of energy] from kt, which means 1000 tonnes. Dondervogel 2 (talk) 09:32, 12 August 2018 (UTC)

See for example this page from the European Nuclear Society, using "kt TNT" (and contradicting my previous assertion that kilotonne is necessarily a unit of mass). Dondervogel 2 (talk) 09:42, 12 August 2018 (UTC)

Or you could read the Wikipedia article on the subject, TNT equivalent. Kilotons of TNT are a measurement of energy, not mass. It is not quite the same as the power of a tonne of TNT - see the article for the explanation. Hawkeye7 (discuss) 10:12, 12 August 2018 (UTC)

I'd suggest kt_{TNT Eqv} and Mt_{TNT Eqv}, or just kt _TNT would work well to distinguish between mass and energy. Kylesenior (talk) 11:12, 12 August 2018 (UTC)

Be careful about "kt", it is a common abbreviation for knot as endorsed by the IEEE and United States Federal Aviation Regulations though not by SI who prefer "kn". You'd probably have to work hard to get a situation where kilotons and knots could be confused though! Martin of Sheffield (talk) 16:08, 12 August 2018 (UTC)

Yes, but if you succeeded in that confusion the result could by cataclysmic. E Eng 16:14, 12 August 2018 (UTC)

Yes indeed. On the day they're instructed to fire a 20 kt missile let's hope they choose the gold-plated one. Dondervogel 2 (talk) 17:13, 12 August 2018 (UTC)

Yes, gold plating can be an issue. --Izno (talk) 17:30, 12 August 2018 (UTC)

The noughties

Mae West, one of the naughtiest of the late naughties
-E **Eng**

I am trying to improve an article, Churchill, Victoria, that uses the term "late noughties" to describe a time late in the period 2000 to 2009. That grates terribly with me, so I came to the MOS, especially MOS:DECADE, for something better. It hasn't really helped. (Maybe I haven't looked far enough?) Writing "the late 2000s" would be ambiguous. Does it mean 2008, or 2095? No other option suggested there seems to work either. Idea please? And can something be added to this section? HiLo48 (talk) 04:13, 9 June 2018 (UTC)

I'd just go with late 2000s, since for now that's unambiguous, given that events of the past are being narrated. Editors in the year 2095 can worry about what to do at that point. E Eng 05:04, 9 June 2018 (UTC)

Thanks for that. Love the pic. HiLo48 (talk) 06:02, 9 June 2018 (UTC)

The previous decade is referred to as the aughties by just about every American publication I've seen that refers to the decade in such shorthand. Naughties was considered somewhat seriously, but probably just somewhat, as an alternative, IIRC. Dhtwiki (talk) 19:01, 9 June 2018 (UTC)

Dhtwiki - Can you provide a link to any quality source using the term "noughties"? (In writing that I am reminded that my spellchecker disapproves of it.) Anything in Wikipedia? HiLo48 (talk) 23:53, 9 June 2018 (UTC)

Note: 0 says that 'nought' is UK English and 'naught' is US English. Stepho talk 00:38, 10 June 2018 (UTC)

Ah, wasn't aware of that difference. Thanks. The article I am working on is Australian. Australian English, while being recognised as a distinct variety of the language, is more like UK English than US English. The "Naughties" sound like they were a much more fun decade. HiLo48 (talk) 00:50, 10 June 2018 (UTC)

Yep, I'm Aussie too (WA). I remember in the late 90's the radio stations got all excited about what to call the next decade (noughties/naughties, nothings, oh's, etc) but then it fizzled out and nobody thought of it again. It never really got a name that stuck with a significant amount people. Stepho talk 02:24, 10 June 2018 (UTC)

@HiLo48: I have seen "aughts"—not "aughties", come to think of it—in The New Yorker and Harper's Magazine. An article in the first-named magazine is referenced at the "aughts" article, but it doesn't describe the usage they settled on, just the difficulty of coming to a conclusion on which term to use. However, it's my impression that "aughts" is the term generally used, at least in American journalism. So, possibly "noughts" would be the British English equivalent, "noughties" sounding like someone being a bit naughty. Dhtwiki (talk) 00:07, 11 June 2018 (UTC)

Using late 2000s isn't ambiguous, since the late 21st century hasn't happened yet. It's always fine to use "the first decade of the 21st century", something more specific like "from 2007 through 2010" or whatever, or some other approach. "The noughties" and "the aughts" are silly slang and aren't encyclopedic wording. — SMcCandlish ☏ ¢ 😼 23:07, 12 June 2018 (UTC)

It's possible to argue that the aughts are from '00 to '09, whereas the "first decade of the 21st century" is from '01 to '10. That shouldn't really matter for "late aughts", which seems deliberately slightly vague. But I don't know how you can be deliberately slightly vague with any of the "more specific" formulations, so it's not clear that there are any perfect replacements.

I also am not a big fan of "aughts", but I think maybe this is a case where the MoS can do best by saying nothing. --Trovatore (talk) 05:51, 14 July 2018 (UTC)

@SMcCandlish: What leads you to believe noughties to be a "silly slang" term (outside, perhaps, North American English)? 142.160.89.97 (talk) 03:00, 24 August 2018 (UTC)

The expression "late 2000s" doesn't pass WP:RELTIME, meaning: it will eventually become ambiguous. Will 80 years from now someone think about rewriting sentences that use such expression? And what would be the downside of doing such rewrite without further delay? As it happens, I WP:CHALLENGEd the entire sentence in the Churchill article, as possible WP:SYNTH. Find a reliable source for these assertions, without conflating if it is in separate sources. If a reliable source uses "late 2000s" or "noughties", there's always a possibility to quote literally, in quotation marks, with an in-text attribution that makes clear which noughties or 2000s are meant. --Francis Schonken (talk) 10:41, 6 July 2018 (UTC)

Let's invent Category:Articles with Y2.1k problems and rig some sort of atomic-powered alarm clock to draw attention to it around 2090. E Eng 12:10, 6 July 2018 (UTC)

Well I mean I have it on good authority that 80 years from now people won't be reading Wikipedia but instead downloading it directly into their brains thru an implanted USB port, and the software which converts all the text to Humano Unilingo will also handle conversions like these.
No human person in America uses the term "naught" or "aught" and many don't know what it means.
You can link 2000s (decade), altho you have to pipe it, if you think that will help (Narrator: it will).
You can also use the template {{Update after}} to alert the steam-powered Encyclopedia Editing Jennys of the future that the situation needs to be addressed.

Herostratus (talk) 04:42, 18 July 2018 (UTC)

Good ideas all, though if we're still using USB in 80 years God help us. E Eng 04:46, 18 July 2018 (UTC)

"Aught"/"ought" survives in American English in a few stock phrases only, like the pronunciation of .30-06 Springfield. "Naught" is most unheard here. — SMcCandlish ☏ ¢ 😼 03:32, 19 July 2018 (UTC)

"Noughties". en.oxforddictionaries.com. and it appears in a number of book titles listed by Google Books -- PBS (talk) 13:05, 15 August 2018 (UTC)

One of the books listed is:

Fotheringham, Richard; Smith, James (1 November 2013). Catching Australian Theatre in the 2000s. Rodopi. p. 9. ISBN 978-94-012-1003-4.

It contains a preface by Richard Fotheringham called "Preface: Australian Theatre in the Noughties" so it shows that at least in theatrical areas of Australian society both 2000s and noughties can be interchangeably. -- PBS (talk) 13:17, 15 August 2018 (UTC)

A search using site:uk throws up lots of reliable sources using noughties including this one:

Rohrer, Finlo (31 December 2009). "Decade dilemma". BBC News. 'But this term [noughties] was always going to struggle to be universal. As the decade got under way, Douglas Coupland noted that the "[Noughties] won't work because in America the word 'nought' is never used for zero, never ever".'

So it seems that this is another WP:ENVAR issue -- PBS (talk) 13:29, 15 August 2018 (UTC)

WP:MOSDATE is about numbers? WP:NUMBER is about notability?

Out of the corner of my eye I keep seeing ~~arguments~~discussions about date formats, with the shorthand MOSDATE thrown around. How strange then that when I used WP:MOSDATE I hit a page that starts with '"WP:NUMBERS" redirects here.' This is disorienting.

Would it be reasonable that WP:MOSDATE be a redirect to the 'correct' section about dates, just like the to-you-so-obviously-intended MOS:DATE? And comfortingly, the matches found searching for 'MOSDATE' in talk/template pages all seem to be discussing dates, years, seasons, etc. So I don't think it'd be misleading.

Oh, and hey, way back when, WP:MOSDATE *was* all about dates, and times, and only then about numbers, um, sorta like the page title. The page has been rearranged without considering the redirects. Can we make WP:MOSDATE about dates again?

Just for review, here's what I found:

Top of page WP:Manual of Style/Dates and numbers

Dates section #Dates, months and years

Numbers section #Numbers

MOS:NUMBER

Notability? WP:Notability (numbers)

WP:NUMBER

WikiProject Years WP:WikiProject Years

WP:YEARS

nowhere

MOS:YEARS

And... maybe change WP:DATES and MOS:DATES too? Yours confused, Shenme (talk) 02:58, 5 September 2018 (UTC)

"Make MOS:DATES Date Again"? Sorry, I'll go home now... --Masem (t) 03:03, 5 September 2018 (UTC)

Alumni, graduation years of (class of 1995)

..., UCLA ’95, ...
When including the graduation years of alumni, commas are placed after the person’s name and after the year. A closing apostrophe (’), not an opening apostrophe (‘), appears in front of the date. (ie. U+2019)

ℹ Request for comments regarding adding something simular to the bottom of the MOS-dates table.

GSMC(Chief Mike) Kouklis U.S.NAVY Ret. ⛮🇺🇸 / 🇵🇭🌴 10:10, 8 September 2018 (UTC) — Preceding unsigned comment added by Mkouklis(2) (talk • contribs)

Where did you get that? I believe our MOS discourages the use of U+2019, although I can't remember where that is and I can't say I agree with the reasoning. We also discourage the use of two digit year number abbreviations. Kendall-K1 (talk) 13:27, 8 September 2018 (UTC)

Indeed, two MOS violations here: MOS:CURLY and MOS:BADDATE. --Redrose64 🌹 (talk) 16:22, 8 September 2018 (UTC)

The MOSNUM doesn't mention graduation years at all, and I think it's a US-specific habit to quote them like that. Best avoided. PamD 17:00, 8 September 2018 (UTC)

Well, let's skip the America-bashing, but in general we should just write e.g. John Smith (BA 2015) or whatever. E Eng 17:39, 8 September 2018 (UTC)

I was reading/typo-fixing Oakwood mutiny since it's been in the Philippine news lately due President Duterte and opposition Senator Trillanes's (he's one of the 2006 mutiny leaders) drama, but couldn't find anything here & duckduckgo.com came up the above link/statement from ¿IIRC? John Hopkins University manual of style.

It's common here in the Philippines to he/she is from "PMA batch '06" instead of a Californian saying "..., graduated from UCLA Class of '06 "I was reading/typo-fixing Oakwood mutiny since it's been in the Philippine news lately due President Duterte and opposition Senator Trillanes's (he's one of the 2006 mutiny leaders) drama, but couldn't find anything here & duckduckgo.com came up the above link/statement from ¿IIRC? John Hopkins University manual of style.

GSMC(Chief Mike) Kouklis U.S.NAVY Ret. ⛮🇺🇸 / 🇵🇭🌴 11:45, 9 September 2018 (UTC) — Preceding unsigned comment added by Mkouklis(2) (talk • contribs)

Year range for two consecutive years

An RfC at Wikipedia:Village pump (policy)#Year range for two consecutive years concerns article titles illustrated in the following question. Which title is preferred: 2015–2016 Grand Prix of Figure Skating Final or 2015–16 Grand Prix of Figure Skating Final? Johnuniq (talk) 23:20, 9 September 2018 (UTC)

Proposal: End "date-forking" into different styles for publication and access/archive in same cite

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

There is no consensus to change remove date-forking in citations from MOS:DATE. —Compassionate727 ^(T·C) 23:40, 12 September 2018 (UTC)

Should MOS:DATE stop explictly permitting mixed date styles within the same citation, and recommend a consistent date format as we otherwise use article-wide? — SMcCandlish ☏ ¢ 😼 15:29, 29 July 2018 (UTC)

Yes. There is no sensible reason to use two conflicting date formats in the same article's citations, one style for publication dates and a different one for access and archive dates. Any time time I encounter this and have time and inclination to do it, I normalize them to the majority style of the article, and in 12+ years I've been reverted on this only one time, and groused at about it only one other time. That's two disagreements in the course of cleaning up many thousands of inconsistent dates.
I do not believe there is actual consensus support for this wacky "date-forking" notion; it's something someone came up with for unclear reasons, against common sense, way back when, and it's just been lingering around for no reason.
Ending this would handily also allow us to compress two otherwise redundant sections of material in the guideline into one more concise one.
— SMcCandlish ☏ ¢ 😼 20:35, 27 July 2018 (UTC)

I hate to say it but I've come to appreciate the visual distinction between the "actual" date of the source (in human-friendly MDY or DMY format) and the techie access/archive dates (in YYYY-MM-DD). It's your funeral but are you sure you want to poke this particular wasps' nest? E Eng 20:46, 27 July 2018 (UTC)
Yes, I'm immune. I would buy the "visual distinction" thing if there were a rule to use ISO dates for archive/access and it were consistently employed, but the opposite is the case. Some people do it manually, and some tools are doing it by default; that's the only reason its in use at all. See previous ISO dates discussion on this page, still open. A few nerds like this style, but it's not an average human preference (even among professional nerds). — SMcCandlish ☏ ¢ 😼 22:36, 27 July 2018 (UTC)
The main problem with the ISO style dates is that most people do not know what order the elements are in and you get all sorts of combinations, some causing invalid dates to be flagged. Personally I would like to ditch ISO dates as they are not clear, which in turn would remove the problem of mixed dates in references. A rather larger nettle to grasp! Keith D (talk) 22:58, 27 July 2018 (UTC)
ISO covers several formats, but the principal one concerning us is yyyy-mm-dd. What is unclear about that? Perhaps there are some people inclined towards making yyyy-dd-mm dates, but strictly speaking those are not ISO. And anyone doing that is unlikely to be aware of ISO's more esoteric formats. ♦ J. Johnson (JJ) (talk) 23:24, 27 July 2018 (UTC)
Those who know about the MOS know that it should be yyyy-mm-dd but many of the numeric dates are not in that format all sorts of combinations are given by editors, yyyy-dd-mm, dd-mm-yyyy, mm-dd-yyyy etc. many of which are ambiguous, even yyyy-mm-dd format can be ambiguous when you are unsure if the user specified it in yyyy-dd-mm format. Eliminating this format from the MOS removes that ambiguity. Keith D (talk) 10:10, 28 July 2018 (UTC)
MOS specifically disallows NN-NN-NNNN exactly because it's ambiguous as to DD-MM-YYYY vs. MM-DD-YYYY. So that leaves NNNN-NN-NN, and I challenge you to point to any significant real-world use of NNNN-NN-NN that's not YYYY-MM-DD other than Kazakhstan and Latvia – get with the program, Kazakhstan and Latvia. E Eng 13:46, 28 July 2018 (UTC)

As EEng says: we disallow nn-nn-nnnn and other such. All that we are really concerned about here is whether a date in yyyy-nn-nn form should be interpreted as yyyy-mm-dd or yyyy-dd-mm. If we haven't already disallowd yyyy-dd-mm we should do so. That some editors get it wrong is a matter for education. Just because some small number of editors get it wrong is no reason to ban all ISO yyyy-mm-dd formating. That would be like banning streets because some people drive on the wrong side. ♦ J. Johnson (JJ) (talk) 20:58, 28 July 2018 (UTC)
Yes, YYYY-DD-MM is indeed disallowed, in the sense that the only NNNN-NN-NN format allowed is YYYY-MM-DD. E Eng 15:42, 29 July 2018 (UTC)
The proposal was about mixing dates within a single citation. Or was it a back door proposal to forbid ISO dates? Please either make it clear which is actually being proposed or stick to the topic. Stepho talk 22:35, 30 July 2018 (UTC)
No, YYYY-MM-DD is an internationally recognized, unambiguous, and valid date format. And the visual distinction is between access-dates and publication dates is both visually pleasing and helpful. Headbomb {t · c · p · b} 13:15, 28 July 2018 (UTC)

Yet the entire point of the discussion above is it is not unambiguous to our readers. It's unambiguous to computers and to people who work with technical material a lot. — SMcCandlish ☏ ¢ 😼 15:11, 29 July 2018 (UTC)
While YYYY-MM-DD is standard almost everywhere and I find it's very commonly used on e.g. the Chinese Wikipedia, I think it still risks being ambiguous for some editors and should therefore be avoided. Jc86035 (talk) 17:35, 28 July 2018 (UTC)
Just to be clear, I'm not even suggesting that it be "banned"; rather, we should not be using two different date formats in the same citation. — SMcCandlish ☏ ¢ 😼 15:11, 29 July 2018 (UTC)
Update: I turned this into an RfC and advertised it around a bit. MOS:NUM tends to be a bit on the walled-garden side, so broader input would be of value. — SMcCandlish ☏ ¢ 😼 15:29, 29 July 2018 (UTC)
Strongly oppose changing the existing guidelines: access and archive dates have a different function to publication dates, and are usefully de-emphasized by the abbreviated style of YYYY-MM-DD dates. It ain't broke, so don't try to fix it. Peter coxhead (talk) 16:25, 29 July 2018 (UTC)
Strongly oppose. I happen to think that date-forking is a useful style for emphasizing the dates that are important to readers in citations and de-emphasizing the dates whose primary importance is for editors. —David Eppstein (talk) 19:13, 29 July 2018 (UTC)
Assuming that were not a false dichotomy, the sane way to do that would be to put the latter in a smaller font, or just suppress their rendered display with a CSS class by default. What you're saying is rather like "It's a good idea to save all my personal correspondence in MS Word format, and all my business correspondence in OpenDoc format, all government-related stuff in PDF format, and all my other papers in RTF format, so I can tell them apart", when saving them to different directories would make immensely more sense. You're misunderstanding what differing formats are for, and coming up with a weird kluge to try to leverage them for a different purpose than that for which they were intended. We don't have different date formats to trick readers into ignore some of them. But really, the entire premise is faulty. As a savvy reader, I actually care quite a lot about the access-date, since it tells me when someone last checked that this source verified the claims to which it is attached; WP:HIJACK is a constant problem. — SMcCandlish ☏ ¢ 😼 23:02, 31 July 2018 (UTC)
Oppose. For various reasons, but also one that goes against the very premise of the question: that there is a very "sensible reason" for using two contrasting formats. Particularly, to better distinguish publication dates from access (or "last checked") dates. ♦ J. Johnson (JJ) (talk) 19:24, 29 July 2018 (UTC)
Oppose - I prefer to cite the date of the work as it is cited in the work, while putting access date in the general date format followed throughout the article. Renata (talk) 23:07, 29 July 2018 (UTC)
- I don't believe that variation is allowed by the current MOS. —David Eppstein (talk) 00:01, 30 July 2018 (UTC)
  Whether or not it is current allowed, it should be--and possibly should even be required. Mterial take mfrom the work should be taken exactly.It's part of the way the work is identified. DGG ( talk ) 19:42, 31 July 2018 (UTC)
  So you propose that if the work is in German then our citation could have a date like '30 Juni 2018'? Japanese references could show 30 June 1980 as '1980年6月30日' or '55年6月30日' (emperor accession dates). China could show it as '1980年6月30日'. Taiwan could show it as '1980年6月30日' or '69年6月30日'. Middle Eastern countries have other calendars where all fields differ from the western calendar. — Preceding unsigned comment added by ‎ Stepho-wrs (talk • contribs) 22:47, 31 July 2018 (UTC)
  Yeah, this doesn't make any sense at all. DGG is confusing quotation with metadata. — SMcCandlish ☏ ¢ 😼 23:02, 31 July 2018 (UTC)
  - I agree with David Eppstein, all dates of a particular type, such as publication dates, should be in the same format. But if the publication date is a season, or other such period, such as "Autumn term 2007", the information conveyed in the citation should be the same as in the publication. Such seasons or the like should be made consistent; if an article had sources with publication dates "Fall 2001", "Autumn of 2001, and "autumn issue MMI" they would all be written "Autumn 2001". Jc3s5h (talk) 00:44, 30 July 2018 (UTC)
Oppose. This is just going to lead more people to "fix" things that aren't broken. NinjaRobotPirate (talk) 20:08, 30 July 2018 (UTC)
Support A single date format should be used within a single citation. That style could be '1 December 2018', 'December 1, 2018' or '2018-12-01'. Stepho talk 22:35, 30 July 2018 (UTC)
Oppose - largely per Renata because the publication date formatting given by the source might have to be preserved where possible as an aid for researchers in finding that particular volume. A hard rule against such might scratch the itch of detail-oriented MOS writers, but such pedantry doesn't actually help readers or editors. -- Netoholic @ 14:39, 1 August 2018 (UTC)
I don't follow this rationale at all. We have |date=3 March 2017...|access-date=2018-07-23 not for any reason that has anything to do with the wording in the text, but because people and some tools have been using ISO dates "just because". It has nothing to do with "pedantry" or with source verifiability. I don't think you've actually understood the proposal. — SMcCandlish ☏ ¢ 😼 16:37, 1 August 2018 (UTC)
Chicago Manual of Style rejects the notion that a date in a citation should be written in the same style as in the source. On page 496 of the 17th ed. Chicago gives this example note citation:
4. "Wikipedia Manual of Style," Wikimedia Foundation, last modified April 7, 2016, 23:58, http://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style.

Checking that URL and modification date and time shows a time stamp on the history page of "23:58, 7 April 2016‎", which is a different format. Jc3s5h (talk) 16:57, 1 August 2018 (UTC)
Yeah, this notion that we should mimic the style used in the source isn't supportable by any on- or off-site reference. It's actually exactly antithetical to everything MOS:DATE says, which is to use a consistent date style in the WP same article, and to normalize date formats to that style (including getting rid of ordinals) – other than it weirdly permits a divergent style for access and archive dates in the same citation, which is the only thing this RfC is about. — SMcCandlish ☏ ¢ 😼 01:09, 2 August 2018 (UTC)

@Netoholic: Why would we insist on mimicking the cited work's date style when we don't do the same for, say, capitalization of work titles (which we would normally do in line with MOS:TITLE where there is not another style being consistently used in the article)? 142.160.89.97 (talk) 02:56, 24 August 2018 (UTC)
Oppose I sometimes appreciate the visual contrast between the real date and the URL access date that is seen in many articles, but overall I think that WP:CITEVAR is the main point: You should be allowed to set this as a desired style (e.g., to provide more compact citations), and if it's not explicitly permitted, someone will try to declare that it's banned (again).
That said, whenever these things are being considered, my ultimate preference is that whatever happens in the CS1 template system is whatever makes maintenance easier for User:Trappist the monk. If he wants "date forking" to stop, then I'll go along with his preference. (Also, did you know that you don't have to re-type dates in the ISO format? Just fill in the |df= and CS1|2 will automagically fix it for you.) WhatamIdoing (talk) 06:39, 2 August 2018 (UTC)
Oppose I actually think that  SMcCandlish is technically correct – there is so much inconsistency on Wikipedia, that any step in the opposite direction is good. SMcCandlish, I do empathize with you – I regularly grit my teeth and stop myself from completing/formatting a bit of seemingly random text or an obscure external link that some people think suffice for a reference. But, my work on my other pet peeve, which is making introductory sections accessible and clear to the general reader, I feel, is much more important.

There is so much work to be done overall, just to get many basic articles done well, and to get any citations at all for many articles/parts, that I think the big picture must be considered. Thus, unfortunately, I think this is a relatively low priority item. (I know you could argue "do it right the first time," but see below first).

I do really like the idea of distinguishing the accessed/archive dates visually, rather than with date format. Would doing that help encourage writers to use consistent formats, since they no longer would have to worry about visual distinction? I would support that proposal. This proposal might lose opposition and go down more easily after that. Could a "bot" (correct word?) be created to do some of the work? Rather than you doing one at a time? Peacedance (talk) 18:29, 5 August 2018 (UTC) "...take what you like and leave the rest."

The objection you raise isn't an objection to anything contemplated here. This is about recommending a consistent date style, and being explicitly permitted to clean up inconsistent ones; it has nothing to do with forcing anyone to do anything, much less impeding citation entry. None of our style guides is ever interpreted that way. If you want to, you can input a citation like looks like "First LAST The Article Title Here YYYY JOURNAL TITLE vX 7 p25" with abuse of caps and no punctation, and it's still a valid citation. The issue is, it should not be any kind of debate that someone's permitted to make it a better citations. Yet, for no explicable reason we do – at least theoretically – have some sort of debate about whether people are permitted to clean up date mess. I can see where this proposal is going (largely because people are misunderstanding it), so I'll raise it again in a year in clearer wording. I certain won't refrain from doing date cleanup in the interim, however, since 12 year of doing it at article after article has met with no resistance. — SMcCandlish ☏ ¢ 😼 13:26, 12 August 2018 (UTC)

Oppose - it's useful to distinguish the accessdate clearly from the article date. --SarekOfVulcan (talk) 16:17, 9 August 2018 (UTC)
Support – There's no good reason to use different date styles in the same citation. 142.160.89.97 (talk) 01:37, 24 August 2018 (UTC)

Surrender Dorothy! E Eng 01:41, 24 August 2018 (UTC)

I don't know that a consensus has been reached one way or the other. 142.160.89.97 (talk) 02:44, 24 August 2018 (UTC)

Silence, you clinking, clanking, clattering collection of caliginous junk! E Eng 04:31, 24 August 2018 (UTC)

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.

RfC on date formats in East Asia-related articles

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

No consensus here to change anything. —Compassionate727 ^(T·C) 19:54, 12 September 2018 (UTC)

Should topics with strong ties to a particular East-Asian country use the yyyy-mm-dd date format outside sentences, such as in lists, tables and infoboxes? Szqecs (talk) 06:48, 24 August 2018 (UTC)

Comment – Why? 142.160.89.97 (talk) 06:50, 24 August 2018 (UTC)
Yeah: why? Tony (talk) 06:56, 24 August 2018 (UTC)
Same reason why US-related articles should use MDY. Szqecs (talk) 07:02, 24 August 2018 (UTC)
Yeah, you'll have to elaborate. 142.160.89.97 (talk) 17:23, 24 August 2018 (UTC)
@Szqecs: Do you have any evidence that English speakers in Asia primarily use YYYY-MM-DD? I'd think it's quite common for multiple formats to be in general use in English-language East Asian publications, especially since English isn't an official language in most of East Asia (and in Hong Kong I don't think there's any widely-followed standard). In general I think this isn't really necessary and would probably be worse than the status quo in some areas. Jc86035 (talk) 07:53, 24 August 2018 (UTC)
Familiarity is not an issue since this is the ISO format. This format is also good for table sorting. If this is not necessary, I don't see how MOS:DATETIES is. Szqecs (talk) 08:37, 24 August 2018 (UTC)
Table sorting can function with a mix of ISO, MDY and DMY. DATETIES is only useful where there is a widespread accepted convention, such as in the US (note the existing exception for Canada and Israel). Prohibiting the use of month names is not the same as asking users to order the month and day in a specific order. Jc86035 (talk) 09:04, 24 August 2018 (UTC)
As far as I know, table sorting only works with non-YMD if you use a template like {{Start date}}, so YMD is superior in this regard. Indeed, MOS:DATEFORMAT considers YMD acceptable in tables, infoboxes, etc. regardless of national conventions because it is ISO. Szqecs (talk) 09:32, 24 August 2018 (UTC)
That was true at one time, but enhancements in mid-2011 mean that you can mark a table column as containing dates that should be sorted as such. For example:

Sortable table with dates
Name	Born	Died
Al	September 3, 1942	—
Brian	June 20, 1942	—
Carl	December 21, 1946	February 6, 1998
Dennis	December 4, 1944	December 28, 1983
George	25 February 1943	29 November 2001
John	9 October 1940	8 December 1980
Mike	March 15, 1941	—
Paul	18 June 1942	—
Ringo	7 July 1940	—

As may be seen, it even handles inconsistent date formats. More at Help:Sorting#Configuring the sorting. --Redrose64 🌹 (talk) 11:18, 24 August 2018 (UTC)

Comment – The format is ambiguous to most of the community, it may be a standard, but very few know the order in which the digits should go. You can find many instances of the format being used incorrectly and leaving you having to investigate to see if the month and day are switched round. We should not be introducing yet more unclear information into articles by advocating wider use. Keith D (talk) 11:24, 24 August 2018 (UTC)
Oppose. Date formats other than yyyy-mm-dd are sortable. ISO 8601 requires agreement of data exchange partners (that is, readers) for dates before 1583. ISO 8601 requires use of Gregorian, not Julian calendar, but many people don't know that. ISO standards are outrageously expensive. Jc3s5h (talk) 11:25, 24 August 2018 (UTC)
Oppose because no cognizable reason for this vagary has been offered, and I'm getting pretty damn sick and tired of people opening RFCs out of the blue with no prior discussion. E Eng 12:08, 24 August 2018 (UTC)
Non-issue. Following on from Szqecs, MOS:DATEFORMAT allows yyyy-mm-dd "Only where brevity is helpful (refs, tables, infoboxes, etc.)". So you are already allowed to use it in tables (unless the article is already using a different convention - you need consensus to change). The table sorting issue is no longer an argument for or against because tables can already sort dates correctly. So, if an article is using tables with yyyy-mm-dd then they can remain. It is using tables with other date formats then yyyy-mm-dd should not be introduced unless there is a local consensus to do so. Make sure the article has consistent date formats in all of its tables. Stepho talk 23:36, 24 August 2018 (UTC)
Clarification request Is the RfC asking whether East-Asian articles should, must or can use yyyy-mm-dd in tables. As I said above, the 'can' case is already allowed. I would be reluctant to agree to 'should' or 'must' as a policy. Stepho talk 01:13, 25 August 2018 (UTC)
Oppose as no valid reason has been provided, That being sad I would certainly like to see YYYY-MM-DD done away with here but that's another discussion for another day. –Davey2010^Talk 00:25, 25 August 2018 (UTC)
Oppose baseless —AE (talk • contributions) 08:27, 27 August 2018 (UTC)

Query on same topic

I see that editor Szqecs is changing all the Taiwan-related articles from LONGmm-dd-yyyy to yyyy-mm-dd format. For example in the Taiwan infobox from February 1, 1950 to 1950-2-1. Taiwan does have a preference for yyyy-mm-dd usage, so I don't really have any qualms about the change of formats. Taiwan also occasionally uses American English style of February 1, 1950 because of its strong ties to the USA but never uses British style dates. My question is, must we use 1950-2-1 shortened style in the infobox? If he is going to change all the Taiwan-related articles it seems like readers would have a better handle of the actual date if we used 1950 Feb 1 if we want to keep it short. I was told by him that WikipediaMOS would not allow 1950 Feb 1 and that we must use 1950-2-1. Even 1950 February 1 would be better than unfamiliar 1950-2-1, but room can sometimes be an issue in charts. Fyunck(click) (talk) 18:54, 4 September 2018 (UTC)

Writing February 1, 1950, in the format 1950-2-1 is just unacceptable. The format yyyy-mm-dd us understood to include padding zeros when needed, so February 1, 1950, would be written in the format 1950-02-01. Also, the all-numeric format may only be used in limited situations. Jc3s5h (talk) 19:17, 4 September 2018 (UTC)

I'm not sure what is meant by "limited situations" but the same question would still apply. Because it is a lesser known formatting wouldn't it be better to use 1950 Feb 1 than to use 1950-02-01? If every Taiwan article is to be changed it seems like it would be better to use February of Feb rather than a number. An example would be right here. If this chart has to be changed from American dates to Taiwan preferred dates shouldn't we retain the month name or abbreviated month name rather than all numbers? Readers might get confused of which is the day and which is the month. Fyunck(click) (talk) 19:42, 4 September 2018 (UTC)

The rules are at MOS:DATE, period. This isn't the Singaporean Wikipedia, and no good can come from carving out more exceptions. E Eng 20:12, 4 September 2018 (UTC)

Hold it a minute. This isn't a policy it's a guideline. Are you telling me that we can use 1950-02-01 under certain circumstances but under no circumstance can we ever use 1950 February 1? In yyyy-mm-dd formatting it can never be used spelled out in full, only abbreviated form? No other formatting styles have this limitation. It needs a full form and an abbreviated form, or no form allowed at all. Without me digging through all the archives does someone know why this parameter has been curtailed in this manner as compared with the other date formats? Fyunck(click) (talk) 21:27, 4 September 2018 (UTC)

Please read MOS:DATEFORMAT. It contains a list of allowed date formats, and a partial list of unacceptable formats. The key thing to keep in mind is the date format should be one of the formats allowed. A format that isn't one of the allowed ones shouldn't be used, even if it not specifically mentioned in the list of unacceptable formats. The date 1950 Feb 1 does not follow any of the acceptable formats. Thus, it should only be used in a direct quote or if used in the title of an exteral work. It could also be used as a publication date in a citation, if a citation style that uses that format had been adopted for the article. Jc3s5h (talk) 20:18, 4 September 2018 (UTC)

But for there to be an acceptable shortening to 1950-02-01 we have to come from a long version. So maybe not Feb but at least February. I need to see a good reason why we can have yyyy-mm-dd in 1950-02-01 format but not 1950 February 1. All the other date formats have a long version. Is it in the archives somewhere where this was discussed? Fyunck(click) (talk) 21:27, 4 September 2018 (UTC)

Or let me put it another way using WikiMOS approved dates and the Taiwan-related articles. If articles use February 1, 1950 throughout in prose, is it appropriate in the infobox or tables to use 1950-02-01 as a shortened date or better to use Feb 1, 1950? 10 characters to 11 characters. All this with the understanding that in schools Taiwan English is taught to use mainly 1950 February 1 and sometimes February 1, 1950. Fyunck(click) (talk) 21:38, 4 September 2018 (UTC)

The format 1950-02-01 is inspired by an international standard, ISO-8601. Therefore, it doesn't come from "2 February 1950", it comes from virtually all the languages of the world (or at least, the countries that send representatives to the International Organization for Standardization).

This is the English Wikipedia. Gaining consensus among editors who use different varieties of English as their first language is hard enough; little to no emphasis is placed on varieties of English that only exist as second languages. One reason for this is that just because an article might be about a place that has quirks in it's version of English as a second language, the presumption is the article is being read by reader's who's first language is English. Readers from the place the article is about ideally would read it in the Wikipedia for the appropriate first langugage of the place.

Another issue with choosing formats is that Wikipedia is not an airline or hotel chain. We do not limit ourselves to dates in the 20th and 21st century. If we don't keep a tight reign on dates, the meaning of 12 February 13 is impossible to guess. Jc3s5h (talk) 22:01, 4 September 2018 (UTC)

Date template, and YYYY Month DD

{{!xt|{{date|April 15, 2007|YMD}}}} gives 2007 April 15, so if the date template has the format of yyyy mmmm d, but why is the the yyyy mmmm d format not allowed on MOS:DATEFORMAT then.

That would seem to indicate that the template is not MOS conformant. (That may or may not be desirable.) You would need to make a discussion at the template talk page about that. --Izno (talk) 16:33, 7 September 2018 (UTC)

Please read the {{date}} documentation, particularly the bullet point that begins "Although these are the four formats supported by MediaWiki's date autoformatting mechanism".... The template acknowledges that only some of the supported formats comply with Wikipedia:Manual of Style/Dates and numbers. Jc3s5h (talk) 16:45, 7 September 2018 (UTC)

Template space is full of stuff that's never used, and never meant to be used, on the English Wikipedia. You just have to get used to that. Maybe some other project uses those. E Eng 18:13, 7 September 2018 (UTC)

Why is yyyy-m-d format not allowed

So if you want to display March 1, 2018 as 2018-3-1 why is yyyy-m-d not allowed then?— Preceding unsigned comment added by 98.31.29.4 (talk • contribs) nine hours and sixteen minutes in the afternoon on the eleventh day of September in the year of Our Lord two thousand eighteen, Coordinated Universal Time (UTC)

See above discussion. --Izno (talk) 21:25, 11 September 2018 (UTC)

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.

Either side

This seems correct to me: "If at least one of the items on either side of the en dash contains a space, then a spaced en dash ({{snd}}) is used". "...one of the items on each side" makes no sense, because there is only one item on each side. The revised wording implies that we would write, for example, "January 2011 – present" with an unspaced dash, which would be wrong. Kendall-K1 (talk) 14:29, 8 September 2018 (UTC)

So does that mean if only one side of the en dash contains a space, it is sufficient to use a spaced en dash? JACKINTHEBOX • ^TALK 03:58, 9 September 2018 (UTC)

I interpret it as a space anywhere related to the dash requires a spaced en dash. Stepho talk 05:35, 9 September 2018 (UTC)

I know exactly what it means because I wrote it: if the thing on the left contains a space, or the thing on the right contains a space, or both, then use a space ndash; otherwise don't. E Eng 06:18, 9 September 2018 (UTC)

Could also be phrased as "If either of the items separated by an endash contains a space, then ..." Jmar67 (talk) 17:12, 15 September 2018 (UTC)

OK, let's nail this down. The current text is:

If at least one item on either side of the en dash contains a space, then a spaced en dash ({{snd}}) is used

How about we make it

If either or both of the items separated by an endash contain a space, then a spaced en dash ({{snd}}) is used

or

If one or both of the items separated by an endash contain a space, then a spaced en dash ({{snd}}) is used

-- ? On the whole I prefer the second; "either ... contain" sounds a bit strange. E Eng 18:02, 15 September 2018 (UTC)

I prefer my version, which is simpler:

If either of the items separated by an endash contains a space, then a spaced en dash ({{snd}}) is used

"or both" is not necessary. "either" covers that. Jmar67 (talk) 18:44, 15 September 2018 (UTC)

After all this fussing I'd rather be belt and suspenders, but I'm easy. Everyone else OK with Jmar's proposed text? E Eng 19:45, 15 September 2018 (UTC)

So would I write "12–14 May" or "12 – 14 May"? Is the "item" on the right side "14" or "14 May"? Kendall-K1 (talk) 00:10, 16 September 2018 (UTC)

That is a day range and would not be spaced. The "right-side" item is "14". Jmar67 (talk) 01:05, 16 September 2018 (UTC)

<weeps quietly> E Eng 03:06, 16 September 2018 (UTC)

You know I'm just messing with you, right? Kendall-K1 (talk) 14:06, 16 September 2018 (UTC)

After years at MOSNUM nothing surprises me. E Eng 15:05, 16 September 2018 (UTC)

MOS:ORDINAL

Alternative version of proposal got nearly unanimous support and was actually implemented over a month ago. — SMcCandlish ☏ ¢ 😼 10:52, 10 December 2018 (UTC)

The following discussion 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.

G'day, there has been a perennial discussion over at WikiProject Military history about the US Government style convention regarding dropping the n and r from ordinal indicators. Thus, we have the 2d Bomb Group rather than the 2nd Bomb Group, same deal for 3d. I tried to find a discussion of this in the archives here, but drew a blank. MOS:ORDINAL seems to indicate (by example) that the convention on WP is to keep the r, but the purpose of that first bullet point seems to be more about superscription rather than mandating a particular approach to ordinal indicators. Can anyone tell us if there has been a discussion about this in the past and point us at it so we can tweak our style guidelines based on any consensus? Thanks, Peacemaker67 (click to talk to me) 07:34, 3 October 2018 (UTC)

I do not recall a discussion here regarding a choice between "2nd" and "2d". For what it's worth, I see zero benefit in dropping the ~~"n"r~~ "n". Dondervogel 2 (talk) 08:22, 3 October 2018 (UTC)

You see zero benefit in dropping what? E Eng 08:29, 3 October 2018 (UTC)

Like Dondervogel 2 said, the "n" of "2nd" → "2d"; the "r" of "3rd" → "3d". --Redrose64 🌹 (talk) 09:14, 3 October 2018 (UTC)

He referred to dropping the "n"r. What's the "n"r ? E Eng 09:17, 3 October 2018 (UTC)

Why not drop both? That's what the British Army do. --Redrose64 🌹 (talk) 08:25, 3 October 2018 (UTC)

You risk confusing and alienating half of your audience to save a single character? Not all the readers will know the ins and outs of number formatting systems for specific countries. For myself, I have never seen 2d and 3d before, except as English money from 50 years ago. Stepho talk 09:30, 3 October 2018 (UTC)

D-day was 15 February 1971, so not quite 50 years. Please stop making me feel older than I am! ;-) More seriously though, 2d and 3d read as numbers of dimensions as in "3d printer". Martin of Sheffield (talk) 10:26, 3 October 2018 (UTC)

Er ... shouldn't that be P-day?!? Dondervogel 2 (talk) 11:07, 3 October 2018 (UTC)

"D-day", short for "decimalisation day", was the term used at the time. I was there. --Redrose64 🌹 (talk) 18:46, 3 October 2018 (UTC)

That makes sense. Thank you for explaining. Dondervogel 2 (talk) 19:51, 3 October 2018 (UTC)

Can the discussion be kept at one place please?Nigel Ish (talk) 10:32, 3 October 2018 (UTC)

What are you referring to Nigel? Peacemaker67 (click to talk to me) 10:52, 3 October 2018 (UTC)

The discussion on the Milhistory talk page is here. If the discussion is kept in one place then there is more chance of coming to a definitive conclusion that won't be subject to future challenge.Nigel Ish (talk) 11:10, 3 October 2018 (UTC)

@Nigel Ish: We didn't know that there was an ongoing discussion. Peacemaker67 merely said "there has been a perennial discussion over at WikiProject Military history", which implies that there have been several discussions in the past, perhaps many of them, that had not been resolved. --Redrose64 🌹 (talk) 18:44, 3 October 2018 (UTC)

Perhaps I should have mentioned that at the outset, but if you look at my query, it was about whether there had been any previous discussion here that might inform consensus at Milhist. It seems unlikely from the above that this issue has come up here before, so of course you are all welcome to chime in at Milhist following the link Nigel provided. Thanks for those who have responded thus far. Peacemaker67 (click to talk to me) 00:42, 4 October 2018 (UTC)

Specific mosnum proposal

The discussion has continued at the WP project Military History but we find ourselves in need of guidance from MOSNUM, closely related to Peacemaker67's original question. To resolve the impasse I propose adding the following clarification at MOSNUM. "The two letter ordinals 1st 2nd, 3rd, 4th ... are used, not 1t, 2d, 4h or any other one letter abbreviation of these". Any objection? Dondervogel 2 (talk) 08:31, 6 October 2018 (UTC)

Thanks for this. I don't think there is any usage of 1t or 4t in the US Govt style guide, just 2d and 3d. But I think something like this is needed. Cheers, Peacemaker67 (click to talk to me) 08:58, 6 October 2018 (UTC)

The Wikipedia "Manual of Style" does not purport to be a complete manual of style. Complete manuals of style such as The Chicago Manual of Style contain several hundred pages. I see no need to address the point about whether to prefer 2nd over 2d and 3rd over 3d. Jc3s5h (talk) 16:08, 6 October 2018 (UTC)

But where manuals of style conflict, isn't it useful for Wikipedia to choose a consistent house style to avoid different ones being used? Particularly where article titles are concerned? Peacemaker67 (click to talk to me) 01:12, 7 October 2018 (UTC)

Here's my standard blurb on this:

It is an axiom of mine that something belongs in MOS only if (as a necessary, but not sufficient test) either:

1. There is a manifest a priori need for project-wide consistency (e.g. "professional look" issues such as consistent typography, layout, etc. -- things which, if inconsistent, would be noticeably annoying, or confusing, to many readers); OR
2. Editor time has, and continues to be, spent litigating the same issue over and over on numerous articles, either

(a) with generally the same result (so we might as well just memorialize that result, and save all the future arguing), or
(b) with different results in different cases, but with reason to believe the differences are arbitrary, and not worth all the arguing -- a final decision on one arbitrary choice, though an intrusion on the general principle that decisions on each article should be made on the Talk page of that article, is worth making in light of the large amount of editor time saved.

I don't think (1) applies. Is there evidence of 2A or 2B? E Eng 01:55, 7 October 2018 (UTC)

That sounds like a reasonable position. Other than the current discussion at WT:MILHIST here, about USAF squadrons, there has been discussion here, on a USAF bomber wing page, here on a US Army infantry regiment page, here on a Milhist task force talk page as far back as 2006..., and multiple times on WT:MILHIST here, here, and here and many more I'm sure. It most often comes up regarding USAF squadrons, but also for other branches like US Army. So far as I can see, 2(a) doesn't apply, as there isn't general agreement (as evidenced in the current discussion at WT:MILHIST), but 2(b) may apply as there has been a lot of WP:LOCALCONSENSUS happening with it, where editors that favour one approach to the other move pages to suit their take on it. Peacemaker67 (click to talk to me) 03:44, 7 October 2018 (UTC)

I should add that for 2(b) the differences aren't arbitrary, editors have valid reasons for arguing the toss over it, essentially "official title" vs. version resulting in least astonishment for the casual reader. Cheers, Peacemaker67 (click to talk to me) 04:00, 7 October 2018 (UTC)

I think (1) does apply. When I see 2d Airlift Squadron and 33rd Fighter Wing my initial reaction is to assume "2d" stands for something other than "2nd", but without understanding what that something other might be. Dondervogel 2 (talk) 09:15, 7 October 2018 (UTC)

There is also Talk:132nd Fighter Wing which has a RM discussion of a number of articles. Peacemaker67 (click to talk to me) 09:39, 7 October 2018 (UTC)

Would it be fair to say that there isn't really an appetite for this to be formalised in the MOS? If so, no dramas, we'll just work on a local solution for Milhist articles. Peacemaker67 (click to talk to me) 05:35, 11 October 2018 (UTC)

Are there diffs you can give us of this being an issue on actual articles? E Eng 05:41, 11 October 2018 (UTC)

Well, there's these on 2d Bomb Wing [4] [5], these on 3rd U.S. Infantry Regiment [6] [7], and these on 3d Airlift Squadron [8] and 3d Fighter Training Squadron [9] [10]. There are no doubt many more diffs that could be mined if necessary, but a lot of 2nd/2d and 3d/3rd articles I looked at had been moved at least once between the two types of ordinals. Pinging @Lineagegeek and Buckshot06: who seem to the the ones who are arguing for 2d and 3d being the preferred option for USAF at least (I hope I'm not verballing them here), as well as @WP:MILHIST coordinators: for more corporate memory of this issue within Milhist. I'll also post a message on WT:MILHIST to ensure visibility of this discussion. Cheers, Peacemaker67 (click to talk to me) 06:06, 11 October 2018 (UTC)

I tried fixing 2d Airlift Squadron and 33rd Fighter Wing to at least make them internally consistent. With the first I succeeded (if not reverted) but the second I gave up on. I suppose it could be renamed to 33d Fighter Wing but that would be unwise during the present debate, the whole point of which is to stop articles flipping from one (name) to the other. Dondervogel 2 (talk) 06:23, 11 October 2018 (UTC)

Dondervogel 2, on the Project talk page, suggested, "mosnum should be updated by explicitly stating that '2nd' is preferred over '2d', even in cases where RS use '2d'". I would oppose that proposition in the strongest possible terms. Bad enough WP imposes a spacing standard to weapon calibers used nowhere else. Bad enough "commonname" over correct usage. Bad enough ill-informed pagemoves based on moscaps. Now this? Never. TREKphiler ^{any time you're ready, Uhura} 07:30, 11 October 2018 (UTC)

Language like Never is WP:BATTLEGROUND behavior. Please tone it down. --Izno (talk) 14:20, 11 October 2018 (UTC)

I would prefer Peacemaker67's suggestion in the WP:MILHIST discussion "Perhaps we identify 2d and 3d as valid options for US units because it is standard US English, but don't mandate it, stating that the ordinal used should be what is most common in reliable sources on the individual unit?" In the meantime, I'd definitely oppose Dondervogel 2's suggestion to ignore WP:RS and WP:COMMON NAME (or make and exception to them) and always use 2nd and 3rd and suggest not exacerbating the issue by editing while the discussion goes on. --Lineagegeek (talk) 11:57, 11 October 2018 (UTC)

Endorse LG's position. Buckshot06 (talk) 12:00, 11 October 2018 (UTC)

Can we at least agree that articles should be internally consistent? For example, if an article title is 2d Airlift Squadron that it should not repeatedly refer to said unit as the "2nd Airlift Squadron", and vice versa? Dondervogel 2 (talk) 12:34, 11 October 2018 (UTC)

In vehicles "(officially named...)" or something similar is sometimes used with WP:COMMON NAME titles.Sammy D III (talk) 13:25, 11 October 2018 (UTC)

Opinion: These should conform to the general reader's expectation, which is "2nd Airlift Squadron". --Izno (talk) 14:20, 11 October 2018 (UTC)

My impression/opinion is that:

The form of ordinals is not a matter of RS or common name but of style.
2d and 3d appear peculiar to the US?
Are 2d and 3d the "norm" in the US or an accepted variation?

As a non-US user, 2d and 3d appear unclear. I perceive that 2nd and 3rd are broadly understood (given WP is global) but 2d 3d (1t and 4t) are not. IMO, matters of style that impact on accessibility globally should default to that which is universally understood (for the sake of our readers) and should disallow that which might be ambiguous or unclear. Regards, Cinderella157 (talk) 14:42, 11 October 2018 (UTC)

2d 3d can be US Army proper names. They are probably never used outside the military.Sammy D III (talk) 15:48, 11 October 2018 (UTC)

@Cinderella157: Sorry to disagree but I think 2d is very clear. It means tuppence. Dondervogel 2 (talk) 17:18, 11 October 2018 (UTC)

Ah, yes, there is an argument from MOS:COMMONALITY. --Izno (talk) 15:19, 11 October 2018 (UTC)

Joking aside, an anonymous editor at Project Military History made an ngram showing that while 22d and similar were common in the 19th century, that is no longer the case today, even in US English. Dondervogel 2 (talk) 17:30, 11 October 2018 (UTC)

Just for clarity, there is no suggestion of 1t or 4t, just 2d and 3d. As Hawkeye7 has indicated at WT:MILHIST, US university style guides are apparently split on this issue. Peacemaker67 (click to talk to me) 05:46, 12 October 2018 (UTC)

There doesn't seem to be a consensus that this is something the MOS needs to address. We will work on adding to our Milhist style guideline along the lines of "The use of the ordinals 2d and 3d instead of 2nd and 3rd are valid options for US units because they are used in standard US English, but their use is not mandated. The ordinal used in any given article should be what is most common in reliable sources on the individual unit, and articles should be internally consistent in the use of ordinals". Thanks. Peacemaker67 (click to talk to me) 03:18, 22 October 2018 (UTC)

I don't really understand why that is the conclusion. There are three comments right above that say you shouldn't have these be options. MOS:COMMONALITY would be salient over your suggested option. --Izno (talk) 13:12, 22 October 2018 (UTC)

Exactly. If the usual ordinal format English is deemed a 'valid option', it should be used per WP:COMMONALITY. There's no reason to use a specialist style if even the relevant sources in that topic area are conflicted about its use. RGloucester — ☎ 14:24, 22 October 2018 (UTC)

As the current proposal is for an addition to MILMOS, discussion should probably continue at Wikipedia talk:WikiProject Military history. Kendall-K1 (talk) 14:36, 22 October 2018 (UTC)

I agree too. No one this side of the pond will read "2d" as an abbreviation of "Second". Best implemented as a clarification to MOSNUM though. Dondervogel 2 (talk) 15:14, 22 October 2018 (UTC)

It is preferable that consensus is achieved here for a MOS amendment to address this, rather than at Milhist, which would only be a WP:LOCALCONSENSUS. It has been suggested (at Milhist) that @Dicklyon and SMcCandlish: might also have informed views on whether 2d and 3d are standard US English alternatives for 2nd and 3rd or not. I do not know what their views might be (in case anyone thinks this might be canvassing), and ping them purely to broaden the discussion about this issue and try to get a solid consensus one way or the other. Peacemaker67 (click to talk to me) 00:04, 23 October 2018 (UTC)

More specifically, whether this reflects contemporary usage (with the same rider as PM). Regards, Cinderella157 (talk) 00:13, 23 October 2018 (UTC)

Those weirdo abbreviations need to be stamped out. Tony (talk) 00:17, 23 October 2018 (UTC)

I have to confess that this American thought it was a British thing. The COMMONALITY argument is a strong one, but the fact that we're talking about proper names makes it not entirely simple. E Eng 00:30, 23 October 2018 (UTC)

Revised mosnum proposal

I agree proper nouns are a complicating issue. In the interests of finding some common ground can we put that (admittedly important) issue aside and consider this alternative proposal. "With the exception of proper nouns, the two letter ordinals ~~1st~~ 2nd, 3rd, ~~4th~~ ... are used, not 1t, 2d, 3d, 4h or any other one letter abbreviation of these". I realise that change leaves 2d Airlift Squadron unresolved but it would help us identify the stumbling block. Dondervogel 2 (talk) 09:16, 23 October 2018 (UTC)

I'm a little frustrated that, despite it being pointed out several times, anyone is still suggesting that 1t and 4h are even involved here. This is about 2d and 3d, that's it. No-one has suggested 1t or 4h are a thing. Why would a proposal include versions that haven't even been floated? Peacemaker67 (click to talk to me) 09:30, 23 October 2018 (UTC)

To me they all sound equally bizarre, but my purpose is not to frustrate. Better like this? Dondervogel 2 (talk) 09:52, 23 October 2018 (UTC)

I appreciate that. I also find them weird, but let's just focus on the issue at hand. Thanks, Peacemaker67 (click to talk to me) 10:18, 23 October 2018 (UTC)

I don't really see a reason not to commit to the common styling entirely without some intermediate stage which sets the potential for wikilawyering a la "it was mentioned as being allowed in proper nouns, which means it's definitely something we should do". --Izno (talk) 11:58, 23 October 2018 (UTC)

Oppose – Again, this is a matter of style, not naming. Whether written as '2nd' or '2d', the reading and the meaning are the same ('second'), and therefore the integrity of any name that includes '2d' is not compromised by styling that '2d' as '2nd'. We should use the common styling. RGloucester — ☎ 21:26, 23 October 2018 (UTC)
Oppose - still. It is a matter of style. Regards, Cinderella157 (talk) 23:20, 23 October 2018 (UTC)
Oppose I think we should be mandating 2nd and 3rd across the board as a matter of style per the commonality argument. I know that this would disappoint the purists regarding official USAF squadron names, but I think we should go for the ordinal least likely to cause surprise to the casual reader. Peacemaker67 (click to talk to me) 23:50, 23 October 2018 (UTC)
Support: To be clear, I am not advocating any departure from "2nd" for common names either - rather my purpose here was to be silent on proper nouns in the hope we can at least agree for other article names; I have the impression others read it differently. Dondervogel 2 (talk) 05:53, 24 October 2018 (UTC)
Oppose - I think we should use only "2nd" and "3rd" in all instances. - wolf 20:19, 25 October 2018 (UTC)

Alternative proposal

The text: "Ordinal suffixes use the form 1st, 2nd, 3rd and 4th etc." This would be added as the first dot point in the ordinal section. Regards, Cinderella157 (talk) 00:15, 24 October 2018 (UTC)

Support: As proposer and IAW with comment by Peacemaker67. The also reflects (IMO) a developing consensus at MilHist TP. Regards, Cinderella157 (talk) 00:25, 24 October 2018 (UTC)
Support: Happy to support this form too. Dondervogel 2 (talk) 05:53, 24 October 2018 (UTC)
Support: Per my comments above, I think we need a standard house style that deprecates strange USAF officialese with ordinals, and doesn't initiate a ″what the?″ response from the casual reader. Peacemaker67 (click to talk to me) 10:43, 24 October 2018 (UTC)
Support: Happy to support this proposal. Hawkeye7 (discuss) 12:00, 24 October 2018 (UTC)
Support – per my reasoning above. Though, I'd prefer if it also said 'do not use 2d', or something like that, to avoid ambiguity. RGloucester — ☎ 20:57, 24 October 2018 (UTC)
Support . And explicitly prohibit the other forms. We should not be using 1t, 2d, 3d or 4h as they won't be recognizable to most readers. — Amakuru (talk) 21:07, 24 October 2018 (UTC)
JESUS FUCK FOR THE VERY LAST TIME no one is suggesting 1t or 4h. E Eng 22:06, 24 October 2018 (UTC)
Probably because you already killed them off, along with the 5h, 6h and 7h offenders mentioned below. Smart move — Amakuru (talk) 22:21, 24 October 2018 (UTC)
Desperate times call for desperate measures. E Eng 22:46, 24 October 2018 (UTC)
I support this proposal per WP:COMMONALITY. I don't think it's ideal to jump into the specifics territory however; "Ordinal suffices use the normal English forms as in 1st, 2nd, 3rd, 4th, and so on." isn't much better, but at least makes it clear we're shooting for normal English.... --Izno (talk) 21:38, 24 October 2018 (UTC)
We have as the current first bullet: Ordinal suffixes (-st, -nd, -rd, -th) are not superscripted (123rd and 496th, not 123rd nor 496th). Perhaps we could frame the proposed first bullet as "The ordinal suffixes on Wikipedia are -st, -nd, -rd, -th. Use of others is not permitted." or similar (and then remove the link and parenthetical in the next bullet). This gets us away from the issue of specifically calling out 1st 2nd 3rd 4th because it naturally leads to wikilawyering a la "what about 5th?". --Izno (talk) 21:50, 24 October 2018 (UTC)
I think there izno need for this. I'll take responsibility for finding and killing any such people. E Eng 22:06, 24 October 2018 (UTC)
Yeah - Anyone taking the 5th is obviously guilty as charged, and so deserves to be shot. Dondervogel 2 (talk) 22:25, 24 October 2018 (UTC)
Don't you mean the 5t? Regards, Cinderella157 (talk) 22:55, 24 October 2018 (UTC)
omigawd... what an awesome thread. llol - wolf 20:26, 25 October 2018 (UTC)
Support E Eng 22:06, 24 October 2018 (UTC)
Support – fits nicely with not surprising readers and MOS:COMMONALITY —Joeyconnick (talk) 22:54, 24 October 2018 (UTC)
Not opposed – You know that as soon as we adopt this someone is going to come up with an example of an actual proper name that includes one of the banned ordinals. Like a band name or book title or something. I assume common sense will prevail at that time, and present this as advance warning, not as an argument against adopting the policy. (actually here's one now: [11]) Kendall-K1 (talk) 22:59, 24 October 2018 (UTC)
Support All the best: Rich Farmbrough, 14:01, 25 October 2018 (UTC).
Support - wolf 20:22, 25 October 2018 (UTC)
Support ... The meaning of "2d" and "3d" has changed since they were originally coopted to mean 2nd and 3rd. These days, they might cause confusion. - Dank (push to talk) 03:16, 28 October 2018 (UTC)
Support – The US government manual doesn't explain its one-letter abbreviations, which are apt to be confusing outside of their use in unit names; and those abbreviations aren't consistently adhered to, even on military sites (e.g. Fort Bragg and the 82nd Airborne).— Preceding unsigned comment added by Dhtwiki (talk • contribs) 22:18, 29 October 2018 (UTC)
Support. While the "2d" style exists, we have no reason to care. All kinds of stylistic divergences exist out there and we don't use them on WP, especially if they either cause reader confusion or editorial conflict. "2d" stuff does both. The only proper-name stuff we need concern ourselves with are trademarks and titles of published works, and we already have guidelines about for those (which would both have us keep a corporation name like 2d Chance Ltd, or a album title like Given a 2d Chance. So, there is not actual proper-name issue to resolve. A military unit, in plain-English writing by people who aren't writing official military material, is as apt to use "Second". It just doesn't matter. I thus support a very concise addition on ordinals just to make such debates stop. It's a waste of editorial productivity. 09:26, 8 November 2018 (UTC)
Support—I hope we discourage superscript in this context. And when I see "2d", I think "twopence" (pron. "tuppence"). Tony (talk) 10:01, 8 November 2018 (UTC)
I was thinking that, too, though I haven't lived in the UK since I was little-ish. — SMcCandlish ☏ ¢ 😼 19:49, 13 November 2018 (UTC)
Support – for the sake of consistency and to avoid alternative meanings in a multinational encyclopedia (as Tony1 notes above). Peter coxhead (talk) 11:56, 8 November 2018 (UTC)
Support per pretty much everything above. It's just not relevant that [some not all] military publishing in the US prefers "2d". It's not done consistently in independent, reliable sources about (not published by) the subjects. Just because a usage is attested somewhere out there in the world doesn't mean WP should use it or endorse it. Otherwise we wouldn't have a style manual. — SMcCandlish ☏ ¢ 😼 15:15, 8 November 2018 (UTC)
PS: That said, we should still be defaulting to "second" (or in proper names "Second"), etc., not the abbreviated form, unless there's a good reason to use the abbreviation. — SMcCandlish ☏ ¢ 😼 19:49, 13 November 2018 (UTC)
Support. Might as well make the count that much higher to strengthen consensus and put paid to the whole discussion. — Preceding unsigned comment added by Herostratus (talk • contribs) 19:30, 9 November 2018 (UTC)

Hello, hello... I get the feeling that those still commenting don't realize that this change was made a week ago [12]. E Eng 15:22, 8 November 2018 (UTC)

Comment

I am seeing even at this stage unanimous support and that, as intended, the support is to preclude the use of other than two-letter suffixes. I think the statement is sufficiently categorical in that they "use" the form indicated and not some other form. Saying: don't use single letters, might be a bit like saying, don't stuff peas up your nose (similar but not exactly the same as a bean). "Etc" is intended to indicate: "and the list goes on", such that lawyering over 5th would not be in good faith - though "and so on" might well be better. However, IAW some of the comments I might suggest a minor ammendment/tweak.

Ordinals use two-letter suffixes of the form 1st, 2nd, 3rd, 4th and so on.

Unless anybody objects, I would not think that this would need to be recanvassed. Regards, Cinderella157 (talk) 23:35, 24 October 2018 (UTC)

I think that is a reasonable tweak and doesn't affect the intent people are supporting above. Peacemaker67 (click to talk to me) 00:00, 25 October 2018 (UTC)

The reason I was nervous about this proposal was experience with how badly Americans take deviation from their norms, which in the past have included diatribes on Fox News about how Wikipedia's acceptance of un-American spellings and forms indicates its virulent anti-American bias. Since the Americans don't seem to have any objection (at least for the moment) about the use of British ordinals, I see no reason not to update the MOS accordingly. Hawkeye7 (discuss) 19:47, 28 October 2018 (UTC)

Except I still don't think it's clear it's a Br-Am thing. The Brits commenting seem to have thought it was American, and the Americans seem to think it's British. Everyone seems to think it's an oddity. I'm vaguely getting that it's a military thing (whether Br or Am or both). E Eng 20:54, 28 October 2018 (UTC)

I believe that EEng is correct. This is not US vs. UK, this is US military vs. every other English speaker on the planet. I don't see any problem with 2nd/3rd other than some US military proper names. Sammy D III (talk) 11:00, 1 November 2018 (UTC)

Of course I'm correct. Didn't you get the memo? E Eng 12:03, 1 November 2018 (UTC)

Is there any other document, other than the US government document linked to above, that explains the military's use of this style? The linked document is typographically flawed (note the spaces in instances of "fi gure") and the style isn't explained, AFAICT. I'm skeptical that the odd use of one-letter ordinal suffixes is really US military practice. It makes little sense. Dhtwiki (talk) 23:30, 1 November 2018 (UTC)

I think it's one of those goofy things someone came up with for"efficiency"and then some other people thought was cool because it was different.We used to have a jerk editor here who refused to put spaces after commas and periods,like you see in this post,to"save storage space".Probably the same kind of thinking.Oh,wait!Here it's called an "archaic variant".E Eng 23:59, 1 November 2018 (UTC)

This has been implemented. Would somebody (Dondervogel 2 like to close this as I am the proposer of what has been implemented? Regards, Cinderella157 (talk) 00:59, 2 November 2018 (UTC)

No formal close is needed. Support was unanimous. E Eng 01:02, 2 November 2018 (UTC)

Agree. Peacemaker67 (click to talk to me) 01:20, 2 November 2018 (UTC)

You want me to agree with myself? E Eng 02:31, 2 November 2018 (UTC)

Yes. Agree and agree now (resistance is useless! Dondervogel 2 (talk) 20:51, 8 November 2018 (UTC)

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.

Two-digit ending years

Can someone weigh in on this dispute, regarding changing already-existing formatted two-digit ending years (e.g., 2017-18) as though four-digit ending years are required, here? --184.153.21.19 (talk) 05:54, 25 December 2018 (UTC)

MOS:RETAIN. E Eng 06:06, 25 December 2018 (UTC)

Thanks. Can you maybe leave word there? I do not want to open discussion in two places. And he will not listen to me. Maybe it will help if you leave your thought. Thank you. --184.153.21.19 (talk) 09:50, 25 December 2018 (UTC)

Done. E Eng 20:41, 27 December 2018 (UTC)

Symbol for hour

Why is the symbol for the unit "hour" listed as hr instead of h in the Specific Units section? I can't seem to find any discussion about this, and even the same page in all other instances uses the latter (as it should be used in both SI and non-SI instances). Does anyone know? — Getsnoopy (talk) 13:31, 8 January 2019 (UTC)

I do not know the reason for his oddity, nor can I recall a discussion of it. I would support a change to use the symbol h. Dondervogel 2 (talk) 18:16, 8 January 2019 (UTC)

It looks like I did this accidentally when fiddling with the table formatting [13]. I'll change it back. E Eng 19:13, 8 January 2019 (UTC)

Clarifying date ranges in YYYY–YY format

Self-closing this per WP:SNOW. I wasn't aware that there is an ongoing WP:VPPOL discussion that overlaps with this (full of a lot of highly polarized invective), and which has been pointed to this thread. It's clear to me that many of the arriving respondents have not actually read the proposal (or at least not understood it), since few comments are substantively responsive to what it says. Of those that were, several are simply dismissive without much of a rationale. So, this is a waste of time. I'll raise the issue again some months from now when heads have cooled, if it still needs to be addressed. — SMcCandlish ☏ ¢ 😼 18:32, 13 November 2018 (UTC)

The following discussion 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.

After various revisions (some of them not discussed enough and without any clear consensus record) over the last several years, we're right back to shitty advice and need to fix it.

The present vague wording which permits (does not recommend, much less require) YYYY-YY format under certain circumstances, but the certainty of them has been lost in fog, as have any restraints and rationales for that. It is being misinterpreted and wikilawyered about as a defensible rationale to force this style, including in article titles (one recent example here).

Every major discussion we've had about this has made the point that this format should not be used (at least not in isolation, versus in something like a long table consistently using this format) for anything ending in "-01" through "-12" because this is routinely misread as YYYY-MM. We cannot count on the en dash versus hyphen distinction at the browser/reader level, because it is not clear or even visible at all in every font.

What I'm seeing in the present wording is a suggestion that variation from the YYYY-YYYY pattern is okay for cases, and some examples of some such contexts; then various blather; then finally a statement that YYYY-YY in particular is permitted, without any tie between this idea and the prior material about contexts. The entire thing has become muddled, and needs to be rearranged and tightened.

It should state something akin to this:

YYYY-YY format is sometimes permissible:
1. In tabular data to save space, if the format is used consistently in that table, list, or other presentation.
2. In running text and in article titles, but:
  1. only for a contiguous two-year range; and
  2. only for particular contexts where this style is conventional, such as sports seasons, television seasons, and [add whatever else we need to list here]; and
  3. only for constructions that do not end with "-01" through "-12" (to avoid confusion with YYYY-MM dates), unless in close proximity to other ranges in this format that end with numbers outside the 01–12 range.
Especially do not use a construction like "2002–05" in isolation.
[Some other format if we need to cover another one] is sometimes permissible:
1. [Conditions and limits here]

— SMcCandlish ☏ ¢ 😼 02:50, 9 November 2018 (UTC)

It's a startling claim that "Every major discussion we've had about this has made the point that this format should not be used (at least not in isolation, versus in something like a long table consistently using this format) for anything ending in "-01" through "-12"". The close of the 2016 RFC was that "The community has decided that four year date ranges (i.e. XXXX–XXXX) should be the default style used in Wikipedia. A limited number of exceptions apply to this. Firstly, when space is at a premium, such as in tables or infoboxes, two year date styles may be used. Secondly, applications such as sports seasons, fiscal years, and consecutive years use the two-year date range convention without problems. These applications can continue to do so. This list is not intended to be exhaustive, and exceptions can apply with a strong local consensus.". It did not bar the use of YYYY-YY for anything ending in -01 to -12, and neither that discussion nor the current and ongoing Village Pump discussion can obviously be summarised as making that point. It's a point that some contributors to the discussions have made, that others have rebutted and that others have ignored. 80.41.128.3 (talk) 13:44, 9 November 2018 (UTC)

Disagreement and ignoring is not rebuttal. It's effectively not actually possible to rebut the fact that YYYY–YY and YYYY-MM, for cases 01-12, can and will be confused; there is no refutation available to be made against the fact that they are visually identical in various fonts. QED. And I never said that all closers of prior discussions raised this issue. I've made not any "startling claim"; you've drawn a self-startling inference and imagined it was a claim. — SMcCandlish ☏ ¢ 😼 16:38, 9 November 2018 (UTC)

Actually, it was specifically rebutted by Reidgreg stating plainly the difference between the hyphen and the dash makes it clear. I'm not sure I entirely agree with that as - & – can be difficult to distinguish, but to say no one issued a specific rebuttal is incorrect. oknazevad (talk) 13:47, 10 November 2018 (UTC)

You wrote "Every major discussion we've had about this has made the point". No, a handful of participants in discussions have made similar points. You wrote that "Every major discussion ... has made the point ... this is routinely misread as YYYY-MM". No, participants have generally avoided making that claim, perhaps because it would lack evidence. You have said now that it's a "fact that YYYY–YY and YYYY-MM, for cases 01-12, can and will be confused", without evidence that it will happen significantly often or that the confusion will be more than momentary, but the close of the 2016 RFC was that "applications such as sports seasons, fiscal years, and consecutive years use the two-year date range convention without problems." The proposed text would be contrary to the RFC close, "These applications can continue to do so." It startled me that you, of all people, would make such a proposal and support it with such claims. 92.19.25.230 (talk) 17:17, 10 November 2018 (UTC)

Could we please see some examples where YYYY-MM is being used in Wikipedia article titles? Similarly, in running text? The format may be useful where data needs to be sortable, such as in a table. However, its usage in English prose would be uncommon. -- Ham105 (talk) 20:13, 9 November 2018 (UTC)

Forbidding YYYY–YY for 01<=YY<=12 unless the same format occurs in the same article for YY>=13 could prevent consistency among closely related articles. If most articles in a related set had values of YY greater than 12, but a few did not, the few that did not would have to use the YYYY–YYYY format. Also, infoboxes would almost always have to use YYYY–YYYY because the infobox author would't know which year range values would be present in the article where the infobox is transcluded. This would lead to preventing the use of YYYY–YY in articles that transclude infoboxes that contain year ranges. Jc3s5h (talk) 13:13, 10 November 2018 (UTC)

Oppose per Jc3e5h's point about consistency. For example, why should 2011–12 NHL season use a different format that every other NHL season article? The context that it's a two-year date range is pretty obvious. Also, I agree with the anon that the claim that prior discussions have leaned towards disallowing the YYYY–YY format for ranges ending in 01 to 12 is wrong. There's no such conclusion in evidence in the RFC, and even the current discussions at the villiage pump have a mixture of opinions, with some arguing for allowing YYYY–YY for non-consecutive years (don't think that's going anywhere, but it's there). So the entire premise of this discussion is off base. oknazevad (talk) 13:47, 10 November 2018 (UTC)

Of course it shouldn't use a different format. They should all be using YYYY-YYYY, since article titles are not tabular data. — SMcCandlish ☏ ¢ 😼 12:08, 11 November 2018 (UTC)

"Secondly, applications such as sports seasons, fiscal years, and consecutive years use the two-year date range convention without problems." I see no requirement that it only be used for tabular data. In fact, the whole point of the sentence is for use in non-tabular situations. You're reading it wrong. oknazevad (talk) 13:23, 12 November 2018 (UTC)

Oppose - having to have 2011-2012 Premier League but 2012-13 Premier League would look inconsistent and stupid -- ChrisTheDude (talk) 16:43, 10 November 2018 (UTC)

Of course it would be stupid. No one suggested anything like that (you're engaging in a straw man fallacy), and WP:CONSISTENCY policy would prevent it. They'd all be at YYYY-YYYY names. — SMcCandlish ☏ ¢ 😼 12:10, 11 November 2018 (UTC)

Thank you for clarifying. I still oppose. I can't believe that anyone would honestly think that 2011-12 Premier League would be about a competition played only in December 2011 -- ChrisTheDude (talk) 20:00, 11 November 2018 (UTC)

Oppose. It is very clear from the context. An article about a season is obviously referring to years. And also agree with the point above that the use of YYYY-MM format is very rare. Regarding the rarity, if anything a proposal to distinguish between the two should focus on changing any use of YYYY-MM to a usage with the name of the month in full or a three letter shortened version (such as November 2018 or Nov. 2018). --SuperJew (talk) 17:40, 10 November 2018 (UTC)

It can sometimes be clear from the context, and sometime it is not. "Jackson did not play in 2010–11.", for example, is apt to me misread by may people as "in November 2010". And article titles (which seems to be what most people are on about here, for no explicable reason, given WP:CONSISTENCY policy) are devoid of context. — SMcCandlish ☏ ¢ 😼 12:17, 11 November 2018 (UTC)

Why would anyone read "2010-11" as "November 2010"? That seems like pretty contrived reasoning to me. – Pee Jay 15:09, 13 November 2018 (UTC)

I support the proposal because it increases clarity by decreasing ambiguity. The above-mentioned inconsistencies are easily avoided by using (eg) 2012-2013 Premier League. Dondervogel 2 (talk) 18:51, 10 November 2018 (UTC)
Oppose. Per the reasons above. 2011-2012 is just stupid and 2011-12 is clear enough. Kante4 (talk) 19:37, 10 November 2018 (UTC)

You're "opposing" something no one has proposed, and not responding to the actual proposal. See above. — SMcCandlish ☏ ¢ 😼 12:11, 11 November 2018 (UTC)

I've never came around when YYYY-MM is/was used and it never crossed my mind that 2010-11 could mean November 2010. So, still not sure what you want or why this proposal is being discussed. Fine as it is. Kante4 (talk) 14:34, 11 November 2018 (UTC)

Oppose I don't know what problem this is supposed to solve. The current format is clear, non-ambiguous, and concise. SportingFlyer talk 23:05, 10 November 2018 (UTC)

The proposal is crystal clear about what problem it will solve, please actually read it. Namely, it's the complete indistiguishability of YYYY–YY and YYYY-MM formats in many fonts. — SMcCandlish ☏ ¢ 😼 12:17, 11 November 2018 (UTC)

Right, but I don't think distinguishing between YYYY-YY/YYYY-MM is a problem. I'm not sure when YYYY-MM is used, and I think it's pedantic to think the en dash/em dash/hyphen are proper disambiguators (they're really difficult to tell apart in even fonts in which they differ). YYYY-MM is rare enough and I'm not sure I've ever come across it. SportingFlyer talk 13:15, 11 November 2018 (UTC)

Oppose Don't see any major issues with the current system. Number 5 7 00:12, 11 November 2018 (UTC)

See above. It appears that zero of the "oppose" !voters actually read or understood the proposal (with the possible exception of SuperJew). — SMcCandlish ☏ ¢ 😼 12:17, 11 November 2018 (UTC)

Mostly oppose. I agree that the YYYY–YY format should only be used for consecutive years, but I don't think the other restrictions are necessary. To be clear, I understand the potential confusion that you speak of, SMC, but I think the YYYY-MM format is so rare that such confusion is in practice unlikely. Can you point us to some sources which use that format so I can evaluate whether it's commonplace in any form of English? On the flipside, Writing it as 2011–12 is a more concise and nice rendition, and is used regularly in sources, so IMHO banning it is unnecessary. Thanks — Amakuru (talk) 21:17, 11 November 2018 (UTC)
Oppose To be honest I don't know understand the reasoning for the change to the 2011-2012 A-League instead of doing the 2011-12 A-League which is what most people think of doing. The amount of articles that have to change is properly in the thousands to do in this system and it's not just soccer that will have to change here but you also have Cricket, Basketball, Rugby Sevens (World Series only), Rugby Union (Northern leagues) to name most of the articles on this list. Not Homura (talk) 22:35, 11 November 2018 (UTC)
Oppose and support the suggestion by SuperJew that to avoid any possibility of confusion, the focus should instead be on the (probably far smaller) number of instances where 2010-11 has been entered intending to be November 2010 and change them to that phrase, 2010-Nov. or similar. Crowsus (talk) 17:21, 12 November 2018 (UTC)
Um, WP doesn't use "2010-Nov." format "or similar". — SMcCandlish ☏ ¢ 😼 15:36, 13 November 2018 (UTC)
Oppose needless, pointless, and functionally redundant. The YYYY-YY format has been a standard applied across sport for decades, and is very unlikely (other than in very specific instances of which I can think of precisely none other than in data analysis to help with table sorting) to be confused with a YYYY-MM function. This is particularly true when season article are routinely named / suffixed with "season" or similar to help eliminate this confusion in any case. If someone within an article was to state "x did not play in 2011-12" then the resolution is to change the text to "x did not play in the 2011-12 season" and is a basic function of grammatical correctness - not a formatting within wikipedia issue. Koncorde (talk) 12:52, 13 November 2018 (UTC)
YYYY-MM is one of the most common date formats used by North Americans. The fact that long-term, MoS-reading WP editors don't use it is meaningless. WP is written for readers, not for WP editors. — SMcCandlish ☏ ¢ 😼 15:27, 13 November 2018 (UTC)
I simply do not believe YYYY-MM is a common date format in the English-speaking portion of North America (since this is the English Wikipedia, that's the area we're interested in when it comes to readability). I exclude computer generated codes such as expiration dates stamped on food packages. Jc3s5h (talk) 15:37, 13 November 2018 (UTC)
You clearly did not understand my comment at all. Please re-read it. It may help to first take yourself out of "pick a fight with SMcCandlish on every single front I can think of" mode. Your three-prong rapid-fire badgering of me is getting tedious. — SMcCandlish ☏ ¢ 😼 17:12, 13 November 2018 (UTC)
Oppose — Preceding unsigned comment added by PeeJay2K3 (talk • contribs) 15:09, 13 November 2018 (UTC)

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.

Post-closure discussion

I object to SMcCandlish giving him/herself leave to raise the issue leave to raise the issue again in a few months. The proposal is soundly defeated and should not be raised again for many years. Jc3s5h (talk) 15:47, 13 November 2018 (UTC)
What, you want to have a discussion on that, too? Relax. E Eng 15:53, 13 November 2018 (UTC)
Anyone can raise any issue they feel like at any time; let's not be silly. It's conventional to let a matter rest for several months after an initial proposal doesn't attract positive attention, then return to it with an alternative approach if there's still an issue to resolve. While there was an alternative suggestion proposed, I didn't see that it garnered enough support to do an immediate followup RfC on it. Let's see how the VPPOL thread goes and if it implements any kind of change. It might moot the issue. If not, then after people have chilled out we can see if something like SuperJew's approach could ameliorate any remaining issue. The fact that this particular proposal wasn't accepted doesn't magically make the objective problem go away. Nor does the fact that you don't seem able or willing to read the material and understand the nature of the problem. I'm not sure I'm willing to continue this discussing with you any further, at least not in this venue at this time, with your current overly-personalized and fight-picking attitude. — SMcCandlish ☏ ¢ 😼 17:12, 13 November 2018 (UTC)
Yes, agreed. The "objection" above seems to be fighting the person rather than the issue, and circumstances and evidence can always change within timespans far shorter than several years. Perhaps there will be a slam dunk argument presented next month that convinces everyone. That said I think you are mischaracterising the understanding of those in opposition above. I'm pretty sure most of the participants (several of whom are experienced admins) understood the nature of the possible ambiguity you mention, they just didn't consider it a major enough issue to warrant changing the guidelines. — Amakuru (talk) 17:49, 13 November 2018 (UTC)
Revised. However, being an admin means the community trusted someone not to be a tool abuser. It doesn't translate into increased willingness to consider what a proposal actually says and why, nor a higher likelihood of taking someone else's concerns at face-value, especially if arriving here from an over-heated argument about essentially the same thing. No one is commenting here in an administrative capacity, but as editors. — SMcCandlish ☏ ¢ 😼 18:32, 13 November 2018 (UTC)

PS: And some of the comments up there really make no sense at all, e.g. the anon's "it was specifically rebutted by Reidgreg stating plainly the difference between the hyphen and the dash makes it clear". It is not logically possible for an observation that a hyphen and an en dash are not always clearly (or at all) visibly distinct to be "rebutted" by simply repeating one's already refuted belief that they're visibly distinct. That's a very basic fallacy called proof by assertion. It's not a real argument, it's just tendentious disagreeableness. I could go on, but re-arguing a closed discussion point-by-point would be counter-productive. My view that the majority of the responses are, well, not actually very responsive is sound in my view. I hope that if this needs to be revisited, that a combination of a clearer proposal and a lack of ongoing, related drama elsewhere will yield us more cogent responses. — SMcCandlish ☏ ¢ 😼 18:43, 13 November 2018 (UTC)
For what it's worth, I see two different kinds of problems addressed by SMcCandlish's proposal. One is the risk of misinterpretation of the ambiguity in 1901-02, which I at least interpret as February 1901 (how else would one reasonably interpret that date?). The other is the present untidy (IMO unencyclopaedic) mix of YYYY-YY and YYYY-YYYY in (for example) sports seasons. The ambiguity and inconsistency are simple facts. A difference of opinion can arise on how to respond to these facts (one might think the inconsistency is minor compared with the effort of making the change), and not on the facts themselves. Dondervogel 2 (talk) 19:24, 13 November 2018 (UTC)
Right. Plus there's the YYYY/YY and YYYY/YYYY stuff further complicating it (mostly also in sports, though I think some fiscal and TV stuff may be being named this way). Especially since YYYY/MM dating (in the real world, regardless what Wikipedia MoS nerds like us insist on here in our back yard) is even more common than YYYY-MM dating. [sigh] But anyway, I don't want to re-open a big discussion about this right now, but just let it go for a while. WP:NODEADLINE, and the sky is not falling. :-) — SMcCandlish ☏ ¢ 😼 19:42, 13 November 2018 (UTC)
Going back to the 1901-02 example. It never crossed my mind that someone would think February 1901 is meant, just logical and common sense for me (can speak just for myself of course). Kante4 (talk) 21:37, 13 November 2018 (UTC)
There are problems with a lot of what SMcCandlish claims, such as "YYYY-MM is one of the most common date formats used by North Americans." which is false and utter bullshit, unless unbeknownst to me it is wildly popular in Canada and Mexico. (Mexico would not count for MOS purposes anyway, since it is not an English-speaking country.) Then the "I'm going to take my ball and go home" response his standard procedure whenever one of his proposals is rejected. It's really childish, and anyone with even one iota of self respect would just admit the lack of support and move on to something else more productive. Instead his obsession with saving face means we are treated to this act anytime he loses. Clearly anyone who disagrees with him simply doesn't recognize his ironclad logic and infallibly superior intellect, since there's no possibility that anyone could have any informed opinion that doesn't completely agree with his. It's tedious and insulting. I think SMcCandlish is smart enough to recognize this, so maybe it is the effect he intends. Quale (talk) 05:11, 14 November 2018 (UTC)
SMcCandlish made two points, which should be distinguished:
A string like "2001-02", regardless of whether a hyphen or an en-dash is used, can be misread as meaning "February 2001".
Although I don't think they are very common, "YYYY-MM" formats are used – I'm certainly familiar with them – and simply saying "I don't misread such a string in this way" is irrelevant.

To avoid the possibility of a misreading, we should avoid "YYYY–YY" where "YY" is in the range 01–12.
There's a perfectly legitimate scope for taking different views on this issue, e.g. believing that the convenience and familiarity of the "YYYY–YY" notation outweighs the small likelihood of it being mistaken for "YYYY-MM". Personally, I wouldn't go as far as SMcC, but the MoS could usefully warn editors to take care to make sure that it's clear that strings like "2001–02" represent consecutive years and not a year+month date.

Peter coxhead (talk) 10:27, 14 November 2018 (UTC)
Peter's point 1 addresses the substantive part of Quale's comment, so I don't need to rehash it. The non-substantive stuff is just WP:IDONTKNOWIT hand-waving commingled with attempts to pick a fight, and I have better things to do. As a factual matter, YYYY-MM is part of the ISO-8601 date standard and is thus frequently used by tech professionals and scientists, and in any context in which sorting by date is desired. Someone simply seems to have been unaware of this. That's certainly excusable, but I'm not going to entertain more denialist "false and utter bullshit" [sic] now; the free pass has been used up. Point 2, a new one by Peter, is fair. Making it clear that it's a two-year range was the entire point of the suggestion to not use YYYY–YY format except in tabular data and in proximity to other dates in this format, specifically so that no one would be unclear on the meaning. (And it may not be the only way to do so, though it obviously is a way.) However, this has very little to do with the heated explosion of negativity in the thread above. Virtually no one addressed anything like this, but instead mostly vented about how important it is to them to mimic a style they see a lot of, in sports and TV publications and such, in our article titles which are utterly devoid of context and thus are not possibly able to make it clear that they mean YYYY–YY. The actual proposal and its rationale were basically ignored in favor of whacking at straw effigies. — SMcCandlish ☏ ¢ 😼 14:07, 14 November 2018 (UTC)

Peter, out of curiosity, where have you seen YYYY-MM date formats used? The only place I've encountered YYYY-MM is as part of filenames used for monthly archives, and I think YYYYMM is more common. This is a rare use and I don't think I've ever seen that format used for a date in prose. (Our documentation describes the monthly filename format, but typical of most developer writing I wouldn't say it rises to the level of "prose". I'm not even sure anyone other than the author has ever read it.) As far as I can recall, whenever I have seen XXXX-XX in newspapers, magazines or online prose it has been a year range. Typically YYYY-YY (or perhaps YYYY/YY) is used for sports seasons, and I think many people have seen those date ranges and recognize them in that context. Quale (talk) 05:09, 16 November 2018 (UTC)
@Quale: I agree that this date format is rarely used outside computer-related contexts (note that I'm a retired computer scientist). However, examples do exist. It's difficult to find them by Google searching, because of the way that it discards punctuation, but if you search for, say, "2012-10" (so that it can't be YYYY–YY), and look carefully at the results, there are examples, such as this church calendar. As I noted above, I'm more willing than SMcC to accept YYYY-YY formats, provided that editors take a bit of care to ensure the context is clear, because YYYY-MM is a rare format. Peter coxhead (talk) 10:28, 18 November 2018 (UTC)
An important point being missed here (except by SMcCandlish himself, who made it clearly enough) is that YYYY-MM (and not YYYYMM) is the international standard date format. Readers familiar with that standard are likely to recognize 2010-11 as a date (November 2010), whereas users unfamiliar with it are more likely to read "2010-2011". The ambiguity is real and would be very easy to remove, at a cost (gasp!) of two bytes per article title. Dondervogel 2 (talk) 13:28, 18 November 2018 (UTC)
I do not quite understand why seasons like 2018-2019 are not abbreviated to 2010/11. This would be clear to both causal readers and people knowing the ISO date standard, in which it is an acceptable form for a period of time covering parts of 2010 and 2011. No ambiguity, no extra characters. −Woodstone (talk) 14:28, 18 November 2018 (UTC)
Causal at left, acausal at right.
-E Eng

That might work for causal readers but the acausal ones would probably prefer 2011/10. Dondervogel 2 (talk) 17:38, 18 November 2018 (UTC)

I guess YYYY/YY is better than YYYY-YY but it would not solve the inconsistency between 1999/2000 and 2000/01. For that reason I still prefer YYYY-YYYY. Dondervogel 2 (talk) 18:25, 18 November 2018 (UTC)
We've had arguments about this before. YYYY/YY conveys (or "can convey") a different and more specific meaning, not of a span of time that randomly happens to span the year boundary ("my 2012–2013 sabbatical") but one that does so by definition, such as a winter sports season, or a non-calendar fiscal year. It's used for irregular publications, e.g. "the 2012/13 edition" of something published every two years, or the "Winter 2012/13 Holiday Special Issue" of a magazine. In all such cases, there is no reason to not write "2012/2013", unless in a table that's running out of space, but there is a good reason not to, since any 1–12 case can be confused as YYYY/MM, though that's not all that common a format (MM/YYYY is more common). — SMcCandlish ☏ ¢ 😼 19:00, 18 November 2018 (UTC)

Comment regarding ISO 8601: The utility of this standard is obvious when used within the context for which it was intended (as another former computer scientist myself, the benefits for data interchange are clear). However, ISO 8601 does not encompass the natural language used for dates in common prose; words like "January" or "Thursday", are not even allowed. Adopting all of the ISO 8601 date formats into the Manual of Style for the encyclopedia should not be (and has not been) the intention at Wikipedia.

2001-07 to represent July 2001 is already noted as unacceptable at MOS:DATESNO, i.e. YYYY-MM should not be used other than in external titles and quotes, according to the current project page.
ISO 8601 encompasses many formats that are not useful as norms within an encylopedia. The year 2 BCE, for example, is labeled with a minus sign as −0001.

Use of the YYYY-MM format within English prose is not at all common. Examples are difficult to find – a point made by many in this discussion. There's no compelling reason for it to be used in running text, and the Manual of Style already proscribes it. The range YYYY–YY, on the other hand, is quite commonly used. -- Ham105 (talk) 18:41, 18 November 2018 (UTC)

No one suggested importing all of ISO 8601 into MoS. Whether we should or not (obviously not) has nothing to do with the fact that the standard exists, that techies use it's shorter forms all the time, and that YYYY–YY is ambiguous (for users who can't distinguish the glyphs or who don't know what en dashes signify; given how many "dash fights" we've had, the latter group is likely a majority of readers). Second, MoS is not read by readers or intended to be; it's an internal editorial reference. It indirectly shapes the reader experience by guiding our creation of it, but it has absolutely nothing to do with informing reader comprehension after we've click "Publish changes". — SMcCandlish ☏ ¢ 😼 19:04, 18 November 2018 (UTC)

Much of ISO 8601 has little relevance here. I also disagree that MoS "has absolutely nothing to do" with reader comprehension. Incomprehensible means you're doing it wrong. To your other comment – There is very little ambiguity when resolved by context and in accordance with common usage, arcane counterpoints with difficult-to-find example cases notwithstanding. -- Ham105 (talk) 20:02, 18 November 2018 (UTC)

Go to any page history and at the top select "Page statistics". Scroll down to the month counts and look at the left-hand column. Martin of Sheffield (talk) 13:51, 19 November 2018 (UTC)

Could we please see some examples where YYYY-MM is being used in Wikipedia article titles? Similarly, in running text? These were my requests 10 days ago, and I think they remain unanswered. As noted at the time, YYYY-MM may be useful where data should be sortable, such as in a table. This matches the case of the "Page statistics" table. Yet it is not a commonplace way of writing November 2018 in natural language. Moreover, where written instead as 2018-11, MoS states "do not use" this format. -- Ham105 (talk) 14:35, 19 November 2018 (UTC)

What use would such examples serve? There are plenty of examples of the ambiguous 2011-12 and similar (the subject of this thread). How is the reader supposed to know what that means?!? That mosnum deprecates use of YYYY-MM for dates is probably a good thing and solves one half of the problem. Now we just need it to deprecate YYYY-YY for a sequence of years and the ambiguity is gone. The ambiguity in 2011-12 exists regardless of what mosnum does or does not say. There is precisely zero benefit in prolonging that ambiguity. Dondervogel 2 (talk) 16:42, 19 November 2018 (UTC)

There should be zero examples of WP articles titles or prose with YYYY-MM because this is banned by MOS:DATEFORMAT. It's circular logic to argue that it should remained banned because there are no examples but there are no examples because it is banned. Stepho talk 23:04, 19 November 2018 (UTC)

Point taken. The consensus, however, is that months are not described that way within common English and, by extension, it is proscribed in Wikipedia articles. Its usefulness is limited to data formats, such as in tables. -- Ham105 (talk) 01:11, 20 November 2018 (UTC)

No, MOS:DATESNO says YYYY-MM is never to be used. E Eng 02:56, 20 November 2018 (UTC)

That is what proscribed means: it is not to be used. -- Ham105 (talk) 04:58, 20 November 2018 (UTC)

I know what proscribed means, thank you. You said it is proscribed in Wikipedia articles. Its usefulness is limited to data formats, such as in tables which sounds a lot like "Not in article text, but OK in tables". I see now that's not what you meant, but I hope you can see why I thought so. E Eng 06:00, 20 November 2018 (UTC)

Actually, MOS:DATEFORMAT says "Special rules apply to citations" and "Only where brevity is helpful (refs, tables, infoboxes, etc.)", so it is not "never to be used", just limited to the special cases listed. Stepho talk 10:29, 20 November 2018 (UTC)

WP:CITE already stated that YYYY-MM-DD is the only all-numeric date format allowed in citations, but apparently that isn't clear enough, so I have added that YYYY-MM is not used. Jc3s5h (talk) 13:40, 20 November 2018 (UTC)

I stand corrected - I was thinking of YYYY-MM-DD being allowed in citations and tables. I would like to have YYYY-MM allowed too but that's a discussion for another day. Stepho talk 14:03, 20 November 2018 (UTC)

(edit conflict) About the entire thread: In the end, I have to point out that we MOSNUM peeps have expended more typing arguing about this stuff repeatedly than probably would be spent by all editors combined to spell out 2004–2005 instead of 2004–05, for about a decade. The "it saves space" argument is a silly red herring, except in the rare case that a table is so thick with data that we desperately need two characters of space. In that case, the table probably needs to be redesigned anyway. The WP:NOTPAPER and WP:NOTNEWS policies are also relevant here: WP is not a newspaper nor written like one. We are under no pressure at all to make our material compressed at the expense of clarity, and encyclopedic writing optimizes a tad in the opposite direction. — SMcCandlish ☏ ¢ 😼 19:00, 18 November 2018 (UTC)

Misinterpretation of YYYY-YY as YYYY-MM

Much of the above discussion is based on the premise that the reader knows what mosnum does or does not say. In general the reader of an encyclopaedia is not familiar with the style guide of that encyclopaedia and WP is no exception. Its readers are not assumed to have read mosnum, or any other part of the MOS. For this reason much of the preceding discussion addresses the main point. In case the reasoning, which is not circular, is not yet clear to all, it goes like this

The text "2010-11" can be interpreted either as November 2010 or 2010-2011, leading in principle to 2 possible misinterpretations:
#1 When used as a date it can be misinterpreted as a year-range
#2 When used as a year range it can be misinterpreted as a date
The present wording avoids #1 but does not nothing to address #2
This discussion is about #2

Discussion about how to address #2 is invited. Dondervogel 2 (talk) 10:38, 20 November 2018 (UTC)

Proposal: templates for working with OS/NS dates

I'm working on Assassination of Alexander II of Russia, which has a lot of ambiguous dates. It would be very helpful if Wikipedia had these two templates:

Purpose	Modeled after	What you type	What the reader sees
Editorially tagging dates whose O.S./N.S.-ness is not obvious to the reader	{{huh}}, {{by whom}}, {{citation needed}}	`March 1,{{what calendar}} 1881`	March 1,^{[in what calendar?]} 1881
Permanently tagging dates whose O.S./N.S.-ness has been definitely established	{{lang}}, {{convert}}, {{interlanguage link multi}}, {{death date and age}}	`{{dualdate\|March 1\|13}}, 1881` `{{julian\|1881-03-01}}`	March 1 (N.S.: 13), 1881

Would anyone else like to see these templates? More importantly (otherwise I'd WP:BOLD myself), do such templates already exist? or is there a good reason they don't? I see that a template {{julian}} did actually exist at one point, but it was deleted six years ago with the comment "nonworking template."

And where should the wikilinked text point? The policy page WP:OSNS exists, but doesn't say anything about how to fix the problem identified by ^{[in what calendar?]}. We'd have to make a policy that explains at least one acceptable format for O.S./N.S. dates. Also, WP:OSNS should provide links to these templates so that people know they exist.

I'll probably WP:BOLD and create these myself in a few days, but I wanted to get some feedback on the idea and some buy-in on the idea of changing WP:OSNS to prescribe a certain formatting for O.S./N.S. dates. --Quuxplusone (talk) 06:55, 27 December 2018 (UTC)

Have you seen {{OldStyleDate}} and the related {{OldStyleDateDY}} and {{OldStyleDateNY}}? Martin of Sheffield (talk) 14:27, 27 December 2018 (UTC)

Thanks, I had not seen those templates! That's basically what I'm looking for in the {{dualdate}} department. I don't particularly like the current rendering — {{OldStyleDate|March 1|1881|March 13}} renders as "March 13 [O.S. March 1] 1881" rather than the more readable "March 13 (O.S. March 1), 1881" — but at least I can scope my request down to requesting changes to the formatting of that particular template, instead of creating a new one.

I'm just going to go ahead and create {{which calendar?}}. --Quuxplusone (talk) 18:19, 27 December 2018 (UTC)

Please don't forget that "March 1, 1881" is US usage, whereas "1 March 1881" is the norm in Europe. So your proposed template:dual date needs also to deliver 1 (N.S.: 13) March 1881 [note, no comma before 1881, bold for clarity only]. You also need to cater for a change of month, like 31 March (N.S.: 12 April) 1881 – and a change of year, like 31 December 1881 (N.S.: 12 January 1882). I'd favour adding an (O.S.) tag to the Julian date too, just to avoid misunderstanding. --John Maynard Friedman (talk) 21:02, 27 December 2018 (UTC)
Obviously the various date formats (MOS:DATEFORMAT) should be accommodated. I suspect that the editors who labored to create Category:Date_mathematics_templates or possibly those associated with Template:Convert could help with this new endeavor. Can any stalkers here help by pinging appropriate template wizards? E Eng 23:44, 27 December 2018 (UTC)

John Maynard Friedman: For Euro-style dates, and changes of month, I believe a simple {{dualdate}} could handle that super easily. Examples:

What you type	What the reader sees
`{{dualdate\|March 1\|13}}, 1881`	March 1 (N.S.: 13), 1881
`{{dualdate\|1 March\|13 March}} 1881`	1 March (N.S.: 13 March) 1881
`{{dualdate\|31 March\|12 April}} 1881`	31 March (N.S.: 12 April) 1881
`{{dualdate\|December 20, 1881\|January 1, 1882}}`	December 20, 1881 (N.S.: January 1, 1882)

For a mathy template that performs the conversion itself, yeah, date formatting would be difficult. I would naturally expect that there would be a template {{date|1999|12|31|,}} that would automagically format itself as "December 31, 1999," or "31 December 1999" depending on the user's preferred date format and/or the {{Use dmy dates}}-ness of the article in which the template appears. But it looks like that's not what {{date}} does at the moment, and I don't even know if it's possible to conditionalize the behavior of a template on the categories of the page on which it appears. So {{julian}} would be really difficult. But {{dualdate}} would be trivially easy, as shown above! --Quuxplusone (talk) 17:31, 3 January 2019 (UTC)

I expect it can be done but have no idea how to do it. I'm just pointing out the further complication. --John Maynard Friedman (talk) 17:47, 3 January 2019 (UTC)

This seems like a very useful new facility, but I beg of you not to put it into use until some real template gurus review its design and syntax especially with regard to DMY, MDY and so on. We have too many complex albatross templates. Headbomb, Trappist the Monk, can you help out? E Eng 18:09, 3 January 2019 (UTC) Correcting ping: Trappist_the_monk. E Eng 18:29, 3 January 2019 (UTC)

@Quuxplusone: Wikipedia used to do automatic date format based on user preferences (and also linked to the article about the date). The entire philosophy of formatting dates based on user preferences was soundly rejected after long debate. A portion of the debate is described at User:Dabomb87/Summary of the Date Linking RFCs. If I recall correctly, a few users who wouldn't go along with the result of the RFCs were indefinitely blocked. My suggestion is to never again mention automatic formatting of dates based on user preference. Jc3s5h (talk) 18:17, 3 January 2019 (UTC)

My recollection from the debates about date autoformatting was that it was impossible to get the grammar and punctuation of a passage that contained a date correct unless the writer knew what format the date was in. So don't expect to be able to achieve too much automation in any {{dualdate}} function that might be created. Jc3s5h (talk) 18:24, 3 January 2019 (UTC)

@Jc3s5h: Heh, okay. No automatic formatting based on user preference. But how about automatic formatting based on the page's own dmy/mdy categorization? @EEng: I'm proposing that {{dualdate}} be just exactly what's in the tables above — no automation at all. I could write that template myself. :) John Maynard Friedman's comment above suggests that {{dualdate}} should have an optional alt= parameter, but that's it as far as parameters, so far. The complicated formatting/computation one would be more like {{julian}}. I think the simple {{dualdate}} would be literally this source code (untested):


{{{1}}} <small>([[Old Style and New Style dates|{{{alt|N.S.}}}]]: {{{2}}})</small>

Does that make sense? --Quuxplusone (talk) 18:57, 3 January 2019 (UTC)

Looks like the right kind of thinking, but we have battle-scarred template veterans who will think of pitfalls I can't even imagine. E Eng 19:15, 3 January 2019 (UTC)

Since I have been pinged into this conversation ...

In the 'what you type' column of the table above, it seems odd to have the year outside of the template because, after all, it is part of the {{dualdate}} the template is attempting to format. Because {{OldStyleDate}}, {{OldStyleDateDY}}, and {{OldStyleDateNY}} already exist, it would seem that {{NewStyleDate}} might be a better choice for a name (though I heartily dislike camel-case names).

It is not possible for wikitext templates to know anything about what lies outside of their bounding {{ and }}. It is possible for a Lua module to read the unparsed content of an article and search that for {{use dmy dates}} (and redirect names and related templates and their redirect names). For most articles these searches will not present a problem but large articles with many dates may use up too much time doing the searching; this is why the cs1|2 templates abandoned this as a way for auto-formatting dates. cs1|2 and other templates have a |df= parameter that usually takes a simple three character keyword as input |df=dmy, etc to specify how the date should render. Such parameter values are unambiguous which is always good.

Were I writing this template, in its crudest form would probably write it so that it required separate parameters:

{{NewStyleDate|<os year>|<os month>|<os day|<ns year>|<ns month>|<ns day>|df=<format>

where all of these parameters are numbers so that the template can choose how it annotates and brackets the ns date. And, were it me writing this template, I would do it in Lua because that is a real language.

—Trappist the monk (talk) 12:26, 4 January 2019 (UTC)

@Trappist the monk: "it seems odd to have the year outside of the template..." Well, the examples show both ways. When the year is part of the date you're trying to format (because it is part of what changed), then it goes inside the template. When the year is not part of the date you're trying to format, then it goes outside.

What you type	What the reader sees
`{{dualdate\|December 20, 1881\|January 1, 1882}}`	December 20, 1881 (N.S.: January 1, 1882)
`{{dualdate\|31 March\|12 April}} 1881`	31 March (N.S.: 12 April) 1881

As several people have remarked by now, it is probably not feasible to have "the template ... choose how it annotates and brackets the ns date", because the template won't understand English grammar and thus wouldn't be able to figure out whether a trailing comma was required in an American-style date (unless a "trailing punctuation" parameter was provided). Besides, there's no need for the {{dualdate}} template to know anything about date formatting — because it's not responsible for date computation. Only templates which compute dates need to care about how to format dates. For templates like {{dualdate}} which receive dates fully formed from a human editor, all they have to do is display them exactly as they were received.

Also, I'm gonna WP:BOLD and create {{dualdate}} just for the sake of this discussion (using the source code already posted above), since I think part of the continual cross-purposes here is that people are imagining things for {{dualdate}} that are really more like {{julian}}. Testing: "The assassination of Alexander II took place on March 1, 1881 (N.S.: March 13, 1881), in Saint Petersburg. Gavrilo Princip was born on 25 July (O.S.: 13 July) 1894." --Quuxplusone (talk) 17:31, 5 January 2019 (UTC)

Wholly encapsulating all of the date parts for both dates is just good practice, is a consistent user interface for non-technical editors, is less likely to confuse bots and other user scripts.

The template can decide how it annotates the ns or os date because it doesn't need to understand grammar, it only cares about the dates, the dmy/mdy format of those dates, and which of the OS or NS annotation to apply; the trailing comma issue is left to the editor just as it is the editor's responsibility to get punctuation right when using {{date|2019-01-05|mdy}} → January 5, 2019.

I have written nothing about date computation. Formatting and date computation are not necessarily the same thing; computation would be calculating an ns date from an os date or Julian date from a Gregorian date. The problem with dates fully formed [by] a human editor is that those dates aren't always consistently written, correctly spelled, and even correctly punctuated. A template can avoid all of those typographical errors that we humans are so prone to making (that's why this editor has spell checking ...). When a template does the formatting, all the editor needs to get right are the elemental date values.

I have hacked a module that does both ns and os annotation for year-only dates, for year and month dates, and for year, month, and day dates using the parameter pattern I described above:

format	os	ns	comment
dmy	1 January 1882 (O.S.: 20 December 1881)	20 December 1881 (N.S.: 1 January 1882)	different years
mdy	January 1, 1882 (O.S.: December 20, 1881)	December 20, 1881 (N.S.: January 1, 1882)	different years
dmy	12 April (O.S.: 31 March) 1881	31 March (N.S.: 12 April) 1881	different months
mdy	April 12 (O.S.: March 31), 1881	March 31 (N.S.: April 12), 1881	different months
dmy	13 (O.S.: 1) March 1881	1 (N.S.: 13) March 1881	different days
mdy	March 13 (O.S.: 1), 1881	March 1 (N.S.: 13), 1881	different days
—	April (O.S.: March) 1881	March (N.S.: April) 1881	year and month dates
—	1882 (O.S.: 1881)	1881 (N.S.: 1882)	year dates
~~dmy~~	~~31 December (A.H.: 1 January) 1882~~	~~20 December 1881 (A.H.: 1 January 1882)~~	~~uses `\|alt=[[Hijri year\|A.H.]]`~~

This code could easily be adapted to support functionality and / or styling of {{OldStyleDate}}, {{OldStyleDateDY}}, and {{OldStyleDateNY}}. We end up with is a single lua module supporting multiple related templates.

—Trappist the monk (talk) 13:30, 6 January 2019 (UTC)

@Trappist the monk: Could you add a "What you type" column to the above table? The "What the reader sees" column looks 100% great to me — I just want to know what you had to type in the source code to get that output. (Btw, I agree that your way of doing alt= is much preferable to my alt=/altlink= thing.) --Quuxplusone (talk) 01:32, 7 January 2019 (UTC)

What I actually typed and what an editor using a template would type is a bit different. Since there is no template that uses the module, here, using Editor EEng's proposed template names, is what an editor might type.

For dates with old style annotation:

{{nsos|1882|1|1 |1881|12|20|df=mdy}} → January 1, 1882 (O.S.: December 20, 1881)

and for dates with new style annotation:

{{osns|1881|3||1881|4}} → March (N.S.: April) 1881

—Trappist the monk (talk) 11:47, 7 January 2019 (UTC)

Order of dates should be reversed; 1 January 1882 N.S. is 20 December 1881 O.S. Jc3s5h (talk) 11:57, 7 January 2019 (UTC)

Surely the order should follow <source>(<conversion>), so if the source uses OS, then use Trappist's {{osns}} whereas if the source uses NS then use {{nsos}}. Martin of Sheffield (talk) 12:05, 7 January 2019 (UTC)

No, date order should be determined by the nature of the article. An article that is mostly about an area where the Gregorian calendar was used would put N.S. first for the occasional mention of something that happened where the Julian calendar was observed, and vice versa. Also, an event may have been described by more than one cited source, each of which differed on calendar usage. Jc3s5h (talk) 12:15, 7 January 2019 (UTC)

Not sure I'd always agree with you there, but that is a discussion for elsewhere. If you want NS first, use {{nsos}}, if you want OS first use {tlx|osns}}. Why should the date order in {tlx|osns}} be reversed – it is the effectively just {{nsos}} with the parameter order changed? Martin of Sheffield (talk) 12:29, 7 January 2019 (UTC)

The name "OSNS" tells the editor what order the input is, and also what order the output is: old style first, then new style. Similarly for "NSOS". Jc3s5h (talk) 12:58, 7 January 2019 (UTC)

I'm getting confused here. You've just stated that {{osns}} implies OS first (input and output) whereas {{nsos}} implies NS first (likewise input and output); yet your reply to Trappist said "Order of dates should be reversed" when his examples clearly show consistent input-output matching and ordering. Martin of Sheffield (talk) 13:37, 7 January 2019 (UTC)

The prospective template names refer to input and output date ordering. The module, as currently written, does not discriminate between the two date values – that is left as an exercise for the editor. Because I am lazy, and because it is the intent of the table to demonstrate final rendering for the various date constructs identified in the comments column, I simply grabbed some dates already present in this conversation and dropped them into the {{#invoke:}}s. Anyone is free to tweak my table to make the dates match the annotations, all else being left alone.

—Trappist the monk (talk) 14:02, 7 January 2019 (UTC)

Since it is factually incorrect to say that 20 December 1881 N.S. is the same day as 1 January 1882 O.S. I will try to correct the dates as Trappist the monk requested. I will do this in several edits because this thread is an intractable sea of markup. Jc3s5h (talk) 14:44, 7 January 2019 (UTC)

I think I'm done. I didn't touch Hijri. I think that calendar would have different month names, and different number of days for each month, than either Julian or Gregorian, so I'm not sure this template could work for Hijri. Jc3s5h (talk) 15:06, 7 January 2019 (UTC)

Uhm... doesn't MOS:ABBR mean these should be rendered as "OS" and "NS" without the periods (as with CE, BCE, AD, BC)? —Joeyconnick (talk) 21:45, 8 January 2019 (UTC)

If we're going to observe MOS:ABBR, that guideline says use full points [sic] (periods) for shortenings unless the particular abbreviation is listed in the exceptions. AD and BC are listed in the exceptions, N.S. and O.S. (in any form) are not listed as exceptions. Jc3s5h (talk) 22:15, 8 January 2019 (UTC)

Alt tag not a good idea

I suggest that the example shown above illustrates very well why it is that the alt tag would best be dropped from this proposal. "1 January 1882" is not a valid date in the Islamic calendar, because the month names are entirely different. In addition, the Hijri year is shorter than the Gregorian year and the conversion from one to the other is far from trivial (see discussion at Hijri era). A CE/AH conversion template would be nice if someone is feeling very brave but really needs to be tackled separately). The big risk of offering ALT=AH or ALT=AM is that someone will use it inappropriately. I have crossed out that line in the table above because it is an example of this kind of inappropriate use. --John Maynard Friedman (talk) 17:37, 7 January 2019 (UTC)

I don't think the complexity of the conversion is a problem. From Battle of Badr: "The Battle of Badr was fought on Tuesday, March 13, 624 (A.H.: 17 Ramadan, 2 AH) in the Hejaz region of western Arabia..."

What you type	What the user sees
`Tuesday, {{User:Quuxplusone/Dualdate\|March 13, 624\|17 [[Ramadan]], 2 AH\|altlink=Hijri year\|alt=A.H.}}, in the Hejaz region`	Tuesday, March 13, 624 (A.H.: 17 Ramadan, 2 AH), in the Hejaz region

Again, {{dualdate}} isn't about automatic conversion between calendars; it's just about styling two known dates in a consistent and aesthetically pleasing way. "Editors might find the conversion mathematically difficult" is a decent reason to avoid putting A.H. dates in an article to begin with, sure; but once you've committed to putting a particular non-Gregorian date (maybe because it's historically relevant), wouldn't it be nice to have a template to do the styling for you? --Quuxplusone (talk) 21:21, 7 January 2019 (UTC)

An alt parameter may be possible in a template where the editor types out the day, month, and year as they are to appear (like dualdate) but not for a template where the editor types in numbers for the year, month, and day and the template changes the format so the month is spelled out, like the proposed NSOS and OSNS. Jc3s5h (talk) 22:33, 7 January 2019 (UTC)

To be fair, the problem of conversion was a red herring and is (and should be) outside the scope of your proposal. Provided that the template properly supports alternative month names (and if at all possible checks for internal consistency between month style and year style), I withdraw my objection. But please make sure that the template documentation makes clear that the editors must use calendars consistently (so ditto the Jewish calendar).— Preceding unsigned comment added by John Maynard Friedman (talk • contribs) 23:17, 7 January 2019 (UTC)

As long as the component parts of any date can be represented with numbers, the AH, and presumably other calendars, can be treated in much the same way as the example osns/nsos templates. Given a template, {{ceah}} (common era /Anno Hegirae), that might look like this in wikitext:

{{ceah|624|3|13|2|9|17}}

the module simply fetches ce month names from its existing table of names and fetches the ah month name from an Islamic month-names table to render an output similar to the AH rendering now struck-out. This would not use the |alt= parameter so it can remain for whatever other use editors would choose for it. Reversing {{ceah}} to {{ahce}} reverses the order of the dates rendered.

—Trappist the monk (talk) 23:39, 7 January 2019 (UTC)

And like this:

{{#invoke:Sandbox/trappist the monk/dualdate|ceah_date|624|3|13|2|9|17}} → 13 March 624 (A.H.: 17 Ramaḍān 2)

{{#invoke:Sandbox/trappist the monk/dualdate|ahce_date|2|9|17|624|3|13}} → 17 Ramaḍān 2 A.H. (CE: 13 March 624)

—Trappist the monk (talk) 00:10, 8 January 2019 (UTC)

FWIW and a little off-topic, I found two date conversion templates template:Today/AD/AH (see effect right) and template:Today/AD/SH/AH that show today's date in various calendars (Common Era, Islamic calendar, Solar Hijri calendar). I don't for a moment suggest that it should be integrated into a new dualdate template (btw, I like TtM's names, their functions are immediately recognisable) but if the template doc has a "See also" section, it belongs there. --John Maynard Friedman (talk) 17:54, 8 January 2019 (UTC)

Automatic formatting of small-integer years

If we leave the date formatting entirely in the computer's hands, I'm a little worried about the rendering of "year 2" and other small-integer years. (This isn't specifically an A.H. problem, but it's a problem that doesn't really apply to Julian/Gregorian in practice AFAIK.) Here's Trappist's ceah_date, compared to a human-formatted dualdate:

What you type	What the user sees
`Tuesday, {{ceah_date\|624\|3\|13\|2\|9\|17\|df=mdy}}, in the Hejaz region`	Tuesday, March 13, 624 (A.H.: Ramaḍān 17, 2), in the Hejaz region
`Tuesday, {{ceah_date\|624\|3\|13\|2\|9\|17\|df=dmy}}, in the Hejaz region`	Tuesday, 13 March 624 (A.H.: 17 Ramaḍān 2), in the Hejaz region
`Tuesday, {{User:Quuxplusone/Dualdate\|March 13, 624\|17 [[Ramadan (calendar month)\|]], 2 AH\|altlink=Hijri year\|alt=A.H.}}, in the Hejaz region`	Tuesday, March 13, 624 (A.H.: 17 Ramadan, 2 AH), in the Hejaz region

The effortless spelling of "Ramaḍān" appeals to me. The bare "17, 2" does not appeal to me. [Also, totally off-topic, but if Ramaḍān is a correct transliteration, shouldn't that page not be a redlink? :)] --Quuxplusone (talk) 15:44, 8 January 2019 (UTC)

This is a new use of the word "effortless" that I hadn't come across before!

"Hard cases make bad law": the aesthetic concern applies to just 9 years. Besides, it only looks ugly in the US md,y style, it is fine in dmy. In any case, because it is preceded by a more familiar Gregorian date, the style and thus the meaning should be reasonably obvious.

IMO, if you want to get consensus for the proposal [which you almost have anyway], beware of feature creep. I advise that you get the essentials through first and then when it is accepted and in use, start to propose extra bells and whistles. --John Maynard Friedman (talk) 22:50, 8 January 2019 (UTC)

13 March 624 is not a Gregorian date ...

In Editor Quuxplusone's preferred rendering AH is used twice which seems a bit much for a single date. When the AH date is the second date, it gets prefixed with the A.H. link but not the reverse. I have tweaked the module so that AH dates in {{ahce}} get an AH suffix:

{{#invoke:Sandbox/trappist the monk/dualdate|ahce_date|2|9|17|624|3|13}} → 17 Ramaḍān 2 A.H. (CE: 13 March 624)

—Trappist the monk (talk) 11:25, 9 January 2019 (UTC)

Minor discussion

Is the wanted style always OS first followed by parenthetical NS? Don't we sometimes want the reverse? If so, may I suggest scrapping {dualdate} and instead having two templates, one called {OSNS} and one called {NSOS}. Those names have the advantage of helping you remember which parameter comes first in each case. E Eng 18:53, 5 January 2019 (UTC)

@EEng: I think the most common wanted style will actually be NS followed by parenthetical O.S.; but I can imagine wanting an abbreviation other than O.S.; for example, A.H. That's why I gave the {{dualdate}} template an alt= parameter. Although I guess it would need an altlink= parameter too, so that "A.H." could be linked to Hijri year. But I'm not an expert; it might be that people don't want to use a template for A.H., or don't want to use the same template as for O.S./N.S., anyway. --Quuxplusone (talk) 20:27, 5 January 2019 (UTC)

Well, I see that someone has changed {{Dualdate}} to be a redirect to {{OldStyleDate}}. I don't see offhand (didn't really look) whether OldStyleDate has the same functions as your Dualdate did. If it does, fine, if it doesn't see if you can work with its authors to enhance it. At all costs try to avoid creating a new, competing template. The {{convert}} template, though way WAY more complex than anything you want to invent here, may give you some ideas about design and syntax. I like the < small> format as seen in your examples above. Good luck. E Eng 22:33, 5 January 2019 (UTC)

I'm the one who did the revert. The changes should be made to the existing template that consensus has established we use, and that talk page should be invited to this discussion. cymru.lass (talk • contribs) 00:01, 6 January 2019 (UTC)

Well, while I cannot urge too strongly that a single, integrated facility is to be preferred over separate templates with overlapping functions, for the record it needs to be said that there's nothing compelling editors to use the template you happen to prefer. E Eng 00:22, 6 January 2019 (UTC)

I mean, this discussion is taking place on a page that prescribes the format preferred for displaying dates on here. I should hope we're attempting to arrive at a consensus on which format we should use to display dual dates. cymru.lass (talk • contribs) 01:02, 6 January 2019 (UTC)

Well if you want to undertake an effort to get agreement on something to be added to this guideline about joint formatting of NS/OS dates and so on, that's fine but I warn you to be prepared for it to take a very long time, as follows:

Imagine in your mind how long reaching consensus should take.
Double it.
Bump up to the next higher unit of measure.

Examples:

If you imagine reaching consensus should take 24 hours, in reality it will take about 48 days.
If you imagine reaching consensus should take 5 days, in reality it will take 10 weeks, more or less.

E Eng 01:45, 6 January 2019 (UTC)

Hmm, that's a good ballpark estimation, actually. — SMcCandlish ☏ ¢ 😼 03:52, 6 January 2019 (UTC)

Never fails for software projects. E Eng 04:06, 6 January 2019 (UTC)

Comma in date—when extraneous according to WP especially in view of chart?

If I am reading the chart in inappropriate date formats MONTH YEAR and DAT MONTH YEAR should not have "st" nd" "rd" 'th" following day, or a comma following day or year? Is this correct because we have someone in TeaHouse who is basically saying to those that rely on the answers there to go by what is right. The justification sustained in question states that when the article they authored was green lighted the approver said the comma style was the approved and so each new article and each new edit concerning the comma issue is including the comma that in the chart seems to indicate it is inappropriate. Of course the chart also says that format is a quote should be followed as original. Also, if there are appropriate variances to what is stated in the chart then those should be included in the chart and an appropriate note for inclusion in the article concerning the variance so that there is not confusion in the future.2605:E000:9149:8300:C9E:6B46:95A6:3A0C (talk) 21:02, 25 January 2019 (UTC)

My understanding is that if an article consistently uses one of the styles in the acceptable date style table, then that style shouldn't be disturbed without good reason. But if an article uses some other style, including the ones in the table of unacceptable styles, then the dates may be changed to one of the acceptable styles. Jc3s5h (talk) 21:22, 25 January 2019 (UTC)

Commas with DAY MONTH YEAR and MONTH YEAR are on the chart marked as inappropriate. What goes?2605:E000:9149:8300:C9E:6B46:95A6:3A0C (talk) 22:29, 25 January 2019 (UTC)

If we are looking at the same thing (A comma follows the year unless followed by other punctuation that replaces the comma: The weather on March 12, 2005, was clear and warm ) then this seems to me to be an error – or to be more precise, correct for EN-US but wrong for EN-UK. Indeed there is an example given of correct usage a little later (under #Consistency) that reads She fell ill on 25 June 2005 and died on 28 June - no comma after the year, exactly as typical in British English orthography. So unless anyone objects I propose to correct the "must have a comma" section. --John Maynard Friedman (talk) 17:52, 26 January 2019 (UTC)

The statement to which you refer (about a comma following the year) occurs only in the row for "September 2, 2001" format, not for "2 September 2001". If you think it might be misinterpreted you might perhaps change "A comma follows the year ..." to "In this format a comma follows the year..." --David Biddulph (talk) 18:12, 26 January 2019 (UTC)

I think it needs to be explicit, to avoid silly edit wars. --John Maynard Friedman (talk) 19:05, 26 January 2019 (UTC)

I have no objection to David's clarification (i.e., I agree with John), though it should be "In this format, a comma follows the year", with a comma after "format". While MOS is long (and MOSNUM is long within it), we should always prefer clearer and slightly longer wording when it clarifies confusions and forestalls repetitive, pointless disputes. The cure is definitely much better than the disease. — SMcCandlish ☏ ¢ 😼 11:51, 7 February 2019 (UTC)

Proposed revision to "acceptable formats" table

If there are no objections, the revised table (taking into account WP:ENGVAR use of commas as discussed above) that I propose is this:

Acceptable date formats
General use	Only where brevity is helpful (refs,^[a] tables, infoboxes, etc.)	Comments
2 September 2001	2 Sep 2001	In British English, a comma neither precedes nor follows the year except when normal punctuation rules apply: She fell ill on 25 June 1895 and died three weeks later She fell ill on 25 June 1895, just a day after her eighteenth birthday, and died three weeks later
September 2, 2001	Sep 2, 2001	In North American English, a comma follows the year unless followed by other punctuation that replaces the comma: The weather on March 12, 2005, was clear and warm Everyone remembers July 21, 1969 – when man first landed on the Moon
2 September	2 Sep	Omit year only where there is no risk of ambiguity: The 2012 London Olympics ran from 25 July to 12 September January 1 is New Year's Day
September 2	Sep 2
No equivalent for general use	2001-09-02	Use `yyyy`-`mm`-`dd` format only with Gregorian dates from 1583 onward.^[b]
September 2001	Sep 2001

--John Maynard Friedman (talk) 19:49, 26 January 2019 (UTC)

Any objections? --John Maynard Friedman (talk) 19:07, 26 January 2019 (UTC)

Sorry, but this is misguided.
- The comment about comma-after-year applies only to the row the comment is on, and that's obvious both from common sense and from the examples in the comment.
- Usage of September 2, 2001 vs 2 September 2001 is explained at MOS:DATETIES and is not as simple as "North American" or not.

E Eng 19:35, 26 January 2019 (UTC)

I suppose for the MOS, the best policy is that if it doesn't absolutely need to be said, then don't say it. So I am happy to withdraw the proposal unless there is a significant consensus that it needs to be said. --John Maynard Friedman (talk) 19:50, 26 January 2019 (UTC)

See WP:If MOS doesn't need a rule on something, then it needs to not have a rule on that thing. E Eng 22:11, 26 January 2019 (UTC)

Back in the 1990s I had an Alberta drivers license with an expiration date of 1999-11-20 where as my current BC driver's license is 2020-Oct-03. I know the Canada Revenue Agency and other branches of the Canadian government make use of ISO601 or its English variants, but I don't see any mention of that here. Zaurus (talk) 20:38, 4 February 2019 (UTC)

The reason ISO 601 is not mentioned is because that standard is about detecting arsenic in solid mineral fuels. Jc3s5h (talk) 21:10, 4 February 2019 (UTC)

I see, and now you're going to pretend you don't see the connection. E Eng 01:07, 5 February 2019 (UTC)

He would, but the poison has already set in. — SMcCandlish ☏ ¢ 😼 11:48, 7 February 2019 (UTC)

I have to concur with EEng that this isn't "it". For one thing, the style you call "British" is actually the majority style of the entire world; only the US and a few places strongly influenced by the US (like Okinawa, to the extent English is used there) regularly use MD,Y format rather than DMY, but DMY is also used in the US for specific purposes (e.g., the US military standard format). Having a summary table may not be a bad idea, but it is not this table. — SMcCandlish ☏ ¢ 😼 11:48, 7 February 2019 (UTC)

Strong national ties vs. international topic: when to prefer metric units

There are a few flashpoint articles for this issue:

Ambassador Bridge (edit | talk | history | protect | delete | links | watch | logs | views)
CanAm Highway (edit | talk | history | protect | delete | links | watch | logs | views)
Rocky Mountains (edit | talk | history | protect | delete | links | watch | logs | views)

At what point can an article have strong national ties to the US to justify US English yet be international enough to require metric units first? All three of these subjects are in the US and Canada. All appear to be written in US English per WP:ENGVAR and have imperial units listed first. However, an editor is insisting that because the subjects are not entirely contained within the United States, WP:METRIC requires metric units to be listed first.

Where is the line? How outside the US does a topic need to be to use metric units with American English? Or are imperial units an implicit part of American English per WP:ENGVAR? —C.Fred (talk) 02:28, 9 January 2019 (UTC)

WP:ENGVAR does not cover measurements; they are not considered an intrinsic part of American English. Usage falls under WP:UNIT, which says: In non-scientific articles relating to the United States, the primary units are US customary... [excepting the UK for the nonce] in all other articles, the primary units chosen will be SI units. Note that there is no discretion here; the MOS reads will not should. With respect to what "relating to the United States" means, WP:UNIT says you "should respect the principle of WP:strong national ties, where applicable." If it were indeed an ENGVAR issue, WP:RETAIN would hold, and the articles would retain their current format regardless. However, it doesn't, so MOS conformance requires metric measurements be put first, and the miles and chains second. Hawkeye7 (discuss) 03:04, 9 January 2019 (UTC)

The first rule of Chain Club is DO NOT TALK ABOUT CHAIN CLUB!. E Eng 03:10, 9 January 2019 (UTC)

Hawkeye: very well put. Tony (talk) 11:01, 13 January 2019 (UTC)

This wording is intended as a rule that is part of the MOS. In the general case there is always some discretion - the header of the page makes it clear that the MOS "is a generally accepted standard that editors should attempt to follow, though it is best treated with common sense, and occasional exceptions may apply."

We've long had the difficulty that either the rule is written absolutely (in which case people say that there are literally no exceptions) or it allows exceptions (in which case people argue that the rule can be overridden by their own personal preference). Generally the latter case has been more problematic so we write it absolutely, but it has always been intended that exceptions apply if there is a good topic-specific reason to make an exception.

My question in this case would be, what would you normally do when there are strong national ties to more than one English-speaking country? This is not WP:ENGVAR, but when WP:TIES exist the points are parallel. My own instinct would be to say that both styles are valid and so to apply WP:RETAIN^[c], but if consensus is that you should apply the default-to-metric rule then apply the default-to-metric rule. Kahastok talk 09:26, 13 January 2019 (UTC)

On checking the three articles in question today, one was metric first (Rocky Mountains) and the other two were US Customary first. Michael Glass (talk) 07:57, 27 January 2019 (UTC)

My 2¢ is don't change it just for the sake of changing it. That's needlessly disruptive. If the article is stable in one form it should not be changed without very compelling reason. Swapping the order of measurements whose applicability is questionable – and it is questionably, as there's literally a question about it – is not a compelling reason and not particularly useful. Hear millions of other articles to work on. Don't go hunting for drama. oknazevad (talk) 14:21, 27 January 2019 (UTC)

Notes

^ Only certain citation styles use abbreviated date formats. By default, Wikipedia does not abbreviate dates. Use a consistent citation style within any one article.
^ All-numeric yyyy-mm-dd dates might be assumed to follow the ISO 8601 standard, which mandates the Gregorian calendar. Also, technically all must be four-digit years, but Wikipedia is unlikely to ever need to format a far-future date beyond the year 9999.
^ or - as one previous editor insisted that WP:RETAIN is irrelevant because it doesn't explicitly mention units - the text at the top of WP:MOSNUM saying that we shouldn't swtich between optional styles without good reason

Meta: I have to observe that in every prior case of someone attempting to have Wikipedia adhere to a strict definition of terms like "should", "must", "shall"/"will", "may", etc., along the lines of IETF specs' rigid definitions of these terms, the idea has been shouted down by the community (on WP:NOT#BUREAUCRACY, WP:IAR, WP:WIKILAWYER, and other grounds). I.e., an MoS line item saying "will be" rather than "should be", or "is usually", or "defaults to", or whatever, does not actually make that line item a magically stronger "mega-rule"; it's still just a line item in a guideline, of equal weight to other line items in guidelines. "Exceptions may apply" to guidelines, as a matter of policy at WP:P&G and as stated in MoS's own lead; we just don't apply them without very good reasons. — SMcCandlish ☏ ¢ 😼 01:01, 8 February 2019 (UTC)

AD in MOS:ERA

MOS:ERA permits the use of AD either before or after the year. This however, is contrary to the guidance provided in most generally accepted English language manuals of style which state that AD should precede the year due to its representing the Latin for "Year of our Lord." Obviously this doesn't sound correct when following the year. I would suggest that when employed AD should precede the year in conformity with the guidance found in the majority of academic and other commonly used manuals of style. In situations where it may seem awkward it would perhaps be better to utilize the more modern usage of "CE." -Ad Orientem (talk) 03:57, 24 January 2019 (UTC)

Whatever these manuals say, "500 AD" is surely far more common in RS than "AD 500"? Unless this is an ENGVAR thing, which I doubt. I don't think this is a flyer either way. Don't forget this argument works the opposite way for (the rather more common) BC, and it would be ridiculous to put AD before the date and BC after. Johnbod (talk) 05:16, 24 January 2019 (UTC)

I think MOSNUM should state clearly whether the AD (or BC) goes before or after the year. I am agnostic on which. Dondervogel 2 (talk) 08:52, 24 January 2019 (UTC)

I think the MOS should state clearly that the possessive of singular words ending in "s" must still indicate this with "apostrophe s" as in "St James's Church", not "St James' Church". But to do so would be pointless because the error is now so ubiquitous. This same applies to the orthography of AD. So MOSNUM can at best state that "AD nnn" is preferred by academic sources but is not mandatory. A ruling is really only essential if there is a risk of confusing or misleading readers, which does not arise in this case. --John Maynard Friedman (talk) 10:45, 24 January 2019 (UTC)

Not a comparable case. We actually do have such a rule, there are simply exceptions for proper names that became ossified without the apostrophe-s or without an apostrophe at all in Early Modern English (and even these may someday change). A rambling aside: I saw an article a few years ago about names like "St James' Foo" being increasingly written with "St. James's", and the even more aberrant form "St. James Foo" being written "St. James'" and ultimately "St. James's", despite various cases having "official" names that do not match modern orthographic norms. Locals will generally prefer the irregular renderings, but in the modern, global writing market, the average writer is simply going to impose a single punctuation style and is not going to research whether a particular church, village, other thing has unusual spelling (and according to whom). Statistically speaking, these divergences are doomed in the long run (unless the possessive apostrophe itself becomes a thing of the past at some point, as some predict will happen). — SMcCandlish ☏ ¢ 😼 00:54, 8 February 2019 (UTC)

I have to oppose trying to make a rule on this, and if we did, it should be for "x AD" order. While "AD x" is arguably more linguistically logically sound, given the meaning of anno Domini, and is well attested, and has been used for longer, the "x AD" format has become more normal in much modern writing, for verisimilitude with "x BC", "x CE", "x BCE", "x mya", "x BP", etc., etc. The literal meaning of AD to most people today is opaque (Concise Oxford Companion to The English Language ["Abbreviation: History", p. 29, EPUB ed., 2005], says it is in that class of abbreviations that "have become over the centuries so institutionalized that their origins and natures are seldom considered", and that AD is normally taken to mean 'in the Christian era', and with that the objection disappears." It also obviates the old dispute that AD "can't" be used with anything but year, i.e. the nonsense prescriptivist idea that "1st century AD" is wrong). Handbook of Good English (rev'd. & updated ed., 1991) concurs: "the meaning of a word can change drastically, making its etymology irrelevant, and the meaning of this abbreviation has broadened".

The "AD x" format is becoming increasingly confined to religious material and to humanities academic material in particular, while it is more and more disused in scientific and other academic material as well as non-academic and non-Christian material, though many journalism house styles also stick with it, at least for now, though not with consistent formatting (dots, spacing, small-caps, etc.). As shown below, it basically breaks down like this: Most style guides are entirely or mostly neutral on the matter. Various style guides (mostly one-author monographs and organizational house style sheets) that are simply unexplained, traditionalistic punditry tend to favor "AD x", as do those that try to justify "rules" they offer on the basis of etymological theories or other logic without any regard for actual linguistic facts about usage; style guides based on scientific observation (proper linguistics) favor "x AD" and can prove that its use is ascendant, though some publishers also want "x AD" without any explanation for why they want it, to be fair.

If we were to require one format or the other it should be "x AD" for consistency and to match what studies of English-language corpora of published material are telling us (see below); but this is one of those trivial matters about which MoS has no reason to issue a rule. "AD x" is not (yet) considered "wrong" by much of anyone, so there's no need for a rule against it, unless and until people fight about it with great heat and frequency.

I dispute the assertion that "most generally accepted English language manuals of style ... state that AD should precede the year". I own almost every English-language style guide in print (and a large number that are not – I've been collecting them avidly for 30+ years), and most modern ones appear to permit either style, or to be silent on the matter, or at best to hint at a preference without mandating one. I'm having trouble finding current ones that insist on "AD x" order, and most of those I have found are just house style for a specific publisher, e.g. National Geographic, a specific newspaper, or a particular government, and they contain a lot of quirks that would not be found in most other publications. An exception is Fowler's, a general-audience usage dictionary which for two successive (now-old) editions was in favor of "AD x", but someone needs to check the current edition. Any style guide older than about 2010 is effectively obsolete for a purpose like trying to "prove" that an in-flux, in-dispute traditional style is still dominant. Let's look at some of them I have handy in electronic form, without regard to date, though:

Gregg Reference Manual (10th ed., 2005, p. 312), favored by American business schools and various universities, prefers "A.D." and "B.C." style, with the dots. However, it's also prefers "x A.D." order, which it describes as "ordinary usage".
Handbook of Good English (rev'd. & updated ed., 1991, pp. 297–298) prefers "x A.D." (with the dots), describing the reversed order as "fussy". It elaborates: "An reader who sees A.D. after the year or century understands it"; and: "The 'correct' placement may even look rather odd except in scholarly or other determinedly formal writing."; and: "let... A.D. fall where it does naturally; for one th ing, there is no short, convenient alterantive to first century A.D.." HGE identifies but dismisses the arguments against using AD with century and with in, as do Webster's Dictionary of English Usage, and Cambridge Guide to English Usage (works covered in more detail below).
Even the rather traditionalist Chicago Manual of Style (16th ed., 2010, ch. 9, sect. 35) only illustrates use of "x AD" in an example but has no rule requiring this order. (I own the new 17th ed., but only have it in paper form and it's presently in a box because I'm moving; someone else can check if they have a copy handy.) Similarly, Concise Oxford Companion to the English Language (2005) and Penguin Dictionary of American English Usage and Style (2000) show examples of "AD x" style, but offer no rule to insist on it. Same with Scientific Style and Format (8th ed., 2014), with the caveat that is just does this once, and thereafter prefers BCE/CE dating (or something more specialized as needed, like mya, BP, or whatever).
American Heritage Guide to Contemporary Usage and Style (2005, and possibly the most conservative of all major-publisher style guides) simply suggests that AD is "usually" put first (p. 9), a claim which is no longer well-supported.
The Blue Book of Grammar and Punctuation (11th ed., 2014) is entirely agnostic on it. So is The Complete Idiot's Guide to Grammar and Style (2nd ed., 2003). The following never address the matter at all: A Guide to Writing for the United Nations (1984), IAP Style Manual (4th ed, 1990), Oxford Guide to English Usage (1995), Oxford English Grammar (1996), Strunk & White's The Elements of Style (4th ed, 2000), The Elements of International English Style (2005), ACS Style Guide (3rd ed., 2006), APSA Style Manual for Political Science (2006), Writing for Scholarly Journals (2007), Analyst's Style Manual (2008), The Global English Style Guide (2008), Larson's Editorial Style Manual (2010), APA Publication Manual (6th ed., 2010), CIA Style Manual and Writers Guide for Intelligence Publications (8th ed., 2011), European Union Interinstitutional Style Guide (2011), Oxford Guide to Plain English (4th ed., 2013), WHO Style Guide (2nd ed., 2013), UNDP Editorial Style Manual (2014), University of Oxford Style Guide (2014, internal style sheet), American Statistical Association Style Guide (2015), European Commission English Style Guide (rev'd. 7th Ed., 2015), Gov.UK Style guide (2018). ASA Publications Handbook and Style Manual (2015) requires BCE/CE dating.
Style guides have been neutral on the matter since at least the 1980s; Webster's Style Manual (1985) and Webster's Dictionary of English Usage (1989) both observed frequent usage of "x AD" order, and permitted both, and the Cambridge International Dictionary (1986) also okayed both styles. WDEU cites "x AD" or "x A.D." usage (in what we'd call reliable sources) back to at least 1917 (and in a style guide, MacCracken & Sandison's Manual of Good English).
Contrarily, National Geographic Style Manual (2016), and U.S. Government Printing Office Style Manual (2008) want "A.D. x" format, but also demand the dots in "A.D.", "B.C.E.", etc., and this verges on aberrant in current English publishing (though can also be found in a handful of stodgy news manuals). UNESCO Style Manual (2nd rev'd. ed., 2004) is the same but without the dots. All three of these are just specialized house style sheets, not general-public advice for English writing. Oxford Guide to Style (2002) expected "AD x"; however, this has been replaced by two editions of New Hart's Rules (and New Oxford Style Manual, which includes NHR and New Oxford Dictionary for Writers and Editors); my own copy of the current ed. is in a box with my current Chicago. Same goes for my current Fowler's Dictionary of Modern English Usage (4th ed., Butterfield). The rev'd. 3rd ed. (as Fowler's Modern English Usage, ed. Burchfield, 1998, p. 19) insists on "AD x" format, and is the only general-purpose major style guide I can find right now that does so, but is even more obsolete than the same editor's Oxford Guide to Style. The Greenslade Free Australian Style Guide demands "AD x", but is the house style sheet of self-publishing mill PublishMyBook.online, and not really consulted by anyone or what WP would consider RS material.
Many (not all) journalism style guides also go for "AD x" order. My AP Stylebook is also in a box, so someone should check their annual copy. An old 2006 PDF has "A.D. x" format, and attempts to outright forbid "xth century A.D.", in both cases relying on the "it's literally 'in the year of our Lord'" theory, which no one really takes seriously as the actual meaning (versus etymology) of "AD" today. The Guardian and Observer Style guide [sic] and Telegraph style book [double sic – the name of the paper is The Telegraph not Telegraph] want "AD x" (both online, and updated in 2018), and so does U. of Queensland School of Journalism & Communications Style and Production Guide (2012). A little differently, Reuters Handbook of Journalism (2018) and The New York Times Manual of Style and Usage (5th ed., 2015) want "A.D. x", but The Times Style and Usage Guide (2011) wants "ADx" (no dots, no space). Meanwhile The Economist Style Guide has been in favor of the opposite order since at least 2005 (in more detail: "76AD" – unspaced, italicized, and small-capped – in the 9th ed., p. 9). Various news publishers with their own style manuals simply do not address the matter at all, such as the Pittsburgh PostGazette Stylebook (2016).
A weird outlier: the AAA Style Guide (2009) eschewed AD and BC, but called for C.E. and B.C.E. with dots and – alone of all style guides I've ever seen – wanted to mimic traditionalist A.D. order with C.E.: "C.E. 1200; 1000 B.C.E." (at sec. 5(d), "Numbers: Dates", p. 3). The association sensibly abandoned maintaining its own style guide (which was oddly divergent in several other ways) in 2015, and now follows Chicago in all matters.
Most importantly, Cambridge Guide to English Usage (2004, p. 13) notes that corpus studies by CCAE and BNC confirm that "x AD" ordering is a growing trend in English, not a receding one nor a temporary blip. CGEU considers "AD x" a traditionalism, not a rule. (Anyone familiar with how MoS debates eventually go on such matters will know that traditionalism-based arguments always fail against corpora-based evidence that the norms of the written language have changed; cf. MOS:JR against inserting a comma in names like "Sammy Davis Jr.", and MOS:ABBR on not writing "N.A.S.A." or "P.R.C.", among many other examples of MoS going with evidence not feelings.)
The somewhat derivative Cambridge Guide to Australian Usage (2007, pp. 16–17) agrees with its 2004 base volume. It considers "AD x" a "historians" usage, and adds: "The convention is not now rigidly observed." It summarizes the CGEU details, then adds that the ACE corpus demonstrates that over 75% of contemporary occurrences are in "x AD" format.
Missing from this review are some key works, including Garner's Modern English Usage which has become a little more evidence-based since its early days as Garner's Modern American Usage, and the current edition of New Hart's Rules AKA New Oxford Style Manual (2014, ed. Waddingham), also shifting more toward linguistic description instead of evidence-free prescriptivism. I own them, of course, but they're packed up in a pile of boxes.

A strong argument for "x AD" order, in addition to consistency with BC, CE, BCE, etc., is that "x AD" is the only permissible order for constructions like "the 3rd century AD"; using "AD x" for years produces a sharp inconsistency with this form, which can even occur in the same sentence (and "x century AD" is perfectly acceptable English, despite what seems to be a grand total of two modern style guides not liking it). A related problem is that the "AD x" form mangles longer dates: "January 24, AD 88", "24 January AD 88" (US GPO Style Manual actually expects this weird construction, which will be even more difficult for machine date parsing that for human understanding).

In closing, I'll just quote Webster's Dictionary of English Usage (1989) on this matter: "Some commentators attempt to rate these stylings on a basis of formality, but our evidence tends to undercut that argument. The question is most likely to be decided as a matter of individual or house style; in other words, consistency of application is more important than which styling is selected." Thus, WP is free to have either rule or no rule (and I advocate none, since we don't need one about this, but support "x AD" if we decide we must have one).
— SMcCandlish ☏ ¢ 😼 00:54, 8 February 2019 (UTC)

Another example of SMcCandlish's superficial, slapdash research. E Eng 01:37, 8 February 2019 (UTC)

[1] Only certain citation styles use abbreviated date formats. By default, Wikipedia does not abbreviate dates. Use a consistent citation style within any one article.

[2] All-numeric yyyy-mm-dd dates might be assumed to follow the ISO 8601 standard, which mandates the Gregorian calendar. Also, technically all must be four-digit years, but Wikipedia is unlikely to ever need to format a far-future date beyond the year 9999.

[3] r - as one previous editor insisted that WP:RETAIN is irrelevant because it doesn't explicitly mention units - the text at the top of WP:MOSNUM saying that we shouldn't swtich between optional styles without good reason

[a]

[b]

[c]

Distances measured in chains

No explicit statement that unit order should be consistent

Scottish chain and other chains

Clean up of Chain (unit)

And so... we are where?

Mixed sources

Editing cooperatively

Clarification on using {{convert}} on nuclear weapons articles for yield

Correct spelling?

See also

The noughties

WP:MOSDATE is about numbers? WP:NUMBER is about notability?

Alumni, graduation years of (class of 1995)

Year range for two consecutive years

Proposal: End "date-forking" into different styles for publication and access/archive in same cite

RfC on date formats in East Asia-related articles

Query on same topic

Date template, and YYYY Month DD

Why is yyyy-m-d format not allowed

Either side

MOS:ORDINAL

Specific mosnum proposal

Revised mosnum proposal

Alternative proposal

Comment

Two-digit ending years

Symbol for hour

Clarifying date ranges in YYYY–YY format

Post-closure discussion

Misinterpretation of YYYY-YY as YYYY-MM

Proposal: templates for working with OS/NS dates

Alt tag not a good idea

Automatic formatting of small-integer years

Minor discussion

Comma in date—when extraneous according to WP especially in view of chart?

Proposed revision to "acceptable formats" table

Strong national ties vs. international topic: when to prefer metric units

AD in MOS:ERA

Clarification on using `{{convert}}` on nuclear weapons articles for yield