Wikipedia talk:Manual of Style/Dates and numbers

Date range redux

To keep Legobot from removing the RfC Technical 13 (talk) 18:03, 29 December 2013 (UTC)

An old issue resurfaced. An editor again reverted a date range in the format mandated by our MOS. I've re-reverted, per MOS.

MOS says:

"Year ranges... sports seasons spanning two calendar years should be uniformly written as 2005–06 season....
A closing ... year is normally written with two digits (1881–86) unless it is in a different century from that of the opening year, in which case the full closing year is given (1881–1986)." (emphasis added)

This editor insists on reverting. Deleting the MOS-approved style of six digits, in the above example. And inserting his own preferred non-MOS style of eight digits (2000-2001).

He doesn't deny that the MOS states what it states. He either argues that there "is not consensus" to enforce MOS. In other words -- it appears that he will not follow MOS or accept it as consensus unless there is another consensus discussion that MOS will be enforced ... a concept I am unfamiliar with, and find unconvincing. MOS reflects our consensus. Or he argues that a wikiproject has decided not to follow MOS for sports articles, and that a wikiproject has the power to trump the consensus reflected in MOS itself.

I've invited him to seek to change MOS, if he wishes to. But asked that he not edit in violation of MOS.

He just reverted to the non-MOS format again.

Thoughts?--Epeefleche (talk) 02:36, 25 November 2013 (UTC)

Correction - it is not accurate to say that I think a project trumps MOS. As I state below, I do not think MOS closes the door on interpretations and since we went through a very long discussion here in April (linked below) with no definite end mandating 6 digit use in these cases, I think that the consensus in the form of tens of thousands of edits by multiple projects should be respected unless and until this is clarified. I don't see it as an MOS violation at all and since this editor started the last conversation he should be well aware that it had no resolution. Rikster2 (talk) 03:25, 25 November 2013 (UTC)

Request to formally insert language that an 8-digit date range format be allowable for sport tenures. This was discussed ad nauseum to no firm resolution in April (see here). In that discussion, it was pointed out that this format is used in infoboxes (not text) by most of the major sports projects (10k+ articles) to display club progression/tenure and that the strict MOS view would show tenures that span over a century change (e.g. 1997-2003) differently than those that don't (1988-91). In that discussion I linked evidence that this exact usage (specifically for summary profiles of athletes showing club tenure) is used by all of the biggest English-speaking professional sports organizations in an official capacity (Here are examples from the NBA, the Premier League, the NHL, the NFL and Major League Baseball (Search any common name in the historical dbase and see what comes back). In my opinion, the use of this format is a valid style choice and should be allowed in these narrow circumstances. I would like to ask that this use be expressly added to the MOS. In my opinion, we discussed this last time and no mandate came (MOS itself says dates are normally shown in 6 digit format, meaning there are circumstances where they aren't). I say we put this to bed and add language that makes it clear. Rikster2 (talk) 03:01, 25 November 2013 (UTC)

It's quite clear from the above-quoted language that MOS dictates precisely the opposite of what you are requesting. The fact that some editors (including, perhaps, you?) have flouted our consensus-driven MOS and -- despite what MOS clearly requires -- input the opposite, doesn't lead to the conclusion that your against-MOS edits then dictate that MOS be reversed. Because you and some others have ignored it.

Furthermore, the MOS quoted above indicates -- specifically as to sports, which is what is at issue here -- the limited instance when the 6-digit format is not used ... which is when "it is in a different century from that of the opening year". Your changes don't fall within that category.

In addition, The issue is 2011-12 (670 thousand ghits) vs. 2011-2012 (197 thousand ghits). As you can see from the ghits, the approach excluding the extra digits (which impart zero info) is standard.

If you search NBA.com, the official basketball website for the NBA, you will see that 2011-12 is also the preferred approach (995 hits vs. 38 hits).

If you search NHL.com, the official hockey site for the NHL, you will see that it is the preferred approach (2,762 hits vs. 141 hits).

If you search NFL.com, the same (approaching 2-1). And more than 3-1 for the Euroleague basketball league.

And that is what our MOS calls for.--Epeefleche (talk) 03:45, 25 November 2013 (UTC)

Never said those specific edits were the turn of a century. I said that a strict mandate for 6 digit was asked for by you and never received. Therefore I don't think you have a leg to stand on to individually force such a strict mandate over the consensus formed over tens of thousands of articles. Rikster2 (talk) 04:05, 25 November 2013 (UTC)

ghits are irrelevant when I am linking to the exact same purpose used on Wikipedia today - summary tenure of athletes' club history - like infoboxes. I have linked player profiles and databases meant to show exactly this, not the site as a whole which has all sorts of date formats mixed in. At a minimum, t shows a valid style choice. And MOS does not dictate anything. It is a guideline. You sought strict enforcecment in these cases in April, and now you are trying to enforce your will in the absence of that happening then. Wikipedia is built on common sense and questioning. Let's have the discussion now and get this to the finish line (though more than just you and I will need to be a part of that of course). And of course I am "one of" the editors who uses this convention - though it is important to point out that I was not the originator of it (though I agree with it). It is used in at least association football, American football, basketball, baseball and cricket. That's a lot of editors to all reach the same conclusion. Rikster2 (talk) 04:01, 25 November 2013 (UTC)

I support Rikster2's proposal that the MOS be amended to allow for 8-digit date range formats for sport tenures. As Rikster2, explains, the relative number of g-hits between the two formats are irrelevant to this issue. Individual seasons (often carrying the 6-digit format) are naturally going to have more mentions that multi-season tenures. I was not the originator of this convention either, but have independently reached the same conclusion about it as Rikster2 has. Jweiss11 (talk) 06:48, 25 November 2013 (UTC)

• Support Rikster2's proposal per common sense and clarity. Sports seasons are often abbreviated using the six digit format - i.e. 2012–13 season. If a player joined a club in January 2012 (i.e. during the 2011–12 season) and left in December 2013 (i.e. during the 2013–14 season). The current format (2012–2013) makes it clear that this is not the same time period as the 2012–13 season. In addition, if we have six digit ranges for years in the same centuries instead of eight-digit ranges, then it just makes the left-hand column in infoboxes look stupid when a player's career spans a new century. We've been using this format for years without complaint and I see no good reason to change. Number 57 13:37, 25 November 2013 (UTC)

• MOSNUM contradicts itself. In the subsection "WP:MOSNUM#Other date ranges" it states "Dates that are given as ranges should follow the same patterns as given above for birth and death dates." In turn, the "Dates of birth and death" section states that in cases where only the years of birth and death are known, the full years should be given (8 digits for 2nd and 3rd millennium births/deaths). On the other hand the "Years" subsection within the "Longer periods" section indicate that for four-digit years the end of the range should be given with just two digits, except when spanning a century. I'd like feedback on whether others agree there is a contradiction, and if so, an RfC should be initiated to see what the community wants to do about it. Jc3s5h (talk) 14:20, 25 November 2013 (UTC)
  • Comment - Certainly looks like a direct contradiction. If it makes the most sense to roll this discussion in with some larger effort to clean this up I am all for it. Rikster2 (talk) 20:59, 25 November 2013 (UTC)
• Support Rikster2's proposal Proposal reflects year ranges in reliable sources in the US sports domain (if not other countries and/or subjects). WP:GUIDELINE states in the lead that WP "does not employ hard-and-fast rules", allowing common sense in cases such as this. Per WP:PROPOSAL, guidelines are meant to document existing practices, not to override them. 2- or 4-digit format can coexist in WP, as long as there is consistency within a given article, and the format is consistent with sources in the article's domain.—Bagumba (talk) 21:22, 25 November 2013 (UTC)
• Support Rikster2's proposal, although "we currently do it this way" is not my primary reason. In football, it is common for a player to stay at a club for between a few months and a few years. It is therefore quite common for a player to be with a club in a period which under the six digit notation would be denoted as 2012–13. Often this will correspond with the 2012–13 season, but his actual tenure at the club could equally be significantly different from the length of time that notation would ordinarily imply. It is therefore preferable to have one form of notation for year ranges, and another for seasons, in articles where both would commonly be used. —WFC— _{FL wishlist} 21:51, 25 November 2013 (UTC)
• Another comment Princeton Editorial Style Guide says that a year range should be hyphenated and generally end in two digits when the range is used as an adjective. The range in the infobox effectively represents a noun, a tenure, and not an adjective. When the year range is a noun, the Princeton MOS recommends four digits, e.g. "from 1989 to 2005". The usage being contested in this thread is regarding a sportsperson's tenure listed in an infobox, not prose. It seems reasonable to allow the option for a compact form in an infobox to drop "from/to" but retain the 4-digit recommendation.—Bagumba (talk) 22:09, 25 November 2013 (UTC)
• Comment preferring uniformity I would tend to agree with the 6 digit form and support Epeeflech. I see no reason to extend the dates as long as the meaning is understood. JOJ ^Hutton 22:40, 25 November 2013 (UTC)
• Comment I disagree that Dates of birth and death has anything to do with the conversation as we're talking about sports tenures which are directly and unambiguously addressed in WP:YEAR. In the Gal Mekel example it is painfully obvious what the Manual of Style states should be done. Furthermore I am not seeing any good reason to change the MOS. Support Epeefleche. Also, regarding the comment "MOS itself says dates are normally shown in 6 digit format, meaning there are circumstances where they aren't", the circumstances where they aren't are plainly stated: "unless it is in a different century from that of the opening year, in which case the full closing year is given (1881–1986). " I find this discussion to be bizarre. The existing policy is neither ambiguous nor broken. Rejectwater (talk) 00:39, 26 November 2013 (UTC)
  • Comment I disagree. "Normally" is not "always" so I read that differently, otherwise there was no need for this to be bantered about to no resolution 7 months ago. And User:Jc3s5h is exactly right in that there are actually two different standards in two different places, so I don't see where anyone can truly argue that this does not need to be clarified at this point. Rikster2 (talk) 00:54, 26 November 2013 (UTC)
    • Please see "sports seasons spanning two calendar years should be uniformly written as 2005–06 season." This is not ambiguous in any way and requires no clarification. "Normally" is not "always": I agree. The word "always" does not appear in the paragraph "A closing CE or AD year is normally written with two digits (1881–86) unless it is in a different century from that of the opening year, in which case the full closing year is given (1881–1986). For clarity, years with fewer than four digits may be written in full (355–372)." Likewise, this paragraph is neither ambiguous nor in need of any clarification. "Dates that are given as ranges should follow the same patterns as given above for birth and death dates." Fantastic. This refers to terms where the entire date is written, as in "Jack Adams was general manager of the Detroit Red Wings for almost 35 years (May 14, 1927 – April 26, 1962)", or when exact dates are not known, or not entirely known (ie, the scenarios covered in the birth and death date section). There are two specific clauses that handle year ranges that only show years (tenures of sports players, for example): "Year ranges, like all ranges, are normally separated by an en dash, not a hyphen or slash: 2005–06 (unspaced) generally denotes a two-year range; 2005/06 may be used to signify a period of 12 or fewer months, such as a corporate or governmental fiscal year, if that is the convention used in reliable sources; sports seasons spanning two calendar years should be uniformly written as 2005–06 season. A closing CE or AD year is normally written with two digits (1881–86) unless it is in a different century from that of the opening year, in which case the full closing year is given (1881–1986). For clarity, years with fewer than four digits may be written in full (355–372)." I fail to see where any clarification or modification is necessary. That "there was no need for this to be bantered about to no resolution 7 months ago", I also agree with completely. Rejectwater (talk) 02:10, 26 November 2013 (UTC)
      • If "A closing CE or AD year is normally written with two digits (1881–86) unless it is in a different century from that of the opening year, in which case the full closing year is given (1881–1986)" means that 6 digit is mandated, then why is the qualifier "usually" included at all? Without the qualifier it means "always," no? With it (to me) it means "usually it's 6 unless it spans a century (in which case it usually means 8)". Very open to interpretation, which is why it was discussed to no resolution in the Spring. And "sports seasons spanning two calendar years should be uniformly written as 2005–06 season" refer to a single athletic season that spans two calendar years (like basketball or hockey), not multiple seasons (ie - tenures, which is the specific 8 digit use being discussed here). Rikster2 (talk) 02:20, 26 November 2013 (UTC)
• I replied yesterday and evidently neglected to save. The gist is that tables of sports data by season should simply use "1898-99", "1899-00", "1900-01". "1899-00" is clear in context and there is precedent, eg for use of YYYY-MM-DD in tables rather than any date format with alphabetic month names. --P64 (talk) 01:47, 26 November 2013 (UTC)
  • Clarifying question Each example you cite is a single sports season. Is your opinion also that tenures of multiple years (e.g. 2001-2005 or 2001-05 if you prefer) must be expressed this way? I think the answer is yes, but I'd like to be clear as single season ranges aren't the focus of the discussion. Rikster2 (talk) 02:28, 26 November 2013 (UTC)
• Would any of the supporters care to explain why it is a good thing for the MoS to specifically encourage 2012–13 and 2012–13, in the specific case of articles which routinely use both? In football the form 2012–2013 would never be used to denote a season, hence that form's desirability as a way of denoting year ranges. —WFC— _{FL wishlist} 02:04, 26 November 2013 (UTC)

• Support for the Request to formally insert language that an 8-digit date range format be allowable for sport tenures. Speaking as a member of the ice hockey project, an 8-digit date range format for article titles is the most commonly used format [1][2][3], and also allows for consistency in appearance when the years span over to the current Millennium. Although most defunct ice hockey teams and leagues have now been needlessly moved from their original (19xx–19xx) to (19xx–xx) titles (see All American Hockey League (2008–11) as just one of many examples), it is much preferred to use (19xx–19xx) for all such article titles when required. Not only does the 8-digit date range comply with WP:COMMONNAME (as least when to comes to ice hockey teams and leagues ) but it is also useful for clarity and consistency between articles which still use the 8-digit format in the title (for example International Hockey League (1945–2001)). Within ice hockey articles the 2012–13 format is correctly used for single seasons, but it is correct to use 2003–2009 to indicate a span of several seasons. Dolovis (talk) 21:32, 26 November 2013 (UTC)
• Strong oppose—Dolovis, eight digits might be, in your view, "the most commonly used format", but so what? We have special requirements, such as infoboxes and tables, both of which are space-constrained. I think this is a case of WP:I'MNOTUSEDTOIT. 124.171.120.208 (talk) 10:11, 27 November 2013 (UTC)
  • Can someone claim responsibility for the above IP comment? I find it strange that an IP's first edit would be this one, citing WP essays. Assuming good faith, I expect someone wasn't logged in, as opposed to engaging in some sort of sock puppetry. Rikster2 (talk) 19:57, 28 November 2013 (UTC)
    • Comment - currently the "space constrained" infoboxes in the majority of sport projects are doing just fine with the 8 digit format. I don't think that reason holds as much water as usage in the real world for the same purpose it's being used here. Rikster2 (talk) 12:54, 27 November 2013 (UTC)

• Correction: Normally the "2005–06 season" would be a 2-year season. A one-year season spanning 2005 and 2006, like an academic or fiscal year, would be the 2005/06 season (or 2005/2006 season). But sports seems to be an exception: "2005–06" is a season of 12 months or less, while "2005–2006" would imply two seasons. The seasons should therefore be 6 digit, while longer spans, such as 2008–2010 in this case, should be 8.
  Also, you can't respell Hebrew with English, so I deleted that. We can have a separate English pronunciation if we want. — kwami (talk) 17:19, 27 November 2013 (UTC)
• Strong oppose Rikster2's proposal: The 6 digit format year span is short and sweet, and is a format adopted as consensus after much discussion. It's a format perfectly suited to the density of infoboxes. Yes, different sports in different cultures seem to treat seasons' spans differently. However, I don't see many instances where there would be cause for ambiguity in an infobox – my major concern. The sport, the article and the other dates supply the necessary context for what the years mean. Also there is the inclination of editors to plaster these infobox dates with links to season articles, so I very much doubt that a year span like "1991–08", sandwiched between lines that have "1989–91 and "2008–11" as seasons, could ever be misconstrued, even if there were no links whatsoever. -- Ohc ^¡digame! 01:49, 29 November 2013 (UTC)
  • Could you please find and link the consensus discussion you mention? It would be helpful to this discussion because there is also a Consensus in the form of tens of thousands of articles for the 8 year span and we need to navigate the two. I should also point out that your proposal of a consistent 6 digit year span, even in cases spanning a century also does not meet current MOS phrasing. One way or the other, this standard will need to be modified. Rikster2 (talk) 03:03, 29 November 2013 (UTC)
• Oppose Rikster2's proposal. Much ado about nothing, frankly. The six digit format works for 99.9% of cases in the sports world, and I see absolutely no value in changing to eight simply for the sake of the .01%. Particularly since it is often unnecessary when placed in context. i.e.: in Jarome Iginla#Regular season and playoffs, nobody with a modicum of common sense would fail to understand that 1999–00 means "1999–2000". Resolute 19:00, 29 November 2013 (UTC)

Even regarding a span of full years, rather than a season spanning two-calendar years, we may expect that almost all readers understand "1999–00" in many contexts. For example, I read in a print newspaper three days ago that Joe Torre, newly elected to the baseball Hall of Fame, managed the New York Yankees to World Series victories in "1996 and 1998–00". Boston Globe or New York Times, a venerable newspaper that does edit such things. --P64 (talk) 23:59, 13 December 2013 (UTC)

Strong oppose. But I'm not so enamoured with "1998–00" ... readers have to stop for a half second to think about it. It's abominable that some infoboxes and tables currently clutter things up with full nine-character year-ranges; and even in running prose, I believe seven-character forms are easier to read (my PhD was in the pscyhology of reading, although I can't point to research precisely on this example, I concede ... it's a hunch from everything I have read on eye movement in reading text). Tony (talk) 01:51, 14 December 2013 (UTC)

• I support Rikster2's proposal for the same reasons as User:Number 57. The 8-digit range also avoid confusion with seasons. --Jaellee (talk) 12:04, 14 December 2013 (UTC)
• Support Rikster2's proposal for sports, as per N57. In association football the format is almost always "xxxx–xxxx". GiantSnowman 13:50, 14 December 2013 (UTC)
• Comment There's no way the average reader can be expected to know that 2012–13 is meant to mean something different than 2012–2013. I'm not crazy about the 2012–13 format in some situations, and don't think it has achieved consensus, which is why it is weasel-worded in the MOS. I think the MOS should be clarified to say that either is OK, and that it is reasonable to try to achieve consistency among a related group of articles. I do think it's reasonable to edit to use the abbreviated format in tables, if only to make better use of precious screen width. These seem like reasonable causes for edits, as opposed to blind following of MOS prescription. —[AlanM1(talk)]— 01:56, 18 December 2013 (UTC)
• Comment. Acceptable numeric season formats: 2011/2012, 2011/12 (only where space is severely constrained), 2012. Acceptable numeric time span formats: 2011…2012, 2011–2012, 2011 – 2012, 2011-12 – 2012-01, 2011-12-30 – 2012-01-02. Acceptable numeric month date format: 2013-12 (i.e. December). Everything else is too ambiguous. — Christoph Päper 13:27, 28 December 2013 (UTC)
  • Oppose two digit year formats such as 2011/12 or 2011-12, and two digit month formats (with no day) such as 2013-12, as I'm concerned this will encourage editors to add ambiguous formats such as 2001-03. GoingBatty (talk) 18:19, 29 December 2013 (UTC)
• Neutral for now... Due to the response that this has gotten so far, I've tagged it as an RfC to get a wider variety of input. Feel free to drop notes on appropriate forums or I can do it in about 9-10 hours (need to run out for a day with the ex and my baby). I'll also add it to {{Centralized discussion}} if not done. Technical 13 (talk) 13:57, 28 December 2013 (UTC)
• Support Rikster2's proposal. It makes sense especially given the fact that some sports pages already use the 8-digit format, and it would help certainly make reading slightly smoother in some cases, such as dates across centuries and cases where the second year could be mistaken for the month (I personally find something like "2001-02" a little distracting since I sometimes read it as "February 2001", although that may just be me...). I also don't expect that the proposal would cause problems with infobox formatting as someone above suggests, simply because I would expect editors to use common sense when applying the changes (it's not like the idea is to mandate that every year range in sports pages must be 8-digit!) As an aside, association football actually seems to use a variety of formats: both "YYYY-YYYY", and "YYYY-YY", are used at various points by the English Premier League.-Well-rested^Talk 16:16, 2 January 2014 (UTC)
• Comment Dates of the form "2003-04" are confusing in the |date= parameter in citations, since they may be interpreted or intended as "2003-2004" or "April 2003". I suggest making it clear that the six-digit year range (e.g. "2003-04") should be used only in prose, but not in citation date parameters or other locations where its meaning may be ambiguous. – Jonesey95 (talk) 16:38, 2 January 2014 (UTC)

• I dispute the concept that MOSNUM has authority over citations. If such a change is to be introduced, it should go in WP:CITE. Also, it should go through a separate RFC rather than being tucked into a thread that is only tangentially related. Note that such a change would potentially break software used in creating citations, whether used to create help:Citation Style 1 templates or other citation styles such as Chicago Manual of Style or APA style. Jc3s5h (talk) 16:53, 2 January 2014 (UTC)

• Support Rikster2's proposal There is no need to be prescriptive here, particularly given the potential for different conventions in different countries or sports. And the point about ambiguity is a valid one too. Neljack (talk) 01:37, 3 January 2014 (UTC)

• Comment There are also YYYY-Y ranges - there appear to be some on Aran_Islands#Further_reading, for example. GoingBatty (talk) 15:49, 4 January 2014 (UTC)

• Support for Rikster2's request: "Request to formally insert language that an 8-digit date range format be allowable for sport tenures." I personally think full-digit writings of years should be always allowed and always preferable in order to avoid potential confusion with YYYY-MM or YYYY-DDD formats (which themselves should be not advised). Startswithj (talk) 22:12, 5 January 2014 (UTC)

• Comment: Epeefleche is correct; MOS is clear on this and is the guideline. If Rikster2 wishes to change MOS he should open up a new RFC and propose his change there. Until consensus occurs through that process, edits should not be made in violation of standing MOS. Holdek (talk) 22:56, 6 January 2014 (UTC)

Comment This discussion is currently an RFC (see top of discussion). It is absurd to suggest that I reopen it and we start all over again. Rikster2 (talk) 23:12, 6 January 2014 (UTC)

Also, I must point out that Epeefleche himself has edited the article starting this discussion using two different date standards, using two different parts of MOS - I think what is clear is that MOS is not clear. This needs to be solved one way or the other. Rikster2 (talk) 23:16, 6 January 2014 (UTC)

The RFC is for comments on alleged violations of MOS by you. However, folks' reaction to your proposal might be a helpful predictor as to whether or not a new RFC by you would be successful in achieving consensus. Holdek (talk) 01:45, 7 January 2014 (UTC)

Totally disagree this is why this was put up for RFC, but why not ask the admin who listed it? 20-something editors have weighed in on my proposal so starting over is, in a word, nuts. It's also red tape for the sake of red tape. Rikster2 (talk) 01:57, 7 January 2014 (UTC)

I just left a message for the admin who listed the RFC. Hopefully he/she will come and clarify. Rikster2 (talk) 02:00, 7 January 2014 (UTC)

Just so I'm clear on the reason for my comment: regardless of the lister's intention, the template is above Epeefleche's complaint and his ending of, "Thoughts?" so I presumed that's what I was supposed to be responding to. I'm not trying to give you a hard time or add red tape for the sake of red tape or otherwise act "absurd" or "nuts." Holdek (talk) 23:10, 7 January 2014 (UTC)

• For the record, I'm the user that tagged this as an RfC. I'm as far from an admin as one could possibly be and the community would laugh at an RfA from me if one was posted because quite frankly, I have very poor social skills and am bad with communicating. That said, the reason I tagged this as an RfC is because I see mostly longer standing editors commenting here that are mostly specifically interested in how the MOS is set up and I thought it would be wise in order to get a wider range of consensus to tag it as an RfC to get a wider range of editors thoughts on this proposal. I am personally interested in the outcome of this as I spent a bit of time trying to make Template:Marriage conform to what my understanding of this is, and if it changes, I'll likely have to update that template again as well. I'm still neutral at this time, as I do not see a whole lot of extra participation going on. Happy editing! Technical 13 (talk) 14:07, 8 January 2014 (UTC)

So - where are we? All - there has been much discussion that lately has tailed off. Where is the closure on this topic. Currently MOS is inconsistent on this matter so the wording needs to be changed either to fully dictate that 8-digit year spans cannot be used or the MOS needs to be adapted to allow for 8 digit spans in certain circumstances. My concern is that this once again fades away and comes back up in 6-9 months. There is plenty of discussion on both sides of this issue so some moderation may be needed. Rikster2 (talk) 21:00, 22 January 2014 (UTC)

Support: I support the proposal. It would be very beneficial. -Pending^{(tell me I screwed up} 13:36, 23 January 2014 (UTC) — Preceding unsigned comment added by Pending (talk • contribs)

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)

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. 8⁠1/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 N⁠p/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}} = Template:Smallfrac, or {{smallfrac|77|23|50}} = Template:Smallfrac 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)

"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)

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 [4]. EEng (talk) 05:14, 24 January 2014 (UTC)

Is YYYY-MM an acceptable date format? Part 2

I've split this into "Part 2" because it was getting a bit long and I'd like to formalise it. The recent (29 Nov 2013) banning of the yyyy-mm format brings about a conflict between parts of MOS but also highlights that the conflict was waiting in the wings as an unknown consequence. The guidelines state:

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

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

The talk page discussion was only among a small set of contributors over a short period of time, so the repercussions were not obvious and were not thrashed out. After nearly three weeks of thinking it through, I haven't found an acceptable solution from any angle but I intend to thrash out the repercussions now . Hopefully it will inspire somebody to suggest a good solution or possibly to find a least-bad solution or at least to make the repercussions obvious in the guideline itself.

I will state each solution I could think of and follow each with pros and cons. Please add your own pros or cons within each subsection.

New ideas can be added to the end of the list.  Stepho  talk  23:37, 11 January 2014 (UTC)

Disallow yyyy-mm-dd altogether

Removes the source of all the conflict. Not used in common English speech anyway. Will make tables wider (big problem). Will require many articles to be changed (by bot?). Might get considerable kick back from some editors. Has trouble with the recommendation to use {{sort|2008-11-01|1 Nov 2008}}. Will need a formal discussion at MOS, not a quick discussion here.  Stepho  talk  23:37, 11 January 2014 (UTC)

As an amateur astronomer and software dev, I write and speak in ISO 8601 (big-endian, YMD) formatting, and I see it and hear it spoken more often than other formats. It should not be disallowed altogether, and I for one would prefer it become our standard first choice in all non-prose contexts. Startswithj (talk) 03:32, 13 January 2014 (UTC)

Support It wouldn't make many tables wider as this is not really that common in tables and for those that it might make wider there is a simple remedy: abbreviate the month. Dmy and mdy dates with abbreviated months are only marginally longer (if any longer at all) than ymd dates. I'm not sure what trouble there might be with the recommendation to use {{sort|2008-11-01|1 Nov 2008}}. Yes, there are some who prefer ymd but for most of us English speakers it is unfamiliar. I see no reason to allow ymd for the benefit of the few at the expense of the many. Jimp 11:48, 13 January 2014 (UTC)

Support. With all respect for those who are familiar with, or even actually use, this format, there is a fundamental reason for not using it in Wikipedia: it is completely ambiguous to those who are not familiar with it (which, I submit, includes most people on the planet). There's no way of telling by inspection whether 2001-07-09 is 9 July 2001 or 7 September 2001. How can anyone know whether or not those who write their dates mdy invert that order to ydm when they want to put the year first (as would be perfectly logical)? Other number-only date formats are not used here for exactly this kind of reason; this one should join them. There's no need to specifically disallow it. All that's needed is to say that all-number date formats are not used here, and month names are written in letters. That would answer the original question here also. Justlettersandnumbers (talk) 00:52, 16 January 2014 (UTC)

Curious comment - it's the only format that is totally 'unambiguous (assuming the Gregorian calendar). There is no group that uses yyyy-dd-mm (with the day in the middle) that I know of. WP:BADDATEFORMAT explicitly comments on dd-mm-yyyy and mm-dd-yyyy as being ambiguous (and hence banned) but there is no such comment for yyyy-mm-dd.

Your use of "most people on the planet" is a bad generalisation becuase most people in northern Europe and Asia are completely comfortable with this format and actually comprise most people on the planet. Granted that this format is still unknown to many native English speakers, it is gaining more traction in technological fields - especially those where technical details have to be shared amongst practitioners from multiple nations.  Stepho  talk  05:58, 16 January 2014 (UTC)

yyyy-mm-dd is not the only format which is unambiguous: dmy & mdy are perfectly unambiguous as long as the month is written in letters. As for there being no group that uses yyyy-dd-mm, what about those who do so by mistake? Perhaps "most people on the planet" is a bad generalisation but those who do use ymd (your "most people in northern Europe and Asia") do so because it's part of their language and their language is not English. Most English speakers on the planet not familiar with it and this is the point. Jimp 08:49, 20 January 2014 (UTC)

Per Jimp. Few English-speakers can parse this format naturally, without a double take. So support. -- Ohc ^¡digame! 07:06, 16 January 2014 (UTC)

Support. Agree with Ohc and Justlettersandnumbers. But we went into all this at enormous and occasionally acrimonious length in an RfC a year or two ago, and unfortunately there was no consensus for this change. (I suspect this was mainly because so many active Wikipedians of the sort likely to take part in such an RfC are rather techie and geeky people for whom this format does not seem as weird and difficult as it does to most ordinary readers.) -- Alarics (talk) 09:37, 17 January 2014 (UTC)

Perhaps this is a good time to try again? The format is unambiguous only to those who already know that no-one uses yyyy-dd-mm. Does anyone know that? I know that I don't, and it seems that Stepho-wrs isn't too sure. It is understandable that it would have been more widely used in the early days of computing, before operating systems were able sort by date without such artificial devices. But that what was, what, twenty-five or thirty years ago? Our purpose here is to be clear, and to be unambiguously clear. A date format that requires specialist knowledge to be understood is hardly consistent with that aim. Justlettersandnumbers (talk) 10:30, 17 January 2014 (UTC)

Oppose. Just to get a feel for how often yyyy-mm-dd is used, I tried a couple of google searches for 2012-01..12 and just 2012 across en.wikipedia.org (both searches with a simplistic removal of disambiguation, sign post and picture of the day articles which nearly always use yyyy-mm-dd in their title):

• 3,000,000+ results from https://www.google.com.au/search?hl=en&as_q=%222012+-02%22+%7C+%222012-03%22+%7C+%222012-04%22+%7C+%222012-05%22+%7C+%222012-06%22+%7C+%222012-07%22+%7C+%222012-08%22+%7C+%222012-09%22+%7C+%222012-10%22+%7C+%222012-11%22+%7C+%222012-12%22&as_epq=&as_oq=&as_eq=%22sign+post%22+%22wikipedia+signpost%22+%22featured+picture%22+POTD&as_nlo=&as_nhi=&lr=&cr=&as_qdr=all&as_sitesearch=en.wikipedia.org&as_occt=any&safe=images&tbs=&as_filetype=&as_rights=
• 82,500,000 results from https://www.google.com.au/search?hl=en&as_q=2012&as_epq=en+wikipedia+org&as_oq=&as_eq=&as_nlo=&as_nhi=&lr=&cr=&as_qdr=all&as_sitesearch=&as_occt=any&safe=images&tbs=&as_filetype=&as_rights=

That gives about 4%. But the result for 2012-01..12 is missing pages that use yyyy-mm-dd reference dates but don't happen to include dates from 2012. And the result for just 2012 is also including many pages that don't have properly dated references. So I feel comfortable that the true number is at least 4% and probably greater than 10%.

I also tried it from a different angle. I pressed Wikipedia's Random page 51 times and tallied which type of dates were used in references. I was quite surprised by the result. I counted:

• 7 articles that used predominately yyyy-mm-dd,
• 11 that use the spelt out form,
• 3 that used both forms, with neither predominating
• 30 that didn't use either (no references, references without dates, disambiguation pages).

Now, 51 isn't statistically significant - especially when 30 have to be thrown away. But 10 articles that have yyyy-mm-dd reference dates (predominantly or mixed) out of 21 shows that there must be quite a few editors that like using them. You are all quite welcome to try your own tally from random pages - the more pages the better.  Stepho  talk  00:19, 18 January 2014 (UTC)

I'm not so sure about "quite a few editors that like using them". My impression is that a lot of instances of yyyy-mm-dd reference dates are put there by bots, such as Reflinks. -- Alarics (talk) 09:05, 18 January 2014 (UTC)

Well, count me in for those liking the yyyy-mm-dd format (on Wikipedia, only inside references). Got used to it long time ago, primarily because it's very easily sortable. — Dsimic (talk) 00:37, 19 January 2014 (UTC)

Results from a sample of WP articles will be skewed by the fact that until recently the cite templates required yyyy-mm-dd. This requirement was put in place for autoformatting purposes. By the time autoformatting was ditched, the notion that yyyy-mm-dd was fine, even the preferred standard, had become well entrenched. I'd suggest that a lot of these yyyy-mm-dd we find in references are relics from the bad old days of date linking and autoformatting and that most of those that were put in since we're formatted like this due to the impression that ymd was the done thing for refs. Jimp 08:49, 20 January 2014 (UTC)

Oppose. YYYY-MM-DD is the International Standard for date and time formats (http://www.cl.cam.ac.uk/~mgk25/iso-time.html) under ISO 8601. It would be ridiculous for Wikipedia to disallow usage of an international standard. I also dispute the statements by Jimp that:

"those who do use ymd (your "most people in northern Europe and Asia") do so because it's part of their language and their language is not English. Most English speakers on the planet not familiar with it and this is the point."

"I'd suggest that a lot of these yyyy-mm-dd we find in references are relics from the bad old days"

The YYYY-MM-DD format is not uncommon in the UK and is becoming more common. Much as you may question it, our language is English! This usage may not be common in North American English, but there are many English speakers who are familiar with this format. Secondly, I'd suggest that, far from being relics, many of the "yyyy-mm-dd we find in references" are because usage of the ISO format is becoming increasingly common, at least outside N.America. TrevorD (talk) 01:18, 21 January 2014 (UTC)

Oppose. YYYY-MM-DD is the international standard for date formats and it makes sorting by date trivially easy. And it's not as uncommon in English-speaking countries as some claim. In Canada, for example, many government documents use this format (such as tax returns and passport applications). -Zanhe (talk) 00:49, 26 January 2014 (UTC)

Disallow yyyy-mm-dd for references.

Removes the source of all the conflict for references. Might still have conflicts in tables but less likely. Not used in common English speech anyway. Will require many articles to be changed (by bot?). Might get considerable kick back from some editors.  Stepho  talk  23:37, 11 January 2014 (UTC)

Again, I would prefer ISO 8601 become WP's standard first choice in all non-prose contexts. Startswithj (talk) 03:32, 13 January 2014 (UTC)

The argument for allowing ymd in tables and/or lists is even weaker than that for allowing it in references. If we get rid of this unfamiliar format in references, there'd be no reason to keep it anywhere. Jimp 11:48, 13 January 2014 (UTC)

Per Jimp. Few English-speakers can parse this format naturally, without a double take. So support. -- Ohc ^¡digame! 07:06, 16 January 2014 (UTC)

Oppose. Quite popular among editors (see tally in 'Disallow yyyy-mm-dd altogether' section above) and likely to get a lot of kick back.  Stepho  talk  00:19, 18 January 2014 (UTC)

Oppose. YYYY-MM-DD is the International Standard for date and time formats (http://www.cl.cam.ac.uk/~mgk25/iso-time.html) under ISO 8601. It would be ridiculous for Wikipedia to disallow usage of an international standard. (See my additional comments under 'Disallow yyyy-mm-dd altogether' section above.)

I also agree with Startswithj's comment that "ISO 8601 [should] become WP's standard first choice in all non-prose contexts." We should be moving forwards - not backwards! TrevorD (talk) 01:18, 21 January 2014 (UTC)

Put conflict repercussions in guideline

State "yyyy-mm-dd is allowed but as soon as a single year and month combination is required then all references must be changed to one of the other allowed formats". Sounds like a rigid schoolmistress grudgingly telling you that yes, you can do that but put one foot out of step and she will come down on you like a ton of bricks. Seems strange to allow you to use this format for references but that the very probable case of a magazine reference will require you to change to one of the other formats (at considerable expense). Goes very much towards disallowing/discouraging yyyy-mm-dd altogether (did I hear a cheer?)  Stepho  talk  23:37, 11 January 2014 (UTC)

Again, I disagree. Startswithj (talk) 03:32, 13 January 2014 (UTC)

I can't see this working. Jimp 11:48, 13 January 2014 (UTC)

A workable algorithm is more trouble than this is worth. -- Ohc ^¡digame! 07:06, 16 January 2014 (UTC)

Again Oppose. YYYY-MM is permitted under ISO 8601. See http://www.cl.cam.ac.uk/~mgk25/iso-time.html:

"If only the month ... is of interest: 1995-02" TrevorD (talk) 01:18, 21 January 2014 (UTC)

Allow yyyy-mm in limited cases

Allow references to use yyyy-mm because references rarely have a date range for the publishing date. For references such as financial results, the date range is often (but not always) in the title and publication date is usually a full date at the end of the range (eg "Company XXX financial results 2012-2013", 2013-08-05), Similarly, some references may have a publishing date at the start of the range. Doesn't cover all cases.  Stepho  talk  23:37, 11 January 2014 (UTC)

I would agree that we might recommend against YYYY-MM due to potential confusion with YYYY-YY (range), but I would not disallow it. I would sooner agree with disallowing YYYY-YY for ranges. Startswithj (talk) 03:32, 13 January 2014 (UTC)

This could be confusing. Jimp 11:48, 13 January 2014 (UTC)

Not one used frequently in the outside world, so can be a problem to parse. Too easily confused with the year range at the best of times. -- Ohc ^¡digame! 07:06, 16 January 2014 (UTC)

I agree with Startswithj. I agree that it might be confusing and that we might recommend against using YYYY-MM, but we should not disallow using an International Standard. I also would sooner agree with disallowing YYYY-YY for ranges. TrevorD (talk) 01:18, 21 January 2014 (UTC)

Allow mixed date formats in limited cases

Allow most references to be yyyy-mm-dd but year+month combos can be in 'January 2014' style (possibly 'Jan 2014' or less favourably '2014-Jan'). Makes a mockery of MOS:DATEUNIFY but most articles ignore it anyway. User: BattyBot has been changing yyyy-mm to mmmm yyyy, translating a violation of WP:BADDATEFORMAT into a violation of MOS:DATEUNIFY.  Stepho  talk  23:37, 11 January 2014 (UTC)

I'd certainly appreciate if BattyBot would stop changing ISO 8601s to MMMM YYYY. Startswithj (talk) 03:32, 13 January 2014 (UTC)

@Startswithj: As stated below, I have temporarily commented out the BattyBot code that changes yyyy-mm format while this discussion is going on. If the MOS is changed, then the code will be changed accordingly. GoingBatty (talk) 04:00, 13 January 2014 (UTC)

Awesome, thank you. User: AnomieBOT might be another? startswithj (talk) 05:05, 13 January 2014 (UTC)

This would soon lead us to a messy situation. Jimp 11:48, 13 January 2014 (UTC)

Frankenstein solution. Quasimodo is next. ;-) -- Ohc ^¡digame! 07:06, 16 January 2014 (UTC)

Make all references use the {{cite}} family of templates and make them use year, month, day parameters.

Allows a future addition to the user preferences to display these params in the user's preferred style. Doesn't help for tables. Unlikely to succeed because we're still trying to convince people to use the cite family at all. Also, the cite family deprecated the separate fields and prefer a single date param.  Stepho  talk  23:37, 11 January 2014 (UTC)

Date autoformatting is dead and gone. For all the reasons it was killed off in the first place, it's not likely to be raised from the dead. The cite templates are not universally used. Also, does this actually fix the problem? Jimp 11:48, 13 January 2014 (UTC)

Per Jimp. Citation templates encourage editors to populate with too much unimportant information, often wrongly. -- Ohc ^¡digame! 07:06, 16 January 2014 (UTC)

Year ranges should use yyyy-yyyy

Disallow yyyy-yy. Since 2001-03 has two possible interpretations, disallowing yyyy-yy is technically as valid as disallowing the other interpretation of yyyy-mm. Likely to be very hard to enforce.  Stepho  talk  23:37, 11 January 2014 (UTC)

@Stepho-wrs: First of all, thank you for creating this very detailed post. I hope it will lead to a consensus and clarification on the appropriate MOS pages. I have temporarily commented out the BattyBot code that changes yyyy-mm format while this discussion is going on.

My primary concern is that the use of unambiguous year ranges (e.g. "2013-14") may encourage editors to use ambiguous dates (e.g. "2001-03"). While "yyyy-yyyy" may be hard to enforce, we can choose to set a good example for our fellow editors. GoingBatty (talk) 17:04, 12 January 2014 (UTC)

I could agree with banning YYYY-YY for ranges. I think it has less validity than YYYY-MM, and the potential confusion is easily abated through writing the full four-digit year. Startswithj (talk) 03:32, 13 January 2014 (UTC)

A fan on ymd would think yyyy–yy had less validity than yyyy-mm but I'd disagree. yyyy–yy is pretty normal in English (as opposed to yyyy-mm). I would not be in favour of disallowing a common form of expression to make room for an uncommon one. Jimp 11:48, 13 January 2014 (UTC)

yyyy–yy is OK so long as we are clear that only years can be shown in this way. The ndash ensures that any ambiguity is kept to a minimum. -- Ohc ^¡digame! 07:06, 16 January 2014 (UTC)

Unnecessary complication. But this is only needed if we don't clarify or ban the ambiguous format of the type '2001-04'. -- Ohc ^¡digame! 07:06, 16 January 2014 (UTC)

Again, I agree with Startswithj. YYYY-MM is a valid format because it is permitted under ISO 8601, and therefore should not be disallowed. TrevorD (talk) 01:18, 21 January 2014 (UTC)

Year ranges should use yyyy-'yy

The second year is truncated, so it should be marked as such. Same as writing "Jan '14" as shorthand for "January 2014". Removes all conflict with yyyy-mm. Probably a good idea, no matter how the yyyy-mm discussion ends.  Stepho  talk  23:37, 11 January 2014 (UTC)

While writing "Jan '14" is an established custom, writing "2013-'14" isn't; it would be a novel extension by the English Wikipedia. I think it would leave readers wondering if that notation has some special meaning they had never heard of. Jc3s5h (talk) 19:00, 12 January 2014 (UTC)

YYYY-'YY looks weird to my eyes, personally. Startswithj (talk) 03:32, 13 January 2014 (UTC)

As per the above, we can't just go making things up: they wouldn't be understood even if they were used in the first place (and to get them used would be an uphill battle in itself). Jimp 11:48, 13 January 2014 (UTC)

currently not allowed by the guideline, and this change would involve a single-quote mark that would be otherwise redundant. Retrograde step. -- Ohc ^¡digame! 07:06, 16 January 2014 (UTC)

References use year and issue fields instead of date

A magazine labelled as June–July 2013 was probably published in mid-to-late May 2013. It is technically the June–July issue from 2013. Gets around a technicality but when displayed it will still look like June–July 2013 or 2013, June–July (depending on vagrancies of the cite template), which still looks like a violation of MOS:DATEUNIFY to the reader. Doesn't help for tables.  Stepho  talk  23:37, 11 January 2014 (UTC)

Magazines and journals often have both an issue number and a date, the later sometimes being expressed as a range such as "June–July 2013". Readers should be provided with both the date and the issue number to give them the greatest chance of finding the right article and confirming the copy in their hand is the right one. The information can also help to confirm that a citation in another article that seems to be to the same source really is. Jc3s5h (talk) 00:01, 12 January 2014 (UTC)

Sorry, I should have been clearer. If the publishing date is known then of course it should be used. But if the publishing date is unknown and the journal has a spelt out month such as 'June' or 'June–July' on the front cover then this suggestion might be applicable (subject to further discussion).  Stepho  talk  21:56, 12 January 2014 (UTC)

First off, I believe if you're going to provide metadata in the form of parameters, it should be accurate. The only use of issue I've ever seen is a number that allows the various issues that constitute a volume to be put in order. Putting a date in an issue parameter is providing false metadata and shouldn't be done. In the rare case where a parameter is mandatory, but putting accurate data in the parameter would make the cite template misbehave, that citation should be formatted by hand rather than introducing false metadata just to make the template work.

Next, the publication date is whatever the publisher says it is. If the publisher prints May–June 1974 on the cover, that's the publication date. If the editor saved his receipt and it's dated April 1, 1974, that makes no difference, the publication date is still May–June 1974. This is because the publication date is not primarily for determining when the publication first became available; the primary purpose is so that a reader can compare the date in the citation to the date on the magazine in his hand and determine if he has the right issue or not. Jc3s5h (talk) 23:11, 12 January 2014 (UTC)

I could see allowing this, but I don't think it should be required. As a reader, I'm more interested in dates (exact dates if possible), rather than issue numbers. Startswithj (talk) 03:32, 13 January 2014 (UTC)

Whatever looks like a violation of MOS:DATEUNIFY to the reader is a violation of MOS:DATEUNIFY. Jimp 11:48, 13 January 2014 (UTC)

Although I tend to agree with Jimp, I see no practical problems with this format, but this should probably populate the |issue= field instead of |date=. -- Ohc ^¡digame! 07:06, 16 January 2014 (UTC)

Restrict yyyy-mm-dd to reference accessdate and archivedate

Emphasize that yyyy-mm-dd is only allowed in "accessdate" and "archivedate" fields in references, not in "date" (or publication date), per the citation style guidelines.

This eliminates the need for commenting on yyyy—mm–mm, yyyy-season, yyyy-yyyy, etc. — Arthur Rubin (talk) 00:08, 16 January 2014 (UTC)

Close but not quite. The line in question in the {{cite}} documentation is:

"Accessdate and archivedate in references should all have the same format – either the format used for publication dates, or YYYY-MM-DD. See: MOS:DATEUNIFY."

This says that yyyy-mm can be used for accessdate and archivedate even when date uses another format. {{Cite}} it makes no prohibition against any other date format used in other fields.

Also, as much as I love the cite family, they should be submissive to here and to MOS - MOS should not be submissive to the cite family.

However, restricting yyyy-mm-dd to these two fields means that the publication date must be fully spelt out, which does remove the conflict. But it looks strange and unprofessional to have two dates on the same reference line in different formats. And the conflict still remains for tables.  Stepho  talk  05:58, 16 January 2014 (UTC)

Does not resolve the apparent inconsistency if/when the publication date is in dmy or mdy format. Also, as it stands now, "|archivedate=2014-01-12" renders in the reference as "Archived from the original on 2014-01-12", which looks simply awful. -- Ohc ^¡digame! 07:06, 16 January 2014 (UTC)

Use the {{date|yyyy-mm-dd}} template

Why isn't the {{date|yyyy-mm-dd}} template used more widely on Wikipedia? As far as its documentation tells, it's supposed to format displayed dates however each Wikipedia account is configured. That way, we'd have no disputes and endless discussions about preferred formats; Wiki code would always (and uniformly) contain {{date|yyyy-mm-dd}} templates, and readers could enjoy the dates in whichever format they prefer. In my opinion, that would be the best solution. Thoughts? — Dsimic (talk) 18:33, 16 January 2014 (UTC)

According to its documentation, {{Date}} does NOT attempt to present dates in the format preferred by the reader; it parses the input date and outputs it in a format specified by a template parameter. Automatic formatting of dates was rejected in the RFC at Wikipedia:Manual of Style/Dates and numbers/Date Linking RFC Jc3s5h (talk) 18:53, 16 January 2014 (UTC)

Thank you for correcting my understaning of how {{Date}} template works, I've somehow misunderstood its documentation. Then, how about making {{Date}} to take user preferences for dates formatting, maybe? Regarding the mentioned RFC, as far as I can see it's about linking dates for the side-effect of their formatting, what obviously isn't a good thing, as concluded in that RFC. In other words, to me, linking dates is wrong, but their formatting is right. Thoughts? — Dsimic (talk) 19:21, 16 January 2014 (UTC)

The concept of automatic formatting of dates was rejected after several long RFCs. In addition, it is technically difficult. The former mechanism only worked for logged-in users, but the majority of readers are not logged in. There is no existing mechanism for a reader with no account to indicate a preference; the general feeling was that mechanisms that don't work for the vast majority of readers are not worth considering.

Also, it is very difficult to find a way to render the mdy format and the dmy format correctly from the same input. Consider these examples:

• The event occurred August 21, 1985, and was very successful.
• The event occurred August 21, 1985; it was very successful.
• The following rules went into effect 1 January 1970:

Obviously it would be quite tricky to determine when a comma should be added after the year for an mdy date. Jc3s5h (talk) 19:41, 16 January 2014 (UTC)

Maybe taking the browser locale, by looking into values of Accept-Language request headers for example, would be an acceptable solution for not logged-in readers? I've seen some commercial web-based enterprise software doing exactly that.

Sorry, but I'm a bit confused about adding commas after years in auto-formatted MDY dates, as years are at the end of strings produced that way? Couldn't any required trailing punctuation marks be added manually, just as links can be extended ([[cookie]]s, for example)? — Dsimic (talk) 19:57, 16 January 2014 (UTC)

Suppose an editor thinks in terms of the mdy format, so codes The wildly successful-#^magicdaterenderer|1985|August|21+#^, event was repeated the next year. Then a reader with her date preference set to the dmy format reads the article and sees "The wildly successful 21 August 1985, event was repeated the next year." The comma after the year is correct for the mdy format but not for the dmy format. Jc3s5h (talk) 20:08, 16 January 2014 (UTC)

Ah, yes. Makes sense now, thanks. Though, an MDY format with its commas is somewhat awkward in such cases, but that's a topic for a totally different debate. :) — Dsimic (talk) 20:42, 16 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 [[5]] and [[6]] 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)

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)

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)

"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 [7] -- 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 [8] 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)

Feedback requested on formatting innovations

Bold, spaced semicolons, code examples

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

(1) Use of bold to make "use cases" visually easy to find e.g.

2005/06 may be used to signify a fiscal year or other special period

(2) "Spaced" semicolons between examples:

355–372 (not 355–72) ; 95–113 ; 95–113 AD

...because with the more conventional

example, example

...it seems (to me) too hard to tell whether we're looking at two examples, or just one (that happens to have a comma in the middle -- it doesn't help that the coloration of the little comma is impossible to see).

(3) "Code:" examples for use of nbsp, endash, etc.

EEng (talk) 02:01, 16 January 2014 (UTC)

• The second change is fine with me, makes things much more readable. For (2), it's good to use semicolons, but without spaces before them; that's going to cause all kinds of formatting issues, with long lines wrapped so a semicolon starts a line etc. Also, that's against how semicolon is generally used. Regarding the first change, applying bold style is fine with me, though in general that's against MOS:BOLD and italicization should be used instead; MOS must have been an exclusion from its own rules. :) — Dsimic (talk) 23:09, 17 January 2014 (UTC) — Dsimic (talk) 01:58, 18 January 2014 (UTC)

Just to be clear, by "second change" you mean (2), right?

Re the bold: bold's main use (beyond emphasis -- at a level not generally appropriate for articles) is to make key phrases etc. jump out visually in a list of instructions, a reference to be consulted in a hurry, etc. And since WP:NOTMANUAL blah blah blah, that doesn't make sense in articles either. But MOS is a manual, so I think that use of bold (to catch your eye with phrases like birthdates of living persons or Old Style dates or whatever) makes perfect sense. EEng (talk) 23:49, 17 January 2014 (UTC)

Exactly, second change is (2), and first change is (1).

I'm perfectly fine with using bold typeface in MOS, it makes things much more readable; I was just trying to make everything clear to the point any later review of this isn't finding it incomplete. — Dsimic (talk) 00:30, 18 January 2014 (UTC)

• In (2), I favour semicolons between examples, but not preceded by a space. Firstly, that's not consistent with proper style in English. Secondly, spaces will lead to wrapping problems where the semicolon will appear at the beginning of lines of text unless you use a non-breaking space, and even then some editors will use a plain space without recognising the difference. Thirdly, the issue (if there is one) seems to arise from the green/red formatting the {{xt}} and {{!xt}} templates use, in which case it may be preferable to adjust the formatting those templates (and associated templates) use. I've customised my stylesheet so the examples are surrounded by a dotted green or red border, so each example appears distinct to me anyway, and you could adopt a similar format for your custom stylesheet if you find the default formatting particularly irksome, rather than prescribing a change to how everyone writes examples across Wikipedia. —sroc 💬 01:27, 18 January 2014 (UTC)

On second thought, I agree with sroc, and I will be changing my comment above. — Dsimic (talk) 01:58, 18 January 2014 (UTC)

Sroc, I wasn't "prescribing a change to how everyone writes examples across Wikipedia". I was trying out a new idea for formatting examples on this page, to address a problem I saw. After people had a chance to comment, it might (a) completely disappear; (b) continue to be used on this page only; (c) slowly spread to other pages where it makes sense; (d) catch fire and suddenly be used everywhere as the greatest thing since sliced bread. It's OK if there's a little inconsistency among pages, a little experimentation, a little demonstration. That's how progress is made.

Suggesting that a problem (if there is one) should be fixed by a user changing his own stylesheet is ridiculous. If it's really a problem likely to annoy many users, we should fix it; and if not then there's nothing to be fixed.

It doesn't matter whether it's "proper style of English" -- programming manuals, style books, and similar works jumping back and forth between text and metatext use all kinds of techniques to keep those clearly separate that you won't find elsewhere. SPACE;SPACE was an experimental way of delimiting examples that (without requiring squinting determine the color of a tiny comma) could be immediately distinguished from the examples themselves. SPACE;SPACE obviously fulfills that requirement exactly because it has the very attribute you complain of -- it's not anything you see in normal English, so can't be confused for part of the examples themselves.

BTW, putting text in green and in red isn't any kind of "proper style of English" I've ever seen. Assuming you haven't either, why aren't you complaining about that too? Here as elsewhere you're so preoccupied with propriety, instead of practicality (not to mention reality), that you get tangled up in your own arguments. (And -- again BTW -- that sentence you just read is a place where, yes, the paren should be followed by a comma.)

SPACE;SPACE may be too radical and I have no special affection for it. I'm happy with just a semicolon (spaced the normal way -- EXAMPLE;SPACE) is enough, because semicolon is sufficiently unusual -- in the few cases where semicolon might be misunderstood to be part of the example, we can break the examples out to separate lines.

All in favor?' EEng (talk) 08:42, 18 January 2014 (UTC)

Sorry I misunderstood the scope of your proposal from your (vague) original post. Was that diatribe response really necessary? I agreed that semicolons were preferable to commas. On the spacing, I pointed out several flaws with your proposal. If others agree that the separation between examples is unclear, then something should be done, but not necessarily what you proposed. If not, then I gave you a DIY fix. I was merely trying to be helpful by raising points you may not have realised or thought of. No need for the blown gasket, Charlie. —sroc 💬 03:05, 19 January 2014 (UTC)

(Nice work on the latest innovations to the date formatting tables, by the way.) —sroc 💬 03:09, 19 January 2014 (UTC)

And thank you for your contributions as well -- I was running out of steam on the table (I hate that syntax with all the ||s and stuff) and just couldn't face breaking up the examples further. I think the result so far is a much, much improved presentation, and the surprising fact that no MOS swarms have appeared out of nowhere to eat out our livers means we must be doing something right.

Naturally I'll be going through to tinker. If you feel strongly about anything we've push-pulled on already raise it here.

Contrary to concerns you've posted elsewhere, except for my very first post (re your statement that I had edited "against consensus" -- that really pissed me off!) I'm not upset nor in any way personally offended. I do think we have different sensibilities on certain subjective questions (in some cases, the differences begin with the fact that I consider subjective many things you consider subjectiveobjective -- a bit of a paradox there) but such tension can be productive, so long as you bear in mind that I'm always right.

File:Turning the Mind Inside Out Saturday Evening Post 24 May 1941 a detail 1.jpg

A pair o' docs

A pair o' docks

EEng (talk) 12:49, 19 January 2014 (UTC)

If you consider subjective many things I consider subjective, our differences may be more similar than you think. —sroc 💬 16:26, 19 January 2014 (UTC)

Well, I said it was a paradox, didn't I? (See images.) Anyway, objectivity is subjective (skip to 0m50s if you're in a hurry).

EEng (talk) P.S. I take it you see now [9] the sense in using a character sequence not found in standard English to separate examplesnot consistent with proper style in English.

P.S. What?! (1) I started off saying "I favour semicolons between examples"! (2) When did semicolons stop being "found in standard English"?

—sroc 💬 01:25, 21 January 2014 (UTC)

They didn't. What you said (and I sorry I misquoted you -- corrected above) is, "I favour semicolons between examples, but not preceded by a space. Firstly, that's not consistent with proper style in English."

Just to make sure... we're in violent agreement on this. I proposed "spaced semicolons" (Ex1 ; Ex2) but figured it would be too radical. You countersuggested normally-spaced semicolons (Ex1; Ex2), and I agreed, because semicolon is rare enough in examples that there won't be too many situations wherein confusion could arise (requiring the examples to be broken out to a bullet list etc.). With commas, in contrast, that happens a lot, as you noted in your edit I linked above. If I were dictator I'd dictate spaced ; but I'm not, so I'm happy with everyday ;.  :)

An important point: I'm not speaking to you again until I get some kind of amused response to the pair o' docs and the pair o' docks. That pair 'o docs, by the way, performed one of the first partial removals of the large intestine, thus inventing the semicolon. EEng (talk) 02:57, 21 January 2014 (UTC)

I must disagree: I'm opposed to violence. —sroc 💬 09:41, 21 January 2014 (UTC)

Semicolon + two spaces

Oh, here's a better way I stumbled upon at MOS:ENDASH—a semicolon followed by three spaces (;   ):

• pp. 211–19;   64–75%;   the 1939–45 war
• 10:30 pm Tuesday – 1:25 am Wednesday;   Christmas Day – New Year's Eve;   Christmas 2001 – Easter 2002
• boyfriend–girlfriend problems;   the Paris–Montpellier route;   a New York–Los Angeles flight
• the Uganda–Tanzania War;   the Roman–Syrian War;   the east–west runway;   the Lincoln–Douglas debates;   a carbon–carbon bond

Let's do that! —sroc 💬 15:03, 21 January 2014 (UTC)

Agreed, spaced that way it looks great! — Dsimic (talk) 01:45, 22 January 2014 (UTC)

I think the even greater separation lent by the 3 spaces is yet another improvement but (especially with 3 spaces "available" now) want to bring back the idea of using one of the 3 to clearly separate the ; as seen here:

• pp. 211–19 ;  64–75% ;  the 1939–45 war

Actually, while my head says that SPACE ; SPACESPACE is more logical my eye says that ; SPACESPACESPACE looks better, so I'll go with whichever the rest of you prefer. I am, however, extremely disappointed at getting not even a giggle at the paradoxical images above, despite dropping hints, giving elbow nudges, and even delivering the extremely topical and clever quip seen in bold. In future I shall cast my pearls before more appreciative swine. EEng (talk) 04:44, 22 January 2014 (UTC)

Umh, I'm still against spaces before semicolons.

About the images, they did bring a smile on my face, and the "semicolon surgery" was funny too! :) You're almost always bringing smile on my face with your comments and overall writing style. :) — Dsimic (talk) 04:54, 22 January 2014 (UTC)

By the way, {{spaces|2}} could be used as a shorthand for   . — Dsimic (talk) 02:22, 25 January 2014 (UTC)

Actually, we don't want semi+nbsp+nbsp but rather semi+nbsp+regularspace -- otherwise no linebreak would be permitted between examples. I'm gonna try this fmt out in WP:Manual_of_Style/Dates_and_numbers#Ranges. If it really catches on a template for semi+nbsp+space as one package would be helpful, but let's wait and see. EEng (talk) 09:03, 25 January 2014 (UTC)

Hm, but you actually proposed use of "   " (that's nbsp+nbsp+space)? That also allows line wrapping, as it includes a regular space. — Dsimic (talk | contribs) 18:17, 25 January 2014 (UTC)

A little chat

Wow. That was really nice of you to say.

Not everyone agrees, however. One editor said that my writing (and in particular my use of the phrase remarkably small) "reads like a teenage girl's diary." I was about to ask what teenage girls' diaries he'd seen until I realized... it was probably the diary of a high school or college girlfriend. The intense feelings of inadequacy this no doubt instilled in him well explain the dyspeptic hostility seen in his activities here.

Anyway, thanks again. You did see the "Coffee-fueled parody" here [10], didn't you? EEng (talk) 06:24, 22 January 2014 (UTC)

You're welcome. Well, it all depends on how people are busy, I'd say. When people are really busy and thus unable to catch up, they tend to detect any digression as completely pointless; usually, males then project that onto the stereotypical female banter-style orientation. On the other side, when people have some slack, a certain amount of fun is actually good; all work and no play makes Joe a dull boy. Of course, all play and no work is equally bad.

And of course, those "radar-equipped year-with-no-comma-detector vans" are hilarious. :) — Dsimic (talk) 06:44, 22 January 2014 (UTC)

There really was a Mill quote I was gonna bring in, but it was a stylistic letdown after Arendt, so I didn't. But for the record here it is, from On Liberty' (Chapter III: "Of Individuality, as One of the Elements of Well-Being"):

In some such insidious form there is at present a strong tendency to this narrow theory of life, and to the pinched and hidebound type of human character which it patronizes. Many persons, no doubt, sincerely think that human beings thus cramped and dwarfed, are as their Maker designed them to be; just as many have thought that trees are a much finer thing when clipped into pollards, or cut out into figures of animals, than as nature made them.

I wish I could write like that. IMHO the three greats of the English essay, ever, are Orwell, Mill, and the strangely forgetten John Wilkins. EEng (talk) 16:57, 22 January 2014 (UTC)

Although I'm more of a binary geek than reading a lot of fine books and great writers, I do agree that humans are still very far away from understanding the true gears behind everything. This video might be interesting to you, in case you haven't watched it already. — Dsimic (talk) 18:23, 22 January 2014 (UTC)

snd template

There's a {{sn}}{{snd}} template for "spaced ndash" i.e. nbsp + ndash + regular space. Any reason not to start using that in e.g. the code examples at WP:Manual_of_Style/Dates_and_numbers#Ranges? EEng (talk) 16:34, 17 January 2014 (UTC)

• For what it's worth, templates of this type can cause problems when they are included in |date= and similar parameters in cite templates. It's fine to use them in examples, but if clever editors view the wiki source, copy the example, and use it in a cite template, it might generate a red error message, and a bot or an editor will have to come along and fix it. And then someone will no doubt post somewhere saying "but the MOS uses them in date range examples, so they must be allowable." Because that happens.

So if they are included, a note (even a hidden comment, for source viewers) about not using them in cite templates might be in order. I sigh because it's all so picky, but clear communication up front may allow us to avoid some of those conversations. – Jonesey95 (talk) 19:03, 17 January 2014 (UTC)

I'll look into what you're saying in a minute, but don't want to waste any time before pointing out that got the template name mixed up in my OP -- now corrected there. EEng (talk)

OK, now that I've gotten over being an idiot in posting the wrong template name... I don't see what the problem is with cite templates. Please explain. EEng (talk) 23:13, 17 January 2014 (UTC)

I was going to provide an example citation, but all of the endashed date ranges that I can think of will give errors regardless of whether templates are used or not, because complex date ranges are currently marked as errors by the cite templates' Lua module code. They should be supported soon, but are not right now. Too much to explain here; see Module_talk:Citation/CS1#HTML_entity_for_n-dash for a taste, and Module_talk:Citation/CS1#Legitimate_date_range_examples_to_add_to_the_date_checking_part_of_the_CS1_module for an extended take on date ranges in CS1 citation templates. – Jonesey95 (talk) 23:24, 17 January 2014 (UTC)

Without getting into whether certain values are or are not valid in certain fields of certain templates, I still don't see, if nbsp+ndash+space is a legal value, why a template that expands to exactly that shouldn't also be legal. And if nbsp+endash+space isn't legal, then none of this matters anyway. EEng (talk) 00:13, 18 January 2014 (UTC)

<bump> Jonesey95, if you really think there's some problem with using snd in citation templates, please explain. Otherwise I don't see why MOS shouldn't start presenting it in code examples. EEng (talk) 03:24, 21 January 2014 (UTC)

Well... I can't explain it, at least not with examples, because the CS1 modules do not currently support validation of date parameters with date ranges that require spaced endashes, like "Fall 1996 – Winter 1997" or "May 27 – June 3, 2002". Since the current module code would mark these as invalid dates regardless of punctuation (because a feature request has not been implemented yet), using a regular spaced endash or {{snd}} will produce identical error messages. As you can see in the linked examples, it doesn't even handle regular endashes of various types consistently.

Go ahead and use {{snd}} in the examples. Since the module has not been programmed to check for these date ranges, it may be able to check for {{snd}} in its new code. – Jonesey95 (talk) 04:56, 21 January 2014 (UTC)

• I've always used that one as {{spaced ndash}}, btw. — Dsimic (talk) 23:02, 17 January 2014 (UTC)

The advantage of {{snd}} is, of course, brevity. It's kind of the tail wagging the dog for the little dash to take up more space in the code than the 4-digit years (or whatever) on either side. EEng (talk) 23:22, 17 January 2014 (UTC)

Makes sense; just got wiring of my brain changed, so {{snd}} is my new friend. :) — Dsimic (talk) 00:44, 19 January 2014 (UTC)

hanging indent, multiple columns for examples

Please don't use templates like {{hanging indent}} or {{columns-list}}. The first causes the text to be misaligned; it is not designed for this purpose, and the use of columns makes it look very disorganized. Using a fixed number of columns is very much discouraged, and it is simply not needed for lists with very few items. — Edokter (talk) — 12:23, 18 January 2014 (UTC)

(1) It does seem something goes wrong with alignment in one situation which you (quite properly) reverted here [11].

(2) There's a bewildering array of multicolumn templates and I just closed my eyes and picked one; certainly a fixed # of columns was dumb. I've removed all the multicolumns for now.

[Later: turns out I failed to remove tham all, actually. [12]] EEng (talk) 10:39, 20 January 2014 (UTC)

(3) However, I don't see the problem with hanging indent. I want to fool with it more myself before trying to explain the use case -- maybe I won't like it myself anyway.

EEng (talk) 13:54, 18 January 2014 (UTC)

Can you "fool with it" in the sandbox, please, not in MOS where everyone will see you building castles with lopsided turrets. —sroc 💬 07:06, 19 January 2014 (UTC)

That's what I meant by fool with it "myself" -- I'm not afraid to innovate modestly on the live page (and almost everything I've done has met with approval so far -- just minor corrections and suggestions) but the moment I get resistance on something new of course I stop moving in that direction, rethink and experiment privately, and either drop it or open a discussion. EEng (talk) 02:57, 21 January 2014 (UTC)

Bullets vs. hanging for example lists

It seems that lists of examples that were previously presented in bullet form are now simply indented without bullets. For example, this edit by User:EEng (I don't have it in for you; you've just been busy) changed this:

• Publication dates in article references should all have the same format. Although nearly any consistent style may be used, avoid all-numeric date formats other than YYYY-MM-DD.

For example, in the same article, write

• Jones, J. (20 Sep 2008)
• Smith, J. (Sep 2002)

but not

• Jones, J. (20 Sep 2008)
• Smith, J. (September 2002)

to this:

• Publication dates in article references should all use the same format. For example, in a single article write

Jones, J. (20 Sep 2008)

Smith, J. (Sep 2002)

but not

Jones, J. (20 Sep 2008)

Smith, J. (September 2002)

Similarly, this edit, introduced this:

• In spelling out numbers, "components" from 21 to 99 are hyphenated; larger ones are not:

fifty-six

five hundred

two thousand four hundred sixty-six

four hundred seven

I'm not sure this is a good thing. Adopting such formatting has a potential to cause confusion between where one example ends and the next begins if the examples are long enough approach the right-hand margin (depending on the device/screen size/window size you happen to be using), which would seem to contradict the point EEng made above about separating examples with semicolons for clarity. Should the bullets return? —sroc 💬 07:33, 19 January 2014 (UTC)

• Hm, it does look cleaner without the bullet points, but that's pretty much an example of form winning over function. I'd vote for returning bullet points back, as it makes clear where are the boundaries of examples. — Dsimic (talk) 01:28, 20 January 2014 (UTC)

Ah, but the hanging indent solves that, as you'll see in a moment. I hope no one objects to my merging this section with the section just prior, because they're actually the same subject. I'm also going to outdent the remainder of my post. Ready? Execute outdent! Executing outdent, sir!

OK, that's better.

Unfortunately the Jones/Smith example above is unique in that the Jones/Smith entries together constitute a single example -- they're not two separate examples. (Though that one example is used repeatedly -- once in green/good, then , modified, in red/bad). So let's leave that one for now. The "numbers writ out" example is more typical. Anyway, take a look at this. Try successively narrowing the window to see what happens to the examples.

Extended content

Pretend these are MOS rules, each introduced by a bullet: A MOS rule saying lorem ipsum A second MOS rule, being a very very very very very very very very very very very very very very very long one wrapping to multiple lines Another MOS rule saying lorem ipsum lorem ipsum lorem ipsum lorem ipsum lorem ipsum A MOS rule blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah Current technique for examples Each is bulleted: good example, bad example or other information good example somewhat longer, bad example longer longer longer longer longer unusual example which exhibits a length so very very long that it almost (but not absolutely) certainly wraps to the next line, bad example good example, bad example Another MOS rule blah blah blah blah blah blah Alt 1 Using hanging indent instead: good example, bad example or other information good example somewhat longer, bad example longer longer longer longer longer unusual example which exhibits a length so very very long that it almost (but not absolutely) certainly wraps to the next line, when it wraps, see what hanging indent does good example, bad example Another MOS rule blah blah blah blah blah blah Alt 2A: bullet list using •   •  good example, bad example or other information   •  good example somewhat longer, bad example longer longer longer longer longer   •  unusual example which exhibits a length so very very long that it almost (but not absolutely) certainly wraps to the next line, when it wraps, see what hanging indent does   •  good example, bad example Another MOS rule blah blah blah blah blah blah Alt 2B: Same as 2 w/ modified spacing    • good example, bad example or other information    • good example somewhat longer, bad example longer longer longer longer longer    • unusual example which exhibits a length so very very long that it almost (but not absolutely) certainly wraps to the next line, when it wraps, see what hanging indent does    • good example, bad example Another MOS rule blah blah blah blah blah blah Alt 2C: "bullet" is & gt;   > good example, bad example or other information   > good example somewhat longer, bad example longer longer longer longer longer   > unusual example which exhibits a length so very very long that it almost (but not absolutely) certainly wraps to the next line, when it wraps, see what hanging indent does   > good example, bad example Another MOS rule blah blah blah blah blah blah Alt 2D: "bullet" is & rarr;  → good example, bad example or other information  → good example somewhat longer, bad example longer longer longer longer longer  → unusual example which exhibits a length so very very long that it almost (but not absolutely) certainly wraps to the next line, when it wraps, see what hanging indent does  → good example, bad example Just another rule at the end

An advantage of bullets is that they catch the eye as it passes down the page: "point... next point... next...". They give the first-time reader overview ("OK, I see there are 4 short points for me to absorb, then one long one..."); the returning reader seeking a point vaguely remembered can use the bullets to skip quickly from point to point ("This one? No, next bullet... This one? No, next bullet...").

What I don't like about the current technique is that the bullets on the examples dilute the eye-catching function of the first-level bullets, and make the left margin much busier, especially since most examples fit on a single line anyway: you pretty much get bullet after bullet coming at you, like from a machine gun.

Instead I'm proposing (for discussion -- not married to it) to replace the bullets with hanging indentation, as seen in Alt 1. I think it's a good fit because most examples fit on one line anyway, so that visually each new line is a new example -- no bullet needed. For the occasional example that wraps to a second line, the hanging indent gets the second (and any subsequent) lines out of the way visually, but indenting them more.

One issue is that the {{hanging indent}} template is verbose. I suppose we could invent {{hi}} for short. Thoughts? EEng (talk) 01:55, 20 January 2014 (UTC)

• Got your point with the hanging indentation, and it does work as expected. Though, with all the respect, I still prefer bullet points, as they simply make things more readable, at least to me. Maybe those bullet points are welded into my perception after spending so much time looking into them, but that's my current point of view.

How about making second-level (and third etc.) bullet points different than the first-level ones? I do agree that having multiple-level bulleted lists is making overall layout overcrowded, especially with short lines on the second level. If we had second-level bullet points different and thus less visibile, maybe that would also be a good solution? — Dsimic (talk) 03:23, 20 January 2014 (UTC)

I agree, having all levels of bullets identical makes it more difficult to parse the page at a glance. Having different bullets at different levels could work, but it may be too much to expect the wiki software to do this automatically. Perhaps we can invent a bullet specifically for examples?

An alternative would be to indent the sub-ordinate bullets by more than one step to make the leap between super-ordinate list of points and sub-ordinate list of examples more obvious, but I'm sure this would have its share of problems (e.g., reduced compatibility with smaller screens). —sroc 💬 07:10, 20 January 2014 (UTC)

See Alts 2A (smaller bullet) and 2B to 2D (fanciful variations). As usual there's a bewildering array of mis-named ill-coded templates for symbols and formatting, so I just hacked it up for now. No doubt there's a cleaner way to do it -- if nothing else we can invent another mis-named, ill-coded template. For anyone considering rushing in where angels fear to tread, {{bullet}} doesn't give the same thing as & bull; and see partial list of bullet-like things here Template:•/doc#Dot_size_reference_list. EEng (talk) 09:32, 20 January 2014 (UTC)

Looks good. I would prefer simpler bullets (e.g., circles) rather than icons which might otherwise be used in examples (e.g., 30,00,0000 → 30,000,000). —sroc 💬 11:20, 20 January 2014 (UTC)

Everyone's excited about &bull;

To me, these below are perfect – looking great, consistent with the first-level bullets layout/spacing, and of course very readable:

• Another MOS rule blah blah blah blah blah blah Alt 2A: bullet list using &bull;

  •  good example, bad example or other information

  •  good example somewhat longer, bad example longer longer longer longer longer

  •  unusual example which exhibits a length so very very long that it almost (but not absolutely) certainly wraps to the next line, when it wraps, see what hanging indent does

  •  good example, bad example

With a neat template, maybe {{bullet2}}, {{smb}} (small bullet) or something similar, that would be awesome. — Dsimic (talk) 21:09, 20 January 2014 (UTC)

I agree -- looks great! I'll use it in a few places live, using the hackish approach from above, and hope to stimulate more reaction. In the meantime, take a look at Template:Unordered_list -- do any of those geekishly-explained parameters allow us to substitute the "bullet" character? One special problem, I can predict now, is that the template machinery has to take into account the width of the bullet, in order to pad the right spacing on each side to get the total margin indent right.

Other editors -- what do you think? EEng (talk) 03:21, 21 January 2014 (UTC)

Template:Unordered list uses CSS to specify a base-64 encoded PNG image in order to produce customized bullet points, so everything should be still properly aligned when that image is substituted with another image of the same size. So, I've created a suitable PNG image (containing a small bullet), and tried specifying it through list_style and item_style parameters, but with zero success – bullets are staying the same, while everything is Ok with the CSS (it works as expected when applied via Firebug, for example).

Either I'm doing something wrong, or the template doesn't allow changing the value of list-style-image CSS property. Here's an example; merge it into single line, got it broken into multiple lines so it doesn't break the layout of this talk page:

{{unordered list|one|two|three|list_style=list-style-image: url("data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAANAQMAAABb8jbLAAAABlBMVEUAAAAAAAClZ7nPAAAAA XRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAAJcEhZcwAACxMAAAsTAQCanBgAAAAHdElNRQfeARYCMSElQjWOAAAAD0lEQVQI12NgQ AEFYAgGAAvqAVGb+hUDAAAAAElFTkSuQmCC");}}

— Dsimic (talk) 03:03, 22 January 2014 (UTC)

Hopefully some helpful wizard will drop by to explain what's going on with that. Just to repeat, the character we're so excited about is &bull;, and note that the *-at-line-begin syntax doesn't give this "bullet" but something else. In the meantime, for simple cases where there's no chance of linewrap (certain tables, etc.) I've created {{bullj}} (for "bull just" or "just-a-bull", since some idiot's created {{bullet}} and even {{bull}} to mean nbsp + &bull; + space -- how dumb can you get?) EEng (talk) 04:05, 22 January 2014 (UTC)

When tried out with plain HTML, like this:

<ul style="list-style-image:url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAANAQMAAABb8jbLAAAABlBMVEUAAAAAAAClZ7nPAAAAA XRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAAJcEhZcwAACxMAAAsTAQCanBgAAAAHdElNRQfeARYCMSElQ jWOAAAAD0lEQVQI12NgQAEFYAgGAAvqAVGb+hUDAAAAAElFTkSuQmCC);">

<li>one</li>

<li>two</li>

<li>three</li>

</ul>

the rendered HTML contains

<ul style="/* insecure input */">

what almost for sure means that MediaWiki disallows such embedding of images inside CSS definitions. Such stuff could be used for exploiting some security issues in browsers, so it's understandable why that isn't allowed. — Dsimic (talk) 04:30, 22 January 2014 (UTC)

What we could get are square points, like this:

• First level, then second
  • one
  • two
  • three

D'oh! — Dsimic (talk) 04:37, 22 January 2014 (UTC)

Nah, that spoils it, because those squares aren't as visually retiring as & bull; If worse comes to worst, can't we just copy {{unordered list}} to some new name (and please, let's think about that name first) and suitably modify it? EEng (talk) 05:16, 22 January 2014 (UTC)

I agree, squares are not even remotely close to what &bull; provides. Discovering that required CSS adjustments aren't allowed was pretty much a sinking feeling... To my (quite shallow) knowledge of MediaWiki, no approach of copying or modifying existing templates would bring us there, as those protections are probably deep inside MediaWiki (based on CSS being filtered out on a plain <ul> HTML element). Anyway, just as I wrote, my knowledge of MediaWiki is not so good, so let's see what the other editors are going to say about this. — Dsimic (talk) 05:26, 22 January 2014 (UTC)

Revamped "Acceptable date fmts" table

I've (boldly -- yes indeed very boldly) revamped the "Acceptable fmts" table at [[13]]. I think it presents all the previous info more systematically, but I know change can be disconcerting. Comments invited.

However, unless it's really, really wrong, I'd appreciate its being left in place for at least a while so others can see and comment on it, so as many as possible can be involved. EEng (talk) 03:41, 21 January 2014 (UTC)

Here are the old and the new...

[Later: In addition to OLD and NEW, there's a new Alt1] EEng (talk) 07:47, 21 January 2014 (UTC)

OLD Acceptable date formats

Format	Example	Where used
D MMMM YYYY Day, space, full month, space, full year	8 September 2001	General use
MMMM D, YYYY Full month, space, day, comma, space, full year	September 8, 2001
D MMM YYYY Day, space, short month, space, full year	8 Sep 2001	Only in references, tables, lists or areas where conciseness is needed (see Wikipedia:Citing Sources § Citation style)
MMM D, YYYY Short month, space, day, comma, space, full year	Sep 8, 2001
YYYY-MM-DD Full year, hyphen, two-digit month, hyphen, two-digit day; use only with years 1583–9999	2001-09-08
D MMMM (Day, space, full month) MMMM D (Full month, space, day)	5 March March 5	Only where no ambiguity (He was born 1866 May 5 but died June 7 or January 1 is New Year's Day)

• When writing dates as MMMM D, YYYY, follow the year with a comma (unless the year is followed by other punctuation):

The weather on September 11, 2001, was clear and warm.

Everyone remembers where they were on July 21, 1969—when Neil Armstrong first set foot on the Moon.

Acceptable date formats (NEW, Alt0)

NEW (Alt0, as posted and reverted) Acceptable date formats For general use For use only where brevity required (references, tables, lists, etc.‍—‌see WP:Citing Sources#Citation style) Notes 22 April 2001 Code: 22{{nbsp}}April 2001 22 April  22 Apr 2001 Code: 22{{nbsp}}Apr 2001 22 Apr  Omit year only where there is no risk of ambiguity: Born 5 May 1866, he died on 7 June January 1 is New Year's Day When writing a date such as April 22, 2001, follow the year with a comma (unless followed by other punctuation): The weather on July 11, 1969, was clear and warm. Everyone remembers July 21, 1969—when man first set foot on the Moon. April 22, 2001 Code: April{{nbsp}}22, 2001 April 22  Apr 22, 2001 Code: Apr{{nbsp}}22, 2001 Apr 22  [yyyy-mm-dd format not for general use] 2001-09-22 Code: 2001-09-22 Use only with years 1583–9999

Acceptable date formats (NEW, Alt1)

Where used Example Markup General use 22 July 2001 22{{nbsp}}July 2001 July 22, 2001 July{{nbsp}}22, 2001 When using these formats, follow the year with a comma (unless followed by other punctuation): The weather on July 21, 1969, was clear and warm. Everyone remembers July 21, 1969‍—‌when man first set foot on the Moon. Only where brevity required (references, tables, lists, etc.‍—‌see WP:Citing Sources#Citation style) Jul 22, 2001 Jul{{nbsp}}22, 2001 22 Jul 2001 22{{nbsp}}Jul 2001 2001-07-22 2001-07-22 Use only with years 1583–9999 Only where no risk of ambiguity: Born 5 May 1866, he died on 7 June January 1 is New Year's Day 22 July July 22 Jul 22 22 Jul 22{{nbsp}}July July{{nbsp}}22 Jul{{nbsp}}22 22{{nbsp}}Jul

Well, that didn't take long

According to one observer [14], the new table "looks awful, is confusing, and has left out substance from the original." Let's start with the least subjective complaint. What "substance from the original" has been left out? EEng (talk) 04:26, 21 January 2014 (UTC)

I like the new format - people tend to absorb examples (with a small amount of notes) better than they absorb lavishly detailed formulae and explanations. Minor gripes: 'Code:' is probably confusing to most people. Possibly use 'Wiki mark-up:' or similar. Even better to drop the entire line (no need to worry about & nbsp ; to avoid splitting on line breaks).  Stepho  talk  05:34, 21 January 2014 (UTC)

Thanks. I'll wire your "expense reimbursement" to the usual numbered account, yes? I think the code is important though, for a coupla reasons

• Editors really should be learning to place {{nbsp}}s as appropriate. It's maybe 50% a pet peeve of mine, but 50% is that it looks awful when a day # is stranded at the end of a line.
• It replaces the awkward "year, space, full month, comma, space, day" that was there anyway.

I put the code directly beneath the sample date to help the reader relate the bits of code to the human format. Maybe that's not so good. Anyway, I'm working up another fmt that's more like the old one (and changes "Code" per your suggestion).

EEng (talk) 05:51, 21 January 2014 (UTC)

OK, see Alt1 above -- now my preferred (and proposed) version. Thoughts? EEng (talk) 07:47, 21 January 2014 (UTC) P.S. Still would like to hear what "substande from the original" is missing, as claimed.

Thank you for bringing the discussion to the talk page. Making radical (potentially controversial[*]) changes to project pages (particularly the much trafficked MOS) without discussion first is so prone to upset and edit-warring, especially if one repeatedly undoes reverts by others and leaves a breadcrumb trail of edit summaries to justify the changes instead of forming consensus first. [*By "controversial", I mean subject to dispute or differing opinions, not necessarily scandalous. 15:36, 21 January 2014 (UTC)]

Let me add that EEng has been putting a lot of effort into MOS these last few days and I think some of this is a marked improvement on the earlier state of affairs: for example, setting out the entire "Unacceptable formats" section in a table is clearer than the dot points and random-examples-table we had, and it was a bright spark to come up with that. Kudos.

I actually think the old "Acceptable date formats" table was fine — I refer here to the last consensus version without the last row D MMMM and MMMM D that EEng has inserted here. I'm not afraid of innovation, but I have the following issues with these revised versions:

1. It is less clear because it does not provide any explanation of the acceptable formats (e.g., D MMMM YYYY) and instead relies solely on examples. This compounds confusion when the guideline later refers to specific formats (e.g., "YYYY-MM-DD") without having established that notation earlier. The reader has to read between the lines, and this is unnecessary.

2. The coding is unnecessary: editors know how to enter the text. It's also garish.

3. In both the new "Old" version and revised "Alt1" version, it is unclear whether omitting the year is permitted only in prose or in references as well.

4. The example Born 5 May 1866, he died on 7 June is very much prone to ambiguity: it is not at all clear that "he" died in the same year as his birth, so it's a horrible example for "where there is no risk of ambiguity".

5. Tables should have a heading for each column: e.g., in the "Alt1" version, the last column might be headed "Notes".

6. Tables become ugly when cells are merged over different spans in different columns: for example, in the "Alt1" version, disregarding the header row, the first cell in the first column ("General use") spans rows 1 and 2 and the second cell (Only where brevity required") spans rows 3, 4 and 5, whereas the first cell in the third column spans rows 2 and 3, and therefore spans some but not all of two different "Where used" cases. This is rather counter-intuitive and no doubt difficult for some readers to follow which cells overlap which rows.

7. Shrinking the text to shoehorn long notes and examples into all-pervasive tables makes it more difficult to read and may present an accessibility issue.

—sroc 💬 10:17, 21 January 2014 (UTC)

8. The last row in "Alt1" implies that D MMM and MMM D formats may be used anywhere there is no ambiguity over the missing year; actually, these formats should not be allowed in prose (just as neither are D MMM YYYY nor MMM D, YYYY), but this is not clear from the structure of the table.

9. The formatting of the examples in that row ("22 July/July 22/Jul 22/22 Jul") is cracked because the line breaks are within the example templates rather than using a separate template on each line: with my custom CSS, they are formatted as a single example with line breaks (i.e., no borders at the start/end of each line).

—sroc 💬 15:36, 21 January 2014 (UTC)

Alt 1B

Thank you for your kind comments and (despite confusion re nuns) I look forward to continued collaboration. I hope you'll forgive my numbering your points above for ease of reference, and I've created a revised "Alt 1B" incorporating some of your comments.

1. With one exception the only format referred to later is "the all-numeric YYYY-MM-DD", and I've added e.g. "(e.g. 2001-04-22)" at each reference to clarify (a bit clunky, but that can be improved later). The exception is that in the no-no table the formats DD-MM-YYYY and MM-DD-YYYY are mentioned, and these are directly adjacent to examples of those formats which make it obvious what is meant. The other format "pictures" aren't used at all so the old table was teaching a headache-inducing taxonomy for no apparent purpose.

2. I think the code layouts are good for two reasons (neither of which, on its own, would convince me to use them):

• Contrary to what you say, editors don't know where to put the {{nbsp}}s, as is obvious from looking at almost any article
• The code layouts double as replacements for the very clunky "full month name, space, day, comma, space, blah, blah, huh??" specifications inflicted by the old tables

3. If you think this is important suggest clarifying text to be added.

4. We've gone over and over this. You keep fussing that this --

In 1877 a son was born January 13, but the child died February 8.

-- is ambiguous because (you say) the reader can't be sure that the "February" referred to is February of 1877. I'm sorry, but that's ridiculous, and reflects the strange rigidity of thinking that you display now and then. (I say that with only the greatest affection, of course.) It's just idiotic. No one in his right mind would read that and say, "Huh? Wait... did the baby die at age one month, or one year and a month, or two years and a month... maybe the baby grew up and became President of the US and then died at the age of 87 years, plus one month. What ambiguous writing!" You would have us write --

An appeal was filed September 3, 1972; arguments were heard on September 27, 1972; and the Court ruled October 4, 1972.

-- instead of --

An appeal was filed September 3, 1972, arguments were heard on September 27, and the Court ruled October 4.

In fact, let me quote from a recent US Supreme court opinion Planned Parenthood v. Abbot (November 19, 2013):

In July of this year, the State of Texas passed two amendments to its abortion laws, which were to go into effect on October 29.

Mr. Justice Breyer didn't write "to go into effect on October 29, 2013", because he knows that his readers, by application of their native shrewdness, will infer that "October" is the October following the July already specified.

Now please, since the Supreme Court has ruled in my favor, can we drop this?(I surmise that you live outside that court's jurisdiction, but I'm asking you to respect its moral, if not judicial, authority.) EEng (talk) 08:33, 22 January 2014 (UTC)

5. No, not every column of every table needs a heading. If the content of a column is patently obvious, and can only be described by some vacuous phrase, then a heading adds nothing and can (or should) be omitted.

6. I agree that the relationship of the cells and overlaps take some thinking to understand, but that reflects the complexity of the rules being represented, which induce a sort of Venn diagram of rules applying to cases. The alternative is to go back to a lot of bullet items describing verbally, instead of visually, which rules apply to which formats. (I've changed it a bit in the new version below.) Also, this can probably be improved by changing the weight of (or erasing) some of the cell borders.

7. I "smalled" the verbiage because I think it looks better. I could be wrong. As I recollect {{small}} keeps text within size guidelines.

8. This requires more of the complex precision you complained of in item 6. However, I've tried to address this in Alt 1B below -- probably can do better with some thought.

9. Fixed in Alt 1B.

EEng (talk) 08:33, 22 January 2014 (UTC)

Acceptable date formats (NEW, Alt1B)

Acceptable date formats (NEW, Alt1B)

Where used Example Markup General use 22 July 2001 22{{nbsp}}July 2001 July 22, 2001 July{{nbsp}}22, 2001 When using these formats, follow the year with a comma (unless followed by other punctuation): The weather on July 21, 1969, was clear and warm. Everyone remembers July 21, 1969‍—‌when man first set foot on the Moon. Only where brevity required (references, tables, lists, etc.‍—‌see WP:Citing Sources#Citation style) Jul 22, 2001 Jul{{nbsp}}22, 2001 22 Jul 2001 22{{nbsp}}Jul 2001 2001-07-22 2001-07-22 Use only with years 1583–9999 Shorten month only where brevity is required, per above. Omit year only where no risk of ambiguity: Oktoberfest 2013 began 21 September and ended 6 October January 1 is New Year's Day 22 July July 22 Jul 22 22 Jul 22{{nbsp}}July July{{nbsp}}22 Jul{{nbsp}}22 22{{nbsp}}Jul

• I believe the complex alignment of the columns will lead many editors to misinterpret the table. I also believe someone will come along and change the alignment, but no one else will notice for several months, after some bot coded to the non-consensus meaning has changed tens of thousands of articles. One reason I predict this problem is that in a diff, words are much easier to notice than column alignment. Jc3s5h (talk) 17:21, 22 January 2014 (UTC)

Alt 1C/1D

Here's my go at showing how this table might be better adapted. I've also replaced the {{center}} template with align=center | as it's easier to follow than counting the nested braces.

Acceptable date formats (NEW, Alt1C)

Acceptable date formats (NEW, Alt1C)

Where used Example Markup Notes General use 22 July 2001 22{{nbsp}}July 2001 July 22, 2001 July{{nbsp}}22, 2001 When using these formats, follow the year with a comma (unless followed by other punctuation): The weather on July 21, 1969, was clear and warm. Everyone remembers July 21, 1969‍—‌when man first set foot on the Moon. Only where brevity required (references, tables, lists, etc.‍—‌see WP:Citing Sources#Citation style) Jul 22, 2001 Jul{{nbsp}}22, 2001 22 Jul 2001 22{{nbsp}}Jul 2001 2001-07-22 2001-07-22 Use only with years 1583–9999 General use 22 July July 22 Jul 22 22 Jul 22{{nbsp}}July July{{nbsp}}22 Jul{{nbsp}}22 22{{nbsp}}Jul Omit year only where no risk of ambiguity: Oktoberfest 2013 began 21 September and ended 6 October January 1 is New Year's Day Shorten month only where brevity is required, per above.

Where did this requirement to use {{nbsp}} in dates come from? —sroc 💬 11:06, 22 January 2014 (UTC)

Later. Bed now. Must rest. EEng (talk) 04:48, 23 January 2014 (UTC)

Here 'tis without the markup column, the only purpose of which is to highlight the use of {{nbsp}} (which is not the only way to produce a non-breaking space, nor does this appear to be an established convention):

Acceptable date formats (NEW, Alt1D)

Acceptable date formats (NEW, Alt1D)

Where used Example Notes General use 22 April 2001 April 22, 2001 A comma follows the year in these formats (unless followed by other punctuation): The weather on July 21, 1969, was clear and warm Everyone remembers July 21, 1969‍—‌when man landed on the Moon Only where brevity required Apr 22, 2001 22 Apr 2001 2001-04-22 Use only with years 1583–9999 General use 22 April April 22 Omit year only where there is no risk of ambiguity: In 2013, Ramadan started 10 July and ended 7 August January 1 is New Year's Day Only where brevity required Apr 22 22 Apr

—sroc 💬 11:20, 22 January 2014 (UTC) [revised —sroc 💬 01:32, 23 January 2014 (UTC)

Your 1D is by far the best so far. (I was too focused on the minimalism -- too many Karnaugh maps as a youth, you see.) But some ideas for hybridizing some of the versions we've passed through are beginning to simmer... EEng (talk) 04:48, 23 January 2014 (UTC)

You must be good at KenKen puzzles. —sroc 💬 08:59, 23 January 2014 (UTC)

Hate them. EEng (talk) 15:26, 23 January 2014 (UTC)

Alt 2A, 2B, 2C, 2D

Acceptable date formats (NEW, Alt2A) -- withdrawn

General use Only where brevity required (tables, lists, references, etc.) Notes August 22, 2001 22 August 2001 Aug 22, 2001 22 Aug 2001 In these two formats, a comma follows the year (unless followed by other punctuation): The weather on September 11, 2001, was clear and warm Everyone remembers July 21, 1969‍—‌when man landed on the Moon 22 August August 22 Aug 22 22 Aug Omit year only where there is no risk of ambiguity: In 2013, Ramadan began 10 July and ended 7 August January 1 is New Year's Day mmmm-dd-yy format not for general use 2001-08-22 Use only with Gregorian dates between 1583 and 9999

Sroc, I've left out the "not in prose" etc. provisions -- I think the "only where brevity [etc]", with its examples, makes that clear, and I fear people will start arguing about what "prose" means etc etc and so on and so forth. EEng (talk) 15:26, 23 January 2014 (UTC)

I rather like this idea of having separate columns for "General use" and "Where brevity is required", but could we possibly reduce the wording in the column heading for the latter (move some of it to the footnote if necessary)? Also, can we split the MDY and DMY examples so that the note clearly only applies to MDY without needing that awkward [*] that isn't used anywhere else? —sroc 💬 22:28, 23 January 2014 (UTC)

Thusly:

Acceptable date formats (NEW, Alt2B)

Acceptable date formats (NEW, Alt2B)

General use Selected cases where brevity is required Notes 22 August 2001 22 Aug 2001 August 22, 2001 Aug 22, 2001 A comma follows the year (unless followed by other punctuation): The weather on September 11, 2001, was clear and warm Everyone remembers July 21, 1969‍—‌when man landed on the Moon 22 August 22 Aug Omit year only where there is no risk of ambiguity: In 2013, Ramadan began 10 July and ended 7 August January 1 is New Year's Day August 22 22 Aug No equivalent for general use 2001-08-22 Use only with Gregorian dates between 1583 and 9999

—sroc 💬 22:36, 23 January 2014 (UTC) [revised 03:08, 24 January 2014 (UTC)]

---

I considered something like your 2B as well. Basically our choice is the clean symmetry of 2A/2C (within which is the slight awkwardness of the [*] note) vs. the more fragmented structure of 2B (which however breaks out the cases needing the note into a row of their own, so no [*] is needed). I don't see a solution that avoids at least either one or the other disadvantage. Personally I like the way 2A makes the symmetries of the format choices, and their applicability, so immediately clear.

As to the "brevity" text -- I agree the full specification is wordy, but I really prefer to banish to footnotes only stuff that the reader doesn't need unless he himself decides he wants to know more -- the baloney about ISO 8601 being a great example. So I'd rather keep that text in the heading -- another opportunity for me to trop out my favorite {{small}}! Oh goody -- see 2C. EEng (talk) 04:50, 24 January 2014 (UTC)

Acceptable date formats (NEW, Alt2C)

General use	Only where brevity required (references, tables, lists, etc.)	Notes
August 22, 2001 22 August 2001	Aug 22, 2001 22 Aug 2001	In these two formats, a comma follows the year (unless followed by other punctuation): The weather on September 11, 2001, was clear and warm Everyone remembers July 21, 1969‍—‌when man landed on the Moon
22 August August 22	Aug 22 22 Aug	Omit year only where there is no risk of ambiguity: In 2013, Ramadan began 10 July and ended 7 August January 1 is New Year's Day
No equivalent for general use	2001-08-22	Use only with Gregorian dates between 1583 and 9999

---

I prefer 2B over 2C.

• I don't like the asterisks: they are unnecessary; they are not used elsewhere, so this use is unexpected and perhaps counter-intuitive; they may cause confusion with footnotes; it may not be obvious to all readers that the asterisk/note only applies to the top example in each cell in that row.
• I don't see why having each example on a separate row is a "disadvantage"; it's fine; you have no compunction about merging cells across multiple rows in other cases.
• In general, I don't like the use of small text: as I wrote above, it makes it harder to read; it should be avoided. That said, I acknowledge your point about not wanting to relegate the list of places where brevity is require to a footnote, so perhaps the small text is a necessary evil in this instance.

If we can't reach agreement on this, it would be good to get feedback from others. —sroc 💬 14:47, 24 January 2014 (UTC)

Based on others' comments I've decided that, while the kind of rowspan trickery I displayed earlier has its place if really needed, it's best to avoid it to the extent possible. I don't feel very strongly about 2B vs 2C.

Naturally we're looking for feedback from others -- that's the title of this section, remember? I think they're just waiting for us to take a break so they can get a word in edgewise. EEng (talk) 08:50, 25 January 2014 (UTC)

Waits for comments. Considers RfC to draw attention. —sroc 💬 11:19, 25 January 2014 (UTC)

Please, no RfC. It's great that both you and I care enough to want to make the best presentation possible of this very visible information, but we're just talking about presentation of the rules, not the rules themselves. Let's just see what others say and I'm sure we'll figure something out together. EEng (talk) 15:46, 25 January 2014 (UTC)

I'm not pushing for an RfC, merely pointing out that its purpose is to attract comments from others, which is what we're hoping for. Waits patiently. —sroc 💬 01:34, 26 January 2014 (UTC)

So I've consolidated the aspects of Alt 2B and 2C that I think we can more or less agree on, if not completely in agreement overall.

Acceptable date formats (NEW, Alt2D)

Acceptable date formats (NEW, Alt2D)

General use Only where brevity required (references, tables, lists, etc.) Notes 22 August 2001 22 Aug 2001 August 22, 2001 Aug 22, 2001 A comma follows the year (unless followed by other punctuation): The weather on September 11, 2001, was clear and warm Everyone remembers July 21, 1969‍—‌when man landed on the Moon 22 August 22 Aug Omit year only where there is no risk of ambiguity: In 2013, Ramadan began 10 July and ended 7 August January 1 is New Year's Day August 22 22 Aug No equivalent for general use 2001-08-22 Use only with Gregorian dates between 1583 and 9999

—sroc 💬 17:11, 26 January 2014 (UTC)

A request

Thank you to everyone who has been working to improve the MOS documentation! I do have a request about the last example in MOS:BADDATEFORMAT, which shows born in 1995. While I agree this is perfectly fine within a full sentence, the standard format for the lead of our biographical articles would be Joe Schmo (born 1995) is a ....., and I would hate for people to accidentally misinterpret the example and start using Joe Schmo (born in 1995) is a ..... instead. Is there another example we could choose to illustrate that we should use "in the year" only where needed for clarity? Maybe sold in the year 1995 and sold in 1995 (or some other short word instead of "born")? Thanks! GoingBatty (talk) 21:51, 21 January 2014 (UTC)

You wish is my command. Done. EEng (talk) 08:33, 22 January 2014 (UTC) (I tried to work Joe Schmo in but it made the example too wide for the column.)

@EEng: Thanks for making this update! If you grant non-Wikipedia wishes too, I might have a few more requests... :-) GoingBatty (talk) 23:40, 22 January 2014 (UTC)

Table caption required

Tables describing acceptable or unacceptable date formats shall have a caption so they may be referred to from other guidelines. Alternatively, each table shall be in a subsection to itself. Jc3s5h (talk) 16:08, 23 January 2014 (UTC)

Editors leaving imperative posts shall contextualize their remarks so others will have at least some idea what they're talking about. EEng (talk) 21:29, 23 January 2014 (UTC)

The most popular form of citation templates are described at Help:Citation Style 1. The Help:Citation Style 1#Dates section adopts the acceptable dates format table as the acceptable dates for this family of citation templates. If the caption is removed from the table, there is no date format guidance for citation templates. Jc3s5h (talk) 21:35, 23 January 2014 (UTC)

I don't get it. Why does Help:Citation Style 1 specify "Acceptable date formats are shown in the "Acceptable date formats" table of the Manual of Style/Dates and numbers, Dates and years section" -- why not just refer to MOS:DATEFORMAT? And if Help:Citation really does mean to reference only the table, and not (for example) the surrounding text, that's insane. Meanwhile, over here [15] you complained that the table does not limit dates in citations, so I really don't understand what you want at all. EEng (talk) 02:43, 24 January 2014 (UTC)

In general, citation styles really are allowed to use any consistent style, just like it says in the "Consistency" section: "For publication dates, nearly any consistent style may be used...." However, Citation Style 1 is a distinct citation style, just like Chicago Manual of Style or APA style. The editors of Citation Style 1 have decided they don't want to use any consistent date style; they only want to use the styles listed in the acceptable date formats table. It would be improper to refer to the MOS:DATEFORMAT shortcut because that includes the unwanted statement "For publication dates, nearly any consistent style may be used...." Jc3s5h (talk) 03:06, 24 January 2014 (UTC)

Look, if we can't rewrite individual sections of MOS to present the same requirements more clearly, at the same time preserving all shortcuts and anchors, then we'll just have to leave it the current jumble of accreted bullet points and inconsistent formats. But seriously, folks, it's insane to write "the acceptable dates are those shown in Table Foo of MOS:WHATEVER, excluding the rest of that section, except including the third bullet point of the second paragraph..." and expect that to be preserved. Might be best if Help:Cite 1 said something like,

Of the date formats more completely described at MOS:DATEFORMAT, the following are the forms used in Cite 1:

September 11, 2001

11 September 2001

[etc etc]

EEng (talk) 05:10, 24 January 2014 (UTC)

Hold on a sec. If it has been decided that citations should only use the formats in the acceptable date formats table, then why is the text "For publication dates, nearly any consistent style may be used" there at all? It seems like this either needs to be removed or re-written to ensure consistency between the guidelines. —sroc 💬 11:30, 25 January 2014 (UTC)

"It has been decided that citations should only use the formats in the acceptable date formats table" is a false statement. It has only been decided that Citation Style 1 (that is, the templates {{cite journal}}, {{cite book}} and their ilk) will limit dates to those in the acceptable date format table. Editors are free, as always, to use a different citation style in an article. Jc3s5h (talk) 13:30, 25 January 2014 (UTC)

It was a conditional statement preceded by "if". I was merely extrapolating from your preceding comment, trying to understand why MOS says "nearly any consistent style may be used". Should this instead say something like:

Publication dates in references should also all use use the same format. Any format from the Acceptable date formats table above may be used, unless the citation style being used requires a different format (however, all-numeric date formats other than YYYY-MM-DD must still be avoided). For example, in a single article write...

Is that accurate? If so, it seems to be much clearer than the present text. —sroc 💬 00:54, 26 January 2014 (UTC)

I think the wording in the present guideline is meant to have the same meaning as sroc's wording at 00:54, 26 January 2014 (UTC). I also think sroc's version is clearer. My guess is the wording is as it is for brevity, since sroc's version is longer. Jc3s5h (talk) 01:12, 26 January 2014 (UTC)

If it causes this much confusion/discontent, clarity over brevity, I say. My revision is also consistent with the formatting of the other items in that section, by the way:

• Dates in article body text should all use the same format...
• Publication dates in references should also all use use the same format...
• Access and archive dates in references should all use the same format...

—sroc 💬 01:39, 26 January 2014 (UTC)

As I see it, the problems with the current wording "nearly any consistent style may be used" are that: (1) "nearly" is vague; (2) it implies a free choice of any date format with complete disregard of the acceptable date formats table; (3) it is not confined to specific exceptions (i.e., to suit specific citation styles). —sroc 💬 01:43, 26 January 2014 (UTC)

I think the "nearly" is meant to go with "but avoid all-numeric date formats other than yyyy-mm-dd" later in the sentence. As for suiting specific citation styles, at some point in the past I suggested (probably at the WT:CITE talk page) that citation styles be limited to styles that had been published by some reliable publisher, as opposed to allow anything the early editors of the article invented. Unfortunately this idea did not gain consensus. So if some editors wanted to format publication dates like "2014, January 25" (like APA does) but otherwise wanted to follow the Chicago Manual, they could. Jc3s5h (talk) 02:23, 26 January 2014 (UTC)

I'm guessing the weird "nearly any" wording was just imported from WP:Citing_sources#Citation_style. Why that wording is there is a different story -- one gets the impression that some stubborn editors threatened to hold their breath until they turned blue unless they were allowed to use dates like "2014, January 15" in cites, and others decided to give and let them have their way, as long as the cancer was restricted to citations and not MOS in general. Thus MOS said one thing and Help:cite says another. At some point someone carried the weird language on cite dates into MOS so that during citation fights people couldn't point to MOS as overriding Helo:Cite.

In short, more complicated rules to accommodate the eccentric quirks of a very few editors. EEng (talk) 02:46, 26 January 2014 (UTC)

If "nearly" only refers to "but avoid all-numeric date formats other than yyyy-mm-dd" then the "nearly" is redundant and only leaves doubt about what other exceptions there might be. "Oh, no, not that one either. Did we not say?" If my alternate wording has the same effect but is clearer, can we try updating it and see if anyone objects/reverts? Or do we need an RfC over this? —sroc 💬 14:04, 26 January 2014 (UTC)

Considering that "citation style" in sroc's wording links to the part of WP:CITE that says any consistent style may be used, I favor sroc's change. Jc3s5h (talk) 14:52, 26 January 2014 (UTC)

I even created a shortcut for it: WP:CITESTYLE. Feel free to link to that instead. —sroc 💬 16:26, 26 January 2014 (UTC)

 Done I've made the change. —sroc 💬 16:34, 26 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:[16]

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)

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

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

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

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

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

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

Discussion of ISO 8601 and YYYY-MM-DD

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

RFCs consume a great deal of community time and energy, especially with multiple related RFCs going on already. It would have shown respect for other editors involved in the current discussion on this very topic to have discussed with them whether to start an RfC, and if so, how to word it. Earlier today I explained ([[#noISOrfc|see prior section) why I think an RFC isn't required, and instead of answering that, you pull everyone further into this vortex of pointlessness by doing this.

You say, "I cannot find any reliable source that describes the YYYY-MM-DD format without also mentioning that it is part of ISO 8601 and that the dates must be Gregorian." It doesn't matter whether there are sources "describing" the format that don't mention Gregorian etc. I've got something better -- a bunch of sources using the YYYY-MM-DD format: [17] [18] [19] [20] [21] [22] [23] [24]. These are from the 1970s, proving that people were using YYYY-MM-DD, with no thought of 8601 or it restrictions, long before 8601 even existed. EEng (talk) 05:22, 26 January 2014 (UTC)

Thank you for this list of sources; I have made a copy of the list for future reference. I felt sure the use of the YYYY-MM-DD format would have arisen spontaneously due to its obvious advantages in computer sorting, but I had not come across any pre-1988 sources that used it. I would point out that the source numbered 20 does not use the format. Jc3s5h (talk) 14:02, 26 January 2014 (UTC)

I found those by searching Googlebooks for one or two specific dates, in quotes, such as "1974-08-23". Obviously there are tens of thousands more for different specific dates, if not more. The fact that you seem to feel this is an accomplishment worth saving for future reference brings into serious doubt the breadth of your experience in real-world usage. EEng (talk) 15:18, 26 January 2014 (UTC)

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

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

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

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

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

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

You have it exactly right. 1776-07-04 means July 4, 1776. Now, that may still leave the question of whether that's meant to be interpreted as Julian vs. Gregorian, and maybe Wikipedia has good rules or bad rules for how articles are to clarify that, but the situation is exactly the same regardless of whether the date was expressed as 1776-07-04 or as July 4, 1776. That's it. End of story. Everything Jc and

Some of the other discussions I have pointed to advocate the YYYY-MM-DD date for all dates in citations. In the article George III of the United Kingdom we see citations (footnote no. 124) to the London Gazette for seven specific dates beginning 1748 and ending 1750; these dates are in the Julian calendar. If the YYYY-MM-DD format were allowed for these dates, they might have been expressed in that format.

As for your example of 1309-12-24, if you see it in Wikipedia, it's an error (for now). If it's someplace else, and you didn't agree with the person who wrote the date to allow dates that early, then it isn't in conformance with ISO 8601. So you would have to determine from context and whatever you know about the author whether it's intended to be a Gregorian or a Julian date. (If it's Gregorian, the corresponding Julian date is 16 December 1309, or if it's Julian, the corresponding Gregorian date is 1 January 1310.) Maybe the author thinks you consented to use ISO 8601 for such an early date, but you didn't. Maybe the author is using RFC 3339, a simplified ISO 8609, which retains the Gregorian calendar restriction but allows years "between 0000AD and 9999AD" [sic]. Jc3s5h (talk) 16:31, 26 January 2014 (UTC)

An example of a potentially confusing use of a Julian date in the YYYY-MM-DD format is footnote 6 in Capacitor, which refers to a letter of Benjamin Franklin dated "1749-04-29". As long as the website linked to is still around, one can work out that this is actually a Julian date. But if the website stopped working and one had to look for the letter elsewhere, and imagined the editor had followed the rules, one would be looking for the wrong date. Of course, one would eventually figure it out, but it would make it a little harder. Jc3s5h (talk) 18:27, 26 January 2014 (UTC)

You haven't answered Jonesey's question: How does the fact that the date is given as 1749-04-29, instead of as April 29, 1749, affect anything? The answer is that it doesn't. As always, the reader has to look elsewhere to know whether this is a J date or a G date, and that's true no matter what format it's given in. You may as well argue that if the date is printed in Arial font that somehow means something different than if it's printed in Courier. It's absurd. EEng (talk) 02:41, 27 January 2014 (UTC)

Perhaps in terms of explanation, it might makes sense to point out Conversion between Julian and Gregorian calendars. The format of the calendars is the same, except that the Julian calendar includes leap years on all multiples of 4, whereas the Gregorian calendar skips them in century years not divisible by 400. The calendars are the same between 200 AD and 300 AD, and move out of sync by 3 days every 400 years.

The ISO standard requires the use of dates using the Gregorian Calendar, and does not allow dates before October 1582 (when the first countries made the switch). The reason is that, for the purposes that ISO standards are generally used for, absolute precision is necessary. If you don't know what calendar you're using, you could be several days out. If you use dates before 1582, you're using dates that were never rendered as such at the time.

Wikipedia has never adopted the ISO standard, and has somewhat different needs: we need to render dates prior to 1582 and there's also the problem that not all countries switched in 1582. The British Empire (including the 13 Colonies) did not switch calendars until 1752, for example, and Greece didn't switch until 1923. Insisting on Gregorian dates may be at odds with the historical practice in many countries, and culturally significant dates (e.g. Fifth of November) were not necessarily converted - possibly causing strange results.

The concern is that someone who knows the ISO standard will interpret 1515-06-20 as being 20 June 1515 Gregorian (10 June 1515 Julian), whereas the author intended it to mean 20 June 1515 Julian (30 June 1515 Gregorian). Kahastok talk 17:14, 26 January 2014 (UTC)

Like all standards, 8601 says it only applies if the everyone involved agrees it implies. Anyone who knows the standard will know that, and know therefore that it doesn't apply. This is an absurd concern. EEng (talk) 02:41, 27 January 2014 (UTC)

Remove these silly restriction

There seem to be two reasons given for these restrictions:

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

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

I'll repeat what I said above:

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

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

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

-- then we'll write back thus:

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

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

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

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

Damn! This discussion seems to fragment at a moments notice, making it hard to keep a contiguous train of thought. My reply seemed to be better placed in the #ISO 8601 section above as a reply to other comments. It is dated 09:17, 26 January 2014 (UTC).  Stepho  talk  09:27, 26 January 2014 (UTC)

Is that 26 January Gregorian, or Julian? EEng (talk) 09:57, 26 January 2014 (UTC)

The proposal is inadequate. If carried out as stated, the cell in the "Acceptable date formats" table would change:

Full year, hyphen, two-digit month, hyphen, two-digit day; use only with Gregorian dates between 1583 and 9999^[3].

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

Taken in conjunction with the instruction 'Do not "zero-pad" month and day, except in all-numeric (yyyy-mm-dd) format', this means the proper format for 19 August 14 AD would be 19-08-14. Also, there would be no prescription against expressing the first day of the Julian calendar as 45-01-01 BC. Jc3s5h (talk) 14:33, 26 January 2014 (UTC)

To Jc3s5h. Yes, amending MOS would require changing the text/tables in MOS. Remove all mention of ISO 8601 in MOS and put in my proposed rule that says how to interpret a date to be in which of the 3 eras (Julian, illegal, Gregorian). Your zero pad argument is an argument about whether yyyy-mm-dd is to be used at all and is not relevnent my proposal of how to disamgiuate date formats between the Julian and Gregorian calendars (which is a problem for all date formats). If you raise that argument in a different section then I will be happy to give answers to your argument.  Stepho  talk  00:43, 27 January 2014 (UTC)

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

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

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

I don't think we're in a position to be telling readers how to interpret dates, because very few readers will ever come to this page. If we feel the need to explain what our dates mean, it probably means that the format is unsuitable.

My own view is that we should deprecate all formats of all-numeric dates, regardless of circumstance, because of the potential for them to be misunderstood and because they are relatively difficult to parse. I note in particular usages in tables such as on Enlargement of the European Union, where the presentation of key dates is practically impenetrable. I see no significant reader benefit in using all-numeric dates over short-form text dates (e.g. "16 Jun 1995"). Kahastok talk 20:16, 26 January 2014 (UTC)

I agree with Kahastok that avoiding all-numeric dates would be best in the context of an encyclopedia, but in view of this failed proposal, I don't think that's going to happen. Jc3s5h (talk) 20:49, 26 January 2014 (UTC)

To Jc3s5h. I looked at Enlargement of the European Union and did not find any impenetrable presentation of dates (with one exception which I will return to). I saw a number of tables using yyyy-mm-dd. Given that the user knows they are dates (the table heading could be a little clearer to say 'Date issued'), the user must sure be able to work out that the 4 digit numbers are years. After that, the user can easily see that the last field has numbers that can be months (eg contains 31). Which leaves the middle field as months (which only contains the numbers 01-12). To me this is similar to spelling 'centre' and 'center'. It may not be in the form that some readers like but it is not impenetrable. And like many things, it also becomes easier the more you use it.

Since we're here, I will also answer your earlier comment about 19-08-14. If it was in isolation then yes, it would cause trouble with somebody not familiar with MOS. However, it is not likely to appear in isolation. Its use is not allowed in prose. It is most likely to appear in references or tables. In both cases there will be many other dates to compare it to and the reader is then able to compare them in the manner I showed in the previous paragraph. In the very rare case where all references or the entire table have 2 digit years then it would be wiser for the editor to use some judgement and not use yy-mm-dd for that article. This rare case is not a reason to outlaw it for all articles.  Stepho  talk  00:43, 27 January 2014 (UTC)

Stepho-wrs, the problem with the number of digits in the year has been resolved by EEng's rewrite of his proposal (although whether to allow negative years, the year 0, or the BC prefix could use further clarification). Of course, in my example of "19-08-14", this means the fourteenth day of August in the year of our Lord nineteen, since both the old and new proposal require a full year. Jc3s5h (talk) 13:43, 27 January 2014 (UTC)

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

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

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

The digital copy of the standard that I downloaded before it became hard to find has an introduction, which indicates some of the goals were preventing ambiguity and confusion in multi-national environments. There is no mention of it being easy to sort dates on a computer with off-the-shelf features of the operating system or software, but informal descriptions of the standard often emphasize this point. I don't think you could use off-the-shelf sorting features and sort Julian and Gregorian calendar dates into their proper chronological order. Jc3s5h (talk) 20:25, 26 January 2014 (UTC)

There's no mentioning of grass being green, either. — Dsimic (talk | contribs) 20:32, 26 January 2014 (UTC)

Well said. Anyone who can say with a straight face that no part of the motivation for adopting YYYY-MM-DD dates is that they are easy to sort, obviously has no idea what he's talking about. EEng (talk) 03:36, 27 January 2014 (UTC)

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

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

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

In its place put the following:

(Where used: Only in references, tables, lists or areas where conciseness is needed -- see Wikipedia:Citing Sources § Citation style) Use YYYY-MM-DD (all-numeric) format only for A.D. dates; zero-pad year to four digits, and month and year each to two digits. Editors should not use this format to imply conformance with ISO 8601, nor to imply that the date represented is to be interpreted in any particular calendar system (e.g. Julian calendar or Gregorian calendar). Nor should readers assume such conformance or infer any such interpretation.

(Where used: Only in references, tables, lists or areas where conciseness is needed -- see Wikipedia:Citing Sources § Citation style) Use YYYY-MM-DD (all-numeric) format only for A.D. dates (though A.D. or AD should not be specified – 1776-07-04 not 1776-07-4 AD). Zero-pad year to four digits, and month and day each to two digits. Editors should not use this format to imply conformance with ISO 8601, nor to imply that the date represented is to be interpreted in any particular calendar system (e.g. Julian calendar or Gregorian calendar). Nor should readers assume such conformance or infer any such interpretation.

[Minor fixes per comments] -- EEng (talk) 16:46, 27 January 2014 (UTC)

(Where used: Only in references, tables, lists or areas where conciseness is needed -- see Wikipedia:Citing Sources § Citation style) Use YYYY-MM-DD (all-numeric) format only for years 1 AD and later (though A.D. or AD should not be specified – 1776-07-04 not 1776-07-4 AD). Zero-pad year to four digits, and month and day each to two digits. Editors should not use this format to imply conformance with ISO 8601, nor to imply that the date represented is to be interpreted in any particular calendar system (e.g. Julian calendar or Gregorian calendar). Nor should readers assume such conformance or infer any such interpretation.

[More minor changes] -- EEng (talk) 21:43, 27 January 2014 (UTC)

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

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

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

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

• Support, obviously. EEng (talk) 04:25, 27 January 2014 (UTC)
• Weak oppose. This proposal essentially admits defeat about enforcing the Gregorian for pre-19th century dates, which is perhaps the more realistic position. But Wikipedia should not be the only publication to say Julian dates are OK in this format, and I give greater weight to that concern. If it is adopted, it should be modified to more clearly state whether negative years and the year 0 are allowed. Also I presume the era notations AD, CE, BC, and BCE are disallowed, but this should be explicit. Jc3s5h (talk) 13:33, 27 January 2014 (UTC)

What do you mean by "admits defeat about enforcing the Gregorian for pre-19th century dates"? This has nothing to do at all with whether an article gives a G date or J date -- the rules for that are at WP:JG, and this proposal doesn't change any of that. All that's being proposed is to allow all dates to be presented in YYYY-MM-DD format, whereas now certain dates (i.e. J dates) are forced to be presented in "July 4, 1776 / 4 July 1776"-type format only.

I see no need to say years must be nonzero and nonnegative -- that's implied by "AD-only" provision. EEng (talk) 16:46, 27 January 2014 (UTC)

By "admits defeat about enforcing the Gregorian for pre-19th century dates" I meant that many editors have never read this page, and although they might have heard of ISO 8601, they've never read it, so they use the YYYY-MM-DD format for Julian dates even though, at present, they shouldn't. It is a difficult rule to enforce.

As for the need to indicate that years less than 1 are not allowed in this format, "AD" does not necessarily imply that. When AD is written immediately before or after a year number, it certainly means the year is a positive year, but when it is not next to a year number, it might be thought to refer to the general concept of numbering years from the Incarnation of Jesus (as estimated by Dionysius Exiguus). Most people would that goes without saying, but someone might regard it as an unnecessary flourish rather than a prohibition of 0, BC, or negative years. The new wording gives a stronger implication for the minimum year being 1, but a specific statement that the first possible date is 0001-01-01 would be shorter and more certain. Jc3s5h (talk) 19:27, 27 January 2014 (UTC)

You just don't get it. The proposal isn't an "admission of defeat" in enforcement of this "difficult rule to enforce" (i.e. the restriction of YYYY-MM-DD dates to Gregorian only). It's a recognition that the restriction solves an imaginary problem, is illogical and undesirable, and never should have been instituted in the first place.

I've modified the proposal yet again to address your concerns re AD, Dionysius Exiguus, etc. -- how erudite you are!

EEng (talk) 21:43, 27 January 2014 (UTC)

• Comment: Shouldn't the clause zero-pad year to four digits, and month and year each to two digits read: zero-pad year to four digits, and month and day each to two digits? —Trappist the monk (talk) 13:56, 27 January 2014 (UTC)

Fixed, thanks. EEng (talk) 16:46, 27 January 2014 (UTC)

• Oppose - this looks like a solution in search of a problem, being engineered (or attempted) by literally a handful of people, more or less behind the backs of millions of others who don't even know what you are discussing here on their behalf.

Til Eulenspiegel /talk/ 13:59, 27 January 2014 (UTC)

• This is an RFC (though I think it was unnecessary, and I didn't initiate it) so nothing's happening behind anyone's back.
• You have it backwards. The existing text's restrictions were a "solution" to a nonexistent "problem"; the proposal removes those restrictions, and for the avoidance of doubt explicitly repudiates them.

Does that make sense? EEng (talk) 16:46, 27 January 2014 (UTC)

ISO 8601 is garbage

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

Since we're in a joking mood, try this one: http://xkcd.com/1179/ . As an added bonus, hover the pointer over the image for an additional joke.  Stepho  talk  00:22, 24 January 2014 (UTC)

How can it simultaneously be garbage and cost CHF134,00? Or is that CHF 134.00? Anyway, it seems like more of a buffalo jump than a trapping pit to me, but that's probably just my cultural hegemony talking. – Jonesey95 (talk) 04:50, 24 January 2014 (UTC)

Buffalo jumps are much bigger than trapping pits, thus they're better. :) — Dsimic (talk) 05:15, 24 January 2014 (UTC)

Is it a joke? Tony (talk) 06:29, 24 January 2014 (UTC)

• Doesn't look too serious to me. -- Ohc ^¡digame! 07:29, 24 January 2014 (UTC)

• Lots of people have heard of ISO 8601, and the ISO's web page encourage everyone to use it, but one has to shell out a relatively large amount of money to see the details. But the anonymous authors of the ISO's web page seem to have an unstated mindset that it would only be used for current events such as airline tickets or grocery receipts. It is left as a surprise for those who shell out CHF 134.00 for the official standard that one must only use it for Gregorian calendar dates, so be very careful if one is writing about Russia or Greece in the early 20th century. Also, one must obtain explicit permission among the data exchange partners (in Wikipedia's case, readers) if one intends to use the standard before the first full year the Gregorian calendar was in force anywhere (1583). So there is a large risk of false information if the standard is used for historical dates, which is something that tends to come up if one is writing an encyclopedia. This is exacerbated when dates written in other formats are silently emitted in the ISO format, as is the case with some templates such as {{start date}}. Jc3s5h (talk) 10:42, 24 January 2014 (UTC)

FWIW I have a set of paper round-the-world ticket from few years ago - in this case, nineteen sectors involving five airlines based on four continents - and they use all-numeric DDMMYY. Kahastok talk 10:16, 26 January 2014 (UTC)

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)

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)

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)

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)

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)

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)