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

Archive 140

Archive 141

Archive 142

Archive 143

Archive 144

Archive 145

→

Archive 150

Categorising people with uncertain birth years

Your views are invited at Wikipedia talk:People by year#Ambiguity vs accuracy. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:03, 20 November 2013 (UTC)

Important dates

The manual says only "important" dates should be linked. Can we make his more explicit and write that even if the date is important it should not be linked next to a person's name as its birth nor death date and better be emphasised in the text? I would like to see all cases like his one delinked. -- Magioladitis (talk) 13:54, 22 November 2013 (UTC)

Thousands separators

I've noted on the Delimiting (grouping of digits) section that apostrophes or spaces should not generally be used as thousands delimiters. This was added and reverted a while back so I am adding this comment to explain — I can't see it as controversial because we say commas are correct; it follows that others are not. Certainly an apostrophe is never used as a thousands separator in any native English-speaking country of which I am aware. Stifle (talk) 21:42, 15 November 2013 (UTC)

It never follows that given agreement that A is correct, B must be incorrect. Indeed, numbers in tables are often separated by spaces, and not necessarily into groups of 3. Also, general English-language usage doesn't seem to have formed a consensus about what to do with many digits to the right of the decimal point. Therefore I have reverted the change. Jc3s5h (talk) 22:13, 15 November 2013 (UTC)

• I believe Stifle was referring to the number separator as we use these in thousands et seq, in which case I fail to see how that change to the guideline justified being reverted. The space is commonly used in continental Europe but an anathema to English-speaking nations, and the apostrophe is used in even fewer places, AFAIK. But nothing beats the Indian Numbering System, which is a barrier to accessibility, and is not endorsed by MOSNUM. Your "numbers in tables are often separated by spaces, and not necessarily into groups of 3" seems to refer to other manifestations of numbers that have nothing to do with thousands. If not, kindly elucidate with examples. -- Ohc ^¡digame!_{¿que pasa?} 03:02, 16 November 2013 (UTC)

• Because the new material in a new sentence, it isn't entirely clear that it applies only to separating thousands, rather than other possible digit groups. In any case, it contradicts a later bullet which states that thin spaces may be used to group digits in scientific articles. We really shouldn't have bullet points contradicting each other. Also, since the changed bullet point has no qualification as to what kind of material it applies to, I would point to any number of tables published in English-speaking countries which group digits in a wide variety of ways, including the use of spaces to delimit groups of digits to the left of the decimal point. Jc3s5h (talk) 06:25, 16 November 2013 (UTC)

OK, fair point on spaces. I think we can agree that apostrophes would never be used, though? Stifle (talk) 14:44, 24 November 2013 (UTC)

I agree, apostrophes are not used in modern English texts in countries where the majority of the inhabitants speak English as their mother tongue. (I'm not so sure about countries where English is used as a widespread language to allow different ethnic groups within the country to communicate.) So I think we are justified in rejecting apostrophes in Wikipedia articles as thousands separators. Jc3s5h (talk) 17:03, 24 November 2013 (UTC)

A question of implimentation of STRONGNAT

User Jojhutton made a script-automated change that took The Beatles: Rock Band from dmy to mdy ([1]), which I reverted back. Ignoring the issue about mass-date format changing without consensus (which should not be done period), Jojhutton raised the issue on my talk page, believing that because the game was developed by American developers, that mdy must be used; I've argued that dmy makes more sense as it is the music of a UK band that this game is about, making it a stronger national tie than the American developers. (If this was any of the other Rock Band games which have no specific band focus, mdy all the way makes sense). It is generally true that we at the VG project use the nationality of the developer to set the language/date choices, but there are plenty of other cases where it makes sense to go against that - such as here, or Batman: Arkham Asylum (developed primarily by a UK studio but about an American comic icon, so the dates are mdy). I'd like to get more opinion if STRONGNAT would suggest one way over another, or if this should be a matter of consensus on individual talk pages. --MASEM (t) 18:16, 21 November 2013 (UTC)

• I fail to see why there has to be uniformity; these must be treated on a case-by-case basis. I've had lengthy discussions with JOJH before and we've agreed to disagree, JOJH believes that the studio (in the case of films) reigns supreme and is applying the developer's nationality to it (even to Harry Potter), whilst I disagree. The Beatles here are clearly the most powerful tie, and so it should be dmy. -- Ohc ^¡digame! 09:29, 22 November 2013 (UTC)
  • I think that where a topic is in a grey area: first we shouldn't be too fussed; and second, it's not worth changing from one to the other. So I'm slightly veering towards Masem's revert as the preferred option, and asking Batman to reconsider his/her studio-determines dictum as a little prescriptive. When gnoming, BTW, I generally find that Brits who end up in the US have US spelling and dates, which I don't change. Tony (talk) 09:47, 22 November 2013 (UTC)

Honestly, this doesn't seem to be the type of instance where STRONGNAT was meant to be applied. One way or the other, the item in question can be decided, whether based on the studio, Beatles, or whatever. That, in of itself, implies that there are not strong ties. Cases of strong ties are usually unambiguous, hence the "strong". The game is an international one, that is not restricted to any one country. STRONGNAT is clearly meant to refer to articles that have an unambiguous tie to a country. In this case, it makes sense to follow the guidelines for articles that do not have strong ties, and this would mean that the article should remain at the stable variant, rather than change. RGloucester — ☎ 14:57, 22 November 2013 (UTC)

I do agree with OhC that it should be case-by-case (Jojhutton was pushing on my talk page for absolute uniformity), but from the comments above, I'm definitely reading it that in the specific case of TB:RB that there's no STRONGNAT tied to require one version or the other, so the article should remain at the stable date format. --MASEM (t) 15:03, 22 November 2013 (UTC)

The problems that occur when you deal with situations on a "case-by-case" basis is that we tend to get mob rule instead of following a set rule that is fair and just and unambiguous, as can happen with certain talk pages of certain guidelines from time to time. Without following a set guideline the rules become confusing and they tend to lead to major disagreements. Without uniformity Wikipedia falls into the mass chaos of majority rules, which isn't the spirit of the project at all. The spirit is to work together if we are going to share the project. Otherwise, whats the point? —JOJ ^Hutton 17:13, 24 November 2013 (UTC)

The rules are simple. STRONGNAT only applies in cases of "strong ties" ,that is, unambiguous connection to the subject of the article. If there is ambiguity, by default STRONGNAT does not apply. STRONGNAT is an exception, it is not a rule. The rules state that articles should use one consistent date format throughout, whether DMY or MDY, and retain the existing stable variety, just as for varieties of English. Changes should not be made to the date format once it is established in the creation of the article, unless a strong case can be made that STRONGNAT applies. RGloucester — ☎ 17:19, 24 November 2013 (UTC)

In a perfect world I may agree with you, but unfortunately we as human beings are a flawed species. We tend to look at the world through our own biases. Without a good standardized way of determining what articles use which date format and spellings, Wikipedia articles will fall into a mob rule mentality. Consensus only being determined by the local majority and not determined by any guideline or policy. All I ask is that DMY and MDY be standardized and unified by using the same rules throughout all articles, rather than having a hodgepodge of confusion. I don't care if DMY or MDY are used, only that there is consistency in the way they are applied. If in this case, the topic makes a stronger tie to a video game than the developer, then it's fine, just so long as it's applied equally. My opinion is that the developer, who created the game code and owns the game, creates a stronger tie. If I'm right, then there are dozens of British made games which currently use MDY that would use DMY. JOJ ^Hutton 20:34, 24 November 2013 (UTC)

I don't think you understand what I said. The article above, the game, does not have strong and unambiguous ties to any particular nation. Therefore, the default rules state that the format of the first major contributor be retained in all instances. RGloucester — ☎ 20:57, 24 November 2013 (UTC)

I understand exactly, but I disagree that there is not a STRONGNAT tie. Also the first major contributor to enter a date was a MDY date. It was changed to DMY because of STRONGNAT. Unfortunately it seems that the rules change based on convenience rather than what the guidelines say because if STRONGNAT was good enough for that article at one point why is it not now? And if STRONGNAT does apply, then what are the rules? You see this is the problem when we edit without rules, we get confusion and anarchy. . JOJ ^Hutton 22:35, 24 November 2013 (UTC)

If it was originally MDY, then it could be returned to that if there is consensus to do so. But as it has been stable at DMY for a good period of time, it seems that retaining the existing variety is the best approach, if one takes the rules into account. STRONGNAT was never "good enough" for this article, and should've never been applied. This isn't anarchy, it is more like an adhocracy. That happens to be the way Wikipedia works, and if you'd like to change that, fine. As it stands, though, there are multiple options in this specific instance. You could just WP:IAR and change it to whatever you like. RGloucester — ☎ 00:34, 25 November 2013 (UTC)

Actually, IAR mass date changing is not allowed, which is the initial change Jojhutton did on the article. Normalizing the established date format by script is okay, but this was transferring >90% of the dates from dmy to mdy. That's not allowed without consensus change per this policy. —MASEM (t) 02:06, 25 November 2013 (UTC)

I don't think "not allowed" is the word. It is discouraged, and isn't likely to stand up to consensus, but anyone can do what they like with regard to guidelines. Their actions, however, will be checked by those that adhere to the guidelines. That's the difference between a policy and a guideline. Anyway, I was just trying to make it clear that Wikipedia, at present, is not as rigid as that fellow wants it to be. It isn't just with regard to dates, but with regard to pretty much everything from content creation to blocks and units of measure. If he'd like a more rigid Wikipedia, he can campaign for one. However, that's not the way it works at the moment. RGloucester — ☎ 02:20, 25 November 2013 (UTC)

YYYY-MM-DD (ISO 8601) in All Scopes

I'd like to suggest allowing this date format in all scopes, rather than limiting it to "references, tables, lists or areas where conciseness is needed."

• It's arguably the most unambiguous format (by virtue of starting with the year, it can't be misread as "American" MM-DD-YYYY when it's actually "European" DD-MM-YYYY, or vice versa).
• Its big-endian format mirrors decimal numbering.
• Its worldwide adoption keeps increasing, thanks perhaps to its use by computers, the military, and the ISO.

I'm not suggesting it be listed as preferred, only as acceptable. Thank you. Startswithj (talk) 01:52, 5 September 2013 (UTC)

There has been no end of discussion on the matter. Please check talk archives. -- Ohc ^¡digame!_{¿que pasa?} 02:35, 5 September 2013 (UTC)

When Startswithj wrote "'American' MM-DD-YYYY when it's actually 'European' DD-MM-YYYY" I wonder if the editor meant all numeric dates, for example, 9-5-2013 or 5-9-2013. If so, these are already forbidden, so the reason for the change does not exist. Jc3s5h (talk) 04:02, 5 September 2013 (UTC)

Can you give some examples of adoption increasing? I'd love to see it happen, as I'm a big supporter – I just haven't seen any increase in usage. —[AlanM1(talk)]— 07:27, 5 September 2013 (UTC)

MusicBrainz use YYYY-MM-DD see [musicbrainz.org/artist/e9fb8bad-ec0e-4cf1-aa82-a7e04a34b278 this example] (top right in desktop mode) . Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:51, 5 September 2013 (UTC)

The simplest reasons to avoid ISO dates in running prose is that it breaks the reading process with an unnatural format. I realize not everyone reads "verbally", but even having the ISO date requires one to pause to flip around. There are times where dates are being presented inter-sentence as data, but more often than not, dates as process lead off a sentence ("On January 1, 2013, this happened...") or used in other adverb-like phrasing, and there just make the ISO inclusion needlessly complicating the sentence. Hence why preferable to avoid the format in running process. --MASEM (t) 13:00, 5 September 2013 (UTC)

I wouldn't disagree that the majority of English speakers read and speak dates primarily as either "on January one, twenty thirteen" or "on one January twenty thirteen" (perhaps swap "first" for "one," and/or add "the" and/or "of" around the day). But I have heard (and I personally read and speak) "on twenty thirteen January one" (or "…first"). Being US-born, the little-endian model gives the slightest pause to my reading…and being a traveler and sometime programmer, the middle-endian ("American") model gives the slightest confusion to my comprehension.

I realize no single person's preference nor any anecdote counts for much, and we can't serve every reader perfectly. The manual does say "acceptable" however, not "preferable." Startswithj (talk) 18:31, 5 September 2013 (UTC)

• Too much choice is dangerous. It's like the proverbial genie. Let it out of the bottle, and although most people will not use it, it will end up running our lives. Once it's made optional, it's one more format to manage and maintain. There will always be those who insist it is de rigeur on articles they work on. Then will begin the edit warring and never-ending jostling for the validity of the format. -- Ohc ^¡digame!_{¿que pasa?} 18:51, 5 September 2013 (UTC)

The problem with this argument is that it ends up with "only those choices preferred by [any user ]". However, I do agree that the best compromise is the current one: allow its use in tables and "bare" lists but not in running text. However, this is a compromise that needs to be respected by both "sides" (am I ever hopeful!). Peter coxhead (talk) 08:45, 6 September 2013 (UTC)

May I add URL access-dates to that list. Using YYYY-MM-DD consistently in an article allows the reader to quickly differentiate between access-dates and publication dates. Martinvl (talk) 11:35, 6 September 2013 (UTC)

Being a proponent of YMD everywhere, I for one obviously would not object to what I think you propose. Startswithj (talk) 01:11, 11 September 2013 (UTC)

It's not a natural format for most English speakers. I'd rather it not be used at all on WP. Jimp 10:57, 13 September 2013 (UTC)

Being a proponent of the ISO 8601 format as well, I would, of course, support a change to allow the yyyy-mm-dd format everywhere. However, previous discussions have shown that some people are attempting to overturn even the long established consensus which allows the yyyy-mm-dd format to be used in lists, tables and references. I don't think it would be a good idea trying to defeat one extreme position by another, therefore I think the current consensus to allow the yyyy-mm-dd format in list, tables and references, but not in prose (except for if the article must use this format for some reason), is a good and working consensus. The number of people accustomed to ISO 8601 is constantly increasing, and there will be no turning back the more we get interconnected, so, in the long run the English Wikipedia will have to allow the yyyy-mm-dd format in prose as well for simple reasons of practicability, but apparently it is still too early for this to happen now. I think, it will happen naturally and noone will have reasons to object any more in a couple of years, so there is no reason to push it, IMHO. --Matthiaspaul (talk) 12:16, 21 September 2013 (UTC)

It's an ISO format, hence language has little to do with it. It is an extremely logical date format which neatly resolves the question of how numerical dates are to be written. Obviously, in prose, written dates are to be preferred as a (strong) rule, so the ISO format is quite irrelevant there, but I see no reason for it not to predominate in tables, references and suchlike, for the sake of brevity. Archon 2488 (talk) 22:24, 16 October 2013 (UTC)

Language has a lot to do with it. The encyclopædia is written using language. Ymd is still a very unfamiliar format to most of us. The reason not to put these in lists, tables, references or anywhere really is its unfamiliarity. Why not just get back to writing in English? The brevity argument is weak as dates with abbreviated month names are not significantly longer. Jimp 08:19, 12 November 2013 (UTC)

Abbreviated month names are a bad idea, as there is no standard way of abbreviating them – Sp, Sep, and Sept will all be found, for example. Citations are not "written in English", i.e. they are not continuous text; nor are some tables. Hence there is no reason not to use YYYY-MM-DD in such contexts. Peter coxhead (talk) 08:54, 12 November 2013 (UTC)

Dislike and disagree with the double negative above. This is a classic example I came across today why it's not a good idea to use purely numerical dates. You might think it's yyyy-mm-dd whilst another might think it's yyyy-dd-mm, the existence of standard notwithstanding. -- Ohc ^¡digame!_{¿que pasa?} 09:53, 12 November 2013 (UTC)

As it happens your example is the same date either way. But the real point is that at present we have a compromise that all "sides" should accept. I'd prefer more use of this style, you'd prefer less, suggesting the MoS is about right. Peter coxhead (talk) 10:36, 12 November 2013 (UTC)

What d'ya mean "the same date either way"? My familiarity with Eastern dates formats (Chinese, Japanese) makes me naturally predisposed to yyyy-mm-dd as "natural", but it's not at all the case for Westerners, and should be avoided. However, Britain and the USA are two countries separated by a common language and divided by "endianism". Using "2013-11-12" to mean 11 December 2013 is simply wrong, and that's what I was trying to illustrate with my example. I was trying to illustrate that a purely numerical format is not universally known nor unambiguous, notwithstanding the existence of the ISO 8601 standard. Just because the person used the less ambiguous "2012-17-12" in the example doesn't make it potentially the same date. Even abbreviated months, provided that we can agree on a standard (say 3-lettered) contraction, is infinitely preferable. -- Ohc ^¡digame!_{¿que pasa?} 01:52, 13 November 2013 (UTC)

What I meant was only the trivial point that the dif you gave shows someone adding "2013-11-11" – not the best example of your point. On the issue of whether abbreviated months is better, we simply disagree. I believe the ISO date format is better.

I repeat that we have a compromise in the MoS and we should all follow that consensus. YYYY-MM-DD dates are allowed in defined contexts (e.g. access/retrieved dates in citations) and should not be changed simply because some editors don't like them any more than they should be changed the other way round. Peter coxhead (talk) 08:21, 13 November 2013 (UTC)

I invite you to carefully examine the diff again. The newly added content includes a number of erroneous dates, such as "2012-17-12" which gave [@ERROR@]s when I treated it with my script. It's not a case of liking or disliking. Numerical dates are ambiguous. That was my point. -- Ohc ^¡digame!_{¿que pasa?} 08:58, 13 November 2013 (UTC)

I would agree with Ohconfucius that to pass this off as a question of likes and dislikes is missing the point. The arguments against ymd are that it is not familiar to most English speakers and, as mentioned, has the potential for allowing errors (in spite of the fact that YYYY-MM-DD is official and logically ordered whereas YYYY-DD-MM in neither). What are the arguments for ymd?

• It has been suggested that it's "arguably the most unambiguous format". Well, that argument doesn't fair well against the question "What's ambiguous about '15 November 2013' or 'November 15, 2013'?". Further, as mentioned above, it's only unambiguous to those who know it and that's not everyone as Ohconfucius has demonstrated.
• "Its big-endian format mirrors decimal numbering." Yes, this is true but we, as humans, don't generally think of dates in the same way as we do numbers so I'd argue that this is of little worth.
• "Its worldwide adoption keeps increasing, thanks perhaps to its use by computers, the military, and the ISO." Perhaps so but it's still less familiar to English speakers than the more traditional dmy or mdy formats.
• The conciseness of ymd makes it useful where space is limited. As has been mentioned a number of times, the space-savings of ymd as opposed to dmy or mdy with abbreviated month names range from negligible to non-existent. I propose deleting this misguided notion from the guidelines (yes, it's still in the MOS). If there be no standard for abbreviating month names, let's make one (or perhaps two). There is, though, already something of a WP standard in existence in that the {{#time:M}} parser function gives three-letter abbreviations. The only other common style that I'm aware of is to abbreviate month names of more than four letters to three followed by a full stop except for "Sept.". This could be allowed as a possible alternative. We don't need to allow anything that's out there. We don't allow "lbs" for pounds, "mtr" for metres, "kts" for knots, etc.
• It's also been suggested that it's the standard system used in South Africa and commonly used in Canada so falls under ENGVAR. I'm unconvinced. The US is officially metric. A country can declare a standard but do the population actually use it? And as for Canadians, sure, you might have to fill out dates on cheques and forms in year-month-day order but Canadians in general don't write dates like this.
• It allows readers to quickly distinguish access and publication dates if the former are written in ymd consistently throughout the article. Weigh the few milliseconds saved here against the time lost reeling at the inconsistency of having these less-than-familiar telephone-number dates juxtaposed with traditional one and ask whether it's worth it especially in the light of that fact that not every article will follow this practice.
• It's been noted that ymd dates are naturally sortable. This is irrelevant as the problem of sortablility has been solved by templates and improvements to the WM sort table software.
• Ymd in lists and tables, it's argued, has a long-standing consensus. As noted above, ymd doesn't significantly save space and isn't necessary for sorting so perhaps this consensus for allowing it in lists and tables is based on outdated and/or misguided notions. I wonder whether consensus hadn't already swung against ymd in lists and tables and the guideline just didn't manage to get updated. Perhaps it could be time to test this consensus.
• Ymd in references, it's also argued, has a long-standing consensus. The current abundance of ymd in references can, at least in part, be attributed to date-delinking. In the bad old days of autoformatting the citation templates would link all dates with the mistaken idea that they would be automatically formatted according to the reader's preference. Some dates parameters were required to be in YYYY-MM-DD format (otherwise you'd get a red link). When autoformatting was finally ditched these YYYY-MM-DD suddenly became plain for all to see. This plus the fact that people tend to follow the examples they see on other articles must account for some not insignificant proportion of the ymd dates we now find in references. Thus I find this consensus to also be somewhat unconvincing.
• Peter, you write "Citations are not 'written in English', i.e. they are not continuous text; nor are some tables. Hence there is no reason not to use YYYY-MM-DD in such contexts." Of course, this is not really an argument for ymd since I might well counter that there is no particular reason to use YYYY-MM-DD in such contexts either but, no, these are not exactly "written in English" but the fact that ymd is unfamiliar and error-prone are reason enough not to use it here.

Jimp 10:09, 15 November 2013 (UTC)

We can, of course, have yet another RfC on this, in which I and others could respond to your points. In the absence of this process, it seems to me that we are just going over old ground again (as we seem to do endlessly on MoS talk pages – anyone want to discuss dashes vs. hyphens again?). I'm willing to accept the current compromise. If you're not, you know what to do (but please don't – let's work on articles). Peter coxhead (talk) 14:18, 15 November 2013 (UTC)

Unless examples can be presented of writers purposefully demonstrating the use year-day-month formatting, I would assume that the linked edit showing yyyy-dd-mm is surely a typographical error, and other typos could likely be found supporting opposing positions on this topic. Startswithj (talk) 20:06, 24 November 2013 (UTC)

YMD, in my opinion, is only useful in sortable lists. DMY and MDY are the preferred formats and should be used consistently within both the body and the citations. JOJ ^Hutton 20:18, 24 November 2013 (UTC)

Ymd isn't even useful in sortable lists. Sortable tables are able to handle dates these days. Any problems that do still exist can easily be overcome using templates such as {{dts}} or {{sort}}.

No, I'm not happy with what you call the "current compromise", Peter. I'm not convinced that it is any true reflexion of consensus. I believe we'd find the proportion of users who'd advocate ymd anywhere but in references to be quite small. Further, the current abundance of ymd in references has, in my opinion, as I've mentioned before, little to do with user preference and a lot to do with the fact that the citation templates used to require it as input. Jimp 09:27, 25 November 2013 (UTC)

Problematic binary prefix paragraph

Compvis (talk · contribs) has been replacing, against a clear past consensus, with no evidence of even an attempt to find a present consensus,

In quantities of bits and bytes, the prefixes kilo (symbol k or K), mega (M), giga (G), tera (T), etc. are ambiguous. They may be based on a decimal system (like the standard SI prefixes), meaning 10³, 10⁶, 10⁹, 10¹², etc., or they may be based on a binary system, meaning 2¹⁰, 2²⁰, 2³⁰, 2⁴⁰, etc. The binary meanings are more commonly used in relation to solid-state memory (such as RAM), while the decimal meanings are more common for data transmission rates, disk storage and in theoretical calculations in modern academic textbooks.

with (emphasis added)

In quantities of bits and bytes related to "semiconductor storage" < ref>JEDEC. "Mega (M) (as a prefix to units of semiconductor storage capacity) (part of JESD100-B, 12/99)." Retrieved November 30, 2013.</ref>, unlike in any other field of business, medicine, science, technology and engineering worldwide, the prefixes kilo (symbol k or K), mega (M), giga (G), tera (T), etc. are ambiguous. They may be based on a decimal system (like the standard SI prefixes), meaning 10³, 10⁶, 10⁹, 10¹², etc., or they may be based on a binary system, meaning 2¹⁰, 2²⁰, 2³⁰, 2⁴⁰, etc. The binary meanings are more commonly used in relation to solid-state memory (such as RAM), while the decimal meanings are more common for data transmission rates, disk storage and in theoretical calculations in modern academic textbooks.

One might say this is supposed to represent the real world, so consensus need not be obtained before making a change, per WP:BRD, but, at least, the text irrelevant to Wikipedia should be excised. Normally, text in guidelines should not be changed without some evidence of correctness. — Arthur Rubin (talk) 17:14, 30 November 2013 (UTC)

No matter if the change is kept or not, I don't think you've done your job. You've undone my change while saying it's a lie. You might want to check your dictionary. While my change may be false, it's definitely not a lie, and it's quite surprising that you would jump to such conclusion. Is is the kind of behaviour an admin should have? Also, if it's false, it should be quite easy to point out in which other field an SI prefix is not decimal, thereby improving the discussion. Can you do this? As for me, I have never heard of such case, but I may be wrong. Another reason why I don't think you've done your job, is that I have no idea what I've done wrong precisely. Also I haven't checked but your "clear past consensus" probably very old. You could also have informed me about how to overturn that consensus, but you didn't. I have to admit I'm quite unimpressed by your reaction. Compvis (talk) 20:59, 30 November 2013 (UTC)

I agree the original text should be retained. The first sentence states that usage is ambiguous. The Japanese standard is not evidence for the binary usage occurring only with semiconductor storage; rather, it clearly indicates that the binary usage should be restricted to semiconductor storage and is otherwise deprecated but occurs, so the "unlike in any other field" generalisation is excessive as well as being superfluous. The paragraph already begins with restricting the scope to bits and bytes and goes on to mention that the binary usage is more common in relation to solid-state memory; that's enough. Arthur's edit summary "revert lies"[2] was surprisingly strong and I wouldn't criticise Compvis for not being persuaded by it. NebY (talk) 18:16, 30 November 2013 (UTC)

Two points:

1. I see no justification in calling Compvis's edit a lie. The onus is on Arthur Rubin to prove or retract that accusation.
2. The (self-evident) ambiguity of the prefixes K, M, B etc in the computer industry is the problem. The only real question is whether Wikipedia wishes its articles to follow that same ambiguity, when a simple alternative is available.

Dondervogel 2 (talk) 18:23, 30 November 2013 (UTC)

It is ambiguous and that's history. I expect K M B G T ... to be decimal power prefixes unless they're prefixing b or B or (preferably) bit or byte, then I read very carefully attempting to determine which it is (both decimal/binary base and bit/byte.) The confusion started long before there was solid state memory -- I'll go so far as to guess it started with the mechanical counters for paper tape and card reader/punches, which counted decimal, while the electronic counters for those counted octal. htom (talk) 19:48, 30 November 2013 (UTC)

Electronic counters can count in decimal just fine; see for example early digital voltmeters, frequency counters, pulse counters (seen in radiation monitors among other places), the Dekatron tube, etc. Even if you're building it out of logic gates and flip-flops, a decade counter is only slightly more complicated than a four-bit binary ripple counter, and the logic to then drive a multi-digit decimal readout is far simpler than from a binary ripple counter.

Of course electronic counters can count in decimal. One of the first I saw in the wild (1965), though, was counting up and down, in octal, steps in a paper tape reader. It was used for adjusting the position of the tape for reading without having humans do binary <--> decimal conversions. htom (talk) 05:12, 2 December 2013 (UTC)

The history of the confusion did start with computer memory... but with core, not solid state, as this was the first type of computer memory that was both a) binarily addressed, making powers of two the "natural" size and b) commonly appeared in sizes of 1024 addressable units or more. Some early uses of "K for 1024" and more of the "history of confusion" are referenced in Binary prefix. Jeh (talk) 07:52, 1 December 2013 (UTC)

The original text was correct and the qualification is unhelpful. The prefixes are indeed ambiguous in ALL contexts, when applied to bits and bytes. But Arthur Rubin had better remember that BRD does not stand for "Bold, Call Them A Liar, Discuss". – Smyth\^talk 20:11, 30 November 2013 (UTC)

On the other hand the text "The IEC prefixes kibi-, mebi-, gibi-, etc. (symbols Ki, Mi, Gi, etc.) are rarely used, even in technical articles" is at best misleading. It would be more appropriate to say "The IEC prefixes kibi-, mebi-, gibi-, etc. (symbols Ki, Mi, Gi, etc.) are the method of choice in scientific articles to avoid ambiguity, but they are almost never used in lay publications in which ambiguity is considered acceptable." Dondervogel 2 (talk) 22:46, 30 November 2013 (UTC)

Somebody needs to do a realistic analysis as to whether that even that is correct; the question of what disambiguation is used in scientific articles "to avoid ambiguity" needs to be established. I haven't read many scientific articles in fields where MB might be used, so I couldn't say, but there are other possible disambiguation methods which might be used other than the IEC-specified method.

As for calling him/her a liar, that was wrong. It was, however, an edit contrary to an established consensus, and he/she had been informed in April of that consensus. That it resembles a statement of fact, even though in a guideline, might have confused him/her. — Arthur Rubin (talk) 06:24, 1 December 2013 (UTC)

I believe that Dondervogel's suggestion represents OR (or, rather, OG: original guesswork). Someone needs to provide RSs showing that the "lay publications" in question really do consider ambiguity to be acceptable, and that that is their justification for not using the IEC binary prefixes, before we can entertain adding such verbiage. (I'd guess—yes, I'm guessing, but at least I'm admitting it—that the reason is more that most of their editors haven't even heard of the IEC binary prefixes.) Similarly, a survey of recent articles in e.g. the various IEEE publications and CACM needs to be undertaken before we can conclude that IEC prefixes are "the method of choice" in them.

In the meantime, we could just say that "they're rarely used" and let it go at that, dropping the "even in technical articles" part... if that is really so problematic. (TBH it's no more supported than "are the method of choice in scientific articles to avoid ambiguity" would be.)

This particular corner of MOS already allows the use of IEC binary prefixes in articles where the majority of sources use them. So, if they catch on, eventually WP will shift. Until then, it is not WP's job to lead the charge, even by so gentle a means as including in MOS an argument for their use. Jeh (talk) 07:52, 1 December 2013 (UTC)

I personally have never seen anything *other* than IEC prefixes used in technical articles seeking to avoid ambiguity, so the existing wording is simply and demonstrably incorrect. Of publications seeking to disambiguate (or at least claiming to), Wikipedia is the only one I know that goes through these ridiculous contortions to avoid them, ultimately in its own detriment, because in doing so it encourages ambiguity by discriminating against the simplest and most widely used disambiguation method. Dondervogel 2 (talk) 09:49, 1 December 2013 (UTC)

"I personally have never seen..." Sure. You simply characterize any article that does not use IEC prefixes as "not seeking to avoid ambiguity." Why don't you cite some examples? Jeh (talk) 16:42, 1 December 2013 (UTC)

I have already cited hundreds of examples at the Megabyte talk page. How many examples can you cite of an alternative disambiguation method other than the amateurish attempts on wikipedia? Dondervogel 2 (talk) 20:20, 1 December 2013 (UTC)

An "alternative disambiguation method" is beside the point and not required here to rebut you. The point is that the IEC prefixes are not anything like the "method of choice". Your claim to that effect is belied by your own search results; those are absolutely paltry numbers of hits. You claim to "have never seen anything *other* than IEC prefixes used in technical articles seeking to avoid ambiguity"? Try perusing this search. You see, where you got 643 hits on GiB MiB, I simply changed your search keywords to GB MB and got over 100,000. What kind of "method of choice" is it if it's chosen for fewer than 1% of articles? Jeh (talk) 04:39, 2 December 2013 (UTC)

• I checked the first 10 from your list of hits. Of these one (Li et al 2005) is a false positive. Of the other 9, not one make any attempt at disambiguation. All are content to use "1 MB memory", "20 GB/s data stream" or "11 Gb/s data rate" as if it were obvious what is meant by the "M" and the "G" (and by the "b" and "B" for that matter) to all readers. I can make an educated guess, as I am sure could you too, but the whole point of disambiguation is to make guesswork unnecessary.
• My first 10 hits also include one false positive (Zhang & Yu 2005). The other 9 all use IEC prefixes to disambiguate. .

That makes the tally 9-0 so far in favour of use of IEC prefixes for disambiguation, out of 20 articles investigated. So far you have not provided one single example of a disambiguation method other than IEC. Is that because you do not know any alternatives in current use? Dondervogel 2 (talk) 17:06, 2 December 2013 (UTC)

I'm not looking for "alternate disambiguation methods." I'm simply showing you that your claim of universal usage of IEC prefixes is ludicrous.

Sure, you are simply declaring any article that does not use IEC prefixes as "not disambiguating" and therefore not relevant to your argument. I rather think that the vast majority of the technical community (that you're trying to say is on your side) actually thinks there is not sufficient ambiguity to make it worth using the IEC prefixes. (And that position very much is relevant to your argument.)

So who is WP to disagree with the vast majority of the technical community? As has been said a very large number of times, Wikipedia must follow its sources. If most of a WP article's sources use IEC prefixes then, per WP:COMPUNITS, the WP editor can use them. Otherwise, we (I'll say it again) must follow our sources. The results you have just observed show that the vast majority of articles in your search results do not use IEC prefixes.

You might also consider that WP, while it does contain highly technical information, is not written for a highly technical audience. It's written for a general audience. Every time this issue has come up, consensus has been that most of our readers are unfamiliar with the IEC prefixes. And we are not supposed to use terminology here with which most of our readers are unfamiliar. This is why we have WP:COMMONNAME, among others.

Please note: I like the IEC prefixes. I'd like to see them more widely used. I use them in my own work. I was once on the opposite side of the argument here. But I came to realize that WP is not the place to promote them, not when most readers are unfamiliar with them and most of our sources don't use them. Jeh (talk) 19:27, 2 December 2013 (UTC)

OK, now I think we are getting somewhere. I have never claimed that there is universal usage of IEC prefixes. I agree that use is rare outside of scientific publications. I am also not arguing that an article using MB to mean (1024)^2 bytes is automatically ambiguous. It becomes ambiguous only if it fails to explain that MB means (1024)^2 bytes, especially when it is used in the same article to mean (1000)^2 bytes!!! Wikipedia does prefer familiar units, and for good reason. Is that familiarity intended to be at the expense of precision in some contexts? Mosnum requires editors to follow some complicated disambiguation rule that no one else in the Universe uses (in what sense is "(1024)^2 bytes" consistent with following sources?), with the inevitable result that no one bothers, making the articles ambiguous. If this proliferation of ambiguous articles is the desired end result (in the sense that it is preferred over the dreaded MiB), then that is what mosnum should say, but it doesn't. In a nutshell I see a simple choice here: either accept the mebibyte or accept the inevitable ambiguity that follows from use of "megabyte". Which is it? Dondervogel 2 (talk) 20:44, 2 December 2013 (UTC)

My own use in my own notes is X₂b or X₂B but that's not really handy except to people writing drafts with pen or pencil.htom (talk) 21:32, 2 December 2013 (UTC)

Dondervogel, you are offering what is called a false dichotomy. I don't think use of megabyte to mean 1024 squared in an article where that usage is common (say, regarding RAM) is at all ambiguous. And our search results indicate to me that the authors and editors of roughly 99 out of 100 IEEE articles feel the same way. In other words, the existing MOSNUM text

The IEC prefixes kibi-, mebi-, gibi-, etc. (symbols Ki, Mi, Gi, etc.)
are rarely used, even in technical articles

is quite correct.

But if you insist on seeing things your way, then Wikipedia has indeed chosen to, in your worldview, "accept the inevitable ambiguity that follows from use of 'megabyte'." Trouble is, I don't think you've made a case for Wikipedia doing otherwise, since your concern over rampant ambiguity seems to be very much a minority opinion.

You are concerned about ambiguity in WP articles that use e.g. "MB" or "megabyte." Well, switching to using MiB for e.g. RAM sizes would replace ambiguity with confusion for the vast majority of readers. And simply sticking with GB in articles about hard drives, even though supported by IEC, would not reduce ambiguity or misunderstanding... as a significant fraction of readers seem to be convinced that MB always means 1024 squared bytes, and this would do nothing to educate them. (Look at some of the woefully uneducated comments on this point in talk:Megabyte.)

So if your prime concern is this ambiguity in WP articles, you could find all of the articles that use these prefixes and add a footnote to their first use in each, stating that in this article, megabyte means 1024 squared, or gigabyte means 1,000,000,000 bytes, or whatever is applicable. In fact I think there's even a template for that. In other words... editors are rarely bothering to disambiguate? WP:SOFIXIT. Jeh (talk) 03:29, 3 December 2013 (UTC)

The 99% of IEEE authors that you refer to (if it really is that many - I agree it could but it is hard to tell) make no pretence at disambiguation. Either they are unaware of the ambiguity or they don't care enough to do anything about it. I am not one of them so I can't tell. Mosnum claims to require disambiguation and that is the difference. In some cases it provides the tools required to do so - for example, last time I looked it requires Mbit/s (not Mbps) for megabit per second, nmi (not nm) for nautical mile, even where the sources use 'Mbps' (or just plain 'Mb') or 'nm'. I fail to see why that is any different to using MiB (not MB) when (1024)^2 bytes is intended (yes - even when the sources use MB). In all cases the converted unit is less familiar and less ambiguous, and in each case a judgement is needed by the editor doing the conversion. I have disambiguated many articles with nmi, Mbit/s and similar. The disambiguation tools offered for MB are IMO either too complicated or ineffective. Dondervogel 2 (talk) 07:23, 3 December 2013 (UTC)

• The IEC bibyte stuff should not be generally used on Wikipedia. Generally speaking the real world still does not use KiB, MiB, GiB or TiB etc so don't use them in articles. Instead use the most commonly accepted use which is KB, MB, GB etc... Or instead use numbers of bytes or power notation. Fnagaton 18:29, 3 December 2013 (UTC)

The IEC binary prefixes were proposed almost 20 years ago and have failed to be adopted by the computer industry. It appears that some academics are using Mib and GiB as a secret handshake that they alone understand. I was reading an article titled "Data for the 31st Century" in the latest IEEE Spectrum magazine.[3] It mentions Oracle's "new database system housing a whopping 32 TB of DRAM".[4] Here are some of the specs on the Oracle SuperCluster M6-32.

• 32 x twelve-core SPARC M6 processors (3.6GHz)
• 1024 x 32 GB, for 32 TB total memory
• 32 x 900 GB 10,000 RPM disks

Wikipedia uses the terminology that is commonly used in the real world. We don't use esoteric terms to describe common items even if the esoteric term is more exact. Oracle is comfortable selling a computer with 32 TB of RAM and an array of 900 GB disks. You will be able to by this at your local electronics store in 10 years; GiB and TiB will still be the binary unit of the future. -- SWTPC6800 (talk) 04:12, 4 December 2013 (UTC)

Commas

When a date in the mdy format is used as a noun, common sense, English-language precedent, grammatical logic and our own style guide all require commas placed after the day as well as the year (unless a semicolon or period, etc., are used in its place). For instance, "The tornado that hit us on July 5, 1987, was a booger." But does this also apply to dates used as adjectives? "This year's bovine flu outbreak was bad, but the December 23, 1958 outbreak left 409 cows dead on our farm alone." Or would you put a comma there after 1958?? Red Slash 01:09, 5 December 2013 (UTC)

• Leave out day number and use hyphen: To improve readability of date adjectives, consider omitting the day (and comma) and then add a hyphen, as the "December-1958 outbreak" or "August-2005 Katrina storm surge" to give readers a visual cue how the date will be used as an adjective. Another trick would be to mention the exact day of the month nearby, to allow omission in the adjective date as only month-year format. Guidelines are not mandatory, so try to tailor the style rules to the typical readers of a page. -Wikid77 23:23, 5 December 2013 (UTC)

What would you have done at Talk:April_14–16,_2011_tornado_outbreak#Requested_move? Red Slash 05:14, 6 December 2013 (UTC)

This is wrong and not supported by the MOS. A month and year are never hyphenated (December-1958 outbreak is wrong; it would be December 1958 outbreak). Don't invent rules. Don't suggest tailoring style for individual pages. Follow the MOS and promote consistency, as this will better help all readers across Wikipedia. —sroc 💬 13:05, 6 December 2013 (UTC)

Wrong, wrong and wrong again. A month-year combination can be hyphenated as an adjective, and in fact with the word "early" or "late" then hyphenate all together, as in, "The outbreak came as a late-December-1958 event" or similar. Don't tell people to don't hyphenate or don't tailor style, because the style very much depends on the context, as tailored for customary rules in each subject area, with some flexibility. -Wikid77 (talk) 17:59, 6 December 2013 (UTC)

The example, you gave, December-1958 outbreak, does not have a hyphenated prefix or suffix, so never calls for the month and year to be joined by a hyphen; show a reputable style guide as a source that says otherwise. Moreover, the original post does not refer to compounds with "early" or "late", so these cases are irrelevant to the question. Stop encouraging others to follow your invented style which contradicts MOS. —sroc 💬 05:40, 7 December 2013 (UTC)

There is disagreement on whether the second comma is required in such cases, but the construction should generally be avoided where possible. Please refer to the detailed discussion at Wikipedia talk:Manual of Style#RFC: Proposed amendment to MOS:COMMA regarding geographical references and dates. —sroc 💬 13:05, 6 December 2013 (UTC)

MOS:YEAR

If a company is in operation possibly from sometime in the 1910s until, let's say, 1958, but the 1910s part is only an approximation, then is it proper to write "c. 1910s–1958", or is "c." used only for specific years and not ranges? Rgrds. --64.85.215.35 (talk) 16:07, 6 December 2013 (UTC)

• The "c." is merely abbreviation for "circa" in text: I conclude that your hunch is correct, where "c. 1910s" would be interpreted by many people as "near the 1910s decade" and do not worry if "proper" because the term "circa" can be used in many different contexts, not just with a specific year. -Wikid77 (talk) 17:37, 6 December 2013 (UTC)
• There is a potential ambiguity – whether the c. is to apply to 1958 or not. If it matters, it seems a recast would be needed – e.g. "Starting in c. 1910s and ending in 1958". —[AlanM1(talk)]— 18:23, 6 December 2013 (UTC)
  • The context of the list I'm working on would not lend to ambiguity in this case. Thanks for your input; it's appreciated. Rgrds. (Dynamic IP: changes when I log off.) --64.85.215.45 (talk) 13:48, 7 December 2013 (UTC)

Our article circa is clear about four cases closing with

[4] c. 1732 – c. 1799, both the years shown and the date range are approximately known

--P64 (talk) 23:11, 7 December 2013 (UTC)

Sources for singular fractions

Can someone name/link some wp:RS source webpages which explain use of singular fractions (less than one), such as "one-half foot" (not "one-half feet") or singular "one-third kilometre" (not "one-third kilometres" plural). A scan with Google search confirms widespread usage of singular fractions, but if we could cite some professional style guides or grammar webpage about singular fractions that would be great. Thanks. -Wikid77 23:23, 5 December 2013 (UTC)

I would think you don't really need a source, just consensus. Dondervogel 2 (talk) 03:35, 6 December 2013 (UTC)

How about "half a foot", "half a pound", etc.? These are normal for AmE, but I don't know if they are slang. —[AlanM1(talk)]— 00:37, 10 December 2013 (UTC)

Month abbreviations with four letters

I changed the acceptable date abbreviations to be consistent with WP:MOS, which has accepted month abbreviations with periods since 13 August 2011. In 15 August 2012 an edit was made to this guideline to "summarize" the advice about formats, but the edit did more than summarize, it introduced new restrictions without discussion.

I cannot find any discussion where there is a clear decision about whether month abbreviations may have four digits (such as "Sept.") but that is certainly common outside Wikipedia. I can't find justification for this reversion. Jc3s5h (talk) 23:08, 10 December 2013 (UTC)

All the examples at MOS:DATEFORMAT (8 Sep 2001; Sep 8, 2001; Nov 1, 2008; 20 Sep 2008; 5 Feb 2009) and WP:MOS#Months and seasons (Feb.; Feb) use three letters, not four. Your edit introduced four-letter abbreviations without discussion. The change is controversial and should be discussed first. —sroc 💬 23:25, 10 December 2013 (UTC)

Re: "common outside Wikipedia", other than "Sept", I can't think of any standard 4-letter abbreviations of month names longer than 4 letters. —[AlanM1(talk)]— 23:30, 10 December 2013 (UTC)

Examples are exactly that, examples. If the guideline does not say abbreviations should be exactly three letters, any abbreviations in common use should be acceptable. Jc3s5h (talk) 02:23, 11 December 2013 (UTC)

The changes should not be made without consensus. Tony (talk) 03:04, 11 December 2013 (UTC)

sroc, where I grew up, school students were taught to use "Sept." as the abbreviation for September, and to not abbreviate June or July. So that makes three month names that have four letters within the set of abbreviations. Jc3s5h (talk) 10:52, 11 December 2013 (UTC)

Did you mean to direct that to me or AlanM1? In any case, June and July are not abbreviations and neither Sept nor Sept. are given as examples of acceptable abbreviations in MOS. It may be an abbreviation that you and others use, but that is separate from the issue whether they should be used on WP. Personally, I would prefer to stick to three-letter abbreviations for consistency and because this helps to align dates in the context of tables where abbreviations are more likely to be used. —sroc 💬 11:21, 11 December 2013 (UTC)

Three and one-half miles

• Oklahoma State Highway 147#Route description: Approximately three and one-half miles (5.6 km) north of....

  What about: Approximately three and a half miles (5.6 km) north of...?

I'm finalizing some details for Module:Convert which I hope will soon be used to implement {{convert}}. Currently, the existing templates (convert) say "three and one-half", whereas the module (convert/q) says "three and a half":

• {{convert/spell|3+1/2|km|mi}} → three and a half kilometres (2.2 mi)
• {{convert/q|3+1/2|km|mi|spell=in}} → {{convert/q|3+1/2|km|mi|spell=in}}

I have looked at so much broken and inconsistent text lately that I cannot form an opinion on what to do. This article may well just say "3.5 miles", but I'm wondering about the general case. It's not very important because I think this is the only article where the issue arises, but I may as well get it right. I suppose that it justs depends on what one is used to, although WP:NUMERAL includes Nine and a half. Johnuniq (talk) 02:58, 9 December 2013 (UTC)

"three and a half miles" is excessively informal for an encyclopedia in my opinion, but the the thing that caught my eye is that the construction "Approximately... (5.6 km) north of...". 5.6 sounds doesn't sound like an approximation to me. Sort of like saying "Man, I feel like I've had ten tons (9071.85 kilograms) taken off my shoulders!" If you're going to round the original description to some approximation of the actual value you should do that for the conversion value also -- probably by hand I guess, unless the conversion templates have some rounding function -- or else you're going to imply a precision that isn't there. Herostratus (talk) 04:30, 9 December 2013 (UTC)

Firstly, I agree the words are too informal for most cases, but I'm sure exceptions can be found. Secondly, I think that "three and a half" is superior to "three and one-half" as it is more natural. Thirdly, I agree that "5.6" appears overly precise because "three and a half" seems less precise than "3.5", so it would read better as three and a half miles (5+1⁄2 km) where the conversion is similarly imprecise. Fourthly, should it be "three-and-a-half"? —sroc 💬 04:50, 9 December 2013 (UTC)

I think the "...a half..." form might be preferred on some British English articles, e.g on leisure talks. The precision implied from 1+1/# is more than one decimal place and less than two. The conversion might dictate a drop of one in precision - thus, helpfully :/, more than zero decimal places and less than one. My preference is for the upper bound, 5.6   – Ian, DjScrawl (talk) 05:08, 9 December 2013 (UTC)

In the context of a conversion that is expressed as three and a half miles, which seems to be accurate to half a mile, the equivalent 5+1⁄2 km would be understood as being accurate to roughly half a kilometre, which is a reasonable approximation; conversely, 5.6 km implies accuracy to .1 km, which is impossible to determine from the data given. Part of the difficulty with attempting to convert figures expressed in words will be interpreting the expected level of accuracy (3.5 mi seems more precise than three and a half miles) which may be hard for a computer to gauge in order to respond with a correspondingly precise conversion (5.6 km in the first case or 5+1⁄2 km in the second case). As rare as these cases may be, I think this would be best left to manual use of parameters to set the level of precision to be displayed or otherwise simply being manually entered. —sroc 💬 07:45, 9 December 2013 (UTC)

I would say and write "a half". "One half" sounds unusual. —[AlanM1(talk)]— 00:32, 10 December 2013 (UTC)

As in Cadbury's "glass and a half" slogan. —sroc 💬 03:54, 10 December 2013 (UTC)

"three and one-half" is just horrid. Plain English, please: "three and a half". I've learned to live with the US-originating "one-third of all players", etc. But personally I'd go simple and short: "a third of all players". Tony (talk) 01:53, 14 December 2013 (UTC)

rounding prices e.g. $399.99

I'm having trouble convincing some editors that if something is priced at $399.99 then the correct rounding is $400, not $399. I'm thinking of adding a small section to this page to explain rounding to the nearest integer. OK? Bhny (talk) 19:34, 30 November 2013 (UTC)

Why does it need to be rounded if the sources says 399.99 ? MilborneOne (talk) 19:37, 30 November 2013 (UTC)

In an info box where if everything had five figures it would not fit e.g. PS 4. Also there is no need for that kind of precision. The figure is going to be rounded so I need to be able to point editors to the correct method. Bhny (talk) 19:41, 30 November 2013 (UTC)

That article already uses 399.99 without any problem I dont see why it has to be changed or rounded, I have not seen it but I presume that is also what the source for the price says as well. MilborneOne (talk) 20:17, 30 November 2013 (UTC)

I'm trying to get agreement for standard MOS for rounding, not a particular edit. If no one objects I'll just write the section. (Someone just did that edit to PS4 as a compromise.)Bhny (talk) 20:23, 30 November 2013 (UTC)

OK I dont have a problem with your rounding up/down and clearly 400 would be the right result here, but I still have an issue of changing figures from that which has been sourced so should not be rounded in the first place. MilborneOne (talk) 20:26, 30 November 2013 (UTC)

There's no need to round: it takes little more space, WP is not so space constrained, and $399.99 is correct. Putting anything else without saying it's rounded would be misleading – e.g. contradicting accurate statements from Sony that it costs under $400, or being out by 99¢ if rounded down. Saying it's rounded would take far more space than just giving the right figure, as is given in sources.--JohnBlackburne^words_deeds 21:08, 30 November 2013 (UTC)

Unless we are actually citing a source, we have no obligation to use a source word-by-word. We can (and typically do) rephrase a statement in our own words. So, if a source says "$399.99" and if we do not need that precision in the article for some reason, we can safely use "$400" in the article without worrying about introducing unsourced statements. It doesn't change the meaning. We even don't need to state that it's rounded, unless this would be an important fact in itself (and in this case, we might just state "$399.99"). --Matthiaspaul (talk) 15:12, 17 December 2013 (UTC)

I disagree. Rounding happens with prices all the time. A building costs 3 million etc. All distances and measurements are rounded to some significant figure. The section could be about rounding and significant figures in general, including math and science numbers. Correct rounding obviously happens in many articles already where the editors are aware of this. I don't see how cents are different. Bhny (talk) 21:14, 30 November 2013 (UTC)

If the source uses a rounded figure then we can. Economic figures are often rounded: the GDP or inflation rate to the nearest 0.1%, government borrowing to the nearest billion, and so on. Buildings are different: $3m might be the price. Here properties are often priced to only 1 or 2 significant figures, especially commercial properties. The cost to build something may only be an estimate so only given approximately. But in all cases we follow sources.--JohnBlackburne^words_deeds 21:34, 30 November 2013 (UTC)

Obviously some sources have to be rounded [[5]]. I guess you are saying that if a figure is rounded from the source, it should say that it is rounded or approximate. Bhny (talk) 23:02, 30 November 2013 (UTC)

• I find that psychological pricing is a rather deceptive marketing nonsense aimed at fooling the customer into thinking something is cheaper than it really is. Unfortunately, it's also used by some consumer magazines as a basis of categorising or giving awards, where we have "best xxx under $400". I think may be acceptable for editors to write an article and round $399.99. But when they do, it should be up to $400 – $399 is clearly wrong but is what the marketers would prefer. But when it comes to mentioning such awards, we may need to clarify that it was priced a a penny below $400. And if there's a dispute and something hangs on it – but usually nothing does except fucking with people's minds – we need to be precise with the numbers. -- Ohc ^¡digame! 03:24, 1 December 2013 (UTC)

Just as a sidenote, I saw "five and a half years in jail" be "rounded" to "five years in jail". The source (BBC) said five years (and further down five and a half years). Just pointing this out as an example that I assume the exact number applies. At first I only saw the "five years" part in the BBC source but knew from a non-English source that it was not true. I wander what dould have been the right thing to do (non-English source ref I guess even though most would not be able to confirm). comp.arch (talk) 11:54, 13 December 2013 (UTC)

Is YYYY-MM an acceptable date format?

Is YYYY-MM (e.g. 2011-05 to represent May 2011) an acceptable date format? MOS:DATEFORMAT is silent on this issue. ISO_8601#General_principles says that YYYY-MM is acceptable, and MOS:DATEFORMAT appears to be based in part on that standard.

The reason I ask is that a number of scientific articles are showing up in Category:CS1 errors: dates‎ because editors have used the YYYY-MM date format to list the month and year of a cited journal's publication. The CS1 error-checking code looks for dates that conform strictly to the date formats listed in MOS:DATEFORMAT, and since YYYY-MM is not explicitly listed in MOS:DATEFORMAT, dates in that format are flagged as errors. – Jonesey95 (talk) 23:07, 27 November 2013 (UTC)

I would think it's a bad idea, particularly because of the potential for confusion between e.g. 2005-06 (June 2005) and 2005-06 (period from 2005 to 2006). The latter is endorsed for a year range per WP:YEAR. Kahastok talk 23:19, 27 November 2013 (UTC)

I concur. This is consistent with WP:MONTH, which states: "Months are expressed as whole words (February, not 2), except in the YYYY-MM-DD format." In other words, we use June 2005 or 2005-06-01 but not 2005-06. —sroc 💬 02:55, 28 November 2013 (UTC)

Thanks. I had not found WP:MONTH. Would it be reasonable to add "2001-06" to the Incorrect/Correct table in MOS:BADDATEFORMAT, in the same "Incorrect" cell as "June, 2001"? I would like to see that in there explicitly, as I expect there may be objections if I change dates in the articles described above so that they match WP:MONTH. I propose changing the table to read as follows:

Incorrect	Correct
9th June the 9th of June 9. June	9 June
June 9th	June 9
June, 2001 2001-06	June 2001
9 June, 2001 09 June 2001	9 June 2001
June 9 2001 June 09, 2001	June 9, 2001
'01	2001

Objections? – Jonesey95 (talk) 04:49, 28 November 2013 (UTC)

Looks good. It might also help to avoid any misconception that "except in the YYYY-MM-DD format" in WP:MONTH would allow YYYY-MM format dates for month and year only. And avoid it being overlooked. —sroc 💬 07:50, 28 November 2013 (UTC)

• Endorse new table, at the risk of being creepy. -- Ohc ^¡digame! 01:52, 29 November 2013 (UTC)
• Also endorse new table. It's not creepy, just the inventiveness of editors who don't happen to think of a confusion they might create. htom (talk) 02:03, 29 November 2013 (UTC)

Don't get me wrong; I think it's a minor case of creep too, but the new CS1 date-checking code is calling it out as an error, and it was not explicitly permitted or denied (and YYYY-MM is permitted in ISO 8601). In my experience, it is good to have a section of MOS or some other consensus to point to when fixing these CS1 errors, otherwise reverting and grumpiness ensues. We've seen it happen recently with citations tagged as having deprecated parameters. – Jonesey95 (talk) 05:38, 29 November 2013 (UTC)

• As Jc3 keeps on saying, MOSNUM never specified nor named 8601. It just lists "yyyy-mm-dd" as an acceptable date format to use in the reference section. And he's absolutely correct. yyyy-mm is never mentioned in MOSNUM. -- Ohc ^¡digame! 07:38, 29 November 2013 (UTC)

This brings up a conflict. If an article has all its references in ISO 8601 yyyy-mm-dd format but one of them only specifies year and month then this newly changed MOS:BADDATEFORMAT says it can't use ISO 8601 (presumably dropping back to formats like February 2013). But we now have two different formats in reference dates, which conflicts with MOS:DATEUNIFY, which says all reference dates must be in the same format. So I would tweak MOS:BADDATEFORMAT to say that yyyy-mm is disallowed for prose only and that it is perfectly accepted wherever yyyy-mm-dd is acceptable (ie references and tables but not prose).  Stepho  talk  20:33, 13 December 2013 (UTC)

Can you rule out the possibility that a publication might give a publication date as 2010-11, meaning that it covers some period of time beginning in 2010 and ending in 2011? (Such as the phone book in my hand.) You might argue that should be written as 2010–11, but in many fonts, the difference is not discernible; this idea has been rejected in the past since the difference is so hard to see. Since the possibility exists that the format 2010-11 could refer to a time span rather than November 2010, the format should not be used to describe a month. Jc3s5h (talk) 21:14, 13 December 2013 (UTC)

Support. That some readers of some fonts may interpret some publication double-year 2010–11 as 2010-11 should not interfere with this sound proposal. One who uses the reference to consult a source will learn that the publication reports double-years and will probably then understand 2010–11 as a double-year, which is sufficient. A few may not, but we cannot prevent all error, and should take for granted some savvy on the part of readers who consult double-year sources. --P64 (talk) 23:53, 13 December 2013 (UTC)

@Jc3s5h: No, I can't rule that out. But I think it an unlikely scenario. Most publications covering a date range put the range in the title (eg company 2011-2012 financial results and 2011-2012 phone books) and have a single date of publication (if a publication date is not given then financial results can safely be assumed to be the later year and phone books can safely be assumed to be the earlier year). For the very, very few that do put an actual range as the publication date (do you have an examples of this?), we can use the 2011-2012 format. Whereas publications with years and months but no day are actually quite common (eg printed magazines). A rule saying yyyy-mm is never allowed is effectively forcing us to either mix 2011-05-21 style dates with December 2011 style dates (which violates MOS:DATEUNIFY) or to not allow yyyy-mm-dd dates at all (which is an unacceptable loss of freedom). Most people will have commonsense - if they see lots of reference dates like 2011-12-21, 2011-12, 2011-12-31 then they will people make an educated guess that the middle one means May 2011 and not the years 2011 to 2012 - or they will look it up, as suggested by P64.  Stepho  talk  03:52, 14 December 2013 (UTC)

I actually think that it will not even occur most people, who have not read the ISO 8601 standard - a standard that, it's worth reminding everyone, we have not adopted - and are unaware of all of its intricacies, that "2011-12" could possibly mean anything other than a "2011-2012". "2011-12" meaning December 2011 is hardly well known and I would not expect it to be understood as such even in a list of references otherwise entirely filled with yyyy-mm-dd. Kahastok talk 12:58, 14 December 2013 (UTC)

Yes, some printed magazines and suchlike differentiate their issues with a month and a year but no day. But the Cover date is very often not the publication date. Some cover dates extend beyond a single month; for example I have here bi-monthly issues - all of the same magazine - cover-dated December 2009-January 2010, 12/01.2006 and 12.2000/1.2001. That's fine because we can and should cite the cover-date as the issue, exactly as shown on the covers. That is not an argument for permitting YYYY-MM publication dates; indeed, any attempt to use a YYYY-MM publication date is very likely to be an attempt to use the wrong date. NebY (talk) 14:27, 14 December 2013 (UTC)

The documentation for one system of citing a periodical, {{cite journal}}, is rather hazy and confusing about whether to cite a date or an issue. Chicago Manual of Style 16th ed. pp 731–2 and 738–9 are more clear. The date is the publication date is what the publisher prints as the publication date. I haven't encountered a journal or magazine that has a different date on the cover than what is printed inside, but if I did, I would use the inside date. The issue is the number of the issue. It is only required for scholarly journals, not for popular magazines. If a scholarly journal has continuous pagination for the entire volume (which is usually a year) it is mandatory to include the issue number. If the scholarly journal begins each issue with page 1, the issue number is optional so long as the date is provided. So for example I would cite an article from the magazine in my lap as

1. John L. Marshall, "Screwdriver Antenna Atop a Light Stand," QST, January 2014, 35–7.

Although an issue number, 1, is printed on the same page as the masthead and table of contents, I omit it because I think of QST as closer to a popular magazine than a scholarly journal. Jc3s5h (talk) 15:53, 14 December 2013 (UTC)

There is a simple solution that avoid the conflict: change the format of all those dates to another acceptable format (e.g., 12 Feb 2010) so that it complies with both MOS:DATEFORMAT and MOS:DATEUNIFY. —sroc 💬 05:37, 14 December 2013 (UTC)

You are effectively proposing that yyyy-mm-dd can not be used in any article. A change that requires a significant percentage of all articles to change is hardly a simple solution. yyyy-mm-dd has been a perfectly acceptable format to use until this very recent change. But an even simpler solution (that doesn't require an arbitrary change to thousands of articles) is to remove yyyy-mm from the denial list.  Stepho  talk  11:26, 14 December 2013 (UTC)

No, I am not saying that YYYY-MM-DD cannot be used in any article (although already it is only acceptable in certain space-saving situations, not in prose). What I am saying is that YYYY-MM should not be used, and if using another format (such as MMM YYYY) for some dates alongside other dates in YYYY-MM-DD format would violate MOS:DATEUNIFY, then the solution is to use another acceptable date format for the dates in that article. —sroc 💬 12:21, 14 December 2013 (UTC)

But effectively you are saying the yyyy-mm-dd can not be used. Let's say that I am maintaining an article that consistently uses yyyy-mm-dd in all its references - as I am quite free to do under existing Wikipedia guidelines. Then let's say a single editor adds a single reference that only has a year and month. Your brand new, freshly minted rule of not allowing yyyy-mm dates means that the new reference has to use a mmm yyyy style date. This causes a conflict with WP:DATEUNIFY. Which means forcing every yyyy-mm-dd date in the references to be changed to dd mmm yyyy or mmm dd, yyyy. Since many of the articles that I maintain do use paper magazines for references, you have effectively said that I can no longer maintain these articles using yyyy-mm-dd dates. The two solutions are to lose my freedom of choice of a perfectly valid date format or to allow yyyy-mm in references.  Stepho  talk  06:03, 15 December 2013 (UTC)

Also, forcing me to change all the reference date formats in an article violates WP:DATERET - no changes unless there are strong national ties or talk page consensus.

A possible solution is to allow yyyy-mm but only for references when the other references are in the yyyy-mm-dd format.

Another possibility is for year ranges to be in the format 2013-'14 (ie an apostrophe to indicate the missing digits, which is consistent with general English grammar rules). Personally I prefer always putting year ranges as 2013 to 2014 to avoid any misunderstanding for readers new to English.  Stepho  talk  06:29, 15 December 2013 (UTC)

Let us be clear: it is not a "brand new, freshly minted rule of not allowing yyyy-mm dates" (and it's not my idea, either). MOS:DATEFORMAT specifies acceptable date formats but does not include YYYY-MM as acceptable under any circumstances. The acceptable format YYYY-MM-DD (described as "Four-digit year, hyphen, two-digit month, hyphen, two-digit day") does not allow YYYY-MM, so you are already not permitted to use that format. This is with good reason, to avoid confusion with YYYY-YY, because this is a format readers will readily recognise, regardless of whether we were to adopt a consistent format of YYYY–'YY or YYYY–YYYY for year ranges (although MOS:YEAR currently permits YYYY–YY). In any case, MOS does not currently allow YYYY-MM format so this is not a "new" rule but a clarification. The fact that this means YYYY-MM-DD format will not work in some cases due to a conflict with MOS:DATEUNIFY is not new either, you just didn't realise it until now. Finally, MOS:DATERET does not exempt compliance with the aforementioned guidelines. —sroc 💬 09:35, 15 December 2013 (UTC)

Not quite. Previously 5 date formats were explicitly allowed: D MMMM YYYY; MMMM D, YYYY; D MMM YYYY; MMM D, YYYY and YYYY-MM-DD). Notice that all of them have days, month and years and none of them allow month+year only combinations. If you want to say that only the explicitly allowed formats are allowed then February 2013 is not allowed. Conversely, the unacceptable list did not state that yyyy-mm was disallowed until 29 Nov 2013 - which makes it a new, freshly minted rule - or at least a new addition to an old rule that causes it to be applied in a new scenario. However, I will retract the 'your' part of 'your rule' - it was meant in the plural but I didn't express it clear enough. As for my not realising the implications of the rules, well I'm hardly without company. Until now it has been a grey area about how to handle yyyy-mm. It was neither explicitly allowed nor explicitly denied. If formats like MMMM YYYY are assumed to be valid as an extension of D MMMM YYYY being valid (even though not explicitly listed) then YYYY-MM can also be assumed to be valid as an extension of YYYY-MM-DD being valid. But to explicitly allow it creates a conflict with date ranges. And to explicitly deny it creates a conflict with DATEUNIFY with the knock-on effect of effectively denying YYYY-MM-DD as an allowed format - even though YYYY-MM-DD is explicitly allowed. What is the point of explicitly allowing a format if it can not be used in practice? As for DATERET, until 29 Nov 2013, the many pages using YYYY-MM-DD in referneces with the occasional YYYY-MM were not in conflict with any rule. Slipping in that one extra denial rule force a change on many pages and effectively rules out any practical use of YYYY-MM-DD. A rule change that makes a significant change to many pages should not have been made so quietly without a much larger consultation than just the handful of editors that commented on this page last month.  Stepho  talk  23:18, 15 December 2013 (UTC)

If we decided to tolerate the ambiguity of whether 2011-12 means December 2011 or 2011–12, we would still have a problem. It isn't all that uncommon to find publications with publication dates like June–July, 2013. So how would such a publication date be represented if other publication dates in the article were in the YYYY-MM-DD format? Jc3s5h (talk) 01:49, 16 December 2013 (UTC)

Hmm, I hadn't considered that case. Magazines that come every 6 weeks tend to do that every second issue. I could argue that the range is in the title or possibly is a sale date range rather than a publication date (which I would think of as a singular date, not a range) but I can also see where both of those get all gnarly. I will need to think that one through.  Stepho  talk  05:22, 16 December 2013 (UTC)

There are |month= and |year= parameters in citation templates, and these can suitably accommodate such publication dates. We could have "|month=June–July" and "|year=2013", which will display as "June–July 2013". I don't see any issue but for the hypothetical incompatibility with dmy, mdy or yyyy-mm-dd. -- Ohc ^¡digame! 05:57, 16 December 2013 (UTC)

@Ohconfucius: Unfortunately, |month= has been deprecated - see Template:Cite web#Deprecated. GoingBatty (talk) 06:20, 16 December 2013 (UTC)

Oh boo, another one bites the dust ;-) Anyway, "|date=June–July 2013" would still be preferable to "06–07, 2013" or whatever could be used to represent it in pure-numerical dates format. -- Ohc ^¡digame! 06:26, 16 December 2013 (UTC)

In citations, we should remember we are not trying to figure out when a publication was really made available to the public. We are trying to allow readers to obtain the correct publication, and be confident they have done so. This might involve making a request at the Wikipedia resource request page, making a request at the circulation desk of a library that doesn't have open stacks, or requesting an inter-library loan. We must identify the issue the same way the publisher did, whether it's true or not. Jc3s5h (talk) 15:46, 16 December 2013 (UTC)

<mystified>Journals, books and periodicals can be tracked by publication date/year, or often by volume, issue number and ISBN. Our citations provide for all those fields. So what's all that have to do with the point about date formats we are discussing? I don't think that extends to en.wp allowing a publication date of "fall 2012" or "7/26/11" even if that's what the publisher actually used for publication date. If it's an issue #, it can be treated as such; if it's a date, it needs to conform to MOS:NUM. -- Ohc ^¡digame! 01:25, 17 December 2013 (UTC)

MOS and MOSNUM don't govern dates citations; they are governed by WP:CITEVAR. "Our citations"? We don't have a house citation style. I think one is expected to change the format of a full date to be consistent with other citations, so rather than write 7/26/11 we would write in the same format as other citations in the article, for example, 1911, July 26 if the article used the APA style. We would not change the information, however. If the publisher gave a season and year, so would we. Chicago gives this example on p. 732:

23. Boyan Jovanovic and Peter L Rousseau, "Specific Capital and Technological Variety," Journal of Human Capital 2 (Summer 2008): 135, doi:10.1086/590066.

Jc3s5h (talk) 02:12, 17 December 2013 (UTC)

For the record, I concede that MOS:DATEFORMAT did not previously explicitly define acceptable date formats for month and year alone. Nonetheless, as YYYY-MM can be mistaken for YYYY-YY and month ranges represented as YYYY-MM-MM can be mistaken for YYYY-MM-DD, this format is not particularly adept for our purposes where only a month (or month range) and year are known. —sroc 💬 10:43, 16 December 2013 (UTC)

I'm not saying I'm thrilled about the citation date rules that have evolved in Wikipedia, but I think this discussion is forgetting some points:

• According to WP:CITEVAR any consistent citation style may be used. WP:MOS makes reference to WP:CITE. This guideline is subsidiary to WP:MOS. So it isn't at all clear that this guideline even applies to citations. The following points are somewhat dubious, because this guideline might not even apply to citations.
• We haven't adopted ISO 8601, but to avoid confusing people who think we have, we don't use it for dates that are not Gregorian calendar dates or which are before 1583. Thus, some articles won't be able to use publication dates in the YYYY-MM-DD format because they contain a citation that isn't in the Gregorian calendar.
• The YYYY-MM-DD format may be used for access and archive dates even if the publication date is in a different format.
• We don't have any specification of what YYYY-MM-DD dates mean outside the range 1583-01-01 to 9999-12-31.
• We don't have any specification of what 2013-12 means. ISO 8601 does, but we haven't adopted it.

If we were to adopt a simple statement that ISO 8601 is 0K, it would open us up to all kinds of crap such as 201312, 20131214, and all kinds of junk involving week numbers. We would have to create a profile specifying which parts of ISO 8601 we accept and which parts we reject. And somebody would have to shell out >$100 for a copy of the official ISO 8601 spec in order to draft the profile.

If somebody asked me to make the rules, I'd adopt a single citation style manual, adapt the templates to follow it, and use the date format specified in that manual. But that will never happen. Jc3s5h (talk) 14:15, 14 December 2013 (UTC)

Thank you. For all these reasons, but more particularly because YYYY-MM is not a commonly understood format for conveying a month and year in the real world (as opposed to YYYY-YY which is commonly understood for date ranges), we should not support the YYYY-MM format (and should explicitly reject it to avoid the converse implication by accepting YYYY-MM-DD format). If that means some articles need to abandon YYYY-MM-DD format for the sake of consistency when another format is used for specific months, so be it. —sroc 💬 00:02, 15 December 2013 (UTC)

• i agree with sroc. i belong to the school that believes humans parse spelt out months easier than months aumbers. that certainly ought to be the case with year–month combinations. it would eliminate no end of ambiguity even though some may believe it violates DATEUNIFY. -- Ohc ^¡digame! 01:08, 15 December 2013 (UTC)

I take it you have never lived in Asia. They find spelt out months so hard to get used to. Having grown up in Australia and then lived for a few years in China, I find the yyyy-mm-dd format both easier and more consistent - start with the biggest (years) and then work down to the smallest (seconds). The mmm dd, yyyy format is so inconsistent, requires memorising an arbitrary set of month names and has an extra comma that complicates other commas in the sentence or reference. Although I agree that it may take a little time to get used to them for some readers, I contend that yyyy-mm in the context of references are understandable for most readers. And even if some readers do misundestand them, then they can always follow the reference link to read it in another format.  Stepho  talk  06:03, 15 December 2013 (UTC)

We are an English-language encyclopædia. It matters not a bit what the common date format in China is: Chinese readers are going to need to speak English if they're going to have any understanding of the English Wikipedia. And that includes normal English-language style conventions such as dates with spelt-out months. We do not and should not risk confusion among English-speakers for the sake of non-English-speakers - if a Sinophone reader wants an encyclopædia that uses Chinese standards, there are places they can go. Here, for example.

I contend that dates of the form yyyy-mm are not understandable to the large majority of English-speaking readers in any context, and that most readers will never have seen a date formatted in that way. The best we can hope for is reader confusion. The worst is that the usage will actively mislead the reader: that they will find that the notation unambiguously means one thing, when it actually means something completely different. Your suggested remedy, to click through links, is not a substitute for clear writing. If the reader is confused and the source is paper, it's useless. If the reader is misled, it's useless because they assume they know what we're talking about. Kahastok talk 09:39, 15 December 2013 (UTC)

As logical as YYYY-MM-DD format is and as widespread as it is in some regions, until it takes hold amongst most English speakers in preference to other formats that are currently more clearly and less ambiguously understood, we should stick with what is most familiar to most readers of English Wikipedia. —sroc 💬 09:44, 15 December 2013 (UTC)

• @Stepho-wrs: Funny you should say that. I'm totally familiar with "big-endianness" in the Asian context. We have dates all the time stated "1917年9月7日", and you know why it's never ambiguous? Well, it's because Chinese/Japanese take great pains to specify that number "9" refers to "month 9" (i.e. September). Nobody ever skimps on that small qualifier, whether it's the year, month, or day. But en.wp isn't Asia. We live in a mix-and-match system here on en.WP, and dmy, mdy, and yyyy-mm-dd are all "allowed". And while machines rarely parse a date like "1917-09-07" wrongly, the input unfortunately depends on humans, many of whom here are clueless when it comes to date formats. As one person whose main job here on en.wp is to sort out the mess of date formats used in different articles by different editors, I see plenty ofoddities. The number of different permutations of these disallowed formats my script has to rectify may surprise or even scare you! -- Ohc ^¡digame! 11:12, 15 December 2013 (UTC)

• Well said, OC. Tony (talk) 11:16, 15 December 2013 (UTC)
• Hear, hear! —sroc 💬 12:05, 15 December 2013 (UTC)

I'm well familiar with decoding date formats. In the 1990s I used to program credit card terminals in Asia that had to handle international dates (with the joys of Y2K) and different base years (eg Taiwanese credit cards use years counting from 1911 AD, with it's own 2 digit roll-over problems) and so many oddball card formats from China that were mutually conflicting (horribly complex parser that checked for multiple formats and used only the one that had consistency among multiple fields besides the date). Also had many discussion with companies like American Express trying to print receipts with mm/dd/yyyy in a Hong Kong that was used to either dd/mm/yyyy or yyyy-mm-dd. But the real point I was trying to make was that "humans parse spelt out months easier than months aumbers" is not a given.  Stepho  talk  23:18, 15 December 2013 (UTC)

Oho, so I'm trying to teach grandma to suck eggs! ;-) -- Ohc ^¡digame! 01:25, 17 December 2013 (UTC)

I like them sunny side up but somehow they always come out as scrambled :)  Stepho  talk  14:39, 17 December 2013 (UTC)

I would sooner think XXXX-XX would mean YYYY-MM (month of year) rather than YYYY–YY (year range), though some might even mean it as YYYY-DDD (day of year). Shouldn't we say both YYYY-MM and YYYY–YY should be avoided to prevent such confusions? Startswithj (talk) 21:04, 20 December 2013 (UTC)

Yes. Peter coxhead (talk) 21:13, 20 December 2013 (UTC)

Agree with the two above. I've never liked YYYY-YY and would like to see date ranges expressed as YYYY-YYYY. Adding YYYY-MM to the allowable date formats just compounds the offense. Jeh (talk) 21:21, 20 December 2013 (UTC)

Yes, avoid yyyy-nn in any use as it is ambiguous. Vegaswikian (talk) 22:05, 20 December 2013 (UTC)

WP:BLP have strong national ties to their nation?

I have assumed changing to DMY for non-English language country person biographies, where DMY is the norm. No one has objected, then I saw "Articles on topics with strong ties to a particular English-speaking country should generally use the more common date format for that nation." Isn't "English-speaking country" just redundant? Maybe there was a specific reason for it. BLP wasn't it? comp.arch (talk) 12:18, 13 December 2013 (UTC)

I would assume that the reason is that date format is usually changed according to the appropriate target language/culture when translating, in which case it would be sensible to do the equivalent when writing in English (as well as when translating into English). In practical terms, I suppose this means that we don't (in running text) use YYYY.MM.DD or similar for articles related to China, Hungary, Iran, Japan, Korea, Lithuania, and Mongolia. On the other hand, I suppose it also means that there is no rule for the majority of countries (e.g. Germany and France). Perhaps it would be simpler to specify "DMY" for all articles with national ties to any country other than the United States (or even for all articles without strong national ties to the USA). --Boson (talk) 15:04, 13 December 2013 (UTC)

Well, United States and Canada, at least. Resolute 15:35, 13 December 2013 (UTC)

I think the reasoning has been that the MDY format and the DMY format are equally good. The supposition is that if the person is from an English-speaking country, most of the people reading the article will be from that country, so we should provide the format they are most familiar with. If they are from a non-English speaking country, we can't predict where the readers of an English-language article would be from, so both formats are equally good. Hence the format first used in a non-stub version of the article is retained. Jc3s5h (talk) 16:04, 13 December 2013 (UTC)

Well, whether both formats are "equally good" is a matter of subjective opinion. MDY format leads to problems that DMY format doesn't. Personally, I would prefer use of DMY format because the progression from smallest-to-largest units is logical and consistent with the formats used around most of the world (whatever format is used), and easily understandble for those using largest-to-smallest units (YMD), as compared with MDY which follows neither logical pattern — but that's not strictly a "national ties" issue. —sroc 💬 05:47, 14 December 2013 (UTC)

• I have been having a discussion about dates used in newspapers with User:Jimthing, who asserts that Britain traditionally used mdy, but switched over at some stage to harmonise with continental Europe. Although we now accept dmy as "the British date format" on WP, fact is that France, Germany, Spain, Portugal etc all use dmy. They don't use md,y at all at all at all, and by that reckoning WP:TIES should mean dmy should be the prevalent format for European articles, not just British and Irish. -- Ohc ^¡digame! 02:18, 16 December 2013 (UTC)

WP:TIES simply doesn't apply to non-English speaking countries. If the months are in a different language, it is a different format, one which the English Wikipedia doesn't use. Any change to this long-standing interpretation would require an RFC. Jc3s5h (talk) 02:27, 16 December 2013 (UTC)

My script converts European dates into English. I noted that four of the month names in German (April, August, September, November) are identical to English. ;-) -- Ohc ^¡digame! 02:48, 16 December 2013 (UTC)

WP:TIES simply doesn't apply to non-English speaking countries. If the months are in a different language, it is a different format, one which the English Wikipedia doesn't use. Any change to this long-standing interpretation would require an RFC. Jc3s5h (talk) 02:27, 16 December 2013 (UTC)

There are two binary systems mapped onto each other in our rules on date formatting—although regrettably complex, this has served us well. The first is the division between majority-anglophone countries and the rest is hierarchical in a way that might leave a foul taste in our mouths—but it keeps the peace among the natives, who I suppose are prone to think that they own what has become the international language. It boils down to the illogical and punctuation-cluttered md,y for the US (optional for Canada), and dmy for the other majority anglophone countries. Personally a lot of WPians would be happy to have uniform international (dmy) date formats and metric units, and I count myself among them. But the sensibilities of North American editors and readers outweigh this, and they do represent more than two-thirds of natives.

The rule for other countries is that unless there's a good reason they should be left as they were established; the most common "good reason" to impose dmy or md,y is where there's significant inconsistency in the text. Tony (talk) 03:02, 16 December 2013 (UTC)

I normally apply WP:ENGVAR in these cases. Some countries use a format close to dmy, so that might count as a nation tie. E.g. Denmark using "2. oktober 2003" (http://sproget.dk/raad-og-regler/artikler-mv/svarbase/SV00000046) might be considered a variant of dmy, so that we could write Danish dates here as "2 October 2003". If there are no close ties to a common English format or the closeness is disputed then the common English format chosen by the first major contributor remains in force. Wholesale changes to another format without a close tie or without talk page consensus is frowned upon. If the article uses a mixed bag of date formats then they should be changed to the format used most often in the article.  Stepho  talk  14:36, 17 December 2013 (UTC)

• Interesting article about it. --John (talk) 07:05, 17 December 2013 (UTC)

It explains endiness nicely but doesn't say why the Americans use mdy. My thoughts (purely anecdotal) is that the Brits were using mdy when they first colonised America, so the young country naturally continued using it. The Brits changed to dmy sometime in the early 1900's but conservative America never made the change (similar to their metre vs foot history). Which is why traditional newspapers in both Britain and my country of Australia continue to use the traditional mdy on the front page mastheads but use dmy in the article text. But I have no idea why mdy was used in Britain in the first place.  Stepho  talk  14:36, 17 December 2013 (UTC)

I remember (rue) the day when The Age reverted from DMY to MDY format. Le sigh. I always assumed someone came up with month–day order first then later realised they needed to add the year and tacked it on the end without any consideration of endianness, but I have no basis for this. —sroc 💬 16:21, 17 December 2013 (UTC)

There's also this article that supports |'s idea that "America inherited the months-first dates from the United Kingdom" although "historical reasons for the unusual date format are foggy". —sroc 💬 12:51, 21 December 2013 (UTC)

Fraction in title

When fraction is used in writing, what should be used in the title (wikipage title)? Examples:

7 1/4 gauge railway, Category:7¼ inch gauge railways in England, Category:5ft 2½in gauge railways. -DePiep (talk) 19:28, 24 December 2013 (UTC)

Good question! I came here to ask the same. The MOS clearly states:

• The use of the few Unicode symbols available for fractions (such as ½) is discouraged entirely, for accessibility reasons among others.

yet this search (if I have conducted it correctly) appears to show the "½" character in use in about 13,400 pages; Wikipedia search for ½ just yields an error. Presumably a bot of some sort could be asked to replace those occurrences with 1⁄2, 1⁄2 or 1/2 (templates {{fraction}}, {{frac}} and {{sfrac}} respectively), though it would have to be a very clever bot to know whether an article is maths-related; but what should be done about article titles such as 8½, Spin-½, 9½ Weeks, etc.? Justlettersandnumbers (talk) 12:11, 27 December 2013 (UTC)

Can we use things like {{frac}} in a title, would it need {{displaytitle}}? -DePiep (talk) 01:45, 29 December 2013 (UTC)

The text passed in displaytitle must exactly match the title itself. Parts can be hidden, but adding or replacing any characters is not possible. — Edokter (talk) — 12:24, 29 December 2013 (UTC)

• I don't see why any of those would use a fraction in the title instead of a decimal as decimals are easier to accomplish, have less issues (per below), and are more consistent. Technical 13 (talk) 02:02, 29 December 2013 (UTC)

Well, the most obvious reason for not having titles such as 8.5 or 9.5 Weeks is that those are neither the published names nor the common names of those films (they are redirects). But perhaps I have missed the point: was your suggestion intended to be humorous? Justlettersandnumbers (talk) 13:14, 29 December 2013 (UTC)

You have certainly missed the obvious... The examples listed in the OP were 7 1/4 gauge railway, Category:7¼ inch gauge railways in England, and Category:5ft 2½in gauge railways which I think would all be fine as decimals... Published names would likely be the only real concern here. For the record {{Fraction}} uses the unicode 1⁄2 if it is possible and there are 2,241 transclusions of that template... So, some of the 13K+ uses are likely there which could be fixed fairly quickly. Personally, I think this is the wrong direction. I would rather see {{Fraction}} fixed to use unicode in a screen reader friendly way. It should apply the unicode as <abbr class="fraction" title="one half">½</abbr> and abbr.fraction{ border-bottom: medium none; } added to MediaWiki:Common.css which would produce "½" which I think looks and reads just fine even with screen readers or if the unicode fails to load... Technical 13 (talk) 14:59, 29 December 2013 (UTC)

If you read a little further down you'll see where I wrote "what should be done about article titles such as 8½, Spin-½, 9½ Weeks, etc.?". Perhaps you missed that? The same arguments re common names apply equally to the topics you mention. The problem with any solution using unicode is that, as things stand, such use is "discouraged entirely". Justlettersandnumbers (talk) 16:04, 29 December 2013 (UTC)

I did miss that actually Just /[\w\d]*/i, and although I know the MOS says they are discouraged, they are not prohibited. Also, if you look to the section below, I've made a more formal and complete suggestion for this idea which overcomes most of the reasons they are discouraged in the first place... Hopefully CCC is really true... :) Happy editing! Technical 13 (talk) 17:39, 29 December 2013 (UTC)

Flavors of date uncertainty

To indicate around, approximately, or about, the unitalicised abbreviation c. is preferred over circa, ca, ca., approximately, or approx., and should be spaced (c. 1291). Do not use a question mark for this function (1291?), as this may imply to the reader an uncertainty on the part of Wikipedia editors rather than on the part of reliable historians.

I don't get that last bit -- why would ? imply that? I've got the following situation: RS says maybe July 9 is the subject's birthday, or maybe July 9 is a total mixup and (from other evidence) the birthday is anywhere from May to September. It's not that e.g. the birth register says July <single-digit smudge that looks sort of like 9>, which would make c. July 9 appropriate. It seems to me this situation is exactly what July 9 (?) is for. Thoughts? (There's no doubt about the birth year, however.) EEng (talk) 21:02, 24 November 2013 (UTC)

I agree that " (?)" in "July 9 (?)" should pertain to July as well as 9. Perhaps "July 9?" should cover the single-digit smudge. But no such use will be stable even if we agree on the convention. The same is true of "c1920", "c.1920", "c 1920", "c. 1920". To agree that such differences in punctuation and spacing represent differences in meaning is folly, I think, because too many visitors will take for granted that they see wrong punctuation or spacing to be fixed. ...

In the case of dates in the article body, infoboxes, tables, and the like, I think it makes sense to require that "c." be used and that it mean uncertainty expressed by a reliable source, or differing statements by different reliable sources. Trying to invent a series of abbreviations or symbols to indicate different kinds of uncertainty about the date would just confuse readers. Any unusual sort of uncertainty should be explained in the text or an explanatory footnote.

Another area of concern is uncertainty about a date related to a source, such as the publication date. This should be expressed in accord with the citation style adopted for the article, per WP:CITEVAR. Jc3s5h (talk) 21:16, 24 November 2013 (UTC)

Re citations editors should be wary that sources use 'c' for another purpose, especially to indicate a copyright rather than a publication date. ...

But c. means "around" (the give or take being implicit in the specificity of the data -- c. July 9 implies give or take a few days; c. 1217 means give or take a few years) and that's not the case here. July 9 is either right or randomly off.

What the article had originally was John Doe (1823–1860) in the lead and Born: July 9, 1823 (date uncertain) in the infobox. Someone changed to c. July 9, 1823 in both locations, which is what led me here. I was perfectly happy with saying (date uncertain), which is the sort of thing I think you're suggesting.

However, I'm bound to say I've seen the distinction between ? and ca., as discussed, many times and I don't think it's confusing. If nonetheless MOS wants to deprecate ? that's fine, but we should strike the bullshit about how it might imply uncertainty on the part of editors blah blah blah, which has no basis that I can see.

Since I'm free-associating, let me also point out that there are types of data where only ?, and not c., make sense. For example, one might list siblings in an infobox as Fred (?), Mary, Joan; using ? for the kind of date uncertainty I'm talking about is a natural extension of that. I don't really give a shit overall but c. is just misleading for the facts at hand.

EEng (talk) 21:38, 24 November 2013 (UTC)

Offhand I suppose that the current guideline is related to others about the use of '?' --and perhaps '(?)' or '[?]' separately-- in other contexts. Or there may be a general guideline to limit or avoid its/their use.

I believe many readers will interpret this/these symbols as they personally use them elsewhere, and so their interpretations will differ.

--P64 (talk) 21:54, 24 November 2013 (UTC)

Offhand I can't think of another meaning for ? than not sure on this, but I agree it's hard to know what interpretations might be given. So how about:

To indicate around, approximately, or about, the unitalicised abbreviation c. is preferred over circa, ca, ca., approximately, or approx., and should be spaced (c. 1291). Other forms of uncertainty should be written out e.g. (unattested date). Do not use a question mark (e.g. 1291?) for such purposes, because this may imply different things to different readers.

EEng (talk)

I agree that c. (there's a template for that: {{circa}}) should not be used for disputed dates that vary significantly. In such cases, I would recommend a footnote explaining the discrepancy, either as July 9^{[note 1]} if this is most likely the correct date or just the year 1920^{[note 1]} (or perhaps even something like disputed^{[note 1]}) if there is no way to tell which date is more likely. Details of who gives which dates can then be more explicitly explained in the footnote, removing doubt as to what was intended. —sroc 💬 00:11, 25 November 2013 (UTC)

OK, try this:

To indicate around, approximately, or about, the unitalicised abbreviation c. (or template {{circa}}) is preferred over circa, ca, ca., approximately, or approx., and should be spaced (c. 1291). Other forms of uncertainty should be written out in running text e.g. (unattested date) or in a footnote. Do not use a question mark (e.g. 1291?) for such purposes, because this may imply different things to different readers.

EEng (talk) 06:34, 25 November 2013 (UTC)

• Support EEng's proposed wording because I'm EEng, and maybe if there's a bold support or oppose it will catch people's attention. EEng (talk) 01:09, 26 November 2013 (UTC)

<bump> Since – it would seem—there's a lull in the hyphen-dash wars (or maybe it's the hyphen–dash war) perhaps we could give some attention to th relatively (I hope) uncontroversial clarification proposed above? EEng (talk) 14:59, 16 December 2013 (UTC)

• Support Seems a reasonable improvement over the previous text. Wee Curry Monster talk 15:16, 16 December 2013 (UTC)
• Support Looks right to me. The ? has always seemed unprofessional. —[AlanM1(talk)]— 01:36, 18 December 2013 (UTC)
• Support --P64 (talk) 22:28, 20 December 2013 (UTC)

Seeing that this seems to be completely uncontroversial, I'll edit the new text in momentarily. Then everyone who didn't participate yet objects vociferously will suddenly appear out of the woodwork to upbraid me. Or, defying all experience, maybe not. EEng (talk) 17:49, 29 December 2013 (UTC)

Actually, I copyedited it a lot, so if you care better go look. EEng (talk) 11:42, 30 December 2013 (UTC)

Symbols for 2^30 bytes and 2^40 bytes

It is clear from the present text that the symbol MB is used for 2²⁰ bytes because that is stated explicitly ("256 MB of RAM" is preferred to "256 MiB of RAM"). By extension it follows also that the symbol GB is used for 2³⁰ bytes (ie "4 GB of RAM" would be preferred to "4 GiB of RAM"), but what about 2³⁰ or 2⁴⁰ bytes? Only KB, MB and GB are defined by JEDEC, which makes it unclear whether TB (or PB) is preferred over TiB (or PiB) for 2³⁰ bytes (or 2⁴⁰ bytes). Dondervogel 2 (talk) 14:37, 1 January 2014 (UTC)

You changed the binary prefix section to state it follows the JEDEC standards then add a dubious complaint about JEDEC has not updated their documents to cover terabyte RAMs. They will get around to that in due time. -- SWTPC6800 (talk) 05:59, 2 January 2014 (UTC)

OK, so WP does not follow JEDEC, but prefers the ambiguous "TB" and "PB" to unambiguous prefixes. I have edited the text to make that clear. Dondervogel 2 (talk) 07:48, 2 January 2014 (UTC)

Section entitled "Common mathematical symbols"

Please note that a discussion has been initiated at Wikipedia talk:Manual of Style#Common mathematical symbols that includes discussion of a section of this guideline (specifically, the section entitled "Common mathematical symbols"). Participation in that discussion is hereby encouraged. —BarrelProof (talk) 16:27, 2 January 2014 (UTC)

Removing a column from the "Common mathematical symbols" table

The "Common mathematical symbols" table has a column for "Name", which includes multiple names for some symbols, and it has a column for "Other use" which looks mostly useless, as it only includes a couple of entries and those entries look like small variations of what is in the "Name" column. I suggest either simply removing the "Other use" column or merging its contents with the "Name" column. —BarrelProof (talk) 15:06, 2 January 2014 (UTC)

The way I see it, plus and minus are mathematical operators whereas positive and negative generally represent poles and charges. Car batteries have a positive and negative pole, not a plus and minus pole. Therefore, I think that it is appropriate to list the other uses for the symbols as listed. Attempting to merge the column with the name column would be ugly imho. Technical 13 (talk) 15:22, 2 January 2014 (UTC)

I think that people looking for a way to indicate positive and negative charges are probably not going to become very confused by seeing a description of a "Plus sign" that is not accompanied by an explanation that the symbol is also used as a "Positive sign". And anyhow, that section is already hatnoted to indicate that it is just a summary of more detailed guidance provided elsewhere. —BarrelProof (talk) 16:34, 2 January 2014 (UTC)

That's not the point of the column. I think that if the table is too wide, it would be more intuitive to remove the last two columns, which add no value a couple of bullet points above couldn't add like Any sign used as a binary operator should be spaced. Technical 13 (talk) 16:49, 2 January 2014 (UTC)

I agree that it looks like a good idea to remove the last two columns and replace them with a bullet that says "A symbol used as a binary operator should generally be spaced, while a symbol used as a unary operator should not". I think the issue is not just the width of the table (which certainly sometimes matters – e.g., on a mobile device with a small display), but the idea that having fewer columns makes the table simpler and easier to grasp at a glance., Simplicity has value. —BarrelProof (talk) 16:57, 2 January 2014 (UTC)

Regarding how to word the guidance about spacing of operators, note that there are bullet point descriptions on that topic included at Wikipedia:Manual of Style#Common mathematical symbols. —BarrelProof (talk) 17:08, 2 January 2014 (UTC)

BP dates - guidance needs to say don't change BP to BC/BCE

The guidance says don't convert other dates to BP, but the problem I find far too often is people changing BP to BC/BCE, often simply doing literally that, sometimes adding 2000 years. Even that is wrong particularly with uncalibrated dates. Dougweller (talk) 12:53, 23 December 2013 (UTC)

Too right - must be added. Even calibrated dates are not all the same, and using two different RS may produce inconsistent results and implications. I've been bold and added two magic words: "Do not convert other notations to or from BP unless you are certain of what you are doing.." But a bit more on the dangers might well be added. Not that the people doing it will ever look here, but it may help those reverting them. The page suggests "Years ago" may be a better alternative altogether, which I agree; converting to this is I feel somewhat less of a problem. I think it would be reasonable to insist on raising the issue on talk first. Views? Johnbod (talk) 13:54, 23 December 2013 (UTC)

Agreed guidance must be really, really clear. I do have some sympathy for the misinformed changers as palaeontological/geological/archaeological dates are often a complete mess when they get through to the sorts of secondary and journalistic sources used for Wikipedia. The temptation to 'tidy' them all up must be very strong. Maybe there's an argument for the front end articles connected to Dating (disambiguation) to have clearer guidance too. I've been meaning to fix that since -61BP. PatHadley (talk) 11:14, 24 December 2013 (UTC)

As a relatively few readers will be aware of the difference between BP and BCE dating, could not the convert template be updated to correctly calculate and display both BP and BCE dates in articles? It would seem an educational and productive use of templates to display both to readers. • Astynax ^talk 21:06, 1 January 2014 (UTC)

The convert template automates conversions. The point of this discussion is that the conversion can't be automated. Jc3s5h (talk) 21:50, 1 January 2014 (UTC)

I understand converting BCE to BP would be a chore and a waste of energy, but BP to BCE or even "Years ago" should be doable to address the problem noted of editors attempting to convert. As a calculated date, a conversion can surely be automated, no? If not, then how is the general readership supposed to glean any useful information from dates given as BP? • Astynax ^talk 08:11, 2 January 2014 (UTC)

My (limited) understanding of BP is that it is typically in very rough figures such as 500, 1000, 5000, 1,000,000 - eg 1000 BP rather than 1002 BP. Any automatic conversion would have to round the BC/AD year and also indicate that massive rounding has taken place. The actual amount of rounding would depend on the size of the number. Eg '500 BP' would convert to 'circa 1500 AD' (not '1514 AD') and '1,000,000 BP' would convert to '1,000,000 BC' (2014 years being about 0.2% error).  Stepho  talk  09:16, 2 January 2014 (UTC)

I'd say it is only normally used in article-like contexts (rather than technical reports etc) for BC/BCE dates, and rounded to the nearest 100 at least, more often 1000, then 10K further back. Mind you, there are things like this important article saying things like "an age of 17,610cal.yrBP" (last figure first page). It may depend on context. The last bit of the first para of the article proper is worth reading as an example of the clutter you have to specify if you use radiocarbon data figures properly. Don't forget "500 BP" would be 1450 not 1514, as 1950 is the fixed "Present" - itself enough of a reason to need 2000 years of distance before you start using it. Johnbod (talk) 23:20, 2 January 2014 (UTC)

I'm working on Module:Convert (which implements {{convert}}) at the moment, but I don't think that is the right place for a BP function as only very rudimentary time conversions are available, and BP does not convert to other supported units. However, some other module like Module:Age would be good, and it would be straightforward to implement what Stepho describes—providing someone makes a table of examples showing what is wanted. Perhaps Template:bp (not Template:BP) would be used to invoke the module, but some planning of expected input and output would be needed. Johnuniq (talk) 22:53, 2 January 2014 (UTC)

Conventionally, BP is used to indicate a date obtained by radiocarbon dating. These dates may be uncalibrated, or calibrated in various ways; see Radiocarbon dating#Calibration. A glance at that article will demonstrate this is a complex subject, not suitable for a template. For a module, it would appear that a number of parameters would have to be provided, and the person invoking the module would have to know a great deal about radiocarbon dating in order to understand the parameters. Jc3s5h (talk) 23:24, 2 January 2014 (UTC)

"b." or "born"?

I'm pretty sure that it's MOS to use "(born 1952)" or "(died 1066)" rather than "(b. 1952)" and "(d. 1066)", in the body of an article as well as at first mention in the lead, but another editor disagrees - see Baron Grimthorpe. If I'm right, could someone point me to the appropriate wording somewhere in MOS to cite: I can't see it explicitly mentioned in either WP:MOSNUM or MOS:BIO. If I'm wrong, let me know and I'll back down gracefully! Thanks. PamD 16:39, 8 January 2014 (UTC)

Ah, I've now found Wikipedia:WikiProject Peerage and Baronetage, which mandates the use of such abbreviations. I'll back down. PamD 16:45, 8 January 2014 (UTC)

I'm not comfortable with Wikipedia:WikiProject Peerage and Baronetage trumping Wikipedia:Manual of Style/Abbreviations and Wikipedia:Manual of Style/Dates and numbers. If a WikiProject wants to do something in a way that disagrees with the Manual of Style, they should propose it and seek a consensus. I sometimes change "b."s to "born" and "d."s to "died". It seems to me that understandability should be paramount since there's no limit on space like there would be in a book. SchreiberBike talk 19:09, 8 January 2014 (UTC)

"born instead of "b." is also good for non-native English speakers. I know for sure that many Greeks confuse b with d. Search for the famous in Greece phrase "how bo you bo?" :) -- Magioladitis (talk) 08:13, 9 January 2014 (UTC)

Spacing of mixed numbers

After 3 users noted relevance, tagged as RfC. -Wikid77 18:03, 27 December 2013 (UTC)

The templates {{fraction}}, {{frac}} and {{sfrac}} output mixed numbers with a strange and intrusive space between the integer and the fraction: {{fraction|8|1|2}} -> 8+1⁄2. This is clearly at variance with normal usage; the Fellini film is 81⁄2 not 8+1⁄2, and so on. It seems appropriate to seek consensus here before requesting changes to those templates. I tentatively propose replacing the first two bullet-points of Wikipedia:Manual of Style/Dates and numbers#Fractions with this text:

• The templates {{fraction}} (e.g. 81⁄2), {{frac}} (e.g. 81⁄2) and {{sfrac}} (e.g. 81/2) are available for representing common fractions.
• Mixed numbers are unspaced:

• Correct: A History of the World in 101⁄2 Chapters is a novel by Julian Barnes.
• Incorrect: A History of the World in 10 1⁄2 Chapters is a novel by Julian Barnes.

• Unless there is sound reason to the contrary, fractional parts of metric units should be expressed as decimal fractions (5.25 mm), not vulgar fractions (51⁄4 mm). However Imperial, English, avoirdupois, and United States customary units may use either form – both (5.25 inches) and (51⁄4 inches) are acceptable, provided that there is consistency in the way that the fractions are represented.

This introduces threetwo changes with respect to the current wording: the matter of spacing; a mention of {{fraction}}; and the replacement of algebraic with numeric examples, since an expression such as Np/q would in algebra probably be read as a product and not as a mixed number. Justlettersandnumbers (talk) 12:51, 27 December 2013 (UTC)

There are technical and accessibility reasons why the space is required. Please see Wikipedia talk:Manual of Style/Dates and numbers/Archive 140#Non-breaking spaces in mixed numbers for example, as well as the talk pages of the templates, for further discussion. MOS should not diverge from the well-considered implementation of the templates without good reason. —sroc 💬 13:33, 27 December 2013 (UTC)

Also, this should be posted on the talk pages of the various affected templates if this requires further consideration. —sroc 💬 13:36, 27 December 2013 (UTC)

• Extra space should be hidden to meet real-world styles: It is possible to hide the internal space before the fraction part inside a span-tag. The visible extra space, where {{frac|8|1|2}} has shown "8 1⁄2" has also caused inconsistency when used as "8{{frac|1|2}}" to show "81⁄2" where the whole-number portion is placed before the "{frac...}" part. The trick is to position the hidden space off-screen inside a valid span tag, as follows:
       • 8<span style="position:absolute; top: -9999px"> </span>¹⁄₂, to show: 8 ¹⁄₂
       • 87<span style="position:absolute; top: -9999px"> </span>²³⁄₁₀₀, to show: 87 ²³⁄₁₀₀
  During the past year, many users have tested such hidden spaces, on various browsers, to confirm how copy/paste as plain text indeed does retain the hidden space as visible in the copied text, such as "8 1/2" or "87 23/100" rather than 8723/100. -Wikid77 (talk) 15:20, 27 December 2013 (UTC)
• sroc: MOS should not diverge from the well-considered implementation of the templates: I'd say the other way around. We can change MOS with good reasons, and the templates should follow. -DePiep (talk) 16:07, 27 December 2013 (UTC)

Thank you, sroc, for linking to the earlier discussion. It seems to be both inconclusive and ill-considered. If there are technical and accessibility problems with displaying mixed numbers correctly, then those problems need to be addressed, at whatever level is needed (and luckily there are plenty of people here who are very clever at that sort of stuff). Just opting for an incorrect display of such numbers is not really an acceptable solution. What are the obstacles apart from the copy-paste problem (many things in wp fail to copy correctly, including, most notably, wikilinks)?

I'm with DePiep on the priorities here: first reach consensus, then make changes to the MOS if necessary, then make changes to the various templates if required. It isn't just the fraction templates that are affected - this post arose from discussion about {{Convert}}. Justlettersandnumbers (talk) 17:12, 27 December 2013 (UTC)

I agree, in principle, that MOS should take priority over templates and then templates should fall in line. However, accessibility also needs to be considered and should not be ignored (MOS:ACCESS is also part of MOS, by the way, and should not conflict with MOS:FRAC). Much work and discussion has taken place around these particular templates in recognition of accessibility issues and this should not be disregarded simply because it looks wrong. I agree that mixed fractions without the space look better and probably conform with other style guides, but I urge caution before leaping with this. Wikipedia works in electronic media and faces unique challenges that other style guides don't need to be as concerned about. There's also little point in changing MOS in such a way that it forces editors and templates to make a choice between complying with MOS:FRAC or complying with MOS:ACCESS if they conflict. It may also be important to post a link to this discussion at Wikipedia talk:WikiProject Accessibility for comment. —sroc 💬 05:43, 28 December 2013 (UTC)

re sroc: Is removing the space from {{frac}} an access'ity issue? I thought an universal typography could apply. -DePiep (talk) 11:55, 28 December 2013 (UTC)

Reply to sroc: in full agreement on all points. Thank you for mentioning this discussion at Wikipedia talk:WikiProject Accessibility. The accessibility issue (if there is one, I don't know) should of course not be disregarded; nor should the typographic appearance. It's my hope that a solution can be found that accommodates both. Whether or not fractions copy-paste correctly seems on the other hand quite trivial. Justlettersandnumbers (talk) 12:48, 28 December 2013 (UTC)

You can call me an enemy of the absolute offset hack for accessibility. It works, but it's bound to break some stuff somewhere in the future. I'm also an enemy of hidden characters. I'm an enemy of having to correct for the broken implementations of operating systems in terms of glyphs and copy paste implementations. And an enemy of the fractional notation to begin with. In all honesty, in the big picture it truly doesn't matter here very much. All solutions are broken and the only thing saving us here is a template so that once the majority of all browsers, Operating Systems and screen readers have proper implementations to deal with this, we can go back and adapt the template. So everyone can nitpick on this all they want, which i'm sure is what we will do, but in the end it's pointless and we will fix this in 5 to 10 years. —TheDJ (talk • contribs) 18:29, 27 December 2013 (UTC)

re TheDJ: so simply removing the space from {{frac}} give broken outcomes? (It's just a &#x20; in superscript). If so, I better rest this case. -DePiep (talk) 11:55, 28 December 2013 (UTC)

You have a lot of enemies :) We have to deal with the here and now, which means there is no perfect solution. But the 'hack' currently in place seems to be the best working solution out there... for now. — Edokter (talk) — 12:14, 29 December 2013 (UTC)

• Okay, without me having to go through and spend an hour reading the wikicode for each, what is the difference between the three templates and why are there three different templates to achieve the same result? Would it be possible to combine all three into one all inclusive template that functions the same as any of the three existing templates and add a parameter/function that will allow an editor to define if there should or shouldn't be a space between the two? Could there "ever" be any reason that a space in the middle would be appropriate (perhaps a movie, song, band, etc title with the space for effect)? Would it be better to simply create a fourth template that does not have the spacing? Lot's of questions to answer here before I can say that I support or oppose this. Technical 13 (talk) 21:19, 27 December 2013 (UTC)

@Technical 13, those 3 templates show 3 different formats: {{fraction}} uses unicode fraction glyphs ("8+1⁄2)"), {{frac}} uses slash virgule "/" between sup/sub numbers ("8+1⁄2), but {{sfrac}} uses horizontal bar (8+1/2). Plus {{convert}} shows fractions. Most worldwide styles have no space inside mixed numbers, but I think a [hidden] space between whole-number & fraction parts helps screenreaders (or copy/paste) to separate the parts; hence style="position:absolute; top:-9999px" could be used as tested (for months) to allow a hidden space to reappear in copy/pasted text (on any browser), such as copy "87 ²³⁄₁₀₀" into a text window. I think the absolute span-tag would be the compromise solution for all concerns. -Wikid77 23:47, 27 December 2013 (UTC)

When are the WMF engineers going to give us a less ugly formatting option for fractions? I'm talking about the unseemly size. Tony (talk) 00:30, 28 December 2013 (UTC)

Compare with small-font fraction: {frac|8|1|2} = 8+1⁄2, small-font = 8¹⁄₂. Hence, a user could enclose fractions within small-tags: <small>{{frac|1|2}}</small> for the smaller size, where needed. -Wikid77 (talk) 01:13, 28 December 2013 (UTC)

Okay, I see the differences and still think that all of these templates could be merged with an added |separator= parameter which would be defined as unicode, slash, or dash (or something of that nature). I'm also wondering why the unicode option is frowned upon where unicode symbols exist, as any system/browser that wouldn't support them would have to be very outdated. Also wondering why we aren't just using a LaTeX fraction such as $1{\tfrac {1}{2}}$? Technical 13 (talk) 02:19, 28 December 2013 (UTC)

Unicode support in screen readers (at least with their default settings) ) ranges from patchy to non-existent, in my experience. Graham87 03:47, 28 December 2013 (UTC)

Wikid: hardly any difference on Mac Safari. Tony (talk) 12:02, 28 December 2013 (UTC)

• IIC, the proposal is simple: remove the pre-numerator space from fractions, like this. From technical talks here (TheDJ), I understand that that could give browser issues (which looks weird, maybe it has to do with the optional class=frac?). I do not understand how accessability would oppose this (as sroc says). -DePiep (talk) 12:18, 28 December 2013 (UTC)

There was a time when {{frac}} could do Unicode fractions where possible like {{fraction}} does now, but this “smartness” led to inconsistencies in articles, most notably tables, and hence was removed. The consensus basically was that {{fraction}} should not be used at all; certainly, it shouldn’t be advertised in the MoS.

Smart fonts can easily turn a coded string sequence 8 1/2 into looking the same as “8 ½” or “8½” or anything in between, but CSS and browsers aren’t quite there yet. The template(s) should be prepared to take advantage of that technology as soon as possible. Few entries in the common stylesheet would make this easier. Actually, when I initially made {{frac}} I thought fraction slash ‘⁄’ would make such automatisms easier, but it may well be the case that more fonts implement the Open Type features for the solidus ‘/’ exclusively.

It would be possible to combine {{frac}} and {{sfrac}} into one template, but this required quite bloated HTML code and, again, some additions to common.css. The misuse of <sup> and <sub> could be removed at least. Stacked fractions (OTF feature afrc, CSS value font-variant-numeric: stacked-fractions) could be the default inside {{math}} and <math>, diagonal fractions (frac, diagonal-fractions) elsewhere. Logged-in users could then also select their preferred vulgar fraction style by editing their user stylesheet, which could also be turned into a preference setting of course.

Semantically speaking, the space between integer and fraction means ‘plus’ and there is a character for it: U+2064 INVISIBLE PLUS. Font and browser support wasn’t good enough, though, the last time it was suggested in Template talk:Frac. There used to be a hidden ‘+’, though, but it wasn’t accessible to tools – like spreadsheets – that would eventually need it, because browsers didn’t copy it. Not putting anything there is not an option, like others already said. — Christoph Päper 12:38, 28 December 2013 (UTC)

Thanks to Crissov and Wikid77 for pointing out the problems with {{fraction}}, which, it turns out, produces a few "better-looking" fractions, but defaults to rather ugly ones, e.g. {{fraction|7|9}} -> 7⁄9. If it uses the unicode characters that are specifically "discouraged entirely" here, then should not it also be "discouraged entirely" (deprecated and/or merged)? Unless there is any reason not to (?), I will strike it from the tentative draft wording I have proposed above. Justlettersandnumbers (talk) 13:14, 28 December 2013 (UTC)

Still not seeing why not use <math>...</math> and LaTeX... It's clearer, more precise, and has no messy, inconsistent HTML to deal with. Technical 13 (talk) 13:57, 28 December 2013 (UTC)

For all the reasons listed in Wikipedia:«math» and probably more. — Christoph Päper 14:40, 28 December 2013 (UTC)

Which are all moot as they can be dealt with... So, I'm still unclear why we can't use unicode in a screen reader friendly way. The template should apply the unicode (or fraction in general) as <abbr class="fraction" title="one half">½</abbr> and abbr.fraction{ border-bottom: medium none; } could be added to MediaWiki:Common.css or we could just do it with in-line styling like <abbr style="border-bottom: medium none;" title="one half">½</abbr> which would produce "½". For those that there are no unicode characters, it would simply render as "⁹⁹/₁₀₀". For mixed numbers, it would render as "25¹⁷/₃₂". For mixed numbers with a unicode fraction option "5¼". I think these look and read just fine even with screen readers or if the unicode fails to load... Technical 13 (talk) 15:11, 29 December 2013 (UTC)

Which one is it, TeX or Unicode?

For what it’s worth, I’ve implemented your suggestion to use abbr and title in {{fraction}}, although I don’t know whether any aural browser or screen reader actually makes use of that: 1⁄2, 99⁄100, 25+17⁄32 or 25 17⁄32, 5+1⁄4. — Christoph Päper 13:24, 8 January 2014 (UTC)

Would the use of thin spaces like   (en-space, U+2002),   (thin space, U+2009), ‍ (zero width joiner, U+200D, maybe only for Middle Eastern browsers) or a number of Unicode space characters such as U+200A (hair space), U+2006 (Six-Per-Em Space) or U+200B (zero width space) be useful? Some other possible alternatives are listed at Space (punctuation)#Spaces in Unicode. I don't know if they are well supported by the majority of browsers or screen readers.  Stepho  talk  23:38, 28 December 2013 (UTC)

Opinion of unspaced mixed numbers

• Support proposal to hide/omit space inside mixed numbers, which is the common, predominant format in worldwide styles. -Wikid77 15:20, 27 December 2013 (UTC)
• Support as nom and per Wikid77 - this is how mixed numbers are written. Justlettersandnumbers (talk) 17:12, 27 December 2013 (UTC)
• Support. Let us not concern ourselves with copy/paste issues; that is unsolvable as each browser behaves differently. Screenreaders should work though, but without any hidden-span-hack (the hack currently in place at {{sfrac}} does show the space, which it should not, which is probably a Chrome bug). — Edokter (talk) — 12:35, 28 December 2013 (UTC)
  • A hidden space CANNOT be "&#32;" to remain hidden, but using &#160; would stay hidden and allow upcasing text which contains mixed numbers. Beware: {{uc: &nbsp;}} = &NBSP;.
    Example fix: {{smallfrac|8|1|2}} = 8 ¹⁄2, or {{smallfrac|77|23|50}} = 77 ²³⁄50 to copy/paste as "77 23⁄50". -Wikid77 16:23, 28 December 2013 (UTC)

New {{smallfrac}} is deprecated until this issue has an outcome. A MOS fork? Demo's shouold be in a /sandbox. -DePiep (talk) 20:34, 28 December 2013 (UTC)

Both {{frac}} and {{sfrac}} now employ this method. I think it was ment as a test template. — Edokter (talk) — 20:41, 28 December 2013 (UTC)

Test, demo, /sandbox: prevent gaining weight in mainspace. This one is inviting to fork MOS. -DePiep (talk) 07:54, 29 December 2013 (UTC)

• Weak oppose. The space probably shouldn't appear in normal display, but must appear to screen readers, and should appear to copy-paste. The latter "should" seems more important than the former, if there is a conflict. — Arthur Rubin (talk) 16:35, 28 December 2013 (UTC)

  As an aside, I created a linear fraction display {{tfrac}}, which has now been deleted; however, if major changes are made in the way {{frac}} and {{sfrac}} are implemented, {{tfrac}} should be restored as a backup format. {{tfrac|a|m|n}} was basically "a&160;m/n". — Arthur Rubin (talk) 16:47, 28 December 2013 (UTC)

  • Both {{frac}} and {{sfrac}} now use the &#160; method of hiding the space form display but not screen readers. — Edokter (talk) — 19:56, 28 December 2013 (UTC)
• Support There shouldn't be any space displayed here. The template could used a hidden space/plus sign (like it used to do). Jimp 12:13, 13 January 2014 (UTC)

GPS, MOS and events

Please see related discussion at Wikipedia_talk:WikiProject_Geographical_coordinates#GPS.2C_MOS_and_events. Relevance here is that our GPS section should include at least a sentence guideline regarding events. --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 13:02, 13 January 2014 (UTC)

Width first or height for screen sizes? And inches again..

This is maybe not strictly about numbers, I'm sorry, but if there is another place to discuss nr. 1. then let's point that out. I do not want to discuss this in here then.

Nr 1. For screens, they were traditionally always in landscape and the bigger number comes first eg. 1920x1080. For eg. smartphones, *should* they use eg. 1080x1920 pixels? I do not want to bother changing pages anymore if not or even if I'm mistaken and the longer side (in pixels) should be first. Usually pixel are square, but the longer side could theoretically be fewer pixels.. Should the MOS (somewhere) say something about this?

Note also that portait would (?) have implications for aspect ratio as it is defined there. No one says 9:16, always 16:9? comp.arch (talk) 15:47, 13 January 2014 (UTC)

Nr 2. Screen size has traditionally been given in inches, and while this has been discussed before is anyone willing to accept an exception to say explicitly that inches should be primary (cm could be secondary). The MOS might even say this implicitly because of accuracy arguments (if we treat sizes scientifically), as cm is more accurate than an inch and we run into WP:OR problems if we encourage in cm (mm).

Nr 3. Nr. 2 Also applies to pixels per inch (ppi). PPI is universally used (not ppcm). This has been maybe overlooked. Given screen (diagonal) size (and resolution), PPI can be calculated exactly (and is done in Wikipedia), I guess avoiding OR issues. Given PPI size could be calculated backwards from that..

Nr 4. PPI vs. ppi? I have a IEEE style guide saying ppi is correct spelling and another one from IEEE using PPI.. comp.arch (talk)

Computer screens have always been listed as horizontal x vertical - even for the rare portrait monitors. As you said, most desktop/laptop screens were landscape mode, so this means most screens had the large number first but that is just coincidence. A mobile phone (eg Samsung Galaxy S) would be shown as 480×800.

Basic maths doesn't count as original research - conversions between units is allowed. Neither inch nor cm is more accurate - just specify the appropriate number of decimal points or fractions. {{convert}} is useful here.

PPI is generally only used for printed output (ie where the paper size is fixed or a very limited selection). For screens, it is more common to use a combination of screen size and number of pixels.

It is becoming more common to use mm for mobile screen and cm for TV sizes - at least outside of the US. Computer screens seem stuck with inches :(  Stepho  talk  23:29, 12 January 2014 (UTC)

WP general prefers to use lowercase initials - eg mph.  Stepho  talk  23:29, 12 January 2014 (UTC)

The thing with "horizontal first" is that who is to say that the phone's natural position is "pointing up" and that is the narrow side. They can be turned and probably usually are for watching videos (or maybe to type on a keyboard). Do we want to demand and standardize on the lower number first for phones? I even remember ("portrait") monitor from way back for the Mac that could be turned and who is to say which way is the correct. comp.arch (talk) 12:29, 13 January 2014 (UTC)

Do we want to go with reliable WP:PRIMARY sources, see [[6]] and [[7]] or make WP consistent in this way? Not other manufactures could reverse for their products. And WP:SECONDARY sources might do their own thing.. comp.arch (talk) 17:03, 13 January 2014 (UTC)

Obviously, width and height are interchangeable based on the orientation of the display. My opinion on this has evolved with the rest of the industry over the last several years. I recall that, when I first noticed smartphones were being listed in portrait orientation it felt wrong. This was due to a long established habit, from computer displays, of primarily seeing/using the landscape orientation. But now, it feels wrong when seeing a smartphone mentioned with screen dimensions listed in landscape orientation, unless landscape orientation is specifically being discussed.

IMO, dimensions should be listed with the width (first number) being the horizontal direction in which the specific display is most commonly used, or intended to be used. In general, for smartphones this is in portrait orientation; for computer displays this is in landscape orientation. Using the commonly used orientation is, effectively, an evolution in the industry due to the introduction of smartphones. Prior to their introduction, there really was not that much which was most commonly viewed in portrait orientation. Thus, the prior convention of using landscape orientation. For smartphones portrait orientation is clearly the norm in the industry. Generalizing this to be that we use the most common/intended by manufacturer orientation as the one in which we show the dimensions is reasonable.

If the article is about screen resolutions in general, then the dimensions should be listed in landscape orientation (largest number first). Unless it becomes that a specific screen resolution is almost always/only viewed in portrait orientation. If an article is specifically about smartphone resolutions, then portrait. In other words, follow the way that is generally use for the item(s) being written about. Which is used may change over time as the use of lower resolutions becomes embedded in our culture as strongly associated with smartphones rather than computer monitors.

As to the specific example you mention of the Samsung Galaxy Note 10.1 2014 Edition: This item positioned as a tablet by the manufacturer. The article explicitly called it a tablet in the first sentence. Tablet screen resolutions continue to be presented in landscape orientation. The fact that it also has phone capability does not change this. Makyen (talk) 20:58, 13 January 2014 (UTC)

New MOS RFC: Month abbreviations

I have begun an RFC on month abbreviations at WT:MOS#RFC: Month abbreviations. I have asked whether this guideline and the Manual of Style should be required to agree on this point. Please discuss at the MOS talk page. Jc3s5h (talk) 23:33, 13 January 2014 (UTC)

Abbreviated months in citations

Per the discussion I started at Module talk:Citation/CS1/Archive 8#Another date check question, I noticed that month abbreviations with a period generate a CS1 date error, but abbreviations without a period are ok. While WP:MOS#Months and seasons shows that "Feb." is appropriate, MOS:DATEFORMAT shows "Sep" with no period. Would it be reasonable for this topic to be consistent across these two MOS pages? Thanks! GoingBatty (talk) 04:51, 10 December 2013 (UTC)

Actually, WP:MOS#Months and seasons says: "Feb. in the United States or Feb in most other countries". MOS:DATEFORMAT gives examples of 8 Sep 2001 and Sep 8, 2001 but is not explicit about whether a period is acceptable (it does not say that versions with a period are incorrect) so they are not inconsistent. I would say that either format is acceptable, but be consistent within each article. —sroc 💬 06:11, 10 December 2013 (UTC) —edited 13:03, 14 December 2013 (UTC)

I have no horse in this race except to note that one of the more annoying things about Wikipedia guidelines is that guidelines are sometimes distributed across multiple pages as can be seen by comparing MOS:DATE#Chronological items to Wikipedia:MOS#Dates and time. Which of these is the "more correct" guideline? If neither, then perhaps they should be merged so that there is a single complete guideline. It would seem that MOS:DATE#Chronological items is the primary guideline given that MOS#Dates and time several times links to it and because MOS:DATE#Chronological items contains multiple shortcut anchors implying that editors ascribe more weight to the content of MOS:DATE#Chronological items than to MOS#Dates and time.

—Trappist the monk (talk) 13:23, 10 December 2013 (UTC)

May be it is time to reduce the number of variants and take this opportunity to remove the option to have a period following an abbreviated month. It is probably the least used from my experience. Keith D (talk) 13:50, 10 December 2013 (UTC)

I am all for harmonisation too. It's not always easy to spot inconsistencies like that, where the ref section might have all of "Sep. 31, 2013", "Sep 31, 2013" and "September 31, 2013". Some readers may be sensitive to the differences, but a script or bot will pick it up in a split second. When there are such mixed formats, a human will need to arbitrate between which one should prevail in each case. A nuisance. -- Ohc ^¡digame! 14:05, 10 December 2013 (UTC)

Regardless of month name abbreviation style, these dates will fail the CS1 date check because there are only 30 days in September.

—Trappist the monk (talk) 16:27, 10 December 2013 (UTC)

There is no consensus about where to settle this question. A discussion about whether it should be covered by this guideline or WP:CITE was inconclusive. A disadvantage of imposing date format requirements on citations is that there is a lot of citation management software out there, such as Zotero and EndNote; any requirements we might invent could be incompatible with citation management software.

There is consensus that ambiguous formats such as 12/10/13 are unacceptable because the uncertainty they introduce is worse than any software incompatibility that might exist (if there are any citation management software designers stupid enough to adopt such a rotten format). Jc3s5h (talk) 15:26, 10 December 2013 (UTC)

• Nobody's talking about ambiguous formats such as 12/10/13. Formats such as 2013-Sep-31 and 31-Sep-2013 were rightly deprecated, and it would be quite logical to do away with one or other of "Sep. 31, 2013", "Sep 31, 2013". The impact that such a move would have on third party citation management software will be non-existent because machines can parse "Sep. 31, 2013" and "Sep 31, 2013" just as well as "September 31, 2013". -- Ohc ^¡digame! 15:35, 10 December 2013 (UTC)

Given the only time we suggest using abbreviated months is for space-saving on tables and lists in prose, I don't believe we should be using abbreviated months in citation formats, since there's no space issues there. I'm also unaware of any citation format that uses that, and even if some do, then we have to worry about our own house style of using 3-letter abbreviations vs. whatever abbrevation format the source may use. It is just easier to stick to dmy, mdy, or ISO-like for citations. --MASEM (t) 15:53, 10 December 2013 (UTC)

Actually, the table at WP:DATEFORMAT lists references first among the places where abbreviated months are allowed.

—Trappist the monk (talk) 16:00, 10 December 2013 (UTC)

WP:CITEVAR indicates Wikipedia does not have a house citation style. Masem would have to get that changed before attempting to apply WP:MOSDATE to citations. Ohconfucius's comment may be true for developers of external citation management software, who could make their software compatible with ever-chainging Wikipedia guidelines if the feel like it, but is not true for end-users who are not in a position to change the software. Jc3s5h (talk) 16:13, 10 December 2013 (UTC)

I may be mistaken but I think that the original topic of this conversation is the discrepancy between WP:MOS#Months and seasons and MOS:DATEFORMAT and how that should be resolved so that Module:Citation/CS1 does the right thing when it checks date-holding parameters in Citation Style 1 templates.

—Trappist the monk (talk) 16:27, 10 December 2013 (UTC)

I believe that the general MOS is meant, when it comes to date related items, to be a summary of MOSNUM, and any change to MOS that makes it inconsistent with MOSNUM is invalid and should be reverted (I will take a look). But since Trappist's software only checks citation style 1 templates, the acceptable date style may be specified at Help:Citation Style 1. If Trappist can gain consensus to disallow periods after month abbreviations there, that is sufficient to include the restriction in the checking software. Jc3s5h (talk) 16:53, 10 December 2013 (UTC)

• Your revert is retrograde. Of course a style guide is meant to give guidance as to permitted styles, and it always needs tightening and updating. That prohibition was placed there is quite reasonable and not queried at the time. It's been stable for 15 months, and it seems that you only realised it wasn't in conformity with what you had in mind when this discussion opened. I'm sure Trappist didn't mean to open up another can of worms with his request for clarification, but the leeway allowed in the guideline leaves plenty of scope for all that to happen. Also, because the body of style guides is now so utterly complex and some editors seek to use different instructions on different pages to game the system, it does not seem reasonable for MOSNUM to defer to the MOS when the subject is how dates are formatted. I have reverted. -- Ohc ^¡digame! 01:28, 11 December 2013 (UTC)

I will not accept the deliberate introduction of contradictions between MOS and MOSNUM. Seek permission at MOS before decpricating periods after month abbreviations and carry out whatever is agreed upon at both guidelines! Jc3s5h (talk) 02:34, 11 December 2013 (UTC)

• There's no contradiction when one is more general and one is specific to the treatment of dates and numbers. It's quite normal for the former to be more permissive or silent on matters and the latter to be more specific. -- Ohc ^¡digame! 04:22, 11 December 2013 (UTC)

• I'm pleased to see you didn't create a deliberate contradiction, but there is a contradiction. Because the allowed characters are laid out so specifically in MOSNUM, there is a clear implication that periods are not allowed. The following example from MOS clearly states periods are allowed:

• Abbreviations for months, such as Feb. in the United States or Feb in most other countries, are used only where space is extremely limited.

Now, if it was MOSNUM that commented on the acceptability of periods, and MOS was silent on the matter, that would be an example of a more general guideline glossing over a detail in a more specific guideline. But this case is a clear-cut contradiction. Jc3s5h (talk) 10:47, 11 December 2013 (UTC)

Two guidelines are not contradictory merely because one contains additional information that is not included in the other. That said, I agree that it would be preferable for both guidelines to convey the same information about whether or not a period is permitted in month abbreviations, so either MOS:DATEFORMAT should be amended to reflect WP:MOS#Months and seasons or WP:MOS#Months and seasons should be amended to remove the option with a period. —sroc 💬 11:43, 11 December 2013 (UTC)

I think that using a stop is so often used and taught that it should be accepted here as well. Is anybody willing to try and push a unification of standards across these two guidelines? Debresser (talk) 01:19, 31 December 2013 (UTC)

I see Jc3s5h has dealt with the issue by amending MOS to say:

• Abbreviations for months, such as Feb, are used only where space is extremely limited; abbreviations should consist of the first three characters of the month, and are not followed by a full stop unless at the end of a sentence.

—sroc 💬 23:14, 13 January 2014 (UTC)

The change having been reverted, Jc3s5h has now started an RfC at Wikipedia talk:MOS#RFC: Month abbreviations. —sroc 💬 03:32, 14 January 2014 (UTC)

"of each month"

No controversy about this:

The museum is open the first and third Monday of each month.

But what about

The rent is due on the 1st of theeach month; nonreceipt means eviction by the 27th.

Certainly we need some way of expressing this. Right now we've got {WP:BADDATEFORMAT):

Do not use ordinal suffixes nor articles (the 3rd of January, January 3rd, January 3d)

Does this provision force us to say:

The rent is due on the first day of each month; nonreceipt means eviction by the twenty-seventh day of the month.

This seems so awkward. Thoughs? EEng (talk) 01:53, 14 January 2014 (UTC)

• Two options I see: 1/leave these alone, 2/expand the phrase to include the month name. My approach up to now is 1/, but expansion is arguably preferable as it leaves less chance for ambiguity. -- Ohc ^¡digame! 02:27, 14 January 2014 (UTC)

Sorry, my example wasn't clear enough -- there is no particular month -- see fix (using "each month") above. So "expansion to include the month name" isn't an option.

Not sure what you mean by "leave these alone", but if you're saying

The rent is due on the 1st of each month; nonreceipt means eviction by the 27th.

is OK, I agree. Thus we arrive at the problem: as quoted above, MOS seems to forbid "ordinals". It would seem, then, we need a modification to MOS. It's that I'm looking to discuss.

EEng (talk) 02:52, 14 January 2014 (UTC)

• Like you said, leaving them alone implies tacitly accepting ordinals. Unfortunately, such formulations are potentially ambiguous, extremely common, and would demand a lot of manual effort to correct. I would favour more precise guidelines as to how to avoid using these. -- Ohc ^¡digame! 03:02, 14 January 2014 (UTC)

So you're saying we can't say, "A typical rental lease calls for payment of rent by the 3rd day of each month"? Really??? Manual effort is needed for this? I have no idea what you're saying, to be honest. EEng (talk) 04:10, 14 January 2014 (UTC)

• Sorry, that's not what I meant. Of course "2nd day" is an ordinal construction, but it's not an "ordinal date" within the meaning of WP:MOSNUM as I see it. -- Ohc ^¡digame! 04:33, 14 January 2014 (UTC)

The MoS advises against ordinals in dates, but these aren't really dates. They have no specific month or year; they just tell what day of the month things happen. Similar to "Monday is the 2nd day of the week". I'm comfortable with ordinals in this case, and I don't think the present MoS prohibits them. SchreiberBike talk 03:35, 14 January 2014 (UTC)

I assure that someone will eventually say that the prohibition on ordinals I quoted means you can't say "the 3rd of the month", even if we sane people don't think it actually implies such a prohibition. So I do think a clarification to MOS is in order. But first I want to hear from Ohc (above) clarifying what he was saying. EEng (talk) 04:10, 14 January 2014 (UTC)

Indeed, these are not dates. Does this really arise in practice to warrant an explicit exception at the risk of CREEP? —sroc 💬 04:29, 14 January 2014 (UTC)

What is the ambiguity here, Ohconfucius? —sroc 💬 04:29, 14 January 2014 (UTC)

Note that MOS:NUMERAL states:

As a general rule, in the body of an article, single-digit whole numbers from zero to nine are spelled out in words; numbers greater than nine, if they are expressed in one or two words, may be rendered in numerals or in words (16 or sixteen, 84 or eighty-four, 200 or two hundred); those requiring more than two words are given in numerals (3.75, 544, 21 million). This applies to both ordinal and cardinal numbers.

So, the first half of the sentence in isolation should be:

• The rent is due on the first day of each month
• not The rent is due on the 1st day of each month.

However, an exception states:

Comparable quantities should be all spelled out or all figures: we may write either 5 cats and 32 dogs or five cats and thirty-two dogs, not five cats and 32 dogs.

So, the whole sentence could be:

• The rent is due on the 1st day of each month; nonreceipt means eviction by the 27th day of the month or
• The rent is due on the first day of each month; nonreceipt means eviction by the twenty-seventh day of the month
• but not The rent is due on the 1st day of each month; nonreceipt means eviction by the twenty-seventh day of the month.

—sroc 💬 04:40, 14 January 2014 (UTC)

Comma after year in m-d-y format

I added this sentence: "A comma is also required after the year unless the year ends the sentence." According to another editor, this issue has been discussed before without consensus as to whether the comma is required. I haven't verified that.

MOS:COMMA has the requirement in it ("Dates in month–day–year format also require a comma after the day and after the year (except at the end of a sentence)."). They can't both be "right". I have a personal preference for the comma, but I recognize that my personal preference doesn't matter much. However, can't we at least make the two guidelines consistent?--Bbb23 (talk) 17:42, 14 January 2014 (UTC)

"Dates in month–day–year format also require a comma after the day and after the year (except at the end of a sentence)" isn't right because other punctuation after the year could eliminate the need for a comma. Examples:

• The event ended January 1, 1900 (except for a meeting of a small committee).
• The deadline is December 31, 1998; entries received later will be burned.

Jc3s5h (talk) 17:51, 14 January 2014 (UTC)

I agree with your two examples. Obviously, one would never insert a comma before an open paren or a semi-colon. Whether that needs to be stated is a matter of opinion, but it doesn't alter the run-of-the-mill example used at MOS:COMMA.--Bbb23 (talk) 18:14, 14 January 2014 (UTC)

It is, in fact, well settled that a comma is required after the year in MDY format (unless superceded by other punctuation, such as a period, closing parenthesis, etc.). Until recently [since 2011], MOS:BADDATEFORMAT said this:

Wikipedia does not use ordinal suffixes, articles, or leading zeros (except for the YYYY-MM-DD format). Wikipedia does not insert a comma between month and year, nor does it insert a full stop after the day (10 June 1921); however, when using the mdy format, a comma is required between day and year. When a date in mdy format appears in the middle of text, include a comma after the year (The weather on September 11, 2001, was clear and warm). Write out the full year string instead of using the apostrophe (') to abbreviate the first two digits of the year.

On 13 January 2014, this edit by User:EEng moved the text relating to the trailing comma and this next edit removed it entirely, without consensus and contrary to MOS:COMMA which clearly requires it, consistent with major style guides. This needs to be restored. —sroc 💬 22:19, 14 January 2014 (UTC)

Why editors cringe at the phrase MOS discussion

Over the last few weeks I've made 50+ edits to MOS/dates'n'numbers [8] -- rearranging, reorganizing, reducing repetition and redundancy, resolving apparent conflicts where I could (and tagging others for the attention of my fellow editors) -- improving (I hope) and making more palatable (I hope) the presentation in many ways.

I don't expect adulation and flowers for these efforts but I do expect that another editor, on noticing what is obviously (to anyone not afflicted with borderline hypervigilance) an honest mistake, will take stock of what I've been doing before giving vent to such absurdly strident huffing and puffing about "against consensus" and so on. What's wrong with you? Really! What in the world is wrong with you???

It's behavior like this that inspired one appalled editor to pen the following some time ago:

In the last 48 hr I've become aware of a simmering dispute over whether the text of MOS itself should be in American or British English. With any luck the participants will put that debate (let's call it Debate D1) on hold in order to begin Debate D2: consideration of the variety of English in which D1 should be conducted. Then, if there really is a God in Heaven, D1 and D2 will be the kernel around which will form an infinite regress of metadebates D3, D4, and so on -- a superdense accrection of pure abstraction eventually collapsing on itself to form a black hole of impenetrable disputation, wholly aloof from the mundane cares of practical application and from which no light, logic or reason can emerge.

That some editors will find themselves inexorably and irreversibly drawn into this abyss, mesmerized on their unending trip to nowhere by a kaleidoscope of linguistic scintillation reminiscent of the closing shots of 2001, is of course to be regretted. But they will know in their hearts that their sacrifice is for greater good of Wikipedia. That won't be true, of course, but it would be cruel to disabuse them of that comforting fiction as we bid them farewell and send them on their way.

EEng (talk) 00:32, 15 January 2014 (UTC) P.S. Spare me the lecture about civility. Calling for civility at Talk:MOS is like imploring proper use of the dessert fork in a crack house.

I'm not going to get into the civility issue (almost always a mine field), but I've never been to a crack house. Had I known they served desserts (the pastry kind) ... As for your latest edit, I like the additional examples but am not crazy about the wording, particularly the use of the word "anyway". I would suggest "In the MDY format a comma is required between day and year, as well as after the year (unless other punctuation follows the year)". BTW, I plan on having apple bread pudding tonight with a dessert fork.--Bbb23 (talk) 01:05, 15 January 2014 (UTC)

I like to remind people that in arid regions the desert fork is more appropriate. EEng (talk) 01:14, 15 January 2014 (UTC)

Without changing any single rule, most of the MoS could benefit from a rewrite. It's been written in little pieces by consensus over the years and it could be better in many ways. I've been kinda surprised that no one has jumped on you; you are making lots of big changes. It's hard to follow each one, so I'm assuming good faith and planning to wait until you stop, then I'll go over it to see if anything has changed. Let us know when you feel like you are done. SchreiberBike talk 02:39, 15 January 2014 (UTC)

It's not something I think of as a project -- just here and there I thought I could condense, deduplicate, etc. I do not intentionally change the meaning anywhere (except the rare case in which I call out clearly in the edit summary that I think I'm correcting a mistake etc.) and because I know many eyes are watching, I try to make every edit very transparent i.e. obviously changing version X into version X+1 with the same content, just different presentation. Thus, for example, you'll often see the edit summary "Reorder material (no content changes)" i.e. since when paragraphs are reordered it's difficult to see, in the diff, any changes within paragraphs, I leave such changes to subsequent edits for which the diffs will be easy to interpret. Naturally there are times I get ahead of myself, so some edits are more complex than they should be.

I'm therefore disappointed to hear you say they're individually hard to follow. Can you give me an example. In all seriousness, I'd like to know.

One thing I don't understand is your plan to wait until I'm "finished". I have made a few formatting innovations ("spaced" semicolon between examples, boldface for "subcase" descriptions such as Years written in full when crossing era boundary, etc.), and I expect to hear quickly whether people want to build on them, or don't like them. If you feel you want to check what I've done -- and please, I hope numerous others will do that -- please start at your earliest convenience. I will naturally be pissed off if (assuming my inspiration holds up sufficiently) I make another 50 edits in the same vein, just to have have you declare at the end, "Well, I don't like it." So speak up promptly, please (though I don't feel the inspiration coming on for a few more days at least).

EEng (talk) 03:44, 15 January 2014 (UTC)

You are right that the individual edits are each easy to follow, I just don't consider the MoS to be core to my interests in Wikipedia, and since there are a lot of individual edits, I decided not to check each one. Had I thought about rewriting a section of the MoS, I think I would have worked on it in a sandbox, then sought feedback before proposing the new text. Your approach is completely valid though and what I've looked at has looked good. SchreiberBike talk 06:22, 15 January 2014 (UTC)

@EEng: Firstly, let me say that my comments above were not meant to criticise you, but merely to draw attention to the situation, and by mentioning you by name, your attention could be drawn to the discussion via the notification feature.

Secondly, let me say, with all due respect, that I don't this your edit re-writing that section was an improvement, because:

• I don't think additional examples are necessary (and we've happily gotten on without them for years);
• I don't agree that any punctuation supersedes the need for the trailing comma. For example, I do think that one would be needed following a set of parentheses: September 11, 2001 (now commonly known as 9/11), was a day that.... That second comma is needed because "2001" is parenthetical to "September 11" and needs the matching comma, and the parenthetical remark does not replace this. Similarly, a superscript footnote symbol or asterisk would not avoid the need for the second comma, either. (Yes, other terminal punctuation, such as a question mark, would of course supersede the comma, so this should be listed in the exceptions.)

I hope you don't take these criticisms personally. And thanks for your other efforts in cleaning up the section generally — it's just that this always requires care to make sure the meaning isn't lost in the process. —sroc 💬 03:50, 15 January 2014 (UTC)

You should never talk about edits "against consensus" unless it's clear that was intentional. It's offensive. Why didn't you just make the change yourself, with edit summary, "Looks like this may have been deleted accidentally"?

It's only by some cruel twist of fate that this accidental deletion I made -- I somehow misread the comma-after-year provision as comma-after-day, and therefore deleted it because comma-after-day is stated elsewhere -- happened to intersect one of these endless MOS disputes. I should get the hell out of here, but some Satanic force is draws me closer. I know I will regret it, but can't stop myself. I'll comment below later. EEng (talk) 02:01, 16 January 2014 (UTC)

I'm sorry if what I said was offensive. I wasn't directing criticism or anger against you, just stating the facts. It was directed at the others who created a "do we or don't we?" debate in the interim period while the pertinent text went missing. Please don't take it personally! —sroc 💬 04:44, 17 January 2014 (UTC)

Apology accepted. Now if you will seriously reevaluate whether your role in the promulgation of prescription on points of extremely minor importance (#Why_every_goddam_thing_needn.27t_be_micromanaged_in_a_rule), is helping or hurting the project, than my annoyance will turn to genuine respect. EEng (talk) 05:12, 17 January 2014 (UTC) (That wasn't very well punctuated, BTW.)

EEng, I have been watching your edits with admiration. They are bold, iterative, and for the most part small positive improvements that appear to be leading toward a coherent and much-improved whole. I will paraphrase what another editor expressed above: it is not always clear where you are going from a particular diff, and the next edit is sometimes a reordering or tweaking of the same section, but the sections in general end up clearer. I would also appreciate a posting here when you feel like you are ready for fresh eyes to take a look at the section as a whole. Many of us are willing and could point out, in a friendly and constructive way, minor areas for improvement – I expect there will be a few, as is typical with a complex text like this one. You are brave for taking it on amidst a crowd of picky editors armed with forks of various flavors. Something something just deserts.... – Jonesey95 (talk) 06:10, 15 January 2014 (UTC)

I think greater exposure of Jonesey's edit summary for his post just above ("Use every man after his desert, and who should 'scape whipping?" - Hamlet, II, 2) is no more than, er, its just deserts -- and with the talk now shifting to whipped deserts, the desert fork is more appropriate than ever.

There are three innovations I made at WP:Manual_of_Style/Dates_and_numbers#Ranges about which I'd particularly like feedback:

[List moved to #Feedback requested on formatting innovations ]

Why the comma is needed after parentheses

In MDY dates, the year is in apposition to the date. Appositions are padded by commas, similar to the use of matching parentheses. For example:

• Billy Ray, the son of a preacher, was immortalized in a song made famous by Dusty Springfield.
• The weather on September 11, 2001, was clear and warm.

When an apposition is followed by a remark in parentheses, the second comma is still required and follows the parentheses.

• Billy Ray, the son of a preacher (who is unnamed), was immortalized in a song made famous by Dusty Springfield.
• The weather on September 11, 2001 (now commonly known as 9/11), was clear and warm.

That's why I believe this edit by EEng (removing the comma in one example and removing the explanatory text) is erroneous. I have removed the disputed example for now, but would like to reach a consensus on this. —sroc 💬 22:25, 15 January 2014 (UTC)

• That is how I understand the grammatical rules, and how I usually try to apply them in my writing. -- Ohc ^¡digame! 01:22, 16 January 2014 (UTC)
• Yes, the year is in apposition, hence it requires a comma afterwards, even if there is a parenthetical statement after the year. Example without a year that shows the same idea: Billy Ray, the son of a preacher (who died in a car crash shortly after Billy Ray's birth), was immortalized in a song made famous by Dusty Springfield. The year does not require a comma afterwards if the year is followed by a semicolon, colon period (or other sentence-ending punctuation), or dash. – Jonesey95 (talk) 02:11, 16 January 2014 (UTC)

Let's review your first example (though I trust you don't mind my modifying a bit):

Billy, the son of Joe (who died after Billy was born), was immortalized in a song.

Here the phrase the son of Joe (who died after Billy was born) modifies Billy, and ("zooming in", so to speak) that (who died after Billy was born) modifies Joe. So far so good. But if, as you say, that example parallels this one...

The weather on September 11, 2001 (now commonly known as 9/11), was clear and warm.

...then the result would be nonsense, because by your logic not only does 2001 (now commonly known as 9/11) modify September 11 (which I'll let pass for the moment), but also (now commonly known as 9/11) modifies 2001, which is absurd.

I dare you to point to respectable writing that uses such a construction. I'll have more to say later, but for now I leave you with that challenge. EEng (talk) 02:40, 16 January 2014 (UTC)

By that logic, omitting the second comma (The weather on September 11, 2001 (now commonly known as 9/11) was clear and warm.) would mean that 2001 (now commonly known as 9/11) was clear and warm was in apposition to September 11. This makes much less sense.

I accept that the examples are not in perfect harmony—an unfortunate by-product of the awkwardly un-endian MDY format—but that's how it goes.

I'll need to do some digging to find a style guide on point in this particular case, but you can see from the above comments that I am not a renegade in this understanding. —sroc 💬 02:48, 16 January 2014 (UTC)

Looking at it another way, would you draw a distinction if the parenthetical remark were about the year?

• The weather on September 11, 2001 (a particularly humid year), was clear and warm.

Or if its point of reference were more vague?

• The weather on September 11, 2001 (long after meteorological records were kept), was clear and warm.

Would you dispute the appropriateness of the second comma in those cases? —sroc 💬 02:55, 16 January 2014 (UTC)

Why the comma is not needed even after the year -- at least not all the time

I'll get to your last two examples at the end of this post. I look forward to a published example of the

The weather on September 11, 2001 (now commonly known as 9/11), was ...

kind. But moving on to the more global issue of comma-after-year in general ...

Let me first repeat that my removal here [9] was unintentional (I mistakenly thought it was duplicated elsewhere), and it's only by accident that I find that it intersects a discussion into which I now, contrary to my better judgment, allow myself to be drawn.

You treat punctuation marks like mathematical operators which organize words into nested structures of Russian-doll clauses and such, and they're nothing like that. This talk of 2001 being an appositive (or parenthetical, or whatever) stems from the urge to force everything onto this Procrustean bed. But if that were in fact appropriate, then instead of The attacks of 11 September 2011 were... we'd write The attacks of 11 September, 2011, were... which of course we don't.

The function of the comma in September 11, 2001 -- like that of many commas -- is not grammatical but practical: it separates the two sets of digits -- a function unneeded in 11 September 2011, which is why there is not -- I point out again -- any comma there. There's no need to read the tea leaves of nearby commas in order to assign 2001 a grammatical function such as "apposition", because 2001 -- in that particular position, with its introductory comma -- needn't be justified by such a formal function -- it's just a component of one of (several) conventional ways of writing dates. (And consider the format 2001-09-11 -- where's the apposition there?)

The belief in the "required second comma" after the year seems entirely based on this idea that the year is appositive, and therefore needs to be "bracketed" by a paired set of commas. No appositive = no bracketing = no required second comma.

But that doesn't mean a second comma won't be present for other reasons. Notwithstanding the somewhat conservative NYT (stylistically conservative, anyway -- no doubt their style book dates back to the 19th century, when commas grown by slave laborers on colonial comma plantations were cheap and plentiful) there's plenty of good writing in which the year is or isn't comma-followed according to the logical and rhythmic needs of the sentence (and sometimes desired emphasis) -- not rigid logic alone:

Born on September 11, 2001, he always felt a special spiritual burden.

Born September 11, 2001, he always felt a special burden.

Born September 11, 2001 at 9:11 AM, he always felt a special burden.

Born September 11, 2001 -- at 9:11 AM -- he always felt a special burden.

Born September 11, 2001 (at 9:11 AM!) he always felt a special burden.

September 11, 2001 was a day to remember.

Those born September 11, 2001 may feel a special burden.

His September 11, 2001 birthdate meant he felt a special burden.

His birthdate of September 11, 2001, combined with an absent father, gave him the feeling of a special burden.

Please tell me the truth -- would you really write this?

Born September 11, 2001, at 9:11 AM, he always felt a special burden.

As to your last two examples: I wouldn't write any of those things (no matter how punctuated):

Not:

• The weather on September 11, 2001 (a particularly humid year), was clear and warm. (Kind of sounds like September 11, 2001 was a year.)

Instead:

• The weather on September 11, 2001 -- that year having been a particularly humid one -- was ...
• The weather on September 11 of 2001 -- a particularly humid year -- was ...
• In 2001 -- a particularly humid year -- September 11 was ...

Not:

• The weather on September 11, 2001 (long after meteorological records were kept), was ... (Kind of... well... the following is better...)

Instead:

• On September 11, 2001 -- many decades after meteorological recordkeeping had begun -- was ...

EEng (talk) 08:26, 16 January 2014 (UTC)

Firstly, MOS:COMMA states: "Dates in month–day–year format also require a comma after the day and after the year (except at the end of a sentence)." This guideline has been discussed at length. Your proposal contradicts it. If you want to change the status quo, you will need to form consensus to change both MOS:COMMA and MOS:DATEFORMAT to reflect that and remain consistent.

Secondly, the status quo is supported by reliable sources/style guides:

• Chicago Manual of Style, FAQ:

Q. Is the following the correct way to punctuate the date?

Period between June 23, 2003 and March 19, 2004

A. It’s conventional to put a comma after the year. The commas are like parentheses here, so it doesn’t make sense to have only one.

• C. Edward Good, A Grammar Book for You and I-- Oops, Me!: All the Grammar You Need to Succeed in Life (2002), pp 374–375:

When you indicate month, day, and year, put a comma after the dat and after the year (unless some other punctuation mark, like a period or question mark, follows the year). Include these commas even if the month-day-year expression serves as an adjective:

On July 1, 1991, the committee dismissed the employee.

We already responded to your July 1, 1991, letter.

• Geraldine Woods, English Grammar Workbook For Dummies (2006), p 70:

For a date that includes (in order) the month, day, and year, place a comma after the day. If this kind of date is in a sentence that continues beyond the year, place a comma after the year. ("I plan to blow up the rutabaga patch on August 4, 2006, unless I find a more enticing vegetable.")

• Katherine Hogan, Barron's GED Writing Workbook (2009), p 330:

On December 7, 1941, the Japanese bombed Pearl Harbor. Don't forget to place a comma after the year.

• Stephen R. Covey, FranklinCovey Style Guide: For Business and Technical Communication (2012), p 257:

Use a comma after the year in a date and the state in an address when either appears in the middle of a sentence:

The time sheets for July 6, 2010, show no overtime.

• Gina Hogan, Building Better Grammar (2012), p 214:

If you write a sentence that includes the month, day and year at the beginning, you must include a comma after the year:

On May 12, 2001, I found out about my father's cancer.

• David E. Sumner, Holly G. Miller, Feature and Magazine Writing: Action, Angle, and Anecdotes (2013):

As explained earlier, do not put a comma after a year when no date is mentioned, but do use a comma when the date includes a specific month, date and year. You should also use a comma after the name of a state when it follows the name of a city. Example:

Dennis Ulrich left his job on May 13, 2011, after a dispute with his former employer to move to Anchorage, Alaska, to take a new job.

Thirdly, you can't have your cake and eat it, too, by arguing that The weather on September 11, 2001 (a particularly humid year), was clear and warm implies that "September 11, 2001 was a year" because this: (a) is patently ridiculous; and (b) undermines your argument that the parenthetical remark should only apply to the apposition (i.e., 2001).

Incidentally, can we lay of September 11, 2001? It was a busy day, but it's shouldering a lot of work around here. —sroc 💬 11:44, 16 January 2014 (UTC)

Style guides determine when punctuation should be used. Punctuation is not some flighty thing that you use when it feels right or the mood takes you (otherwise the MOS would be redundant). As such, the following examples you provided are flawed because they flout the accepted style:

• Born September 11, 2001 at 9:11 AM, he always felt a special burden.
• Born September 11, 2001 (at 9:11 AM!) he always felt a special burden.
• September 11, 2001 was a day to remember.
• Those born September 11, 2001 may feel a special burden.
• His September 11, 2001 birthdate meant he felt a special burden.

In response to your question:

Please tell me the truth -- would you really write this?
       Born September 11, 2001, at 9:11 AM, he always felt a special burden.

If I were constrained to use MDY format and it were necessary to include the time, yes, that is how I would format it—but I don't see how the time of birth is relevant to his "special burden", so I would probably recast the text to separate it from the birth information (assuming that the date and time of birth were relevant at all). —sroc 💬 11:55, 16 January 2014 (UTC)

Why every goddam thing needn't be micromanaged in a rule

I'm not (as you say) "arguing that [blah blah] should only apply to the apposition [blah blah blah]", because I'm not arguing that "the apposition" is or is not anything, because as I've said over and over I don't think 2001 is an apposition. I only talked about apposition long enough to apply reductio ad absurdum -- to show that the idea it's an apposition is logically inconsistent with a dozen other things. Once again (for example): if 2001 is an apposition (requiring to be bracketed by mighty commas) in this ...

September 11, 2001,

... then why don't we comma-bracket 2001 here ...

11 September 2001

for the same reason.? Answer, again: in both cases 2001 is not an apposition, just a part of the date. And in the first case (only) convention calls for a comma, I guess because without it the day-digits and year-digits run into each other visually.

Unless I missed it in there somewhere, you still haven't given an example of anything supporting

On December 25, 2001 (which was Christmas Day), we all went ...

which is what I asked for several posts ago. If you can't find even a few (or even one) style guide, or respected-writer exemplar, to illustrate this year-(parenthetical)-comma claim, then that's pretty much it.

However, even if you had found such, that would only mean this construction has at least some support somewhere, so that it's not a waste of time for discussion to continue (looking at other sources, at other examples, into our own secret-hearts-of-style, etc.).

That's why you've wasted your time posting all those examples on the comma-after-year rule i.e. the idea that there must be a comma after the year in e.g.

On December 7, 1941, the Japanese ...

-- wasted your time because we all know lots of guides recommend that and you see that usage all the time. The question then becomes: What other views are there? What other usage is there? And out of all that, what rule do we want to adopt? Or do we need a rule on this at all?

That last is, actually, the most important question. Not everything has to be rigidly prescribed and no, I don't buy into the "OhButIfWeDon'tThereWillBeEndlessArgumentOnEachArticle" reasoning just because that might, sometimes happen.

Coffee-fueled parody

All over Wikipedia there are years with comma following, and years with no comma following, and never have I seen two editors, both of whom are actually engaged on a particular article, in serious conflict over a particular instance of that question. The discussion might go, "Hmmm... I'd use a comma myself but if you prefer none... yeah, that looks OK too. Now about that source-reliability question we were discussing..." but that's about it. Where I've seen actual trouble is when other editors -- who have shown (and will subsequently show) no active interest in the article itself -- arrive out of nowhere in their radar-equipped year-with-no-comma-detector vans, then break down the door to weld court-ordered ankle-bracelet commas onto some harmless 2001 whose only crime was appearing in public with his trailing digit exposed -- something which (these prudish enforcers of Victorian punct-morality seem never to understand) was considered perfectly acceptable in most cultures throughout human history. Did you know, for example, that in the ancient Olympic games, years and days competed completely naked, without even a comma between them? I'm not advocating that unhygienic extreme but a bit of exposed backside shouldn't shock anyone in this enlightened age. But I digress, so back to our narrative underway... Having rendered yet another noble service in defense of the homeland (as they like to tell themselves) they jump back into their black SUVs and scurry up their rappelling ropes to their double-rotor helicopters and fly off to their next target, never knowing or caring whether that particular article has, or has not, been improved by their visitation. Certainly all the breaking of the crockery and smashing of the furniture can't have helped, but order has been restored and choas beaten back, which is what's important. During all this the neighbors cower in their homes with the lights out, glad that they are not the targets of these jackbooted comma-thugs -- at least not this time. "Look," they say to their children, "that's what happens if you don't obey the rules. You should love Big Brother for his heroic decication to relieving your of the burden of deciding anything for yourself." But privately they're thinking, "CAN'T YOU JUST LEAVE US ALONE FOR ONCE -- GRANT US JUST A SHRED OF PERSONAL AUTONOMY, A TINY REMINDER OF THE TIME WHEN THERE EXISTED A FEW ZONES OF DISCRETION IN WHICH MEN WERE FREE TO WORK OUT WITH THEIR FELLOW-EDITORS WHETHER OR NOT TO APPLY A COMMA, ACCORDING TO THE DICTATES OF THEIR OWN CONSCIENCES? CAN YOU REALLY NOT SLEEP AT NIGHT, KNOWING THAT SOMEWHERE OUT THERE, EDITORS ARE DECIDING FOR THEMSELVES THE PLACEMENT OF COMMAS? MUST YOU DICTATE FUCKING EVERYTHING?" As Hannah Arendt put is so well: "It is the inner coercion whose only content is the strict avoidance of contradictions that seems to confirm a man's identity outside relationships with others. It fits him into the iron band of terror even when he is alone, and totalitarian domination tries never to leave him alone except in extreme situation of solitary confinement. By destroying all space between men and pressing men against each other, even the productive potentialities of isolation are annihilated..." Or as John Stuart Mill -- himself a great lover of commas, so you can't dismiss him as a bleeding-heart, comma-omitting permissive corruptor of young punctuators -- said... Oh, never mind.

You say

Punctuation is not some flighty thing that you use when it feels right or the mood takes you (otherwise the MOS would be redundant). As such, the following examples you provided are flawed because they flout the accepted style.

Yes, if we can't prescribe and control every detail of usage and punctuation societal decay sets in and soon there is immorality, open homosexuality, interracial marriage, and baby murder.. Or perhaps I've misunderstood you?

The opposite of rigid prescription of everything isn't "flightiness" on everything; the opposite of rigid prescription on everything is measured guidance appropriate to the point being discussed:

• Rigid prescription where truly appropriate.
• Clear direction where experience shows people often go wrong
• Enumeration of alternatives where choices are available
• Universal advice to use common sense no matter what

That last point, BTW, is one of the first thing MOS says. I'm quite aware (because I accidentally removed it, remember?) that there's currently a MOS rule requiring comma-after-year. And I'm telling you that if it were removed, or changed to a short mention that opinions differ on this, it would go a long way toward repairing the disdain many editors have for those parts of MOS which ridiculously overreach and overprescribe, thus preserving respect for its important provisions on things that really matter. But I have no expectation that will happen and I'm not gonna push it.

You can have the last word now. Unless you come up with something published which supports

The weather on September 11, 2001 (now commonly known as 9/11), was ...

there'll be no need for me to respond. EEng (talk) 02:06, 17 January 2014 (UTC)

Micromanaging the placement of commas for everyone while pushing rampant biases is ignored on numerous subjects. It's what Vogons do - and always will! Til Eulenspiegel /talk/ 02:52, 17 January 2014 (UTC)

Boy, that escalated quickly. I admit that finding an example of this specific arrangement is difficult. The point remains, however:

• Other editors agree that the year is in apposition in MDY dates; in fact, I learned that explanation from other Wikipedians. Perhaps this was a mechanism that was adopted by grammarians to justify the comma in the awkward date format where the elements do not follow a logical, endian order, which would explain why DMY dates do not require this construction.
• Chicago Manual of Style, a prominent style guide, explains that the commas act as parentheses, which would require that they be paired (one before, one after).
• Not to have a comma after a remark in parentheses that immediately follows the year in MDY format would be an exception to the accepted style. You have not provided any style guides or reputable sources that support this exception.
• An accepted style ought to be followed consistently, not decided on a whim on a case-by-case basis as in the examples you gave earlier. The corollary is that if you stray from the accepted style, others may come in and clean it up.
• It is therefore inaccurate to say: "In the MDY format a comma is required between day and year, and (unless the date is followed by some other punctuation) after the year as well." This is because the "other punctuation" could be an opening parenthesis, in which case a comma would be required after the closing parenthesis (as if the parenthetical remark were not there at all). I grant you that this situation may be rare, and the consensus may be to leave it out of the MOS for this reason, and that's fine. If the result is mini edit wars over the insertion/deletion of that disputed comma, then perhaps it would be better to deal with it now once and for all; if the consensus is to leave the exception unstated, then I'll let sleeping dogs lie, though if I ever do come across such an example on Wikipedia, I might just revise it accordingly — and then you'll have your sought-after example. —sroc 💬 12:14, 17 January 2014 (UTC)

Just what did those nuns do to you? EEng (talk) 17:51, 17 January 2014 (UTC)

Edit history chaos

Goodness me: this tidal wave of more than 100 piecemeal edits over the past six days—about 30 today alone—is it all consensual? I'm going to have to return a number of times to try to make sense of it. Tony (talk) 11:24, 19 January 2014 (UTC)

As discussed above, "piecemeal" = it's easy to verify that each step of the process doesn't change the meaning, only the presentation. Shall we stop and wait for you to catch up?

As for whether all this is consensual: I've certainly been subject to no coercion, compulsion, or undue influence, and all these edits are my free acts and deeds. But I'm only speaking for myself. Sroc, has anyone threatened you or otherwise attempted to compel you to edit in any way against your will? EEng (talk) 12:08, 19 January 2014 (UTC)

He's lying! He's forcing me to edit! Call the police! I'm in an abandoned server farm at IP 32 point 122 point 6<mmmph!> EEng (talk) 12:08, 19 January 2014 (UTC) P.S. <grunt!><grrrrr!>OK, I'll be good. Don't make me watch any more Youtube cat videos, please! I'll be good!

Ha, ha. Pay no attention to the man behind the curtain. Just part of the show, folks. Almost seems real, doesn't it?

No, I'm serious! It's horrible here -- we only have dialup! How can you people stand by and let this happen? Save me!

I think Tony1 is nervous about the (many!) edits not having been discussed on the talk page first. My suggestion is to do a comparison between one version before the "tidal wave" and the present version. There have been some edits that have been reverted, re-reverted, reworded, moved, paraphrased, relocated into table, reformatted, shot with a giant camera, transmitted in a million pieces, and reassembled a little smaller than before. The substance should hopefully still be the same, just in a different format which is hopefully easier to follow that before. —sroc 💬 12:50, 19 January 2014 (UTC)

Nonsensical delimitation

Within the guideline is toleration/acceptance of numerical separation that would appear highly unusual if not nonsensical to the average English speaker. We have:

Sometimes, the variety of English used in an article may call for the use of a numbering system other than the Western thousands-based system. For example, the South Asian numbering system is conventionally used in South Asian English. In those situations, link the first spelled-out instance of each quantity (e.g. [[crore]], which yields crore). (If no instances are spelled out, provide a note after the first instance directing the reader to the article about the numbering system.) Also, provide a conversion to Western numbers for the first instance of each quantity, and provide conversions for subsequent instances if they do not overwhelm the content of the article. For example, write three crore (thirty million). Similarly, if you write 3,00,00,000, also write (30,000,000) or (30000000). (Note that the variety of English does not uniquely determine the method of numbering in an article. Other considerations, such as conventions used in mathematics, science and engineering, may also apply, and the choice and order of formats and conversions is a matter of editorial discretion and consensus.)

With the exception of the articles on crore, lakh, Indian Numbering System and Indian English, I cannot see why we would have 3,00,00,000 / 3 crore in the running text, and want/need to "translate" these into both (30,000,000) and (30000000). We don't "translate" 30000000 into 30,000,000 in scientific articles. To require having all these conversions for 3,00,00,000 contributes unnecessary clutter and violates WP:COMMONALITY. Such numbers ought to be made into (30,000,000) (or (30 million)) 30,000,000 (or 30 million) <redacted> by default with there being no permitted use of 3,00,00,000 or 30000000. -- Ohc ^¡digame! 12:38, 19 January 2014 (UTC)

We obviously don't translate 30000000 into 30,000,000 (or vice versa) because the spacing is identical, only the separator is different. I assume you mean "Such numbers ought to be made into either 30,000,000 or 30 million by default"; not that these should be given as "3,00,00,000 (30,000,000)" or "3,00,00,000 (30 million)" as the parentheses in your comment suggested? I agree that it would be confusing to encounter 3,00,00,000 on English Wikipedia, except in an article specifically discussing such number systems where attention is drawn to the otherwise-unexpected spacing. —sroc 💬 12:59, 19 January 2014 (UTC)

Sorry, that is indeed what I meant. I copied the templates and didn't remove the parentheses properly. I also meant that using "lakh" and "crore" are meaningless to the English audience, and would add to unnecessary glossing and/or linking. Cheers, -- Ohc ^¡digame! 13:02, 19 January 2014 (UTC)

This makes more sense now:

*Sometimes, the variety of English used in an article may call for the use of a numbering system other than the Western thousands-based system. For example, the South Asian numbering system is conventionally used in South Asian English. In those situations, link the first spelled-out instance of each quantity (e.g. [[crore]], which yields crore). (If no instances are spelled out, provide a note after the first instance directing the reader to the article about the numbering system.) Also, provide a conversion to Western numbers for the first instance of each quantity, and provide conversions for subsequent instances if they do not overwhelm the content of the article. For example, write three crore (thirty million). Group digits in Western thousands-based style (e.g., 30,000,000, not 3,00,00,000): see Delimiting (grouping of digits) below. (Note that the variety of English does not uniquely determine the method of numbering in an article. Other considerations, such as conventions used in mathematics, science and engineering, may also apply, and the choice and order of formats and conversions is a matter of editorial discretion and consensus.)

• Definitely an improvement over my hatchet-job, thanks. However, I still fail to see the validity or interest of tolerating use of a numbering system (crore, lakh) that is alien to a vast majority of our readers. So I reckon these should be specifically banished in the guideline. But perhaps that's for another day. Regards, -- Ohc ^¡digame! 14:41, 19 January 2014 (UTC)

Hmmm, it looks like a lot of uses of crore do not explain the term and in some cases use it as if it were a currency rather than a numbering unit. The articles at least could use some improvement to comply with MOS:NUMERAL either way. —sroc 💬 14:59, 19 January 2014 (UTC)

I've been trying to clean those up, but it's a struggle. -- Ohc ^¡digame! 15:10, 19 January 2014 (UTC)

Hmmm, there seem to be some misconceptions here. There's nothing non-Western about numbering systems that are not (entirely) thousands-based: the myriad, and modern Greek usage thereof, being one example; the defunct miriametro (10,000 m) is still taught to Italian schoolchildren. So I don't think it has anything to do with language variety. Also, I'm not sure with what justification we would instruct speakers of Subcontinental English not to use the numbering system to which they are accustomed. I note that we do not instruct speakers of Transatlantic English to wake up and use the metric system like everyone else in the world; on the contrary, we go (correctly, in my view) to great lengths to accommodate their eccentricity. I would suggest a much shorter text which specifies that names for higher powers of ten that are outside the common short scale usage (such as lakh and myriad) should be written in words, with a numerical equivalent in brackets; and that comma separators in numbers written in figures should always follow the short scale convention. Any use? Justlettersandnumbers (talk) 19:15, 19 January 2014 (UTC)

Oddity in MDY guideline

The revised text for MOS:DATEFORMAT says:

In the MMMM D, YYYY format the year is followed by a comma...

Ironically, this statement is self-contradictory, because it should read:

In the MMMM D, YYYY, format the year is followed by a comma...

Now, there is some conjecture over whether the comma should be enforced when MDY dates are used as adjectives (although neither the above wording nor MOS:COMMA makes any such exception), but there is a strong view that such uses should be avoided in any case (although a recent RFC to say so at MOS:COMMA was unsuccessful due to disagreement over the wording). To avoid this problem, I suggest either:

• Reverting to the "MDY" wording:

In the MDY format the year is followed by a comma...

• Recasting the sentence:

When using MMMM D, YYYY, the year is followed by a comma...

—sroc 💬 16:10, 19 January 2014 (UTC)

Actually, that should also apply to dates in the format MMM D, YYYY (Retrieved Feb 5, 2009, from...), so perhaps the "MDY" wording is preferable to cover both formats. —sroc 💬 22:47, 19 January 2014 (UTC)

Unwitting rejection of printed style guides

In a recent edit, EEng removed this phrase: "Although nearly any consistent style may be used". This phrase acknowledged that dates within citations may follow the mandate of the citation style used in the article. For example, APA style would call for the date of today's newspaper, in a citation, to be written "2014, January 18". I have reworded so that there is no change in meaning to the guideline. Jc3s5h (talk) 01:15, 19 January 2014 (UTC)

In "dates within citations may follow the mandate of the citation style used in the article" (which -- correct me if I'm wrong -- is your phrase, not MOS') is it your intention that "used in the article" mean "used in the article being cited"? If so that's hard to swallow since the various articles cited in any one WP article will employ a variety of date formats, and if those are imported into WP's citations of those articles, the citations will contain all kinds of different date formats willy-nilly, making nonsense of the "consistent format" provision. I fancy myself less of a control freak than most of those hanging around here, but even I can't conceive that the Creator intended dates-within-citations to constitute a do-whatever-feels-groovy zone.

That leaves "used in the article" to mean "used in the WP article doing the citing", and therefore the "any consistent style" needs to be one of the formats listed as acceptable in the prior sections.

Is there something I'm missing? EEng (talk) 20:26, 19 January 2014 (UTC)

Naturally, by "used in the article" I mean the citation style adopted for a particular Wikipedia article, not the citation style (if any) used in the article being cited. This freedom comes from WP:Citing sources#Citation style. So the table of acceptable date formats does not apply if a different date format has been adopted for citations. This is the inevitable result since Wikipedia decided to write a style guide that only explains the style of the article body, not the citations. Jc3s5h (talk) 21:02, 19 January 2014 (UTC)

Are you sure about this? The "Acceptable date formats" table/section elaborately enumerates all the acceptable and unacceptable formats, and even identifies certain formats as usable only in references and certain other places -- no hint that pub dates in citations can use all kinds of other formats too. And the examples in the "consistency" section use only formats in the "Acceptable" table.

I don't care a whit about which date formats are allowed in citations, but I'm not looking forward to trying to cast these maze-like regulations into something editors can readily comprehend. So (not that I don't believe you, Jc) I'd like to hear this confirmed by other editors. EEng (talk) 23:08, 19 January 2014 (UTC)

But that's not true, is it? The table at MOS:DATEFORMAT specifically refers to formats acceptable for citations in references, and MOS:DATEUNIFY provides guidance and examples for date formats in publication, access and archive dates for references. I inherently understood that the MOS for dates applies to citations as it does to everything else. If this is not the case and citations are an exception (and I would not think that this would be desirable), then MOS:DATEFORMAT is not clear on this and there is an apparent inconsistency. —sroc 💬 22:40, 19 January 2014 (UTC)

Wikipedia editors have been unable to reach consensus about whether MOS applies at all to citations. Note, however, that the "Punction and footnotes" section of MOS lists WP:CITE as the main page for that topic. Also, the MOS simply doesn't provide information on how to style a citation, so some system must be found for each article. It would be rather inconvenient to say it's OK to use, for example, APA style but the dates have to be changed; that would break any program that might be used to help with the citations, such as Zotero. In this guideline, the acceptable dates formats could be understood to prohibit abbreviated and all-numeric dates in places where space is not limited (and references being a place where space has been considered limited). The bullet point about publication date modifies the table, allowing dates in citations that follow the citation style that has been adopted for the article. Jc3s5h (talk) 23:01, 19 January 2014 (UTC)

To reiterate, if WP:CITE were an exception to MOS:DATEFORMAT (agreed by consensus), then this should be explicitly stated. As it stands, there is inconsistency between them to the extent that WP:CITE purports to allow citations to include date formats which are unacceptable under MOS:DATEFORMAT. How can this be resolved one way or the other? —sroc 💬 23:40, 19 January 2014 (UTC)

A previous related discussion may be found at Wikipedia talk:Manual of Style/Dates and numbers/Archive 135#Proposal:_date_formats_in_reference_sections Jc3s5h (talk) 00:27, 20 January 2014 (UTC)

Human height

At Talk:Ian_Baker-Finch an editor has cited WP:UNITS as a reason for prohibiting the use of centimetres to display human height. This doesn't seem right, as the WP:SOURCES that the heights of people are taken from frequently use centimetres, and accordingly consensus appears to exist at the Human height article for their use.--Gibson Flying V (talk) 23:48, 21 January 2014 (UTC)

SI units include base units (such as the metre) and derived units (such as the centimetre). Perhaps this was misunderstood. --Boson (talk) 00:01, 22 January 2014 (UTC)

Thank you. Would it be worthwhile to include a mention to that effect in the guideline to prevent any future misunderstandings?--Gibson Flying V (talk) 00:32, 22 January 2014 (UTC)

Well, I think centimeters are fine, but we should draw the line at centimetres. As a wise man once said:

I believe in making the world safe for our children, but not our children's children, because I don't think children should be having sex.

EEng (talk) 02:43, 22 January 2014 (UTC)

Boson is right: centimetre is an SI unit, though not a base unit. This perhaps has implications for the {{height}} template which is designed for infoboxes and only uses metres and feet/inches: see Template talk:Height#Centimetres. —sroc 💬 12:32, 22 January 2014 (UTC)

By the way, by the logic that cm is not an SI unit, one might also say that one was driving at 16.67 m/s (that's 60 km/h for those playing at home). —sroc 💬 12:37, 22 January 2014 (UTC)

Indeed. And there's been an (apparently unnoticed) RfC listed at Wikipedia:Requests for comment/Wikipedia style and naming on this very issue for a few days now if anyone's interested.--Gibson Flying V (talk) 19:03, 22 January 2014 (UTC)

Worth noting that a convention on an article page doesn't determine policy or guidelines in itself. Ultimately it's down to the sources, and there should be no inherent bias for or against cm. SamBC(talk) 20:47, 22 January 2014 (UTC)

Additional bad date format

Please could we add the date format "June the 9th" to the WP:BADDATEFORMAT table? It is sort of implied by both "the 9th of June" and "June 9th", but I think it would be helpful to include it explicitly, particularly as I have found quite a few instances of it that require correction. Thanks. --Jameboy (talk) 14:42, 11 January 2014 (UTC)

I think you'll agree the current examples cover this sufficiently [10]. EEng (talk) 05:14, 24 January 2014 (UTC)

MOSNUM needs a good audit

I started by reading the lead (chould be shortened, I think—all that fluff).

Then the opening section, with a dreadful "etc." in its title. What on earth does the bullet mean?

Quotations, titles of books and articles, and similar "imported" text should be faithfully reproduced, even if they employ formats or units inconsistent with these guidelines or with other formats in the same article. If necessary, clarify via [bracketed interpolation], article text, or footnotes.

• It is acceptable to change other date formats in the same article to provide consistency, so long as those changes would otherwise be acceptable.

Tony (talk) 06:34, 24 January 2014 (UTC)

Also, that hatnote in the next section is weird:

See also: Wikipedia:Manual of Style#Non-breaking spaces and Wikipedia:Line break handling

"See also"? There's nothing else to see: the section's otherwise empty! There doesn't seem to be any "See" hatnote template, though; {{see}} produces "Further information:". —sroc 💬 15:10, 24 January 2014 (UTC)

ISO 8601

Alternatives 2B and 2C contain the following question in the form of an HTML question: "If someone is aware that ISO8601 is restricted to years 1583-9999, then on seeing a date outside that range he'll know immediately that it's not ISO8601. So what is this potential mistaken assumption/confusion/whatever we're trying to avoid hereby?" The answer is that discussions on this topic reveal that some editors think ISO 8601 applies to Wikipedia, and some don't. A few editors have read the standard, many have not. The risk is that the editor who inserts a date in the YYYY-MM-DD may not realize such dates must be in the Gregorian calendar, but the reader who uses the date may believe the format is an implicit statement that the date is in the Gregorian calendar. Not to mention that using the Gregorian calendar in an article about a country that used the Julian calendar at the time of the date being stated is a violation of this guideline. Jc3s5h (talk) 11:00, 24 January 2014 (UTC)

Would have been better had you quoted the html comment in full. Referring to the MOS restriction of YYYY-MM-DD dates to years 1583-9999 (because of "the possibility that all-numeric yyyy-mm-dd dates will be assumed to follow the ISO 8601 standard, which mandates the Gregorian calendar") the comment said

This seems illogical. If someone is aware that ISO8601 is restricted to years 1583-9999, then on seeing a date outside that range he'll know immediately that it's not ISO8601. So what is this potential mistaken assumption/confusion/whatever we're trying to avoid hereby?

Your post here doesn't answer that, and in fact introduces a new contradiction, as follows. You say,

the editor who inserts a date in the YYYY-MM-DD may not realize such dates must be in the Gregorian calendar, but the reader who uses the date may believe the format is an implicit statement that the date is in the Gregorian calendar.

OK, fine. Suppose an editor inserts 1600-01-01, intending it as a Julian date (but without saying so). Now a readers comes along and mistakenly assumes that it's an 8601 date and therefore (again mistakenly) that it's Gregorian, thereby throwing the balance of the universe off kilter; Jupiter leaves its orbing and in the ensuing cataclysm all life on earth is extinguished. The 1583-9999 restriction didn't prevent this scenario, so I don't see what it achieves. EEng (talk) 13:10, 24 January 2014 (UTC)

No need to catastrophise: Jupiter doesn't orb. —sroc 💬 15:03, 24 January 2014 (UTC)

The note also states that 1600-01-01 must be a Gregorian date, and that that format is not allowed for Julian dates. It is impossible to convince editors that ISO 8601 doesn't apply to Wikipedia, so the only remaining options is to not contradict that standard, or ban the format altogether. Of course, if we want to be a bunch of slobs, we should just delete the MOS and all the subsidiary pages.

Oh, by the way, as trivial as this matter may seem, a problem that could lead to actual misinterpretation of a date is infinitely more important that all the purely stylistic matters mentioned in MOSNUM. Jc3s5h (talk) 15:25, 24 January 2014 (UTC)

I'll add it isn't necessarily about avoiding confusion on the part of people who know how to read ISO 8601 dates, and know that "1582-01-01" is an undefined character string. The note gives a person who wish to correct errors in YYYY-MM-DD usage a leg to stand on. Otherwise, one editor could insist that 1601-01-01 is a Julian calendar date, another editor could insist that's not a proper way to write it, and there would be no criteria to decide who is right. The note also serves as a notice to the people who are constantly running around writing date related bots about the proper range of dates in that format; bot writers may not have much interest in anything that happened before the release of Windows 95. Jc3s5h (talk) 16:20, 24 January 2014 (UTC)

But that still leaves the contradiction pointed out in my html note: If a reader knows that 8601 can only apply to Gregorian dates, then if he sees 1500-01-01 he'll know that it can't be an 8601 date, since to be 8601 a date must be Gregorian and 1500 isn't Gregorian. So I still don't see what problem the year restriction solves.

Everything you say rests on the idea that readers will assume that YYYY-DD-MM dates are 8601. That idea is, to put it kindly, farfetched.

I don't have to read 8601 to know that somewhere it says something like "Unless you and whoever you're dealing with have agreed that a certain dataset will be 8601, don't assume they're 8601 just becuase they look like YYYY-MM-DD." And to any sensible reader 1700-01-01 means January 1, 1700 -- nothing more nor less, with no implication of Gregorian vs. Julian. That leaves the reader exactly where he should be, which is exactly where he'd have been had the article said January 1, 1700 -- he needs to read (WP:Manual_of_Style/Dates_and_numbers#Julian_and_Gregorian_calendars), read the article's footnotes, or whatever, to decide the Julian/Gregorian question (assuming he cares).

You say, "It is impossible to convince editors that ISO 8601 doesn't apply to Wikipedia." I don't care whether they're convinced or not. All we can do is inform them; if they don't want to be convinced, then on their heads be it. If a readser's dumb enough to write to us thus:

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

-- then we'll write back thus:

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

You say, "Oh, by the way, as trivial as this matter may seem, a problem that could lead to actual misinterpretation of a date is infinitely more important that all the purely stylistic matters mentioned in MOSNUM." Yeah, sure, if it's a realistic possibility and not a remote, fantastic conjecture.

All this worry -- that a certain format might cause a tiny, hypothetical segment of over-informed readers to infer something they should know better than to infer -- seems grossly misplaced. I think the note should say:

The fact that a date is in YYYY-MM-DD format should not be assumed to imply that the date represented is an ISO 8601 date; in particular, use of that format carries no implication that the date is Gregorian.

I'd like to know what others think. EEng (talk) 00:44, 25 January 2014 (UTC)

To me, the whole confusion is pointless. Which format (with no additional explanations/wording involved, please) says that a 1583+ date isn't Gregorian? In other words, how (in which format, using only numbers and punctuation marks) should we write a 1583–current date in order to clearly express it's a Julian and not a Gregorian date? If that's doable, only then the YYYY-MM-DD format is ambiguous. By the way, Greece used Julian calendar all the way up to 1923, for example, so such dates are/were used.

In other words, ISO 8601 is ambiguous only if some other date format (using only numbers and punctuation marks) clearly denotes a date as Julian. Otherwise, there's little chance of taking an ISO 8601 as a Julian date. Hope it makes sense. :) — Dsimic (talk) 01:18, 25 January 2014 (UTC)

"Everything you say rests on the idea that readers will assume that YYYY-DD-MM dates are 8601. That idea is, to put it kindly, farfetched." Anyone who believe that has not participated in the many discussions that have occurred over the last several years. For example, read Wikipedia:Mosnum/proposal on YYYY-MM-DD numerical dates and you will find many flat-out statements that Wikipedia uses ISO 8601, despite the fact that no one can find any community process that adopted it. Jc3s5h (talk) 02:05, 25 January 2014 (UTC)

Sorry, I should have said "Everything you say rests on the idea that normal readers will assume...". The kind of people who inhabit these discussions are far from normal. Really -- you think more than 1 in 10,000 people has heard of 8601? EEng (talk) 04:37, 25 January 2014 (UTC)

• We're in a kind of weird situation where we only use gregorian dates in the YYYY-DD-MM format, yet we supposedly don't use ISO 8601. That makes the use of YYYY-DD-MM ambiguous, and gives another reason to reduce our reliance on it, particularly when referring to dates prior to 1583. But in practice, I have never seen any citation with a precise date from that era or earlier. -- Ohc ^¡digame! 02:20, 25 January 2014 (UTC)

Hm, how would you unambiguously write a Julian date using only numbers and punctuation marks? As I wrote above, only then YYYY-DD-MM format could be ambiguous regarding whether it represents a Gregorian or a Julian date. Please correct me if I'm wrong. — Dsimic (talk) 02:29, 25 January 2014 (UTC)

Traditional formats such as 5 November 1605, are well known to be used for both Julian and Gregorian dates. There is no unambiguous way to indicate 5 November 1605 is Julian just by writing a date number, a year number, and a month name. Does that mean 5 November 1605 must be Gregorian? Of course not. Jc3s5h (talk) 02:42, 25 January 2014 (UTC)

Why would then 1605-11-05 be more ambiguous than 5 November 1605? They both can be intepreted as Gregorian and Julian, unless everyone pays CHF 134.00 for the official ISO paper, reads it and remembers important details. :) — Dsimic (talk) 02:50, 25 January 2014 (UTC)

Lots of editors over at Wikipedia:Mosnum/proposal on YYYY-MM-DD numerical dates insist that ISO 8601 does apply to Wikipedia. It seems to me that the insistence is strong enough that a well-advertised RFC would be required to explicitly reject it.

Oh by the way, if we did reject ISO 8601, then we would have no guidance. Some valid dates would be −1-01-01, −0001-01-01, and 45-01-01 BC. So we would have to write guidelines to cover all that, which would make EEng's table uglier. I infer EEng's main concern is a pretty table. Jc3s5h (talk) 03:00, 25 January 2014 (UTC)

I didn't have any concern except to point out that -- even assuming it's true that people will assume that YYYY-DD-MM is 8601 -- restricting use of YYYY-MM-DD to 1583-9999 doesn't in any way fix that. Yes, I'd like a clean table if possible, because all other things being equal that reflects clean (or clear) thinking, and makes it easy for the reader. If things can't be clean then they can't, but the fact that there's some unavoidable complexity doesn't mean that we should uncritically toss in every silly provision solving some hypothetical problem never observed in the wild. EEng (talk) 04:37, 25 January 2014 (UTC)

I was one of those who originally thought the YYYY-MM-DD dates we used are 8601, but I realise that is a misconception because the two are often used interchangeably here and elsewhere. I suspect plenty of others are under that same misconception. -- Ohc ^¡digame! 03:30, 25 January 2014 (UTC)

That's a kind of confusion happening when the rulebook costs CHF 134.00. :) — Dsimic (talk) 03:40, 25 January 2014 (UTC)

Wikipedia covers ISO 8601 adequately and includes the part about the valid date range. There is no surprise after paying money - only more detail of a mundane manner.

Spelt out months and 8601 are equally ambiguous. As mentioned above, dates about Greece between 1583 and 1923 on English Wikipedia could be interpreted as either Julian (if obeying the Grecian dating system) or Gregorian (if obeying the current English dating system). The same could be said for dates about England between 1583 and 1752. At least 8601 places a bound on when it is valid.

If someone uses yyyy-mm-dd on a date after 1583 then it can be safely assumed to be part of the Gregorian calendar. If someone uses yyyy-mm-dd on a date before 1583 then it can be safely assumed to be part of the Julian calendar. To most people this is a non-issue - they couldn't care less. And most references in that era are listed by year only anyway - making this a real non-issue. To those who want/need the extra precision, we should mention in the MOS that 'for the yyyy-mm-dd date format, pre 1583 is Julian and post 1583 is Gregorian - no matter which date system was in use by the country mentioned in the article'. Problem solved! Can we go home now?  Stepho  talk  09:57, 25 January 2014 (UTC)

You seem to agree we should stop letting the 8601 tail wag the dog. But why should we continue to pre-load YYYY-MM-DD dates with special semantics beyond those attaching to a "January 1, 1900"-type date? Here's my proposed note for the YYYY-MM-DD format:

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

EEng (talk) 10:16, 25 January 2014 (UTC)

The statement "If someone uses yyyy-mm-dd on a date before 1583 then it can be safely assumed to be part of the Julian calendar" by User:Stepho-wrs at 09:57, 25 January 2014 (UTC) is not a safe assumption. An electronic copy of ISO 8601 I obtained before these became harder to find states "This International Standard uses the Gregorian calendar for the identification of calendar days." There are no exceptions whatsoever to be found in the standard. The standard has this to say about allowable year ranges:

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

Elsewhere the standard allows more than 4 digits for the year, and/or negative years, by mutual agreement. But the key point is that ISO 8601 always uses the Gregorian calendar; this provision may not be varied by mutual agreement.

Also, Wikimedia can be set to display system dates, such as the time an article was edited, in ISO 8601 format. This can be set by choosing the "2014-01-25T14:05:45" radio button in the "Date and time" section of the "Preferences" menu. I suggest it would be confusing for Wikimedia to support ISO 8601 for display of system dates and times but for the English Wikipedia to reject it. Jc3s5h (talk) 14:09, 25 January 2014 (UTC)

As you surely will understand it's a puzzle what that standard might mean by talking about Gregorian dates prior to 1582/3, since the G. calendar only came into being in 1582. There may be some way to give meaning to such an idea, but it's not something we should concern ourselves with.

Your talk of the Wikipedia preferences is ridiculous. If someone wants to mislead himself about some date in the Third Crusade by reasoning from the Wikipedia preferences menu, too bad for him.

This has now taken on elements of the theater of the absurd. Nobody gives a shit about 8601. Wikipedia hasn't adopted it and it doesn't matter that some tiny minority might stupidly think Wikipedia has adopted it. I say again that the simplest way out of this is to give e.g. 1700-03-02 its plain, facial meaning of March 2, 1700, and provide that (I repeat)

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

EEng (talk) 15:16, 25 January 2014 (UTC)

It turns out that this guideline has considered the YYYY-MM-DD format to be ISO 8601 from the very beginning. On the same day, 12 November 2003, the format was introduced and described as "in accordance with ISO 8601". Unfortunately, from the talk page discussions around the same date the editors in the discussion were suffering from the delusion that this format would not actually be presented, rather the (since repudiated) dynamic date system would present the date according to the reader's preference (but of course, most readers didn't have accounts and hence couldn't record a preference, so they did see YYYY-MM-DD). So adoption of EEng's statement about ISO 8601 not applying would require a well-advertised RFC to reputiate this decade-old association between YYYY-MM-DD and ISO 8601. Jc3s5h (talk) 15:49, 25 January 2014 (UTC)

If the Wikipedia guidelines stated that YYYY-MM-DD format was introduced "in accordance with ISO 8601", then specifying years between 0000 and 1582 is not valid as "values in the range [0000] through [1582] shall only be used by mutual agreement of the partners in information interchange", and there's no such agreement in place; that's also what the current note says. — Dsimic (talk | contribs) 18:11, 25 January 2014 (UTC)

• Please take more care to avoid misrepresenting the evidence of past discussions. What your link shows is that, in a very primitive 2003 version of MOS someone changed

Some wikipedians advocate Y/M/D format dates

to

Some wikipedians advocate Y-M-D format dates in accordance with ISO 8601

And that's it. Your phrasing -- "the format was introduced and described as "in accordance with ISO 8601" -- makes it sound like the 8601 issue was raised and explored in a discussion, then agreed upon, and that's not at all what seems to have happened (not on the evidence of you link, anyway).

• By 2008 that had developed into "ISO 8601 style dates (1976-05-31) are uncommon in English prose, and are generally not used in Wikipedia [but has limited use in tables etc etc]" Then in 2008 someone added, after that text, this:[11]

Because some perceive dates in that style to be in conformance with the ISO 8601 standard, that format should never be used for a date that is not in the Gregorian calendar, nor for any date before the year 1583.

The edit summary read, "Some people don't seem to get this and need to be warned," and linked to "RfC:_Linking_of_dates_of_birth_and_death" which was really on a different topic.

I don't know what happened after that, but on the record so far it looks like someone just stuck 8601 in there and it never left. If you can find something showing an explicit consensus for this "some might perceive"-type language, please do, but otherwise I'm beginning to look like someone's whim. EEng (talk) 21:16, 25 January 2014 (UTC)

I would generally agree that this was not a well-considered adoption of ISO 8601; that's why I said that ISO 8601 and the YYYY-MM-DD format were associated in Wikipedia, and avoided saying that Wikipedia had adopted the standard. But this long-standing association shouldn't just be overridden without proper consideration. My preferred resolution would be for the community to declare this ill-considered introduction to be a mistake, just as date autoformatting has been declared a mistake, and to reformat all YYYY-MM-DD dates with all deliberate speed. Jc3s5h (talk) 22:02, 25 January 2014 (UTC)

I don't know who other than you wants to get rid of YYYY-MM-DD dates. All I care about (and I don't care about it much) is to get rid of the bullshit about how they're 8601 or Gregorian or Antidisestablishmentarian or whatever.

I'm asking you, again, to point to a consensus supporting this idea that YYYY-MM-DD dates should be restricted to years blah blah to blah blah, must be Gregorian, or whatever. Absent that, I'm going to propose removing that language, and if you can't tell us what discussion authorized its insertion, no RfC will be needed for its removal -- a consensus here should be sufficient.

EEng (talk) 23:01, 25 January 2014 (UTC)

There seems to be some misunderstanding about what I said in my last comment, so I will rephrase it.

All date formats will have ambiguity about dates between 1583 (when the Gregorian calendar was proposed in some countries) and 1923 (when Greece was the last country to swap from the Julian calendar to the Gregorian). E.g. 1 February 1600, February 1, 1600 and 1600-02-01 all have an ambiguity over whether they are Julian or Gregorian when mentioned in an article about England. Since yyyy-mm-dd was in use before ISO 8601 existed, 1600-02-01 might be intrepreted as being in ISO 8601 format (in which case it is Gregorian) or as simply being year, month, date (could be from either calendar).

So, my proposal is that the MOS be amended to say:

1. all dates written as on or before 4 October 1582, regardless of the format used, be considered as part of the Julian calendar
2. all dates written as on or after 15 October 1582, regardless of the format used, be considered as part of the Gregorian calendar
3. all dates written as from 4 October 1582 to 14 October 1582 shall be considered illegal.

Note that we do not explicitly state that we follow ISO 8601, even though we have the benefit of agreeing with ISO 8601 for dates after 15 October 1582 and we do not conflict with ISO 8601 for dates before 15 October 1582 (WP has no agreement to use ISO 8601 years before 15 October 1582). It also decouples the argument about certain formats assuming certain calenders. Surely this all matches common sense.  Stepho  talk  09:17, 26 January 2014 (UTC)

Seems to me that this fails the principle of least astonishment. For example, 5 November 1605 is a date known by every schoolchild in England - for the Gunpowder plot. 5 November has entered the culture as the date of Guy Fawkes Night, which takes place every year across the country. But that's in the Julian calendar. This rule would require that the date be rendered as 15 November, which is then going to be continually corrected to 5 November by well-meaning English people unaware that MOSNUM has decided to use the Gregorian calendar for such dates. Kahastok talk 10:23, 26 January 2014 (UTC)

Being as this is an English Wikipedia, we could use the same scheme I proposed but using the pivot dates of 2 September 1752 being followed by 14 September 1752. This is similar to the scheme I used for programming EFTPOS machines to handle Y2K - pick a convenient date and treat before/after that date in slightly different ways. But I'm sure that the same problem for certain well-known dates will crop up in articles about Russia, Greece and many other countries. Due to the nature of the beast, there will always be some cases that will resist any scheme. For unusual cases where the well-known date is different according to which ever pivot point we pick, we could put (Gregorian) or (Julian) after the date to signify that we are using a different calendar. Short of adding (Gregorian) or (Julian) to every date from 19821582[corrrected by EEng] to 1923 (which I don't seriously recommend), I can't any scheme keeping everyone happy.  Stepho  talk  14:27, 26 January 2014 (UTC)

(I hope don't mind that I corrected a date in your post.) The rules for whether an article should use Julian or Gregorian dates are at WP:JG. There's also a little bit about helping the reader understand which one he's getting. The rules aren't very clear and it's easy to see that they could stand improvement. What you're proposing is, essentially, a change to those rules, but this isn't the time and place for that.

The important points, I hope you will agree, are these:

• a YYYY-MM-DD date should be given the obvious and straightforward interpretation e.g. 1776-07-04 means July 4, 1776, with no implication as to whether its Julian or Gregorian; and
• whatever the issues are about how readers are supposed to know whether a date is J or G, how the date is expressed (July 4, 1776 versus 1776-07-04) has nothing to do with that. The format in which the date is expressed is entirely irrelevant to determine whether the date is G or J.

Does that make sense? EEng (talk) 03:36, 27 January 2014 (UTC)

In summary

• Sayre's law
• Parkinson's law of triviality

EEng (talk) 06:12, 25 January 2014 (UTC)

Very well said! :) — Dsimic (talk | contribs) 18:11, 25 January 2014 (UTC)

Units as examples

At Wikipedia:Manual of Style/Dates and numbers#Specific units, why are the names of some units (namely, "gram calorie" and "kilogram calorie") presented as example text? Come to that, why are the symbols (except the primes) also presented as example text. This markup also extends to the "Comment" column where example formatting is used for information, not just examples. —sroc 💬 01:48, 26 January 2014 (UTC)

I'm guessing gram calorie and other unit names were actually meant to be linked using [[ etc., not set inside {{xt}}. But the unit symbols are usefully set in {{xt}} and {{!xt}}, since a lot of the content is instructions on approved vs deprecated symbols (e.g. bit/second vs bps). EEng (talk) 02:35, 26 January 2014 (UTC)

The thing is that the names of units are not examples, so we shouldn't be using {{xt}} or {{!xt}} for them. Also, there's a specific template for deprecated examples ({{xtn}}) which should be used instead of {{!xt}}. —sroc 💬 11:21, 26 January 2014 (UTC)

There are too many variations of green, red, and grey for me to sort out. I have a phenomenologist uncle so you can talk to him about whether a unit name is a thing, or an example of the thing, or a referent of the referring term of the thing itself, or whatever. EEng (talk) 15:07, 26 January 2014 (UTC)

Oh, good. What's his Wikipedia username? —sroc 💬 16:39, 26 January 2014 (UTC)

He doesn't use computers. In all seriousness, if you want to fix the use of xt !xt etc, or fix some part of the table to demonstrate to me which one is used where, I'd appreciate that. But be sure to look the whole table over first -- I think there may be cases which will give you pause about what exactly to do, and that may affect your overall approach. EEng (talk) 06:33, 27 January 2014 (UTC)

Good work on the latest revisions to the table. I've just made a few more to clean up the remaining unit names in the "Name" column that erroneously used the {{xt}} and {{!xt}} templates. Also note that colour alone should not be used to mark differences in text (per MOS:COLOR) so bad examples and deprecated cases should be indicated in the text as well as using the templates where applicable (e.g., "not C"; "μ (deprecated)"). Hence, in the "Name" column, I used "not degree centigrade" and "not calorie (deprecated)" without relying on the colour of the example templates. —sroc 💬 13:53, 27 January 2014 (UTC)

"Good work" to you as well. Coupla comments:

• Between "absolutely wrong" (like kN for knot -- not that I can see how anyone might conceive of doing that) and "approved Wikipedia style" I think there's a least one (and maybe two or three) other stops along the way e.g. "bps -- not wrong in the real world but WP doesn't use it". I'm not sure how these various degrees of condemnation should be expressed. I guess we've got not and deprecated -- should be define them explicitly?
• I'm not sure it's worth calling out speed explicitly along with length in the group name. Several of the "simple" units (mile, cubic foot, bit) are accompanied by "per" units (mph, cu ft/s, bit/s), and I don't even know how how we'd expand some of the group names to acknowledge those (e.g. is cu ft/s a "volumetric rate"? "rate of flow"?). So I'd just name the groups by the "numerator" units -- length, volume, etc.
• BTW, the reason I joined length and volume was laziness -- I just didn't have the energy to move cu ft and cu ft/s where they really belonged. I'll do that now.
• I've never responded to your query re use of nbsp, but I will someday soon. But I think you see their use here for certain, and perhaps you will agree that many editors would find markup examples helpful here. On the other hand you're right that the actual rendered output should be shown too.
  • There's {{markup}} which might be useful for this -- but will it work inside a table?

Will you be commenting at Wikipedia_talk:Manual_of_Style/Dates_and_numbers#Proposed_new_text_for_MOS:DATEFORMAT_re_YYYY-MM-DD_dates? I'm soooo tired of that stupid argument -- makes your trailing-comma preoccupation look positively rational! (Sorry, couldn't resist.) EEng (talk) 22:32, 27 January 2014 (UTC)

Looking good. I don't really mind about "speed", just seemed to be noticeably missing. Perhaps strikethrough (e.g., "not degree centigrade") would be better formatting for unit names? (I might comment on YYYY-MM-DD if I can work up the energy.) —sroc 💬 23:18, 27 January 2014 (UTC)

Just follow that link and agree with me -- that's not too much to ask after all you've put me through, is it? I like the strikethrough idea, though then we'll certainly need a legend explaining what all the various flavors of typography mean. EEng (talk) 00:12, 28 January 2014 (UTC)

I think the preceding "not" should make it clear without a legend, and the accompanying text can explain further where necessary. I wouldn't mind if the strikethough was another colour (e.g., red), but I'm not sure how to achieve it. —sroc 💬 00:30, 28 January 2014 (UTC)

Names of days

Do we have any guidelines on using the names of days as well as dates? For instance, the article on the Attack on Pearl Harbor says:

• "The attack on Pearl Harbor was a surprise military strike conducted [...] on the morning of December 7, 1941..."

not

• "The attack on Pearl Harbor was a surprise military strike conducted [...] on the morning of Sunday, December 7, 1941..."

I couldn't see anything on the MOS page and a quick search of the archives didn't throw anything up (though choosing the right search terms isn't easy...). matt (talk) 17:18, 27 January 2014 (UTC)

I'd phrase it "... conducted [...] on Sunday morning, December 7, 1941 ..." but that's me. htom (talk) 18:21, 27 January 2014 (UTC)

Personally I don't add it at all to articles; I don't see what value it adds (except in cases where the day of the week is important to the event). matt (talk) 18:50, 27 January 2014 (UTC)

In the case of Pearl Harbor, the fact that it was a Sunday was important. The word "Sunday" does not seem to appear in the article, which I find a bit surprising. I'm not sure I'd add "Sunday" to the date without adding some information about why that was important. Jc3s5h (talk) 19:33, 27 January 2014 (UTC)

That's my understanding, too. Surprised it isn't mentioned in MOS:DATE. —sroc 💬 23:06, 27 January 2014 (UTC)

I also come across reference to the DOTW fairly frequently although I often fail to see the importance. We should indeed have a stipulation to use the DOTW only in exceptional circumstances. Such would still allow it to be used in the Pearl Harbour example whilst disallowing it for other cases. -- Ohc ^¡digame! 13:25, 29 January 2014 (UTC)

P'raps my example of Pearl Harbor wasn't the best choice if the day is relevant (!). Most of the time I see this with bios (e.g. So-and-so was born on Friday 32 Julember) and especially with recent deaths. matt (talk) 13:38, 29 January 2014 (UTC)

This is good example of WP:INSTRUCTIONCREEP. Is there any evidence that this has been a real problem -- that editors of this or that article often can't agree about this, or that WP's "professional appearance" (don't know why people keep using that phrase, since we're definitely not professionals -- in our capacity as WP editors, anyway) would be significantly improved by making a "rule" about this?

Most high courts refuse to say how they would rule should such-and-such a potential legal question arise in the future -- in general they will only take up an issue when it's come up over and over, and lower courts have had difficulty resolving the problem. I think we should take that approach here.

EEng (talk) 01:46, 30 January 2014 (UTC)

Uncertainty

Although my previous question here was completely ignored, the {{val}} template has been eventually changed (see discussion there). Maybe, it's time now to bring this manual in accordance with the template that it recommends and the commonly accepted rules? :–) — Mikhail Ryazanov (talk) 08:32, 2 February 2014 (UTC)

Parentheses with ±errors plus exponents is standard, and the template now displays them. I'm not so sure about superscript/subscript errors plus exponents: IMO the alignment should be enough that parentheses are not needed. Should we modify the val template to not display parentheses is that situation? [Done; can easily rv. if we decide we want them.] Also need to rem. the parentheses with () uncertainties, but I'm having trouble w the coding. — kwami (talk) 09:36, 2 February 2014 (UTC)