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

Archive 140

←

Archive 142

Archive 143

Archive 144

Archive 145

Archive 146

→

Archive 150

Date range redux

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

I am astonished that such effort has gone into resolving a dispute about two characters. Rikster2's proposal meets with overwhelming (though not unanimous) consensus. The only oppose rationale that is convincing (ie does not rely on "so what?" or "we've discussed this already") is Tony1's, but it is not discussed any further than his comment. HJ Mitchell | Penny for your thoughts? 20:17, 3 February 2014 (UTC)

---

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)

Useless argument. MOS is the world's most consistently inconsistent set of mandates and pronouncements on style. WP:IAR and do it whatever way looks best. 6 digits, 8 digits. who cares. As long as it's accurate and gets the point across.--ColonelHenry (talk) 01:02, 30 January 2014 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

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 [4] 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 [5], 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 [6].

(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. [7]] 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 [[8]]. 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 [9], 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)

Why suggest {{nbsp}} instead of &? Jimp 09:59, 3 February 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)

2E (faint but growing sound of consensus approaching from the distance)

2D is the best of the lot (including the old version). Jimp 10:13, 3 February 2014 (UTC)

Agreed. However, please make two changes:

• change "A comma follows the year (unless followed by other punctuation):" to "A comma follows the year unless it is followed by other punctuation:" - unnecessary parentheses resulting in bizarre (though technically correct) placement of the ref marker
• change "In 2013, Ramadan began 10 July and ended 7 August" to "In 2013, Ramadan began on 10 July and ended on 7 August" - missing words

Justlettersandnumbers (talk) 14:22, 3 February 2014 (UTC)

Sounds good to me! Although I think that the preposition "on" is not used in some varieties of English (e.g., "it happened [on] Wednesday", "send it [to] me").

Acceptable date formats (NEW, Alt2E)

Acceptable date formats (NEW, Alt2E)

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 on 10 July and ended on 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:06, 3 February 2014 (UTC) [revised 00:14, 4 February 2014 (UTC)]

Thank you. This has my vote; it's succinct, clean and clear. I'd like to see some mention of the many other calendar systems in use round the world and in this wiki (see below), but that doesn't necessarily have to be in this table. (Note: I'm aware that those prepositions are sometimes omitted; I believe, subject to correction, that that is usually in colloquial speech, not scholarly text). My compliments to those who have put such an extraordinary amount of effort into this. Justlettersandnumbers (talk) 23:08, 3 February 2014 (UTC)

---

• EEng (talk) says: I'm fine with 2E as well. To recap we now have (I believe -- apologies if I've put words in someone's mouth) the following editors on board:
• sroc
• Jimp
• Justlettersandnumbers

And that's everyone who's commented in the whole "revamped table" discussion (re the table format, not the Great Gregorian Restriction Footnote Discussion, which is elsewhere), except for editors Stepho-wrs and Jc3s5h. Perhaps the ping will draw them into our cozy circle. EEng (talk) 00:08, 4 February 2014 (UTC)

I just revised the YYYY-MM-DD footnote for conciseness. —sroc 💬 00:14, 4 February 2014 (UTC)

I was waiting for the discussion at WT:MOSNUM#RFC: Month abbreviations to determine what month abbreviations should look like. At present, of those with a preference, six editors want to use only three letters while one wants to allow four. Eight editors don't want month abbreviations to be followed by a period (full stop), one does. There is unanimous agreement that MOS and MOSNUM should agree. So it looks like three letters without a full stop will prevail. So I'm on board with this 2E version (but, as always, revisions may result from the outcome of other discussions). Jc3s5h (talk) 01:09, 4 February 2014 (UTC)

Fine, but we needn't wait for that RfC to conclude to implement this. It seems we've agreed on a good version here and I don't hear any howls of dissent, so why don't we just implement this now? —sroc 💬 03:57, 4 February 2014 (UTC)

 Done —sroc 💬 04:10, 4 February 2014 (UTC)

Other calendars

Other calendars should be mentioned. Are there other ways to write 3 Rabī’ al-Thānī 1435 AH? Justlettersandnumbers (talk) 14:22, 3 February 2014 (UTC)

I assume you don't mean in the table we've been working on just above here. I think it's obvious that it would be a distraction for the vast majority of editors to have a single integrated table including other calendar systems. Let me also suggest that my advice here be applied in the case as well. The best time to develop formatting rules for dates in other calendar systems is when an actual issue has arisen and editors are motivated to get involved and talk things through. EEng (talk) 00:15, 4 February 2014 (UTC)

Agreed: we don't need formatting rules for calendar systems that are not in common use in Wikipedia, as this would potentially be instruction creep.

See also Wikipedia:Manual of Style/Dates and numbers#Julian and Gregorian calendars:

Dates can be given in any appropriate calendar, as long as the date in either the Julian or Gregorian calendars is provided, as described below. For example, an article on the early history of Islam may give dates in both Islamic and Julian calendars. Where a calendar other than the Julian or Gregorian is used, this must be clear to readers.

What more do we need? Should the heading perhaps be amended to a more general term, such as "Calendar systems"? —sroc 💬 00:19, 4 February 2014 (UTC) [revised 00:21, 4 February 2014 (UTC)]

Well, not so much what we need, but what I personally would like: some guidance. It's my impression that Hijri dates are always written in dmy format, and a random check of one (yes, one, will cite it on request) US academic journal confirmed that impression - the Hijri date was in dmy format, the conversion in mdy; I believe "Muharram 10", as seen at Battle of Karbala, to be simply an error. Similarly with French Republican dates: I don't think we'll ever find "Brumaire 18, VIII". But I'm not familiar with usage in the Jewish calendar, for example, and even less so with Asian calendars. I'm as much against instructions as anyone; but some clear guidelines would be much appreciated. Justlettersandnumbers (talk) 19:25, 4 February 2014 (UTC)

Do we need guidance if they are so rare? We don't need guidance on how to punctuate text in French, even though we occasionally include French passages and translations. We don't need guidance on everything. Surely we can simply follow the format used by reliable sources used for the dates we cite in such calendar systems. —sroc 💬 03:21, 5 February 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 [10] 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)

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.wiki.x.io (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.wiki.x.io&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)

Common use in English trumps ISO international standards. Okay, you say you speak English in the UK, I believe you. You say the format is not uncommon and is becoming more common in the UK, I wouldn't know, I'm not from there, I don't speak British English (or North American English, by the way). My impression is that it's an uncommon format amongst typical English speakers but who knows what's typical? As for these ymds in refs' being relics, I'd say that the fact that the citation templates demanded them would have undeniably something to do with it. Jimp 10:28, 6 February 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)

Tax returns and passport applications have labels on the boxes telling the filler out what numbers to put in what boxes; it's a bit different. Making sorting by date trivially easy is not important here; sortable tables can mostly handle dates and where they have trouble there are templates such as {{sort}} and {{dts}} to fix any problem, good writing puts ease of the reader above ease of the writer. Jimp 10:28, 6 February 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)

Part 3

As is so common in WP, the discussion petered out with no result. As it stands, there is a conflict that was introduced by banning yyyy-mm, so I have hidden that clause in the guideline. This isn't meant to be the final solution - just something to prod us back into action to remove the conflict. I listed all alternatives I could think of above but none found much acceptance. There are only three that are worth pursuing:

1. Ban yyyy-mm-dd altogether. Some editors were very much in favour of this and some were very much against it. Unlikely to gain consensus.
2. Ban yyyy-mm but allow yyyy-mm-dd. Needs an explanation that all yyyy-mm-dd references are allowed but will need to be changed to spelt out dates (eg 7 January 2012 or January 7, 2012) as soon as the first year+month combo is added.
3. Allow yyyy-mm and hope that readers are smart enough to see the pattern.  Stepho  talk  23:26, 1 February 2014 (UTC)

This thread cannot generate consensus because it is not a well-advertised RFC. I will revert the edit to the guideline of Stepho-wrs because this discussion is not noteworthy, having not been properly advertised. Jc3s5h (talk) 23:36, 1 February 2014 (UTC)

Just my two pennorth

I have only scanned the debates above, but I am just adding my two pennorth and I don't check the page here very often well not at all, I only arrived via a rather circuitious root.

• MOS is just too big and therefore self-contradictory because it is not centrally overseen by an Editor-in-Chief.
• MOS continuously changes. Editors cannot create or edit articles and keep them consistent, unless they know the whole of the MOS at any particular instant by heart, which is impossible.
• There are well established templates and guidelines for how to write dates and numbers. Changing them affects hundreds of thousands if not millions of articles. It is acceptable to write in certain different ways but it is expected that they are consistent within an article.

• For example, the {{cite}} templates say (or at least did years ago) that dates should be in one format but access dates should be in another... leading to the absolute inconsistency in articles that this kind of things lead to. I have always ignored that because it seems ridiculous to write the date of an article as (say) "27 February 2047" but then its access date as 2047-02-27. I don't see how that helps readers; so I ignore that and write them (or change them) consistently within the article, trying to make an article or set of related articles consistent in style, taking as near as I can with my imperfect knowledge the style already in them (variety of English, variety of punctuation etc).

• If MOS were more stable, and smaller, then the encyclopaedia (or encyclopedia?) would be written in a more consistent style. But that ain't gonna happen.
• Use common sense. Try to write good plain English, whatever variety of it you speak or way of punctuation you were taught, and don't be too prescriptive.

Best wishes Si Trew (talk) 12:43, 8 February 2014 (UTC)

New tables on date formatting

Wikipedia:Manual_of_Style/Dates_and_numbers#Date_formats

1. I don't understand why references are described as space-constrained (requiring brevity). They're not in tabular form; they're not infoboxes; they occupy as much space as they like at the bottom of an article.

2. Why isn't the same date used throughout the tables, for the sake of clarity? Tony (talk) 04:39, 4 February 2014 (UTC)

I've taken the liberty of numbering your points above for ease of reference. I hope you don't mind.

1. Because for better or for worse, that's what the guideline has said for a long time [11]. In general the thrust of current efforts has been to improve the presentation of the guidelines, not the content of the guidelines. (Actually, the longstanding text has said conciseness though, for some reason, the current live version says brevity -- perhaps someone through brevity was more brief than conciseness was concise. But the version just now reaching consensus elsewhere on this Talk is back to conciseness.)

2. The acceptable-forms table does use a single date. As to the "unacceptables" table, it doesn't use a single date for the same reason writing examples don't all use The quick brown fox and See Spot run. Run, Spot, run! -- to avoid numbing the mind and repelling the reader. In fact, clarity is enhanced by variety, as in the "unaccpetables" table, where examples were specifically chosen to reinforce the relatedness or un-relatedness of items nearby one another; the July 3, 2001 set of examples is an illustration of this.

Now I have a question or two of my own. Knowing, as you surely must, that it's only with great difficulty that MOS discussions are kept coherent and organized, why did you start a new thread here without checking whether there's already a discussion underway on one or both of these topics? It would be respectful of your fellow editors' time to integrate your thoughts into ongoing discussion rather than just clicking New section and leaving it to others to bring you up to speed.

Specifically on the point of brevity / conciseness, it would be better had you taken the time to investigate the origin of that phrasing (e.g. in the revision history) before posting. It would only take a few clicks to find out for yourself what I have now found out for you -- that this phrasing is longstanding and that it would take at least moderate effort to trace it to its roots. It's a small thing but, again, it would show respect for other editors' time to do a bit of legwork instead of just wondering out loud.

EEng (talk) 07:49, 4 February 2014 (UTC)

Regarding EEng's comment on 1, actually, the wording has changed in meaning. The old version you linked to said:

Only in references, tables, lists or areas where conciseness is needed

The new version uses the wording:

Only where brevity required (references,^[3] tables, lists, etc.)

These are not the same. In the former, "conciseness" only refers to the other "areas"; in the latter, "brevity" applies to the whole list. To retain the original meaning, the heading should really be:

References, tables, lists or areas where brevity is needed

Whether reverting the wording so or not is a good idea is a different question. —sroc 💬 09:58, 4 February 2014 (UTC)

By the way, EEng, when you wrote, "perhaps someone [thought] brevity was more brief than conciseness was concise", I assume you referred to yourself since the change was in your Alt0 above. Perhaps "it would be better had you taken the time to investigate the origin of that phrasing". —sroc 💬 10:05, 4 February 2014 (UTC)

For a fairly long time one method of producing a list of endnotes, {{Reflist}}, made the font of the endnotes smaller than the font of the article by default. Periodically, suggestions have been made to make the endnotes hidden by default. I infer many people would like the endnotes to be smaller.

An advantage of using different dates in different subsections is to make it easy to search for the section using the browser search feature. Jc3s5h (talk) 17:47, 4 February 2014 (UTC)

Tony's right, conciseness and/or brevity is not an issue in references. If guideline has said otherwise for a long time, it's been wrong for a long time. Jimp 10:14, 11 February 2014 (UTC)

Uncertainties 2

Need some guidelines in developing the formatting templates.

With numbers like 456⁺⁷⁸⁹
₋₁₂₃×10⁻²², do we want parentheses? Do we want large parentheses so they extend across the super- & sub-scripts?

With degrees, do we want 114 ±3°, or 114° ±3°? — kwami (talk) 08:17, 7 February 2014 (UTC)

In the first case, no. In the second, either work. Headbomb {talk / contribs / physics / books} 17:11, 7 February 2014 (UTC)

Aren't parentheses normal in such cases? — kwami (talk) 19:51, 7 February 2014 (UTC)

The majority of publications and style guides omit them, so my educated guess is no. Headbomb {talk / contribs / physics / books} 21:09, 7 February 2014 (UTC)

The NIST (SI) standard is to use parentheses even with units: (3.05 ± 0.06) cm, which I don't see very much except in very data-heavy publications. Perhaps we'd want an option to add parentheses in the template, since we can't just prefix/suffix them. — kwami (talk) 22:42, 7 February 2014 (UTC)

BTW, there was a claim somewhere (forget where now) that it is wrong to space the digits both before and after the decimal point. However, the SI standard is to do just that:[12] (#16), where it says 15 739.012 53 with consistent spacing is correct, and *15,739.012 53 with mixed commas and spacing is wrong. — kwami (talk) 22:54, 7 February 2014 (UTC)

My guess is that the claim was the result of some kind of mix up. If you're using commas, they only go before the decimal. If you're using spaces, they go either side. You don't use both. Jimp 10:18, 11 February 2014 (UTC)

This was discussed in connection with the development of the {{val}} template. Wikipedia editors definitely rejected the SI style spacing, although you sometimes see it in some scientific articles. If I recall correctly, the US Government Printing Office style manual calls for grouping thousands with commas to the left of the decimal, a full-stop for the decimal, and spaces to the right of the decimal. Jc3s5h (talk) 13:06, 11 February 2014 (UTC)

That's fine then, though IMO it is a bit provincial for an international encyclopedia. — kwami (talk) 14:21, 11 February 2014 (UTC)

Hands, bels and bytes

On the subject of specific units, two remarks:

• h for hand should be deprecated (h is the internationally recognised symbol for hour)
• there should be something that recognises the ambiguity between B for bel and B for byte

My tuppence ha'penny Dondervogel 2 (talk) 15:53, 28 January 2014 (UTC)

SI has taken care to avoid having the same symbol for more than one unit or prefix. Traditional units, especially when you consider all the languages in the world, have not taken the same care (and there is no institution charged with such a task). Since Wikipedia has not adopted SI as its only system of measurement, I don't think you should expect all units and prefixes to be unique. Considering that the units in question are unlikely to be confused if the context is clear, I don't think this change is necessary. Jc3s5h (talk) 16:34, 29 January 2014 (UTC)

Oh! It took me a minute to figure out a context in which the height of a horse and a unit of time might be confused. They are both lengths, in a way, but then so are light-years and years (which people confuse or misuse even though they have different abbreviations!) Bel should be capitalized, as we do, because it's derived from a proper name. Here, too, a confusion seems unlikely. htom (talk) 18:07, 29 January 2014 (UTC)

There was more to my point than reducing ambiguity.

• In the case of h vs hh for hand there is a benefit in increased uniformity throughout horse articles if one is preferred, so if there is a good reason for deprecating one of them why not go with that? (If it were not for precisely this reasoning, what is the point of deprecating kt for knot or nm for nautical mile?).
• One point that makes B for bel or byte worth a special mention is that it is the only example (to my knowledge) for which the ISQ uses the same same symbol for two different units. I see no harm in pointing out that the decibyte is rarely (never?) used.

Dondervogel 2 (talk) 23:31, 2 February 2014 (UTC)

nm is SI for nanometre; nautical mile is NM or nmi. Mike Spathaky (talk) 10:52, 10 February 2014 (UTC)

Which is why nm for nautical mile is deprecated, and why h should be deprecated for hand. Dondervogel 2 (talk) 18:06, 12 February 2014 (UTC)

Mixing fonts within numbers

An editor at the {{val}} template insists on mixing fonts within numbers when we have uncertainties, saying that we should even make other templates do that, despite the fact that so far no commenters see any value in it. Does anyone here agree?

The dispute is, should we force monowidth digits in one part of a number, the uncertainty, as here:

1.012 ^+0.001
_−0.002×10⁻²²   (mixed fonts)

or should we allow user preferences, as here:

1.012 ^+0.001
_−0.002×10⁻²²   (single font)

(using default Candara font so we all see the same thing)

Real examples from the infoboxes of dwarf planet articles:

0.12+0.14
−0.06     620+34
−29 km     575+125
−50 km     650+260
−220 km

1200+300
−200 km     0.185+0.076
−0.052     844+207
−190 km     0.96+0.09
−0.04

0.050+0.030
−0.016     600+140
−130 km     727.0+61.9
−66.5     0.107+0.023
−0.016

vs.

{{val/sandbox2|0.12|+0.14|-0.06}}     {{val/sandbox2|620|+34|-29|u=km}}     {{val/sandbox2|575|+125|-50|u=km}}     {{val/sandbox2|650|+260|-220|u=km}}

{{val/sandbox2|1200|+300|-200|u=km}}     {{val/sandbox2|0.185|+0.076|-0.052}}     {{val/sandbox2|844|+207|-190|u=km}}     {{val/sandbox2|0.96|+0.09|-0.04}}

{{val/sandbox2|0.050|+0.030|-0.016}}     {{val/sandbox2|600|+140|-130|u= km}}     {{val/sandbox2|727.0|+61.9|-66.5|u=}}     {{val/sandbox2|0.107|+0.023|-0.016}}

Presumably if there's an occasional need for such a thing, we could always make that an option, as we do at {{su}}. — kwami (talk) 08:33, 12 February 2014 (UTC)

That is not quite an accurate description of the dispute. {{val}} was originally developed in 2008 (mostly by SkyLined) in conjunction with the MOSNUM to produce correctly-formatted and correctly-aligned numbers that would display on the widest variety of browsers, regardless of the choice of fonts. (See original request. The alignment problem is font-dependent and browser-dependent, but for examples you can take a look at

Correctly-aligned Mixed font	Badly-aligned Uniform font
123.0+11.1 −9.9	123.0+11.1 −9.9
123.0+1.11 −0.99	123.0+1.11 −0.99
0.12345+0.00111 −0.00099	0.12345+0.00111 −0.00099
0.1234567+0.0000111 −0.0000099	0.1234567+0.0000111 −0.0000099

Comment: This is not the formatting we are arguing about. I tried correcting it (to val vs val2, using the same font for each), but HB reverted. — kwami (talk) 23:33, 12 February 2014 (UTC)

Kwamikagami wants to unilaterally change this behaviour people have relied on for the past 6 years or so and force badly-aligned fonts across the board by forking {{val}} into {{val2}} [created on February 2 right after {{val}} was protected] and mass changing {{val}} → {{val2}} in whatever article he comes across.

If people decide that badly-aligned uniform font number display is more desirable than correctly-aligned mixed font display, it is very easy to implement this in {{val}}. But that change should not be made unilaterally, or forced down everyone's throat by forking val and then mass replacing val with val2. Headbomb {talk / contribs / physics / books} 12:24, 12 February 2014 (UTC)

The examples given in the MOS do not illustrate the mixed fonts that val imposes. Thus val does not reflect the MOS. I've been converting {{±}}, which does conform to the MOS, to val, and in doing so I modified val to conform to the MOS as well, before splitting it off as val2. I've suggested an *option* for fixed width display, in the unlikely case we actually do get +111 and −99, though I'd suggest formatting the entire number that way. If val is incompatible w normal formatting, we'll either need a duplicate template, as we have now, or to revert to manual formatting, both of which are inefficient.

The "original request" that you link to only request that the uncertainties be right-aligned, not that half the number be monospaced and half not.

Also, the template doc warns that this is "monospaced : currently not printable to PDF". Why would we force parts of our articles to be unprintable?

BTW, you don't edit war on the MOS. I've reverted both our recent edits, back to Jimp, less a couple minor, unrelated corrections. — kwami (talk) 13:25, 12 February 2014 (UTC)

If the template documentation says that, then it's wrong. Luckily for everyone, it doesn't say that.Headbomb {talk / contribs / physics / books} 14:22, 12 February 2014 (UTC)

It's a direct quote, copied and pasted. — kwami (talk) 23:26, 12 February 2014 (UTC)

stranded digits

We said,

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

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

Sorry, could you please provide a source? I'm curious. Archon 2488 (talk) 00:19, 12 February 2014 (UTC)

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

Durations

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

Good question. That article doesn't have any times over 10 hours or under 2 hours, so there is no cause for alarm that anyone is likely to see 9:51 and think it was a blazing pace of under 10 minutes! Although it does technically leave ambiguity, I think it is reasonable to include times in a table in the format 02:52:15 for HH:MM:SS and 09:51 for HH:MM when seconds are unknown, but perhaps include a note to explain that seconds have only been recorded since more precise timing equipment has become available. Certainly a mix of 02:52:15 and 5 h 50 m is not a great look, not to mention that the latter format is not as common in English. —sroc 💬 12:23, 6 February 2014 (UTC)

Ambiguity is seldom a good thing. X h Y m Z s is common enough in English, and should be clear from context. We even have a template for 2^h 52^m 15^s format, though that's for ascension and might not be appropriate for time. (If we don't have one that's not superscripted, we can make one.) IMO we should only use HH:MM:SS or HH:MM in tables where it can be labeled so there is no possibility of confusion. In the case of that article, it's probably best to convert all to X h Y m Z s, since we can't use zeroes as placeholders for HH:MM:SS format. — kwami (talk) 18:21, 6 February 2014 (UTC)

Thanks for the replies. I agree that what I did is not a great look (I was cleaning up a copyvio, not writing on a topic that interests me). But I'm no wiser about how best to improve it - both suggestions are valid, but also mutually incompatible. Justlettersandnumbers (talk) 22:10, 11 February 2014 (UTC)

In the absence of any specific guidelines or known precedents, go with Kwamikagami's suggestion (02 h 52 m 15 s, 09 h 51 m) as it more clearly disambiguates without needing further explanation. Sorry, I'm not sure whether leading zeroes are appropriate in this format, but I'm fairly sure superscripts for "h"/"m"/"s" aren't usually used for time. Even though the format is not as common in English as HH:MM:SS or HH:MM, I wouldn't push for my suggestion over the other. —sroc 💬 01:58, 12 February 2014 (UTC)

 Done [14] —sroc 💬 04:43, 15 February 2014 (UTC)

Formatting the MOS with a template to support that template

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

I agree in principle. It's tempting to use a template, but I would prefer it at least be substituted, and only edited with consensus, so it is easier to see what the template and other forms should match. Template code can still be listed with examples, but probably not as the main MOS examples. If that is too redundant, just list the template examples on its doc page. —PC-XT+ 04:09, 13 February 2014 (UTC)

That sounds reasonable. — kwami (talk) 06:50, 13 February 2014 (UTC)

What about situations where MOS advises to use particular templates? For example, MOS:FRAC:

The templates {{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.
• In science and mathematics articles, fractions should always be written either with a horizontal fraction bar (as in $\textstyle {\frac {1}{2}}$ or ⁠1/2⁠), or with a forward slash and with the baseline of the numbers aligned with the baseline of the surrounding text (as in 1/2). The use of {{frac}} (such as 1⁄2) is discouraged in these articles.

—sroc 💬 12:04, 13 February 2014 (UTC)

That's a good point. Perhaps in such cases we should add a warning to the template talk page (or even better, in the edit window of the template) warning editors that it's transcluded in the MOS and so shouldn't be substantially modified without giving notice there? — kwami (talk) 21:08, 13 February 2014 (UTC)

Questions that come to my mind: Are the templates an integral part of the MOS, or does the MOS hand off these issues for the template to define? Should these templates be specially protected as MOS templates, and only edited in tandem with the MOS, or should the template follow the MOS? Should the discussion of relevant MOS changes occur here or at the template talk page, instead? Does it matter in practice? —PC-XT+ 07:55, 14 February 2014 (UTC)

I'd say, (1) neither. Formatting is defined here, and compatible templates are suggested. (2) Val claims it follows the MOS, and the MOS always takes precedence. The MOS is the guideline, templates tools to help implement it. (3) I'd say anything to bring a template into better alignment w the MOS could take place there without notice. Anything that would adversely affect article formatting that was intended to follow the MOS should at least be mentioned here. — kwami (talk) 08:58, 14 February 2014 (UTC)

Thanks for the answers. I was thinking basically the same thing. I see potential problems in a template following something that uses the same template as part of its definition, but that doesn't mean it can't be handled appropriately, as suggested here by you and sroc. —PC-XT+ 09:34, 15 February 2014 (UTC)

I like your thinking, Kwamikagami! We already have warnings such as {{high-risk}} that appear on template pages where bad edits could have unintended/catastrophic consequences, so a similar warning for templates utilised in MOS seems like it could be similarly workable. Something like {{mos-template|MOS:FRAC}} that could produce a warning that links to the relevant section(s) of MOS where the template is used, perhaps? —sroc 💬 01:40, 15 February 2014 (UTC)

Something like this?

Also, isn't this a conversation for Wikipedia talk:Manual of Style, not this sub-page? —sroc 💬 01:56, 15 February 2014 (UTC)

Yes, exactly. Used in the MOS or even just recommended. If we recommend a template like val, then even if it has no direct effect on the MOS, after a few years there could be many articles where it was used because it followed the MOS. Changing it could mean effectively changing the intent and consensus of many editors. I think a warning would be appropriate in such cases as well.

If the template is actually used to format the MOS, then maybe something a bit more obvious? Currently I think we have warnings for ARBCOM, 1RR, etc. that pop up in the edit window, so there's no way you can miss them. Something like that might be appropriate in cases where editing a template would have the effect of changing our guidelines without the change appearing in the watch-lists of people monitoring them.

And yes, we should move the discussion there of course. I wasn't thinking. — kwami (talk) 02:00, 15 February 2014 (UTC)

Leaping to warnings might be overblown in many cases — remember to assume good faith — but in any case I don't think that's a discussion for here. Certainly propose any changes to the wording to make the intent clear, but no need to blow this out of proportion. —sroc 💬 02:05, 15 February 2014 (UTC)

Too many warnings would dilute them all. I don't think I would worry as much about recommended templates. I would tend to stick to templates used to generate MOS examples. I wouldn't tag templates used for other things on the MOS, such as styling. If the template differs from the MOS, it can be brought up-to-date or removed from the MOS. —PC-XT+ 09:34, 15 February 2014 (UTC)

You're right. And, as recommended above, we use templates as little as possible, and show how they can be used for MOS recommendations in the template documentation. — kwami (talk) 10:18, 15 February 2014 (UTC)

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: [15] [16] [17] [18] [19] [20] [21] [22]. 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)

Maybe it is. I don't believe I've expressed an opinion on the matter (other than that all YYYY-MM-DD dates should be dropped entirely). I actually think the proportion of readers who know the standard is likely to be minuscule, and thus that the fact that a date like 1605-11-15 in England is formally unambiguous does not mean that it is not ambiguous in practice. Kahastok talk 18:43, 28 January 2014 (UTC)

It is ambiguous in practice! Dates in the 1500s, 1600s, and 1700s (and even later, in a few countries) are, in general, subject to potential confusion about whether they're G or J -- the reader has to know what calendar was in use in the country under discussion, and of course a good article will explain that to him. The rules are at WP:JG.

But however good or bad are the provisions for helping readers understand the J/G issue, one thing's for sure: the date 1623-05-23 is no more nor less subject to such confusion on that than is May 23, 1623. So there's no reason to special restrict YYYY-MM-DD to Gregorian dates only.

The idea that they should be so restricted stems from the concern that maybe some readers will know about ISO 8601, which wants YYYY-MM-DD to be used only for G dates -- so maybe the reader will assume that 1623-05-23 must be G, instead of looking around in the article to find out whether it's G or J, as he has to anyway if he'd read May 23, 1623 instead. But as you say, a miniscule number of readers know about 8601, so this is a false concern.

EEng (talk) 23:58, 28 January 2014 (UTC)

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)

Given that the user knows they are dates..., the user must sure be able to work out...

And that's where I stop you.

If the user is having to "work out" what the date is, then we're doing it wrong. There is nowhere in the world where native English speakers would have to do any working out to understand "28 Apr 2008" or "Apr 28, 2008". Any date format that involves the reader having to work anything out is a problem. And in this case, part of the problem is that if you spend time working out the dates, you lose the wider points that the dates are being used to make. This is a bad thing, and there's no need nor benefit in it. Kahastok talk 18:43, 28 January 2014 (UTC)

I was just about to say something along the lines of what Kahastok has just mentioned. Stepho, you've just given us a paragraph on how we could easily figure out what these strings of digits and dashes mean. Consider, though, how long an explanation you'd need if the dates were in dmy format (like the rest of the article). This article is a good example of why we should ditch these ymd dates altogether. Were the dates in a normal format it would be much easier to digest (no figuring out required). Jimp 09:34, 29 January 2014 (UTC)

I wish we could ditch the YYYY-MM-DD format, but previous attempts indicate we can't. Jimp, you haven't expressed an opinion of whether it is better to decide following the ISO 8601 restrictions is unrealistic; if we discard the restrictions, we would become the only publication I know of that explicitly says it's OK to use the YYYY-MM-DD format to express Julian calendar dates. Jc3s5h (talk) 10:20, 29 January 2014 (UTC)

Do you know of any publication (book, magazine, journal, newspaper -- not some data interchange standard) which says anything either way about that? I predict the answer is no, because it would never occur to anyone to bother. The only reason I included the language explicitly allowing Julian dates is for the avoidance of doubt, given that we've had the language rejecting them for so long. EEng (talk) 01:39, 30 January 2014 (UTC)

Let's not give up hope on ditching this eye-sore. I agree that allowing YYYY-MM-DD without the restrictions is likely to make things even more confusing. Jimp 08:38, 3 February 2014 (UTC)

But that's not this discussion. Can we agree on the rules for YYYY-MM-DD assuming they will exist? Please? I've worked so hard on this. <whimper> Take pity. EEng (talk) 09:04, 3 February 2014 (UTC)

No, that's not this discussion, I just thought I'd mention my opposition to YYYY-MM-DD ... (again, in case it hadn't been noticed). Of course, we can't agree on the rules for YYYY-MM-DD assuming they will exist. When do people ever agree on things on this page? Jimp 09:50, 3 February 2014 (UTC)

Never. It's a special circle of hell -- worse than the one where you stand on tippu-toe in raw sewage up to your nose, but not as bad as the one in which you're forced to was the Indy 500 for eternity. <Zoooooooouum><Zooooooooooooum><Zoooooooooooooooooooooooooooom> EEng (talk) 13:48, 3 February 2014 (UTC)

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:

earlier versions

(Where used: Only in references, tables, lists or areas where conciseness is needed -- see Wikipedia:Citing Sources § Citation style) Use YYYY-MM-DD (all-numeric) format only for A.D. dates; zero-pad year to four digits, and month and year each to two digits. Editors should not use this format to imply conformance with ISO 8601, nor to imply that the date represented is to be interpreted in any particular calendar system (e.g. Julian calendar or Gregorian calendar). Nor should readers assume such conformance or infer any such interpretation. (Where used: Only in references, tables, lists or areas where conciseness is needed -- see Wikipedia:Citing Sources § Citation style) Use YYYY-MM-DD (all-numeric) format only for A.D. dates (though A.D. or AD should not be specified – 1776-07-04 not 1776-07-4 AD). Zero-pad year to four digits, and month and day each to two digits. Editors should not use this format to imply conformance with ISO 8601, nor to imply that the date represented is to be interpreted in any particular calendar system (e.g. Julian calendar or Gregorian calendar). Nor should readers assume such conformance or infer any such interpretation. [Minor fixes per comments] -- EEng (talk) 16:46, 27 January 2014 (UTC) (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)

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

EEng (talk) 23:28, 29 January 2014 (UTC)

Replaced {{snd}} with colon; deleted extraneous close paren. —Trappist the monk (talk) 23:40, 29 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)

As suggested by someone privately: The repeat of Prohibition was not an admission of defeat in the campaign to stop Americans from drinking alcohol. It reflected a realization that banning alcohol was a bad idea in the first place. EEng (talk) 05:33, 30 January 2014 (UTC)

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

<bump> EEng (talk) 23:28, 29 January 2014 (UTC)

• Comment – Why would we use restrictive/regressive/religious "AD" (Anno Domini) rather than inclusive/progressive/scientific "CE" (Common Era) for YYYY-MM-DD, which is arguably more relatable to the latter stance than the former? Thank you, startswithj (talk) 18:59, 29 January 2014 (UTC)

Reply - this has been a contentious issue for years on Wikipedia with an activist minority promoting the newer, more awkward, and less familiar BCE/CE notation, and a majority opposing this gratuitous change for various reasons, not a few finding BCE/CE more offensive than the standard notations. The debating over this involved several hundreds of editors and seemed endless. Finally wikipedia arbitrated a compromise along the lines of the British vs US English and similar disputes: Both forms shall be acceptable on wikipedia, articles must be consistent internally and go with whatever format was introduced first, unless local consensus (on the article's talkpage) agrees to change it. Til Eulenspiegel /talk/ 19:23, 29 January 2014 (UTC)

This is a project page and not an article, so the guidance for articles doesn't apply. Since this is one of two pages that sets out the guidance on this, I think this page should the more widely understood term, with an intra-page link to the section that sets out the guidance. Jc3s5h (talk) 20:06, 29 January 2014 (UTC)

It still leaves the impression that Wikipedia prefers AD. And the compromise was not that the first format trumps, but that the established format would need consensus to change it - with no definition of established. Til forgets that quite a few people find AD/BC offensive. And denigrates it by calling it 'gratuitous' and calling it more awkward. Back to the point, why can't we at least have AD/CE in the wording. Dougweller (talk) 21:29, 29 January 2014 (UTC)

Either way, the point is local consensus rules on articles, so I agree that this MOS should reflect both styles and maybe link WP:ERAS. Startswithj came in openly speaking the language of denigration, "restrictive/regressive/religious AD" and I just replied in kind with my own contrary perspective, as one who flags to everyone what his biases are should perhaps not expect a perfectly neutral reply. Til Eulenspiegel /talk/ 22:18, 29 January 2014 (UTC)

Jesus Christ! (If the choice of words may be pardoned...) Can you fight about this if and when the new text is in place? It's really not germane to the main question. I've modified to, I hope, please everyone on this. EEng (talk) 23:28, 29 January 2014 (UTC)

Not sure which of those three words raised offense (perhaps I should have said, "exclusive/traditional/religious"), but regardless I apologize, Til Eulenspiegel. startswithj (talk) 02:52, 30 January 2014 (UTC)

• Support. It's an unnecessary restriction that artificially entrenches ISO 8601 within these walls. Retaining the mention would be meaningless as we don't adopt any of its features other than the big-endian sequence. In practical terms, it will make no difference as I have never seen such a sequence used for pre-1583 dates; nor is that ever likely unless someone is trying to prove a point. Furthermore, it will remove the "is-it:isn't-it" dilemma. -- Ohc ^¡digame! 02:17, 30 January 2014 (UTC)
• Support for reasons stated by others and myself above. startswithj (talk) 02:55, 30 January 2014 (UTC)

Good, gooooood!! My plan is working puhrrrrfectly! <Rubs hands diabolically.> EEng (talk)

• If we feel the need to say, "[n]or should readers assume such conformance or infer any such interpretation", that probably means that we're doing something that is likely to be misunderstood. We need to remember that the proportion of readers who are going to see this instruction is negligible, and the format of our dates should be obvious without need for instruction. I would oppose this wording on that basis.

I noted above that I oppose the use of YYYY-MM-DD format entirely, because it is harder to understand than the alternatives (e.g. 1 Feb 2014) and has no significant benefit over them in an English-language encyclopædia. In that light, increasing the range of circumstances in which YYYY-MM-DD can be used seems to me to be a bad idea. But I'd add to that that IMO removing these restrictions makes the existing problems worse. Dates such as 0562-12-23, 0871-01-08 and the aforementioned 0014-08-19 will be even harder to parse than normal YYYY-MM-DD dates because no other major source allows zero-padded years. While I accept that other limitations will reduce the frequency of zero-padded dates to near-zero, it would be better if they just weren't possible.

All that said, I accept the premise of the change here, that the vast majority of readers and editors are unlikely to even be aware of ISO 8601, let alone the requirement that ISO 8601-conformant dates use the Gregorian calendar only, so enforcing Gregorian dates and post-1583 does not resolve any ambiguity. Kahastok talk 18:03, 1 February 2014 (UTC)

Oppose It is true that ISO 8601 has not been adopted at WP, I don't believe it should be (regardless of whether we keep YYYY-MM-DD) nor do I see it as being a practical possibility. I also agree that editors should not use this format to imply conformance with ISO 8601 or to imply that the date represented is to be interpreted in any particular calendar system. However, does this make the ISO 8601 restrictions simply irrelevant? The suggested "Nor should readers assume such conformance or infer any such interpretation." is somewhat problematic. Now we're proposing that the MOS instruct readers how to read WP, are we? Generally a manual of style is there to instruct writers how to write. Do we now expect readers to visit the MOS to interpret what they read? No, fair enough, normal people don't know anything about 8601; normal people aren't even familiar with YYYY-MM-DD. To most sensible readers 1700-01-01 is gibberish. It's not that far-fetched to suppose that amongst the hand-full of people who actually like this format (or even get it) a number of them might assume ISO 8601 applies. Also by tossing the not-before-1583 clause we've created the need for zero padding thus opening the door so some quite absurd looking dates. When you see 0012-06-24 do you think "24 June 12 AD" ... really? Open a door and some fool is bound to walk through. Jimp 09:50, 3 February 2014 (UTC)

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

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

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

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

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

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

There is probably no wording that supports YYYY-MM-DD that I could unequivocally support, because of my separate concerns with the format. But I believe I could accept this text, or the same text with the additional instruction to editors (i.e. without Nor should readers assume such conformance or infer any such interpretation.) for the purposes of consensus. Kahastok talk 20:45, 1 February 2014 (UTC)

What wording would you -- in your secret heart of hearts if you were All-Powerful High Emperor of the Known Universe and Grand Poohbah of MOS As Well -- desire to see (on the assumption that some even-higher power has decreed that YYYY-MM-DD dates are here to stay)? EEng (talk) 23:27, 1 February 2014 (UTC)

Working under these conditions, I believe I would put the start date at 1000 AD to avoid the question of zero-padding. Chances are the number of cases affected by such a change 1000 AD will be negligible anyway, so I don't see why we should feel the need to go there. This also reduces the need for the comment on era style (because most dates post-1000 will be unambiguous with respect to era). So instead of:

use only with Gregorian dates between 1583 and 9999 (ref) The year restriction on YYYY-MM-DD dates stems from the possibility they will be assumed to follow the ISO 8601 standard, which mandates the Gregorian calendar (/ref)

I would put:

use only with dates between 1000 and 9999

If we felt the need, we could then put in a reference something like This style is similar to that used in standard ISO 8601 - but don't imply that the dates actually use ISO 8601 and apply WP:JG as normal. - but in context I don't think we necessarily need it because I think very few people will be aware of ISO 8601. Kahastok talk 22:44, 2 February 2014 (UTC)

I would support YYYY-MM-DD usage in any non-prose place for any date. I would also generally favor succinctness. startswithj (talk) 21:56, 2 February 2014 (UTC)

I can live with that. So how about:

(Where used: Only in references, tables, lists or areas where conciseness is needed -- see Wikipedia:Citing Sources § Citation style) Use this format only for years 1000–9999 AD/CE (though AD or CE should not be specified: 1776-07-04 not 1776-07-4 AD or 1776-07-4 CE). Zero-pad month and day to two digits.

All in favor? EEng (talk) 09:12, 3 February 2014 (UTC)

I would prefer the version without the not-8601 text, I would also prefer the suggested 1000-to-9999 restriction to avoid the very strange-looking zero padding which is being proposed but, for the reasons mentioned above, I still oppose the change. Of course, I would prefer we got rid of YYYY-MM-DD altogether but, anyhow, whilst on the subject of trimming, how about the ridiculous "areas where conciseness is needed" bit? Conciseness is a completely false excuse for employing this unfamiliar format: just abbreviate the month. Jimp 09:50, 3 February 2014 (UTC)

The "conciseness" language is existing language applying to YYYY-DD-MM along with e.g. 13 Sep and Sep 13 i.e. formats using shortened month names. I've been carrying it along in the succession of proposals during this discussion only for completeness -- it's actually a column heading / footnote in the table. Does that help, O desperately solicited holdout? EEng (talk) 13:48, 3 February 2014 (UTC)

I would accept this or its equivalent in the new system (given my reservations re: YYYY-MM-DD dates in general as previously expressed). Kahastok talk 18:49, 4 February 2014 (UTC)

• Oppose (responding to the notice of an RfC and to the proposal at the top of this section).  It doesn't make sense to document an ambiguous machine-friendly format for dates before 1583.  The fix may be to have additional syntax as part of the format, so that there is no ambiguity to either a human or a machine regarding if the date is Julian or Gregorian.  Unscintillating (talk) 04:20, 17 February 2014 (UTC)
• Support the proposal with or without mention of ISO-8601. Heart of the matter is a format (as in use in the real world) not a whole definition of a time scale. −Woodstone (talk) 07:59, 17 February 2014 (UTC)

Quantitative usage info

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

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

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)

Outside perspective from sroc

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

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

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

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

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

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

If we consider these two separate issues:

• Should YYYY-MM-DD only be used for dates in the Gregorian calendar? I see three options:
  1. Yes, only allow Gregorian dates (the status quo, but using "must" instead of "should")
  2. No, allow Gregorian or Julian dates, but require that Julian dates must be clearly demarcated as such (this would avoid the concern that the reader would assume the date to be in Gregorian because of ISO 8601)
  3. No, allow Gregorian or Julian dates without the need for qualification

On this issue, I tend towards option 2 because it neatly avoids the implication that YYYY-MM-DD = ISO 8601 and avoids confusion amongst anyone who would assume all YYYY-MM-DD dates are Gregorian.

• Should YYYY-MM-DD dates be limited to 1583-9999? I see these options:
  1. Yes, because this reflects ISO 8601, although not exactly (the status quo)
  2. No, allow dates from 0001 to 9999, because we don't follow ISO 8601 and typical readers will understand what these dates mean
  3. No, allow any date range we choose, because we can say that MOS:DATE essentially forms an agreement between Wikipedia and the reader to allow dates outside this range in order to comply with ISO 8601

On this issue, I'm leaning towards option 2 again because it reflects common sense. If we adopt option 2 on both issues, then we can have dates such as 1503-05-27 provided that it is made clear that this is a Julian date. Typical readers unaware of ISO 8601 will understand what is meant and will not be confused or alarmed. Readers with an intimate knowledge of ISO 8601 will realise that it is non-compliant with ISO 8601 because it is out of range and does not use Gregorian, but this is OK because MOS:DATE will allow it and is not bound by ISO 8601.

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

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

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

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

[Revised in light of below discussion that ISO 8601 does not allow dates between 1582-10-15 and 1582-12-31 after all. —sroc 💬 12:10, 6 February 2014 (UTC)]

ISO 8601 sets 1583 as the minimum year that may be used without mutual agreement. Jc3s5h (talk) 17:39, 4 February 2014 (UTC)

Does it not allow dates from 1582-10-15? From ISO 8601: "…ISO calendar dates before the Convention are still compatible with the Gregorian calendar all the way back to the official introduction of the Gregorian calendar on 1582-10-15. Earlier dates, in the proleptic Gregorian calendar, may be used by mutual agreement of the partners exchanging information." —sroc 💬 03:26, 5 February 2014 (UTC)

An electronic copy I downloaded before it became hard to find indicates the minimum year is 1583, in the absence of mutual agreement. Jc3s5h (talk) 04:07, 5 February 2014 (UTC)

Could you copy the exact wording from ISO 8601 for our benefit? —sroc 💬 22:07, 5 February 2014 (UTC)

Sroc, I haven't been ignoring you, just distracted. I'll try to rejoin the conversation in a few days. Keep up the good work. EEng (talk)

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

4.1.2.1 General

In expressions of calendar dates

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

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

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

YYYY-MM-DD and YYYY-yy

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

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

Julian and Gregorian calendars and Days of the Year articles

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

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

• 1776 – Ioannis Kapodistrias, Greek politician, 1st Governor of Greece (d. 1831)

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

• 1776 – Ioannis Kapodistrias (Gregorian birthday February 22), Greek politician, 1st Governor of Greece (d. 1831)

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

• 1776 – Ioannis Kapodistrias (Julian birthday February 11), Greek politician, 1st Governor of Greece (d. 1831)

—Anomalocaris (talk) 10:36, 19 February 2014 (UTC)

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

What exacly is a "UK engineering-related article"

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

• It seems that HS2 started life using Imperial, so I don't think it would be appropriate to flip the units into metric, being a violation of WP:RETAIN. -- Ohc ^¡digame! 08:06, 17 February 2014 (UTC)

• I think WP:RETAIN means use the variety of English the article started with, unless it has strong ties to a particular English-speaking country. The first version didn't contain any language that would vary between American and British English; the current version uses British English. So WP:TIES applies rather that WP:RETAIN. But neither of these is intended to distinguish among English as written by British engineers vs. English as written by British travelers, or anything of the sort. Jc3s5h (talk) 19:07, 17 February 2014 (UTC)

I agree that WP:RETAIN is not relevant here. Keeping whatever units the original author decided on (basically, a coin toss) is not constructive or reasonable. Archon 2488 (talk) 22:05, 17 February 2014 (UTC)

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

Proposal

Doesn't anyone here know what is meant by the term, and whether it was meant to include ALL articles which mention an engineering project anywhere amongst their content? I suspect that this clause is being widely gamed, and used as an excuse by some editors who "prefer the metric system" to fully metrify/metricate UK-related articles against the spirit of these guidelines. For that reason, I propose either removing the exception on engineering related articles or tightening it to define just how much engineering content an engineering-related article is expected to have. Passy2 (talk) 07:32, 17 February 2014 (UTC)

The argument that the HS2 article isn't "sufficiently engineering-related" because not all of it is about engineering strikes me as committing the fallacy of division. It is in any case the only article on Wikipedia about what is indisputedly an engineering-related topic. Or should we venture into angels-on-pinheads territory and say that certain articles on engineering-related topics are not, in fact, engineering-related? What would be the point of this? "Give precedence to the original units" is a generally-sensible rule, it was all that came out of the last unpleasant imperial/metric discussion, and I have not argued against the use of imperial where there is a genuine historical warrant for it. Or perhaps we should berate modern engineers for "preferring the metric system" and putting signs like this all over things that, for apparently political reasons, we are not allowed to call engineering projects, and are not allowed to describe in terms of those same metric units? Does Wikipedia "know better" than the engineers which system of units to use? I'm searching in vain for a rational argument here. At what point does it become acceptable to ignore the units that are actually used in the real world, and impose our own bizarre harlequin mixture of metric and imperial, which doesn't reflect the real world so much as a compromise between different factions of Wikipedia editors circa 2014? For what purpose? Archon 2488 (talk) 14:59, 17 February 2014 (UTC)

Engineering-related articles are articles that primarily discuss engineering-related aspects of the article's topic. An article that focuses on destinations served, cost, political acceptability, and the like, is not an engineering-related article. Jc3s5h (talk) 19:10, 17 February 2014 (UTC)

I guess that's easy enough to say, but then what does "primarily" mean? What does it mean to say that an article "focuses on" X at the expense of Y? What if that focus changes as the article evolves? These seem like weasel words to me. The problem with what you are suggesting is that, as a rule, it would imply that if an article started life as a few paragraphs on engineering-related topics, then was expanded to encompass broader information, it would pass some critical threshold and cease to be officially "engineering-related" as an article. This would then imply, by the utterly Byzantine rules of WP:METRIC, that editors would no longer be allowed to use consistently the units which are used in real life, but would need to follow the somewhat-arbitrary WP convention for generic British articles.

I think that this question of where that critical point lies is an unanswerable one, and the distinction is pedantic and unnecessary. Once again, what actual purpose does it serve? Why should Wikipedia have an "engineering hat" which it puts on to speak in metric, then in some cases takes off to speak in imperial? Archon 2488 (talk) 22:05, 17 February 2014 (UTC)

You seem to be arguing that we should use "the units which are used in real life" - but then rejecting the units used in real life when they happen to be imperial. Note that WP:UNITS deliberately prefers imperial units only in cases where they are overwhelmingly more common in real-life UK usage.

The engineering exception very clearly does not specify metric-first, it specifies the units of design first. In many cases this will actually be imperial.

The article High Speed 2 is not engineering-related, so far as I can see, so WP:UNITS would apply as normal - but the determination is ultimately left to local consensus on the article talk page. I don't see a compelling reason here to change that. Kahastok talk 22:20, 17 February 2014 (UTC)

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

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

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

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

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

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

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

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

I think that the HS2 article is clearly "engineering related." I cannot understand how anyone can seriously argue that it isn't. If a proposal to build a railway isn't related to engineering, what is? Therefore we need to find out what were the units of design for the HS2 proposal and run with that. Michael Glass (talk) 22:29, 17 February 2014 (UTC)

Michael Glass, I moved your comment so it's in a more logical position — hope you don't mind.

I'd suggest looking at the categories in which the article is included, such as "High-speed railway lines in the United Kingdom" and "Proposed transport projects in London". It seems clear to me that inclusion in these categories suggests that the article relates to engineering and infrastructure. Merely discussing other topics doesn't change this fact. By the same token, an article on a proposed bridge, ocean liner or supertall building would clearly be engineering-related. Just think how Wikipedia typically classifies such articles — also in terms of WikiProjects. These are emergent, natural and intuitive classifications which people do not find controversial in practice. The article on the Titanic is engineering-related, so it can give dimensions in feet and inches per the original design, although obviously much of the article is about the sinking and the cultural impact rather than the engineering as such. Archon 2488 (talk) 23:44, 17 February 2014 (UTC)

I cannot believe that another hang-up has resulted here. It is quite clear that the High Speed 2 article is an "engineering-related article". It is exactly the type of article the exception was designed to serve. There is no doubt that the railway has been designed in metric, therefore, measurements pertaining to the railway should be in metric. RGloucester — ☎ 00:04, 18 February 2014 (UTC)

I agree with Jc3 that this is not "Engineering" within the meaning of the wording. By merely asserting that HS2 is Engineering, like shouting loudly over the rooftops, doesn't make it so. The project is too macroscopic for it to be usurped as "Engineering" for MOSNUM purposes, to be used as part of of the Wikipedian "Metric vs Imperial" battleground. It's fundamentally an Economics article, based on the perceived need to build high speed links to the extreme parts of the UK. It's served by major investment in a transportation project; I'd argue that the primary drivers are geographical and political factors. Transport is a major component, of which Engineering is only the enabler in this. This is no synchronous motor or cellular network – I see no scientific equations, workings or hypotheses. There are only about 60 "measurements" in the entire article. So it's probably about as Geography-related as Engineering-related. I'm not saying who's right or wrong, but depending on how you look at it, the HS2 article is only the pawn or Trojan Horse in this game being played out. -- Ohc ^¡digame! 02:19, 18 February 2014 (UTC)

HS2 is a large-scale engineering project, as is any railway line. The economic angle would not exist if it were not for the engineering, that is the physical laying of the track. The exception was created so that engineering projects drawn up in metric would use metric units. This means that the length of the route should be written in metric, along with the gauge of the track and so on. It really isn't that hard to comprehend, and you are taking it much further than is necessary. I don't know if you remember from the previous discourse, but in my own head, I prefer imperial units. I am not a metricator, nor an imperialiser. I have no interest in a metric v. imperial skirmish. I compromise. To call the largest civil engineering project in Britain for a very long time "not engineering-related" is the queerest thing I've ever heard. Anyway, I have no interest in another endless discussion, I was merely here to provide my brief opinion, as I was the drafter of said exception. RGloucester — ☎ 03:35, 18 February 2014 (UTC)

I completely agree with RGloucester. To claim that one of the largest civil-engineering projects in Britain is not "UK engineering-related" beggars belief. This is exactly the sort of article that the provision was intended to address: civil-engineering projects such as bridges, railways, and motorways designed and implemented in metric units, long after the use of imperial measurements for such purposes was abandoned and de facto became illegal. --Boson (talk) 12:24, 18 February 2014 (UTC)

The project is certainly engineering-related. But is the article? Look through the article: how much of it is actually discussing engineering? Most of it is actually discussing the politics, and those parts that aren't are mostly discussing the geography. As others have pointed out, there are actually very few measurements - and most of them are geographical-scale distances and speeds, precisely the sorts of units that would be frequently expressed into imperial in British usage.

But ultimately this is a matter for the article talk page. I do not see an improvement needed on the guideline. Kahastok talk 19:06, 18 February 2014 (UTC)

"But is the article?"

In my opinion: yes; the article is about an engineering project, so it is engineering-related. This does not mean that other aspects may not be discussed at length. For this reason (non-engineeering topics in engineering-related articles and vice versa), I argued, in the protracted discussion at Wikipedia talk:Manual of Style/Dates and numbers/Archive 142#Imperial measurements, that units should be dependent on the context rather than the topic of the article. It was you who rejected that and suggested

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

--Boson (talk) 22:05, 18 February 2014 (UTC)

I agree with Kahastok that the HS2 project is certainly engineering related, but, so is the article that deals with the project. This can be seen from the article's headings: History, Route, Connection to other lines, Journey times, Planned stations, Development, Environmental impact and Alternative plans. The engineering connection is more than a tally of the number of times it refers to measurements. Nor does it cease being connected with engineering because it deals with the politics of this major project or deals with the geography through which the project is to pass.

I agree with Kahastok that this a matter for the article talk page.

I agree with Kahastok that the guideline in question does not need "improvement."

Michael Glass (talk) 22:49, 18 February 2014 (UTC)

I came here hoping for clarification as to what "UK engineering-related articles" meant in the guideline, to help with a disagreement about whether the HS2 article qualifies, or not. Judging from the replies here, it isn't clear at all, with claims both ways in equal measure. So I would suggest that the guideline does need further clarification.

My view remains that, although the HS2 article is about an engineering related topic, it itself is not actually an "engineering-related" article, agreeing with the reasons given above highlighting its broader topic content. Articles specifically about the engineering of the trains or of the track or its many bridges and tunnels would almost certainly be engineering-related, but the current HS2 article itself is more about the economics and politics than specifically the engineering. Passy2 (talk) 07:42, 19 February 2014 (UTC)

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

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

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

I agree that this is a matter for article talk pages, and that the guideline needs no further modification. Archon 2488 has put forth some sensible comments forward. I would direct you, Passy2, to look at the present guideline for "science-related articles". This is what the engineering exception was modeled on, and has not created any controversy. Many of the "science-related articles" could be argued to pertain to things other than science, as it happens. Nevertheless, "science" is their base. As is engineering, for this article.

If we have an article on a plant, that is a botany, or science-related article, even if one could talk about it being sold by greengrocers, and having a large economic impact on world markets. That's because, fundamentally, the article is about the subject. The implications of the subject all stem from the subject. "Engineering-related articles" are those that are based in engineering. Everything that you've mentioned that is discussed in the article is a product of the very engineering itself. One cannot talk about the economic impact of a bridge without the bridge itself, and the bridge is a piece of engineering. I would advise that you to avoid splitting hairs, and reading too much into guidelines. It serves us well on Wikipedia to be pragmatic. RGloucester — ☎ 15:25, 19 February 2014 (UTC)

FWIW, to my mind, if the question is, "[h]ow exactly does one quantify just how much engineering content there needs to be in an article before it's officially engineering-related", the answer is, so long as the spirit of MOSNUM is not clearly being broken, it is engineering-related when the talk page consensus says it is.

Of course, we have to be careful of those who abuse the rules. The global consensus expressed through the letter and spirit of MOSNUM still overrides local consensus if there is a clear conflict, and we have had editors in the past that would quite happily argue that black was white if it served their POV on units. But this is not at issue here: it's a judgement call with legitimate room for disagreement, and in that case talk page consensus is the way to go. Kahastok talk 20:23, 19 February 2014 (UTC)