Wikipedia talk:Manual of Style/Dates and numbers

From Wikipedia, the free encyclopedia
Jump to: navigation, search
Shortcuts:
WikiProject Manual of Style
WikiProject icon This page falls within the scope of WikiProject Manual of Style, a drive to identify and address contradictions and redundancies, improve language, and coordinate the pages that form the MoS guidelines.
 

Acceptable formats (2)[edit]

At User talk:Technical 13#Template:Rotten Tomatoes score, Technical 13 is asserting that since a format like "September 01, 2013" is not explicitly listed as unacceptable in the table at WP:BADDATEFORMAT, it is therefore acceptable. I claim that the "June 09" example covers this, and it is therefore not an acceptable format. Bgwhite says that it is covered by Do not "zero-pad" month or day, except in all-numeric (yyyy-mm-dd) format. I would like a clarification please; not merely on this page, but actually in the table so that there can be no doubt. --Redrose64 (talk) 18:33, 14 October 2014 (UTC)

There is nothing ambiguous about "do not 'zero-pad' month or day". The format quoted from the talk page has a zero-padded day, which is listed as "unacceptable" in the table. – Jonesey95 (talk) 18:56, 14 October 2014 (UTC)
  • Except on full dates, which November 25, 2014 is a full date. The real issue here is whether or not we want to fix our CS1 module to accept such dates or force Rotten Tomatoes to change the format that their API return to the bot that updates the page. I'd say it will be easier for us to fix our module than it will be to get them to change their API, but I really don't care one way or the other. The reason that the bots and the API do it this way is because it is is easier to pick out /$(January|February|March|April|May|June|July|August|September|October|November|December) (\d{2}), (\d{4})^/ than /$(January|February|March|April|May|June|July|August|September|October|November|December) (\d{1, 2}), (\d{4})^/ and have everything line up the way it should. A few less bytes are good things.. — {{U|Technical 13}} (etc) 20:21, 14 October 2014 (UTC)
Wait, I'm sorry. Are you saying we should allow October 04, 2014, which looks hideous, so some regular expression can be more compact? I don't get what you mean by "have everything line up the way it should", and as for "A few less bytes are good things" -- you mean saving bytes in the RE? I hope I'm misunderstanding you, otherwise the response is, "Are you kidding?" EEng (talk) 20:55, 14 October 2014 (UTC)
It does not say "except on full dates"; it says "except in all-numeric ... format" (such as "2014-10-04"). The table is clear that prose dates should not use leading zeros. Archon 2488 (talk) 21:22, 14 October 2014 (UTC)
  • All I'm saying is we can either change the way that the Rotten Tomatoes API returns the data to the page or we can change our CS module to not be so picky. As for your opinion that October 04, 2014 looks hideous, I think it looks better than October 4, 2014 or 4 October 2014. — {{U|Technical 13}} (etc) 00:46, 29 October 2014 (UTC)

leading zeros should be allowed in days in dates[edit]

We all know that dates "should" be formatted in accordance with ISO 8601#Calendar dates. That being said, many people object to 2014-11-04 and so there are many date styles floating around. For all those other date formats, we should allow a leading zero for the days (as closer to ISO 8601 style), or not, as people's individual styles dictate. Perhaps, by implicitly encouraging a leading zero we can begin to move one step closer to overall ICO 8601 compliance. Currently, "04 November 2014" and "November 04, 2014" are not seen as valid dates while "4 November 2014" and "November 4, 2014" are seen as valid dates.
This refers to Wikipedia:Manual of Style/Dates and numbers#Dates and years in which a leading zero is not explicitly discouraged, just that otherwise non-ISO dates are not depicted using a leading zero. This is likely because the date checking code that Wikipedia is now using at Module:Citation/CS1/Date validation uses regular expressions that look for days as "+[1-9]%d?" rather than "+[0-9]%d?". This change in the Manual of Style would also necessitate a change in lua code, but that change would be rather simple, just involving the select and careful change of some regular expressions from [1-9] to [0-9], so let's focus on style and what should be allowed in this discussion.
This of course doesn't impact at all on something like 11 4 2014 or 4 11 2014 or 04 11 2014 or 11 04 2014 as all of those should throw an error as ambiguous, with or without a leading zero. Banaticus (talk) 22:18, 9 November 2014 (UTC)

Haven't we been through this several times before? See for example #Acceptable formats (2) above. --Redrose64 (talk) 22:36, 9 November 2014 (UTC)
Yes, we've been through this a zillion times. People keep showing up talking about ISO 8601 as if it's a given we want to adhere to that. The guideline currently says "Do not "zero-pad" month or day, except in all-numeric (yyyy-mm-dd) format", and that's the way it should stay -- leading zeroes look horrid. EEng (talk) 22:50, 9 November 2014 (UTC)
I agree with EEng. If you spell out the months then no leading zeroes for the day of the month. If you use ISO 8601 then also use leading zeroes. No other cases allowed.  Stepho  talk  23:47, 9 November 2014 (UTC)
I agree with Stepho and EEng – ISO 8601 prescribes an all-numeric format; it does not specify how dates should be written in English prose. There's no reason to encourage leading zeros in "November 4" or similar. Archon 2488 (talk) 00:42, 10 November 2014 (UTC)
I agree with Archon and Stepho and myself. EEng (talk) 01:57, 10 November 2014 (UTC)
In general, Wikipedia style follows real-world usage. I can't recall the last time I saw a reputable published document that used a prose date format with a padded zero, such as "November 04, 1986".
First, thanks for recombining threads. A leading zero is really popular with geneology groups. Apparently the Rotten Tomatoes bot returns dates with a leading zero on the days. IMDB uses leading zeros on days of the month. The US government uses a leading zero on days. Yahoo! uses a leading zero on days of the month. In my opinion, this is a stylistic issue. Let people choose to enter dates the way they're used to entering dates, as long as what they're entering is human/machine parsable. A leading zero on the date is already human parsable and it would only take some slight tweaks to make them Wikipedia/machine parsable as well. Now some might say, "Well, consensus is against you, sucks to be you" but I'd say that EEng has already made the argument that consensus is for a leading zero, if it's been brought up a zillion times already. :) It's really not difficult to find reputable sources which use a leading zero. Apparently the New York Times uses that format as well (top of the page, right after the words "Best Sellers"). I'd say it's really not hard to see that consensus is on the side of having multiple formats. Banaticus (talk) 11:19, 13 November 2014 (UTC)
The US Department of Defense also uses 24-hour time formats, but that doesn't mean WP does as well (except in certain military articles). And I don't see the NYT using leading zeroes other than on the page you link, which I'm guessing is some technogeek oversight no one's bothered to correct. You're right that it's a style issue. Leading zeroes in running text looks awful and catches the eye. The fact that it's come up many times before makes it no different than any number of other poor ideas. EEng (talk) 13:16, 13 November 2014 (UTC)
I'd also want to know what the proposed benefit of having one more optional style is. Does it make anything less ambiguous? There's an arbitrary choice to be made, and the MOS comes down on one side. I don't see a problem with that. Of course other sources are not going to be 100% consistent, but that doesn't justify WP being inconsistent. Archon 2488 (talk) 13:30, 13 November 2014 (UTC)

How to write "number does not exist" in a table?[edit]

In tables, the situation can occur "number does not exist", and "number is not available" (not always the same). Example: see here, in the bottom table. More here.

I wonder which punctuation or text to use for such "does not exist". At the moment I see hyphen, en dash, em dash, and "n/a". What would be the style advice for this punctuation, into consistency? -DePiep (talk) 07:58, 20 October 2014 (UTC)

Wikipedia:Manual of Style/Tables#Multi-column standard with subcolumns shows a similair situation, but there is no 'rule' for this, not even in Wikipedia:Manual of Style#Dashes. I would use an mdash, or ndash if that is too wide, but I would avoid a hyphen. I call these "empty value" cells. -- [[User:Edokter]] {{talk}} 08:26, 20 October 2014 (UTC)
Indeed, I don't think a "rule" can be reached, and that's not my ambition. Gathering opinions & good/bad practices would give a reasonable and workable outcome I guess. As I wrote it, this question is limited to scientific area.
We know that there are different meanings involved: "number not known", "number does not exist (logically; database null)", "situation does not exist", ... That's to be clarified locally, better not adapt a wiki-wide definition for this dash. -DePiep (talk) 08:49, 20 October 2014 (UTC)
I personally find the hyphen the best option in any scenario because it is the smallest. This makes it easiest to distinguish at a glance the empty cells from those with values. I can't think of a practical reason to choose either dash and I don't think they are esthetically more pleasing than a hyphen either (I find the hyphen looks better as well). Where there may be different reasons for having an empty cell, in general superscript symbols should be used after the hyphen/dash to refer to notes below the table that describe the reason. However, I don't think there are situations where the lack of guidance has let to problems in this area. SkyLined (talk) 08:59, 20 October 2014 (UTC)
I think mdash is preferred in case of situations where a hyphen may be mistaken for a minus sign. -- [[User:Edokter]] {{talk}} 09:18, 20 October 2014 (UTC)
Please, en dash is the only true way to show a missing/unknown value in a table! Johnuniq (talk) 09:28, 20 October 2014 (UTC)

Depends on context: for classical compositions a missing catalogue number can be indicated by Deest, see end of this table --Francis Schonken (talk) 09:51, 20 October 2014 (UTC)

I prefer the mdash because it is the most reminescent of a line drawn by hand in the cell to cross it out. Ndash is second best. Hyphen is an outright no because hyphens are meant to join to things together. N/A also works. Headbomb {talk / contribs / physics / books} 13:01, 20 October 2014 (UTC)
Thanks all, so far. As for the infoboxes like this in elements, I already used Edokters suggestion to use en dash, all over. -DePiep (talk) 14:06, 20 October 2014 (UTC)
The en dash, in my view, is much preferable to the em dash, which is just a bit too distracting in most tables. Tony (talk) 12:10, 5 November 2014 (UTC)
I would tend to agree with this. The em dash is a bit too large for most purposes, I feel. It also looks like it belongs in an 18th century novel. Here's a quick example of what the hyphen, en dash and em dash look like in a table:
x y z
123 456 789
-
Archon 2488 (talk) 12:33, 5 November 2014 (UTC)
To be fair, they usually look like this:
x y z
123 456 789
-
Usually, in cells like those linked in the original post of this thread, they're centered. Personally, I favor the em-dash. Banaticus (talk) 11:25, 13 November 2014 (UTC)

Acceptable date formats[edit]

If YYYY-MM is not banned, i.e. is acceptable, it would be consistent to list it next to the other acceptable formats. Michael Shotter (talk) 00:22, 9 November 2014 (UTC)

There is no consensus that YYYY-MM is an acceptable format. It has the potential to be ambiguous – like YYYY-MM-DD, but worse. The MOS currently lists YYYY-MM-DD as "the only acceptable all-numeric format", for what it's worth. Not that MOS is internally consistent 100% (or one hundred percent [per cent?], if you prefer) of the time.... – Jonesey95 (talk) 01:03, 9 November 2014 (UTC)
It has no potential to be ambiguous in environments where it is "clear" that YYYY-MM is meant. Same for YYYY-MM-DD. If YYYY-MM is ambiguous - with what could it be confused? With YYYY-YY? But then YYYY-YY has the potential of being ambiguous too - but that is listed as acceptable. /YYYY-MM-DD as "the only acceptable all-numeric format"/ - and at the same time it allows all-numeric years. Michael Shotter (talk) 04:10, 9 November 2014 (UTC)
However many of the environments in which YYYY-MM could occur are the same as those in which YYYY–YY could occur, which is a good reason not to allow it. Peter coxhead (talk) 07:49, 9 November 2014 (UTC)
If YYYY-MM is banned because it can be confused with YYYY-YY, then YYYY-YY can also be confused with YYYY-MM. Therefore, by your own reasoning, both formats should be banned and date ranges should only use YYYY-YYYY.  Stepho  talk  23:43, 9 November 2014 (UTC)
Sounds good to me. Where do I sign up? – Jonesey95 (talk) 04:42, 10 November 2014 (UTC)
@Stepho-wrs: I agree; I avoid using YYYY–YY and would support it being deprecated. (MOS purists will probably point out that YYYY–YY uses en-dash whereas, if it were allowed, YYYY-MM would use a hyphen, so in principle they could be distinguished. However, who really notices the difference between the two dashes?) Peter coxhead (talk) 09:09, 10 November 2014 (UTC)
Well, the purists would notice (and they'd point out to you that a hyphen is not a dash -- harrumph!) However, the other 99.9% of the population who get out of the house now and then will be unaware of the distinction, so to rely on it to telegraph this semantic difference is a poor idea. (It's interesting -- the difference between , and . is very small, yet we do invest great meaning in the difference. But people are use to that and have been sensitized to it since childhood. Not so with hyphen vs. endash.) Also, in some typefaces hyphen and endash are very hard to tell apart even if you're looking for the difference. EEng (talk) 19:59, 10 November 2014 (UTC)
For what it is worth, the notation YYYY-MM conforms to ISO 8601 (and ISO-conformance is in general an efficient way to avoid ambiguity). Lklundin (talk) 13:54, 13 November 2014 (UTC)
PS. On wikimedia, uploaded media dated as e.g. 'July 1947' will have its date automatically modified to 1947-07 (by OgreBot 2). Lklundin (talk) 13:58, 13 November 2014 (UTC)
I would agree more with this: YYYY–YY should not be allowed in any circumstances. Archon 2488 (talk) 15:49, 13 November 2014 (UTC)

"Current international dollar" (in Infobox) vs. US$ (vs. e.g. Zimbabwe $?)[edit]

"Use the full abbreviation on first use (US$ for the U.S. dollar and A$ for the Australian dollar), unless the currency is already clear from context." - for Zimbabwe nothing "is clear from the context"; the country is a mess and $ could mean (there) Zimbabwe dollar except they have changed to US$. I changed the Infobox[1] but not sure I did the right thing. It seems "Current international dollar" is close enough to US$ (always I guess), at least not Zimbabwe dollar (far from it). See ref[2]. It seems I did the right thing..

Should we say anything at this page about "Current international dollar"? comp.arch (talk) 11:21, 14 November 2014 (UTC)

I agree with your change - since the Zimbabwe dollar is no longer valid and the government uses US dollars, then effectively the nation currency is US dollars. But since both currencies use the $ sign, specifying 'US$' looks like the most accurate and easiest to understand option to me.  Stepho  talk  21:59, 14 November 2014 (UTC)

Trying to do an approximate year but the bots won't have it[edit]

On a citation here. No one knows exactly what year Saint Peter assumably wrote 2 Peter. I've tried "~67" and "c. 67" and both seem to have been flagged as erroneous. Does any one have any thoughts? -- Kendrick7talk 08:58, 21 November 2014 (UTC)

I found Help:Citation Style 1#CS1 compliance with Wikipedia's Manual of Style, "Uncertain, incomplete, or approximate dates: does not support c. or fl.; does not support dates prior to 100"! Help talk:Citation Style 1 seems quite lively and current - maybe ask there? NebY (talk) 10:37, 21 November 2014 (UTC)
The |date= field is for the publication date of the publication that you are citing, i.e. the publication that you saw with your own eyes. I'm guessing that you did not lay your eyes on a publication of the United States Conference of Catholic Bishops that was published in 67 CE. You can use |origyear= for the original publication date of a reprinted source. – Jonesey95 (talk) 15:43, 21 November 2014 (UTC)
That's a fair point Jonesey and I've made the revision; I know I was being a tad flippant. But still, there certainly are extant manuscripts created in the 1st century for which the exact year is entirely in doubt. Citing them shouldn't be automatically flagged as an error as such. I'll probably go ahead and file a complaint over at Help per NebY's advice. -- Kendrick7talk 23:37, 21 November 2014 (UTC)