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)[reply]

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

(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. [8]] EEng (talk) 10:39, 20 January 2014 (UTC)[reply]

(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)[reply]

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)[reply]

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)[reply]

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)[reply]

• 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)[reply]

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.

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)[reply]

• 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)[reply]

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)[reply]

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)[reply]

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)[reply]

Everyone's excited about •

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

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

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)[reply]

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)[reply]

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 •, 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 + • + space -- how dumb can you get?) EEng (talk) 04:05, 22 January 2014 (UTC)[reply]

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)[reply]

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

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

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)[reply]

I agree, squares are not even remotely close to what • 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)[reply]

Revamped "Acceptable date fmts" table

I've (boldly -- yes indeed very boldly) revamped the "Acceptable fmts" table at [[9]]. 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)[reply]

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)[reply]

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

Well, that didn't take long

According to one observer [10], 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)[reply]

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)[reply]

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)[reply]

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.[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Acceptable date formats (NEW, Alt1B)

• 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)[reply]

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)

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

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

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)

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

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)[reply]

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

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

Why suggest {{nbsp}} instead of &? Jimp 09:59, 3 February 2014 (UTC)[reply]

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

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)[reply]

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)[reply]

Thusly:

Acceptable date formats (NEW, Alt2B)

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

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)[reply]

Acceptable date formats (NEW, Alt2C)

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

Acceptable date formats (NEW, Alt2D)

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

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)[reply]

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)[reply]

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)

—sroc 💬 22:06, 3 February 2014 (UTC) [revised 00:14, 4 February 2014 (UTC)][reply]

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)[reply]

• 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)[reply]

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

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)][reply]

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)[reply]

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)[reply]

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)[reply]

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.)[reply]

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

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 [11] 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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

 Done I've made the change. —sroc 💬 16:34, 26 January 2014 (UTC)[reply]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-- then we'll write back thus:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Some wikipedians advocate Y/M/D format dates

to

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

In summary

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

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

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

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

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

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

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

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

Discussion of ISO 8601 and YYYY-MM-DD

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Remove these silly restriction

There seem to be two reasons given for these restrictions:

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

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

I'll repeat what I said above:

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

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

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

-- then we'll write back thus:

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

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

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

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

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

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

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

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

Presumably the footnote would be changed to read ³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)[reply]