Jump to content

Wikipedia talk:Manual of Style/Dates and numbers

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
< Wikipedia talk:Manual of Style
This is an old revision of this page, as edited by Simian (talk | contribs) at 20:14, 15 October 2005 (→Number notation). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Archives at: /archive1 - /archive2 - /archive3 - /archive4 - /archive5 - /archive5a - /archive6 - /archive7 - /archive8 - /archive9 - /archive10 - /archive11 - /archive12 - /archive13 - /archive14 - archive14a - /archive15 - /archive16 - /archive17 - /archive18 - /archive19 - /archive20 - /archive21 - /archive22 - /archive23 - /archive24 - /archive25 - /archive26 - /archive27

See also:

Units

The rules state for conversion and the exaple given

For example, "a 100 millimetre (4 in) pipe ..."

is completely against the international standard SI. After a number the abbreviation form should always be used!!!! AnyFile 17:49, 23 August 2005 (UTC)[reply]

  • We should aim to write language that as many people as possible will understand. The average person on the street is not an expert in SI units, and we should not expect them to be. It seems perfectly reasonable to spell out some units - indeed, it is desirable to do so, jguk 18:05, 23 August 2005 (UTC)[reply]
The SI units are only that dramatically important in contexts like science which actually use it.
Also, remember that that text is in prose. There was no consensus by my memory on the spelling out of numbers (Oxford and Chicago both recommend spelling out "a hundred", but there is no such suggestion here), and therefore we can assume here that, because it is in prose, "100" is a number that is essentially a word (poor way to explain, I know), abbreviated to digits for simplicity. Therefore it makes perfect sense to spell out "millimetre". Neonumbers 07:35, 25 August 2005 (UTC)[reply]
If we spell out "millimetre" and "kilometres", certainly we must spell out "inch" and "miles" as well. Remember that for the vast majority of the planet's inhabitants, "mm" and "km" are readily understood (not only by "experts in SI units") but "in" might cause some confusion (especially with the word "in") and lots of people will never ever have encountered "mi" (despite being familiar with the 1,609-metre mile). Of course there are a few countries where "in" and "mi" might be more easily understood than "mm" and "km", and these countries are very important bases for the English-language Wikipedia, so I'm not proposing dropping them altogether or anything, just being a bit consistent. (I would probably write "400,000 km", not "400,000 kilometres", but I wouldn't revert someone changing it. Non-standard or not, if it's an extra service to the reader, then who am I to go against it?) -- Jao 23:49, 27 September 2005 (UTC)[reply]

I am not certain this has been addressed, but after reviewing other pages for the answer to this question, I believe there is no rule with regard to spelling out numbers under a certain amount (e.g., "John had 1 album" vs. "John had one album"). The Uniform System of Citation (Bluebook) requires spelling out numbers from one to ninety-nine in the main text while one to nine are to be spelled out in footnotes. This does not include volume or page numbers (e.g., "John mentioned the lost album on page 2 of his autobigraphy." Anyone know the status of the rule, if any? Jtmichcock 20:36, 29 August 2005 (UTC)[reply]

I don't believe consensus was reached on the issue, so it's up to the author. In my opinion, numbers twenty-one through ninety-nine should be spelled out in nonscientific articles when numbers are used infrequently. When I edit I spell out numbers one through ten in nonscientific articles and leave the rest as they are (that's just my personal preference/style). —Wayward 00:04, 30 August 2005 (UTC)[reply]
Well, I thought numbers from one to ten were always spelt out, so "one album" not "1 album", and I don't recall anyone who objected to that, so if that's not on the guideline, and I thought it was, it should be there.
My personal opinion matches that of Wayward, with the addition of simple multiples of nice round numbers (so that the entire thing is two words max, e.g. four million, four trillion but not thirty-two thousand). Personal opinion only though. There was no consensus reached, and when I say that I could live without a guideline on something like I am now, then anyone who knows me well enough will know that the need for it is absolutely minimal (there's nothing that bothers me more than non-guidelines.) Neonumbers 08:17, 1 September 2005 (UTC)[reply]

I'm going to start spelling out everything for all those cases where numbers are used to start a sentence—and there are a zillion of them on Wikipedia. That's a much bigger problem than this.

A distinction should also be made between counting numbers (integers) and measured quantities. When 5 means anything within about 0.5 of 5.0, then 5 should usually be written as a digit rather than spelled out. Too many style guides don't even mention that when discussing the spelling out of numbers. Gene Nygaard 11:56, 1 September 2005 (UTC)[reply]

I'm not convinced that spelled-out numbers is a big issue in general. I agree that its awkward to see numerals at the beginning of a sentence, and it would be awkward to see "four million eight hundred and fifty-seven thousand", for example, although "four million" would be fine. Otherwise, I don't think it really matters whether we write 99 or ninety-nine. Unlike some other changes I advocate for, I don't find either hard to read, nor do I find it jarring to see "99" in one article and "ninety-nine" in another. Chuck 15:53, 6 September 2005 (UTC)[reply]

If you want an example of a spelled-out-numbers-policy 'The Chicago Manual of Style' would be a good book to look at. --kop 20:19, 19 September 2005 (UTC)[reply]

Geographical coordinates

The current templates for geographical coordinates display with ugly additional blanks. These occur after the minute and second symbols and before the NESW indicators, like in 33°56'  24"  N 118°24'  00"  W. (to show the effect I purposely replaced the symbols by quotes). Is this intentional? Is there a remedy? I usually see coordinates in other sources formatted as 33°56'24"N 118°24'00"W. −Woodstone 10:27:04, 2005-08-25 (UTC)

Units - superscript

Now that it's been a nice while since the units debate died down, I want to bring a few points up - minor ones, not fundamental ones like the one about conversions. The first is the removal of the line suggesting ¹²³ rather than <sup> tags to make 1 2 3. The reason for this is that the superscript, as you can see, makes the lines uneven. I think ¹ is a relatively new character, so maybe just ² and ³. Come to think of it, there are no situations where you'd need ¹.

So, a suggestion to add a line suggesting the use of ² and ³ where appropriate (e.g. m² rather than m2). This isn't asking much, but this is a style guide and it's worth putting that in just for clarification. Any thoughts? Neonumbers 11:24, 25 August 2005 (UTC)[reply]

Although my user stylesheet takes care of the extra leading, I think it’s a sound (re-)addition. You won’t need ¹ indeed (⁴ rather), but it’s not a new glyph, it’s for instance in ISO 8859-1. Christoph Päper 16:57, 25 August 2005 (UTC)[reply]
P.S.: If you want to improve your user stylesheet or a sitewide one, add a line like this to it:
sup, sub {line-height: 0.1em; font-size: 1ex;}
The default style sheet of my browser (Firefox 1.0.4) doesn't add excess leading when superscripts are used, so this must be a browser-specific problem. It should be pointed out that the Unicode Consortium and the W3C recommend using superscript markup rather than superscript characters because having two ways to represent the same info causes problems for search engines and their users. There is not a superscript version of every character, so you have to use markup sometimes, e.g. 10n or s−1. Therefore, we might as well use markup all the time and be consistent. Indefatigable 19:58, 25 August 2005 (UTC)[reply]

One question: where do you find your user stylesheet? (you can answer on my talk page if you want.)

I wanted to refer only to units here, so mathematical equations et cetera are a different story. Just units.

Now, about the -1, this ties in with something I wanted to discuss but gave way in order to speed things up: representing division in units. I wanted the guide to recommend using a forward slash (what was its proper name? solidus, was it?), so instead of m s-1, use m/s. If we do that, there would be no problem (or at least, I can't think of any units that use something to the fourth power).

On that division thing, the complete line I wanted to add was to recommend using a solidus, and, where more than one unit is below the division line in e.g. newtons per amperes per metres (which is actually teslas if I remember right) would be N/(A m) except with thin spaces. Anyway, that's another issue, but the solidus part ties in with this I guess. Neonumbers 08:11, 1 September 2005 (UTC)[reply]

The farad (1 F = 1 C/V) is probably the most common unit with a power of four. It can be expressed in SI base units like this:
A²·s⁴/kg/m² A²·s4/kg/m² A2·s4/kg/m2
A²·s⁴/(kg·m²) A²·s4/(kg·m²) A2·s4/(kg·m2)
(A²·s⁴)/(kg·m²) (A²·s4)/(kg·m²) (A2·s4)/(kg·m2)
A²·s4·kg−1·m−2 A2·s4·kg−1·m−2
A²·s⁴
kg·m²
A²·s4
kg·m²
A2·s4
kg·m2
37 A²·s⁴
kg·m²
A²·s4
kg·m²
A2·s4
kg·m2
The middle dot is preferable over a (thin) space. The first or third variant of the first or third row should be recommended IMHO. — Christoph Päper 15:22, 1 September 2005 (UTC)[reply]
I'd say anything with two or more slashes and no parentheses is unacceptable. Throw the first row out.
The first set of parentheses in the third row is superfluous. No need to encourage that.
A horizontal bar, no matter how you make it, doesn't work well in running text and should be limited to offset formulas. The table method is clumsy and far too complicated to try to explain and encourage, and would appear to be difficult or impossible to set up so that the number appears separately before the units in this text as opposed to math markup version.
Math markup is often ugly. But a bigger problem when units of measure are involved is the difficulty in getting editors to add either the \mathrm you have used or \mbox to get the symbols upright rather than italic.
Mixing characters and html superscripts in the same unit is ugly. Mixing them in the article as a whole is less of a problem.
I assume that the preference Neonumbers has for the character superscripts and the solidus (obviating the use of negative superscripts) has to do in part with that notion being more familiar to most people.
However, one major advantage of the negative superscripts method is that it is unambiguous. The order in which the units are placed doesn't matter.
  • We already have far too many "J/mol K" and similar undisambiguated units in Wikipedia (in normal mathematics rules, multiplication and division are equal in priority and proceed left to right absent grouping, but that is not what is intended here). Can Neonumbers come up with a way to ferret them out and fix them?
I don't see any big need to prefer either km² or km2 as a general rule in the simple cases such as the area of a country or its political subdivisions. Gene Nygaard 17:01, 1 September 2005 (UTC)[reply]
I agree in general, although I kind of like multiple slashes. I've thought about yet another possibility: A²·s⁴⁄kg·m² That's not a very good one, though. There are Latex packages to ease the handling of units, e.g. SIunits or fancyunits, but they're not installed on the Wikipedia servers. — Christoph Päper 12:16, 3 September 2005 (UTC)[reply]

Well, now I know that there is a unit that uses the fourth power.

With regard to ambiguity: The SI brochure specifically details how to resolve this. It says, for example, the multiple solidi are never to be used (i.e. never A²·s⁴/kg/m²), because this, as well as any multiplication after the solidus (e.g. A²·s⁴/kg·m²), is ambiguous. In any case where there is more than one unit with a negative exponent, i.e. after the solidus, brackets are to be used, so it should be A²·s⁴/(kg·m²) — or, of course, using negative exponents. On the chemical infobox, I think last time I checked parentheses were used (as an example, and I'm too lazy to check again now), so I think it was J/(mol·K).

I quote from The International System of Units (SI), the manual:

The solidus is not followed by a multiplication sign or by a division sign on the same line unless ambiguity is avoided by parentheses. In complicated cases, negative exponents or parentheses are used to avoid ambiguity.

You're correct, my preference for the solidus is partly because people are more familiar with it. (Personally, I like negative exponents, though I don't think should they be used here.) My preference, however, also comes back to the superscript numeral characters: the superscript html tags (at least in my IE7 browser) make the lines uneven, the use of solidi would eliminate their need. (On that note, does anyone know of any units that use a fourth power, like the farad does, but doesn't have its own name, like "mole per cubic metre"?)

My focus with the superscript numerals is actually with smaller cases like area and volume, rather than complicated cases. So for m², that doesn't cause uneven lines (= extra leading?), whereas m2 does. They also look significantly different. This is significant because (here comes my rant about consistency) this is one project by one team and in something like this should have one way. I'll refrain from reciting the extended version of my consistency rant. Neonumbers 13:20, 3 September 2005 (UTC)[reply]

The chemical infoboxes have been sporadic corrections over time, and finally probably some templates with correct J/(mol·K). Most of the elements are probably now correct; many chemical compounds still have "J/mol·K" (see dinitrogen tetroxide, an often used and often linked to article because it is a rocket fuel, benzothiazole, many more).
Some moments such as area moments of inertia (SI units m4) involve units to the fourth power. Note that the dimensions here are simply length to the fourth power. Thermal radiation depends on temperature to the fourth power (see Stefan-Boltzmann law). Gene Nygaard 14:48, 3 September 2005 (UTC)[reply]
As far as the different looks go, my tired old eyes prefer being able to distinguish squared from cubed. So I like the superscripts better. Gene Nygaard 15:04, 3 September 2005 (UTC)[reply]
Maybe I'm too stupid to see it, but how is anything like A²·s⁴/kg/m² ambiguous? J/mol·K isn't ambiguous either, it's just plain out wrong when J/mol/K (= J/(mol·K)) is meant. Christoph Päper 08:44, 6 September 2005 (UTC)[reply]
Because it could mean either (J/mol)·K or J/(mol·K)? User:Omegatron/sig 14:14, September 6, 2005 (UTC)
No, J/mol·K (= J·K/mol) cannot mean J/(mol·K)! Every 5th-grader gets this right, sadly some people with university degrees don't. Units shouldn't be context-sensitive. Christoph Päper 20:03, 6 September 2005 (UTC)[reply]
Right. But even better is to avoid using "/" at all. No way J·K·mol-1 will be confused with J·K-1·mol-1. (No matter how we code its writing) Nabla 21:42:55, 2005-09-11 (UTC)
It's ambiguous because, as Omegatron said, a reader wouldn't necessarily know for sure that the author doesn't have a misconception such that the author thinks he's writing A2·m2·s4/kg, instead of A2·s4/(kg·m2). As Neonumbers pointed out, in SI, only one solidus is allowed, unless you enclose the denominator in parentheses. Adding the parentheses is easy. Regarding superscripts, I prefer the html <sup> superscripts instead of the special character superscripts. As Indefatigable mentioned, using <sup> tags is more consistent and portable, and more logical. And, I usually prefer a solidus rather than a negative exponent, like Neonumbers. --Simian, 2005-09-28, 03:39 Z

Eyesight saving says use <sup> tag. Simplicity of editing says use <sup> tag (that is, I have no ² key on my keyboard). Anti-rule-creep says why have any rule. Consistency says pick either one, but only one. Therefore, if anything, I support using <sup>, otherwise, lets just leave it out. Chuck 16:05, 6 September 2005 (UTC)[reply]

The (US) English keyboard layout, which I assume you are using, is very supoptimal indeed. Most other Lating ones have ², often at AltGr+2. Christoph Päper 20:03, 6 September 2005 (UTC)[reply]
I haven't been here for about a month because I've been caught up in other things and haven't had time to participate in Wikipedia. I probably won't be able to check this discussion again for another while — but I want to say this now that I've read the discussion that's followed my last comment.
It seems as if everyone apart from me and Christoph are for the tags, and that no-one seems to consider the extra leading involved important. I would very much like to point out the leading that 2 causes — note the gap between the line with the superscript and the one above it. I'd also like to point out that the ² character is very conveniently placed as a link below the edit box, alongside ¹ and ³ and also all the other §±×źÂ. So it's not really that much harder to enter, and you're not doing it that often. But I can't argue against the sup tags being easier to read; they do, after all, make bigger text. My eyes have no problem with it, but then again that's me.
I'm quite reluctant personally to accept sup tags, but I'll have to if everyone apart from me wants them standardised. If I don't manage to find time, and you all decide to standardise sup tags and put it like so on the manual, I won't complain — much. Neonumbers 08:31, 3 October 2005 (UTC)[reply]

Dates linking convention currently ludicrous

We link to dates like this [[Month Day]] [[Year]]. The reason we do this is because there is a bit of software magic that makes dates so linked automatically display for logged-in users in their preferred format.

Unforunately this convention makes the links themselves almost complete useless. Have you tried whatlinkshere for your birthday? You get thousands and thousands of links across hundreds of years. For relatively recent dates (say the last hundred years?) it would be much much better to link to [[Month Day Year]]. Then whatlinkshere suddenly becomes a massively useful resource for finding out what when on when in history.

Ok the display preference software will be broken temporarily. This is no big deal:

  1. If people really care, then a developer can be cajoled into making a relatively simple change to the data-matching regex.
  2. Display preferences of logged-in users are secondary at the moment to creating a quality resource.

I am open to suggestions on what content should go at the target of each day. Recent dates can redirect to the relevant part of the archived current events page. Pages refering to pre-2002 will in time grow as people examine the what links here for that page. Initially they should perhaps be a small page pointing to the year and day. E.g. September 3 1939 will point readers at September 3 1939.

I'll await some comments before changing the policy page, but I see this as a big step forward in how we present our information and hope you'll support it. Pcb21| Pete 13:46, 25 September 2005 (UTC)[reply]

As correctly stated above, the current linking allows logged-in users to change the display format of dates. This is a most useful feature, that should not be given up. Linking as is allows to look up events in a year (having some historical coherence) and events on a month+day (meaningful for commemorations). Looking up all articles that contain a certain precise date, does not look particularly useful to me. −Woodstone 14:24, 25 September 2005 (UTC)[reply]
Looking up a particular anniversary or year would only ever be one more click away than it is now. I think you are being short-sighted in thinking that linking to a particular day is not useful. We already have about 200 words on every single day since mid-2002 as part of the current events archiving process. As time goes on, that archive is becoming more and more useful - but we should make it easier to access.
As for your point about display preferences - I already said it would be an easy software change to extend to work with full dates. We should not let the tail of a few logged-in users wag the dog of making content accessible. Pcb21| Pete 14:53, 25 September 2005 (UTC)[reply]
If you wish, you can link to full dates in YYYY-MM-DD format in a single link and have the date preferences work, look at 2005-09-25. If you want to go changing split links to this unified format, you could do so, although i doubt it is worth the trouble. DES (talk) 15:00, 25 September 2005 (UTC)[reply]
A few comments
  • I'd preferences option to be independent from the linking process.
  • We already have things like [[1997 in aviation|1997]] screwing up the commas in the date formats.
  • If all full dates are linked as such for preferences purposes, we need an option to suppress display of the year (something like piping in links, but not screwing up the preferences display)
  • We still need preferences links for partial years, even if the year can be suppressed in specific dates. For example,
As is, we also have too many links to unnotable years and months standing alone, in situations where preferences have no effect on the display. Gene Nygaard 15:19, 25 September 2005 (UTC)[reply]
Another thing on my wish list would be the ability to display only the first three letters of the month. This would be especially useful in tables.
The use of ordinals such as 31st August 1965 is another problem that should be dealt with. I can get by fine without them, but articles which use them often have inconsistent date formats, no matter what your preferences setting. Gene Nygaard 15:23, 25 September 2005 (UTC)[reply]
To DESiegel - that format seems to do the opposite of work! You are forced into the poor linking structure (i.e. linking to anniversary and year separately) even when you explicitly don't want to be. I agree with much of what Gene has said, particularly about having pointless links to unnotable years simply to enforce preferences. Yes there a lot of preferencing issues we could deal with... but more fundamentally we need to separate out display preference and linking completely. Then linking comes back to what in should be about - creating a network of articles. Preferences working on regexes independently of links could then get as funky as the community and the developers desire - I am aware however that the software will not change overnight, so we should push on linking to full dates where appropriate and the software will catch up as it has done in so many ways before. Pcb21| Pete 15:27, 25 September 2005 (UTC)[reply]
I would myself prefer that there was a way to tag a date for preference formattign without linking it -- the two are really separate functions. But that must wait on a feature beign added to the software. In the meantime, I do avoid and remove links to years when these aren't needed for preference formatting (since a year without a day and month won't be preference formatted anyway) and have no particualr relevance to the articvel at hand (which is the normal case). But i can't see intentionally breaking the current preference system as a way to encourage the develiopers to work on a new system. DES (talk) 05:36, 26 September 2005 (UTC)[reply]
It's a method that's worked for the last three years ;). Pcb21| Pete 11:12, 26 September 2005 (UTC)[reply]
Yes it ahs worked, and it does work. But does it work well? To be more exact, it works but has certian undesireable side effects, including the ones detailed here, and including the encouragement to link years when there is no good reason to (not even to suppor the preference mechanism. Other forms of wiki markup are not done with links, why should this one be? why not soemthing like <<26 September 2005>> where anything in the <<>> would be recognized as a date and formatted according to user preferences? I don't say this is vital, i do say it would be an improvement. DES (talk) 14:34, 26 September 2005 (UTC)[reply]
Linking years does in fact support the preference mechanism.
A corollary, as I pointed out above, is that links such as [[1999 in film|1999]] and [[1987 in sports|1987]] screw up that support of the preferences mechanism:
One of these, either April 13, 1999 or 7 May 1987, will be wrong for most people using preferences (except those actually like the way the editors of the American edition of the Guinness Book of Records do it, using that silly "April 13 1999" format). But even for them, they will then see the normal links without "year in ____" as screwed up.
Compare the same one without the "year in ____" link:
April 13, 1999 or 7 May 1987
But without any year link, it's just like with the "year in ____" link
April 13, 1999 or 7 May 1987. Gene Nygaard 15:55, 26 September 2005 (UTC)[reply]
Note also that it is even worse for those using the "2001-01-15 16:12:34" preference; both dates are screwed up, unless there is a link to the unadorned year without piping. Gene Nygaard 16:04, 26 September 2005 (UTC)[reply]

I agree that there should be a change to the date preference mechanism. As I have said before, create date-object should be done with a method different to that for real linking. As examples of how ludicrous the linking has become, dates:

There is a widespread false belief that all calendar elements must be linked each time they occur. So people link solitary elements such as Tuesday or January or 2001 even if they are repeated many times in the same article. These have almost zero added value. I sometimes remove such links but the response is often an immediate revert. Overlinking of solitary date elements is one of the silliest things in Wikipedia articles. I wish the guidance in the Manual of Style could be more explicit.

Date preference formatting deals with two issues with distinctly different priorities:

  • Ambiguity. Digit only dates can be misinterpreted. For example '6/2' could be 6 February or June 2. This cause miscommunication and so for any solution is a 'requirement'.
  • Style. Word dates cannot be misinterpreted but some people prefer certain formats. For example some people like '6 Feb 1802' and others like 'Feb 6, 1802'. I could live with a Wikipedia that did not modify word based dates. I am sure that others could too. But for some people it seems important. It is a 'nice to have'.

Please see a discussion that I raised a while back in Wikipedia:Village pump (proposals)/Archive involving users such as Tim Starling, Thryduulf and Cyrius. Bobblewik 18:10, 26 September 2005 (UTC)[reply]

ISO 8601 (yyyy-mm-dd) is unambiguous and is an international standard. It's been used for almost two decades on usenet and no one has any problem with misinterpreting or understanding it. New users quickly learn the simple, logical, unambiguous format. There's no ambiguity with 2005-06-02 because it's an international standard. One encounters unnecessary additional complexities by introducing ambiguities, instead of just using the simple, international standard already in place worldwide. Using ISO 8601, instead of a plethora of arbitrary formats and personal nuances, will eliminate a significant portion of problems in automation. It's also the only choice that's indiscriminate to any particular group, because it's already an international standard. --Simian, 2005-09-28, 01:07 Z
It is a standard. But it is not a standard that applies to usage such as Wikipedia display of dates. Gene Nygaard 02:50, 28 September 2005 (UTC)[reply]

Numbers in words

This is quite a complicated topic that would need extensive discussion here. Setting guidelines on this matter would require much discussion on elaboration on many exceptions - See http://webster.commnet.edu/grammar/numbers.htm for an example. I think any guidelines should be as simple as possible with as few exceptions as possible. Zero to ten suits me fine, and there are still plenty of exceptions within that. --JimWae 20:00, 25 September 2005 (UTC)[reply]

User:Babajobu started a discussion of this at Wikipedia:Village pump (policy), now basically dormant, which should be moved here, or at a minimum summarized here. Gene Nygaard 20:09, 25 September 2005 (UTC)[reply]
Summary is that there was a lot of resistance to a guideline suggesting that numbers under one hundred be spelled out in non-scientific articles. I had thought that book style, with the general rule of spelling out these numbers, would be more appropriate for Wikipedia than newspaper style, in which only numbers under ten spelled out. But it seems that there are more Wikipedians for newspaper style than for book style. One thing that's clear from the Village pump discussion is that any guideline must emphasize the distinction between counting numbers and numbers in measurements. Babajobu 20:40, 25 September 2005 (UTC)[reply]
Wikipedia is a co-operative (more or less) project among people with different styles. A single person, or a group with a clear line of command, can decide which elements from Chicago they want to use & be consistent without needing to endlessly enforce it (those projects come to an end - whereas wikipedia apparently never does). There will never be a permanent consensus to accept any guidelines like this that are not already nearly-universally recognized. Keep all guidelines simple & widespread & easy to follow. --JimWae 20:47, 25 September 2005 (UTC)[reply]
I feel like this discussion is basically a solution looking for a problem. Does anyone really care if I write ninety-eight or 98? (Obviously they do, I was just being rhetorical.) Chuck 17:47, 26 September 2005 (UTC)[reply]
As you suggest, plenty of people do care. Some people criticise digit format because it is not 'proper' style according to whichever styleguide they prefer. However, nobody has yet suggested that digit format reduces comprehension. In the case of references to centuries (e.g. 7th century), digit format is the default.
Digit format for centuries is the default on Wikipedia, not elsewhere. Babajobu 14:38, 27 September 2005 (UTC)[reply]
Google "20th century" 70,400,000 hits
"twentieth century" 38,100,000 hits
Gene Nygaard 15:12, 27 September 2005 (UTC)[reply]
Good style is not an internet popularity contest. Babajobu 16:19, 27 September 2005 (UTC)[reply]
It is also a matter of language independence. Digit format is more language independent and that is important to Wikipedia which, unlike many publications, is an online international resource. Native readers of any individual language in Wikipedia should be prepared to accept a little style unfamiliarity in exchange for greater access to non-native readers of that language. Bobblewik 09:50, 27 September 2005 (UTC)[reply]

I didn't know there was an on-going discussion about this. I changed the 16th to 21st centuries to number in words format. Phil objected on my talk page. Uncle Ed 16:33, 28 September 2005 (UTC)[reply]

Well, this really depends on the context doesn't it? For example, as someone else pointed out, 10th century is the more common form for history, but Tenth Amendment to the United States Constitution is the prefered form for amendments. You really have to bring a sense of the cultures and/or subcultures being represented by any page to Wikipedia, and since numbers are so primative to most cultures, I'm not sure that you can resonably make a blanket rule. I would propose the following guideline:
  • In reference to a specific historical event, date or fact, use the convention that is most commonly applied.
  • In reference to mathematics or measurement use digits (e.g. "1+1=2" not "one + one = two" and "20 meters", not "twenty meters").
  • When a link is required, and the link has digits, don't "pipe" the link to re-name it (e.g. not [[10th century|tenth century]]).
  • If a number has a fractional or decimal component express it as digits (e.g. "3.141" not "three point one four one") except where traditional usage is spelled out (e.g. "half & half cream" not "1/2 & 1/2 cream").
  • For 100 or greater, always use digits.
  • For 10 or greater, use digits when specifically refering to the number itself (e.g. "after 22 comes 23") or when a seqence of three or more numbers is required (e.g. "we skipped 50, 51, 52, and 53").
  • When cultural context demands digits or words, use what is appropriate.
  • In all other cases, use words.
Seem reasonable? I think this ends up meaning roughly the same thing, but with obvious exceptions that are common usage accounted for. -Harmil 13:46, 6 October 2005 (UTC)[reply]

Currency

Following on from an archived discussion on currency conventions, I'm hoping to nail down some specifics on dealing with currency: comments are welcome at Wikipedia:Naming conventions (currency). Ziggurat 02:17, 28 September 2005 (UTC)[reply]

Units of mass in precious stones

(Discussion moved from Talk:Diamond)

I think the article will be improved by having specialist weight units (carats) supplemented with non-specialist weight units (grams). I made edits to that effect but the article was reverted to remove gram values. See: http://en.wikipedia.org/w/index.php?title=Diamond&diff=24265758&oldid=24260125

This topic was discussed previously at:http://en.wikipedia.org/wiki/User_talk:Bobblewik/units_of_mass#Units_of_mass_in_precious_stones Perhaps we have drifted apart from what was said in that discussion. I would like to find a solution. Can we go through it again please? Bobblewik 23:07, 28 September 2005 (UTC)[reply]

Aside from the simple fact that diamonds are not sold by the gram, converting every carat value to grams does (IMO) impede the flow of the article. The very first mention of "carat" in this article is both wikified and its value converted into kilograms; this gives a clear indication that it is a unit of mass, and if further explanation is necessary, the reader can click through to the carat article. Furthermore, the Diamond#Carat section gives an in-depth explanation.
As for the "specialist" nature of the carat: it's now common for would-be gem purchasers to do a little research before buying, and the term carat has long since entered the lexicon of the general public. It's used in advertisements, TV shows, mainstream movies, and literature. Most jewellery stores (e.g., Peoples, Birks) have informative posters and signs next to display cases to educate the unfamiliar, of which there are increasingly few. As you yourself said in the May 2005 discussion linked to above: "When I first discovered that the carat was simply 200 mg, I was astonished that it was so simple a conversion." (Emphasis mine.) A simple conversion needn't be invoked each and every time. I don't know where in the world you are, but consider that a great many Americans (who make up a sizeable fraction of our readership) are unfamiliar with the gram itself, but that doesn't mean we should convert every g/kg value to ounces and pounds. I think the article is fine as it is. -- Hadal 03:48, 29 September 2005 (UTC)[reply]
I pretty much totally agree with Hadal; the conversion is informative the first time it is made, and useful in situations where bulk mining data are mentioned, but beyond that it is pedantic and interferes with the flow, without adding anything. This is not like giving the height of mountains, where the conversion is useful every time; it is more like giving the translation of a foreign name. Our article on Japan, for example, notes that natives actually call it Nippon, but doesn't then go use the construction "Japan (Nippon)..." every time the word Japan is used. - Bantman 18:50, 29 September 2005 (UTC)[reply]

Times

We've already standardised date format. It seems to me strange that any time format is allowed given that it is 24-hour, and, furthermore, that the manual actually specifically says not to edit an article just to change the time format (which, as you could probably tell, was exactly what I was about to do).

Like dates, there are lots of different time formats. And like dates, it would be better if they were all the same. I don't know about regional formats though.

Anyway, there are two things in time formats that annoy me when I see them, and I'd be very surprised if others here disagreed with me:

  1. When people write 3.25. Times don't use dots, I thought — it was always meant to be a colon, like 3:25.
  2. Inconsistency in using AM and am and a.m. and A.M.. I know the manual says to avoid 12-hour times (a principle which I oppose), but anyway, this inconsistency is blatant (unlike numbers as words). So this should be standardised. Personally, I prefer lowercase. Don't mind about dots, as long as it's consistant.

There is of course one other thing, that is the thing about 12-hour and 24-hour clock which I understand is very controversial and probably won't gain consensus, though if anyone is like me and wants it to be 12-hour in prose (not technical or tables), please drop a word.

Any thoughts? (If I don't post something for ages it means I've been caught up elsewhere, I'll try and check here as often as I can) Neonumbers 08:47, 3 October 2005 (UTC)[reply]

I have a brilliant idea. Let's create a robust template to handle times. Something that would take a time and zone parameter. For example, an instantiation could look like: {{time|2:17 PM|EST}}, which would output 2:17 PM EST (19:17 UTC). I don't know how hard it would be to do that, but the PHP code to convert the times and uniformly case the PM/AM would be incredibly simple. We could then use a bot to snarf up all the times and formatthem uniformly. Local time zones in which 24-hour clocks are preferred would display 24-hour time, and time zones in which 12-hour clocks are preferred would do that, but the UTC time would always print. If a time zone is unknown, the editor can pass LOCAL as the parameter, and the 24- or 12-hour format will be preserved. --Mm35173 19:06, 11 October 2005 (UTC)[reply]
Nice idea, but I'm sceptical about its feasibility — the date convention (I know it's being debated) has worked well for a while now; I very rarely see a date that hasn't been correctly formatted. So I don't think a template's the solution in this case because it's a number format and I highly doubt a template would become common use.
My concern is that the current guideline is a non-guideline and, like dates, times should follow a consistent format. This is one of those things you can flip a coin for — it doesn't matter that much so long as they're all the same (but I don't actually want to pick one completely at random).
If I were to suggest that the format (say) 3:45 p.m., 12 noon, 12 midnight, 12:34:56 a.m. for 12-hour and 23:45, 13:42:36 for 24-hour be standardised, wouldn't that be useful for a manual of style? Neonumbers 06:48, 14 October 2005 (UTC)[reply]
Tell me, Mm35173, if somebody is trying to show that when an event took place, the streets in that residential neighborhood were quiet because it was 4 o'clock in the morning, local time, exactly what good would it do me to know only what time that was in my time zone? Or what time that was in UTC? Or both? Maybe the idea isn't so brilliant after all. Gene Nygaard 16:13, 14 October 2005 (UTC)[reply]
To partially answer my own question, I suppose we could change your "unknown" to "either unknown or the local time is the relevant time", but who are we going to get to even read the instructions on how do it by the time we add all the possibilities, let alone follow those instructions. Gene Nygaard 16:20, 14 October 2005 (UTC)[reply]
Maybe if I keep at it long enough, I'll get to my real point. The notion that there are "Local time zones in which 24-hour clocks are preferred" is what really has me buffaloed, and it is whatever you might come up with for a replacement for that wording that is likely to be the greatest complicating factor by far. Gene Nygaard 16:24, 14 October 2005 (UTC)[reply]

Proposed Currency Section

Following on from the page on currency style - Wikipedia: Naming conventions (currency) - I'd like comments on this proposed section, to be added to the end of the page:

For currency, use the appropriate symbol (before the quantity) or name of the currency unit (after the quantity), for example:

  • "$100" or "100 dollars" not "100$"
  • "€100" or "100 euros"
  • "¥100" or "100 yen"

For national articles or those where the type of currency is unambiguous it is not necessary to denote which currency unit is being used. However, it is necessary to indicate the nationality of currencies in internationally oriented articles or articles referring to more than one currency of the same name. This is done to avoid confusion and potential ethnocentrism. For example, "US$100" or "100 U. S. dollars" (not "100 US$", "$100 (US)", or "USD 100"); "A$100" or "100 Australian dollars."

Standard abbreviations are given at the article on the currency, for example:

We need a guideline, but I'm not happy about the automatic dismissal of the ISO 4217 codes which are the only unambiguous method we've got for indicating currencies. B$ = Bahamas, Barbados, Belize, Bolivia or Brunei? Are formulations such as "USD $100", "$333 (CAD)", or "MXN $250" really unacceptable? Let's explore all the available alternatives. –Hajor 00:58, 4 October 2005 (UTC)[reply]
I'm happy to explore the alternatives, that's what the talk page is for! :-) I'm suggesting this method as
  • the most common standard in current Wikipedia articles
  • the most common standard in international newspapers (Guardian, Times)
  • the World Bank standard
  • the 'cleanest' technique
That said, I have no objections to the alternative styles you list; if we're going for a standard-to-all-articles style I still favour my proposed technique, but if we're going for an article-consistent style instead they're fine.
Ziggurat 01:20, 4 October 2005 (UTC)[reply]
In full support for the existence of this, for standard-to-all-articles. That said...
  • I thought €, by convention, was written after the number, e.g. 45€, and for decimals e.g. 44€99. Or is this just regional differences? I don't know for sure, but that's what I thought so I thought I'd bring it up, feel free to correct me.
  • I prefer US$ to USD, because it's in more widespread use. "USD", like many other international "standards" (like SI units, for example) should only be used in specialised or technical contexts.
  • There is a major downside to using lots of different forms, that is that it looks messy; even if they are consistent within the article, their inconsistency within the encyclopedia degrades the encyclopedia's appearance.
  • I don't want to halt the exploration of alternatives before it's happened, but things like $333 (CAD) and all the other ones are, well, shall we say I've never before seen that format in my life.
And, I have a suggestion:
  • Generally, use the US$ format. If there is risk of confusion with one currency only (like B$), specify at the top of the article in italics ("In this article, B$ refers to Bahamas dollars"). In certain contexts, it may be better to use the USD format; if this is chosen it must be applied to the entire page and the first appearance of each must be linked to the appropriate page.
By certain contexts, well, I don't really know what I mean, I guess I mean in tables where there are lots of different currencies at it's completely unrealistic to specify each one so therefore we turn to our unambiguous standard. Also, in specialised articles that require it, but I don't know what articles would as I have no expertise whatsoever of the area. But anyway, in normal prose USD should be avoided because US$ is more common and understood.
Just to clarify myself, I don't see this as a compromise between standard and non-standard, I am completely against pitiful compromises on manuals of style because it is compromises that make them fail. This suggestion is what I think is best for good style with what I know at present (which may be very little). Neonumbers 10:16, 4 October 2005 (UTC)[reply]

Interesting replies. Has anyone got a link for those codes as used by the World Bank? Googling for "currency codes" on site worldbank.org only gives me results that use ISO 4217. I actually suspect there isn't a canonical list of those codes that covers all the world's currencies, and that once you get past the better known dollars, most of them seem to be pretty ad hoc.

Which leads into my next comment. What's been said so far has mostly focused on dollars, pounds, yen, and euros. And I rather suspect that's the case with the two style guides (Times and Guardian) -- they're very centered on the northern industrial world. If the aim here is to set a global standard (gulp), then we need to consider the full range of world currencies -- dollars and pounds, sure; but francs and lempiras and dinars and rupees, too. Cast the net a whole lot wider.

On reflection, perhaps this is something that needs to be taken on a case-by-case basis. Maybe I wasn't casting my net wide enough, either. Those examples I gave above really only work well with currencies that use the £ or $ signs (does anyone else use ¥ besides the Japanese?). For instance, saying

doesn't sound too bad, but it would be frankly bizarre to say

Much better in those cases to use "...costs L.E.0.75" or "costs GTQ 3.50."

(One downside of the ISO Codes is that the standard recommends they be used without $, £, etc, but that's very difficult to do in everyday texts such as these encyclopedia articles -- it feels very unnatural, counterintuitive to write a dollar amount without including the dollar sign.)

Another alternative -- we are a wiki, after all -- would be to use neither system of code and simply to rely on a link to the currency from the symbol to make it clear what we're talking about: $100, £100, ₪100. That would make the text flow more neatly, but it would have one major drawback: including the ISO 4217 three-letter code makes it crystal clear whether you're talking about ARS or ARP pesos, RUR or RUB rubles, MXP or MXN pesos, ALL or ALK leks, etc. That's lost if we just use the naked symbol, without the ISO clarification.

One thing I don't like about those US$, Z$, RD$, codes is they don't always distinguish between the marker that's used in the country (such as Brazil's R$) and the combination of the domestic marker and additional identifier (such as US$, C$, etc.), in the sense that that's not what's printed on the banknotes or what people write on their checks -- ie, for international consumption only. Thus: the Eastern Caribbean Central Bank's officially sanctioned symbol for the East Caribbean dollar is "$". EC$ is just some form of disambiguation they use internationally to avoid confusion. Also, from an aesthetic point of view, some of them -- even govt. sanctioned ones, such as Barbados's "Bds$" -- are frankly hieroglyphic.

Sorry -- came out a bit rambling, the above. Essential summary: US$, A$, etc. are good (and internationally recognized) for disambiguating one dollar from another, but the system breaks down once you're past that first group of familiar currencies: Is there one for the Uruguayan peso? Is a similar set of symbols used with the pound sign? (I couldn't think of any xx£ examples.) ISO codes are utterly unambiguous but -- as noted above -- not that familiar to non-specialists not accustomed to the world's more arcane currencies and (as also noted) not that easy to work into a grammatically flowing sentence. It may very well be that one system is appropriate for the world's most familiar currency, but not right for the kwanzas and the like that no one's ever heard of. Let's discuss this some more. –Hajor 15:14, 4 October 2005 (UTC)[reply]

Some of the proposals above look really bizarre to me: USD $100, $333 (CAD), MXN $250, $250 (CLP), EGP L.E.0.75, GTQ Q3.50. They double up the name or even give a wrong name (like mixing $ and peso). Written as USD 100, MXN 250, CLP 250, EGP 0.75, GTQ 3.50 they would make perfect sense. This is the form described by the ISO 4217 standard. −Woodstone 20:32, 4 October 2005 (UTC)[reply]
The World Bank standard (pdf) says US$ or U. S. dollars, but for all other currencies suggests that you should "consult Lotus notes" for the accepted abbreviation, whatever that is. Regarding this: "the Eastern Caribbean Central Bank's officially sanctioned symbol for the East Caribbean dollar is "$". EC$ is just some form of disambiguation they use internationally to avoid confusion. " New Zealand is the same; $ is the symbol here (of course) and NZ$ is appended when talking internationally. Ziggurat 20:41, 4 October 2005 (UTC)[reply]
You're right about the standard prescribing "USD 100" etc (without the symbol) but, as I noted above (and I quite understand if you missed it), it's very difficult to get lay writers, in lay contexts, to overcome the urge to indicate a dollar amount with a dollar sign. Problem with (eg) "AUD 100" is, outside a specialised context, it's not intuitively a currency amount. Hence the "doubling up". Of course, that may very well be the best argument against using the ISO codes at all. Or one in favour of "CAD 100" on first use, $100" on second, and "$100" subsequently.
Re "mixing $ and peso" -- $ is the symbol used by all the world's pesos, plus a couple of others (the boliviano and the real, for instance). Yeah, our dollar-, pound-, and euro-wielding editors might not be aware of that, but protecting them from having their horizons involuntarily expanded doesn't seem to be a good reason to deprecate standard local use. –Hajor 21:02, 4 October 2005 (UTC)[reply]
Furthermore, it was a peso sign before it was a dollar sign. Gene Nygaard 16:15, 6 October 2005 (UTC)[reply]
I wonder if a full reliance on links (e.g. $100) would be such a good idea — it's still an encyclopedia, and you can't really see links once you print the article (with a printer).
That aside, I'd like to just resuggest my earlier suggestion, because I didn't read anything about it: where necessary, put "In this article, NZ$ refers to the New Zealand dollar" at the top of the article except obviously not with New Zealand because that's unambiguous and therefore unneccessary. Only where necessary.
I think that that would be a good solution because it removes ambiguity without sacrificing understandability. Like I said before, it won't work where there's lots of currencies on the same page, in that case use those ISO codes no-one knows about. If there's really so many currencies it's better to revert to ISO codes, then I figure it'll probably be techincal/specialised anyway.
Of course, I don't claim by any means to be a currency expert, so if that's the stupidest solution ever please say so and explain why. But my point: ISO codes are not ideal and while their are plenty of situations where they'd be of good use, in articles where only one or two currencies are referred to I make my suggestion (as above). Neonumbers 07:00, 6 October 2005 (UTC)[reply]
Actually, as far as I know, ISO 4217 does not prescribe USD 100, MXN 250 etc, but 100 USD, 250 MXN etc. I would myself never hesitate about writing "100 USD" or "800 SEK" or the likes in an article. Maybe it's because I'm European and we are more used to international standards than Americans are, I don't know, but I really can't see how anyone, anyone, can read "100 USD" and not immediately think "a hundred US dollars". I feel really strongly that if a common currency symbol (most often $) is used throughout an article to mean the same currency, then say so at the top if it's not obvious, and that's fine, but never ever use the $ symbol if the context needs disambiguation. I don't like US$, and I certainly don't like "$100 USD" which clearly means "a hundred dollars US dollars". And we need the ISO codes for non-dollar currencies anyway. There are for instance at least seven countries sharing the currency name "krona", so the "100 yen" trick won't work here, and there's no symbol to denote it.
As I see it, the only reasonable alternative to the ISO codes, when there are several currencies involved in the same article, is writing out the entire currency each time. "There was a transfer of 800,000 Swedish kronor (roughly 100,000 US dollars) to the establishment, which added an additional 50,000 Euros." Something like that. But I think that's unnecessarily obtuse. Use the ISO code, and link it to the currency. Anyone will understand USD and EUR right away, and if someone is dumbfounded by SEK, he can just hover over the link. (This has the additional benefit of not having to use "kronor", a Swedish plural, in English, or contemplate translating it to "crowns".) -- Jao 07:53, 6 October 2005 (UTC)[reply]
I prefer US$125 in most situations, linked on first occurrence.
I find 125 USD acceptable in some situations.
For an isolated occurance, 125 United States dollars is okay.
I hate £3.75bn for £3,750,000,000 or A$1.45m for A$1,450,000.
Even worse is Rs 2.5 crores for Rs 25,000,000, or Rs 47 lakhs for Rs 4,700,000. Gene Nygaard 16:52, 6 October 2005 (UTC)[reply]
We appear to have run out of steam without reaching anything close to consensus. Does anyone want to try a watered-down proposal for language to include: perhaps Gene's first line for "familiar" currencies and his second line for "unfamiliar" ones (except there'd be a large grey area where "familiar" is inherently tinged by geographical bias and hence POV). Or should we continue to take matters in each article on a case-by-case basis? One guideline that should be included, and one on which I imagine consensus would be a given, is the use of lower-case letters for currencies: euros and francs, not Dollars and Rupees. –Hajor 16:44, 11 October 2005 (UTC)[reply]

Skatebiker 07:35, 12 October 2005 (UTC) I think that using currency can be rather relaxed by e.g. using lower case names, ISO 4217 three letter codes, but e.g. US$ 100 os OK as well. But Z$ can be confusing, use rather ZW$ for Zimbabwe dollar.[reply]

Non-base ten numbers

128.186.24.87 changed the non-base ten numbers section recently, to spell out the bases, thus 2345six rather than 23456. Last time I checked mathematical convention was to use the number form 23456, which is how it was before. I could not find a discussion on this change (there was one to introduce the section, I was part of it); if there was one, do tell me. This user noted only that it "made more sense", not that it was proper convention. What is normal convention for showing bases? Neonumbers 22:21, 6 October 2005 (UTC)[reply]

I doubt that there is a uniform, consistent style used for this.
Some people apparently don't like using base ten numerals to specify the base; it seems to me that our words for numbers are at least as base-ten dependent as the base-ten numerals, and I'd even argue more so.

Skatebiker 07:35, 12 October 2005 (UTC): Another proposal is to standardize the extra digits required for bases greater than ten. Using e.g. T and E for ten, eleven for duodecimal and A and B for the same numerals in hexadecimal is confusing. I propose the digit set 0123456789 ABCDEFGHJK LMNPQRSTUV WXYZ (omitting the 'I' and 'O' preventing confusion with '1' and '0', possibly the 'S' might be omitted as well for the '5') which covers all bases up till 34.[reply]

I cannot imagine that there would be enough use of duodecimal numbers on Wikipedia to worry about any perception of inconsistency. Battle it out on the couple of articles which might discuss them.
It doesn't usually matter for integer bases less than 10; if there is some reason to use other symbols, that can be explained when they are used.
The only bases greater than 16 that are likely to be of encyclopedic interest are vigesimal (Mayan numbers) and sexagesimal. You might be able to find graphics of the Mayan glyphs consisting of bars and dots and a football-shaped shell for zero, but otherwise when they are written out, it is customary to use two-decimal digit representations of the vigesimal numbers, and the same is nearly universal for representation of sexagesimal numbers (witness the common sexagesimal fractions of a degree used in latitude and longitude). These are usually separated by a dot or a colon or some other symbol such as the prime and double prime or superscript Roman numerals or written in columns, so that the digit-pairs are clear. I don't see any real need for single-character representations of anything in higher bases than hexadecimal numbers. Gene Nygaard 18:25, 12 October 2005 (UTC)[reply]
The format I last discussed is what is used at Maya calendar for the vigesimal numbers—not strictly vigesimal, either, but three digits for a vigesimal count of tun (years of 360 decimal days) and two digits for the count of the days in that tun: "The Long Count started at 13.0.0.0.0 on Julian day 584283", etc. Gene Nygaard 18:36, 12 October 2005 (UTC)[reply]

talk page oddity

I notice that there is no article/project associated with the talk page Wikipedia talk:Naming conventions (calendar dates). When I go to that talk page, and click the "project page" tab, I'm redirected to Wikipedia:Manual of Style (dates and numbers).

I find this confusing. Should we somehow merge the 2 talk pages associated with that single project page? --DavidCary 15:46, 8 October 2005 (UTC)[reply]

More about overlinking of dates

There was a recent discussion (Wikipedia_talk:Manual_of_Style_(dates_and_numbers)#Dates_linking_convention_currently_ludicrous) about overlinking date elements. Just in case people did not read the references to a proposed solution, below is a quote from: Village pump archive:

I support this proposal. I agree that linking to dates is a generally cause of over-linkink. i think thjat shuch links, as links, are usually pointless, and should be removed if there were to be another way to apply date preference formmatting. I also think that most links to partial dates (D/month without year, or year alone) are already pointles, and i have started to remove them when I edit articles that have such links, although i don't go looking for them.
I have no idea if the proposal is technically hard or easy. I find it hard to belive that it is impossible. Note that instead of _10 Jan 2005_ we could have #Date(10 Jan 2005) if that were technically easier to implent. DES 22:07, 31 May 2005 (UTC)[reply]
There's no need for special syntax, the software can recognise dates in plain text. -- Tim Starling 09:35, Jun 1, 2005 (UTC)
That would be much simpler if implemented! I presume that on occasions (such as this) where we want to see a specific format not altered by preference then putting the date in nowiki tags would allow that? (i.e. 01 June 2005 would appear as per your preference and <nowiki>01 June 2005</nowiki> would always appear that way). Thryduulf 12:50, 1 Jun 2005 (UTC)
Does anybody know how to implement this? Bobblewik 13:38, 6 August 2005 (UTC)[reply]
I think the first step will be to put a feature request on bugzilla. Outside of that, I'll point any of the developers at the discussion if I happen to see them later. Thryduulf 09:54, 7 August 2005 (UTC)[reply]

I tried getting into bugzilla but failed. I would be grateful if somebody else make the request. Bobblewik 16:11, 9 October 2005 (UTC)[reply]

Number notation

Skatebiker 07:48, 12 October 2005 (UTC): In the Number notation section of Wikipedia one is encouraged to write large numbers to split up the digits in groups by three separated by commas. This is against the ISO 31 rule and, moreover, ambiguous in many cases as the comma can be used as a decimal point. Why does Wikipedia not observe the ISO standard ? I propose to change the guideline to avoid writing large numbers with commas (or dots) separating groups of three digits. This is ambiguous particularly for numbers under 1 million. E.g. 123,456 can be interpreted as hundred twentythree point/comma four five six or hundred twentythree thousand four hundred fivty six which is comfusing. ISO 31 advises using spaces (preferably thin spaces HTML : &thinsp;) instead. Commas or points in numbers should only be used as a decimal separator between integer and fraction part.[reply]

Moreover using scientific notation writing the exponent notation as usual in computer output or calculator display. This is easier readable. E.g. 5.67e-8 reads easier and takes less space than 5.67×10-8. So that I propose in the guidelines as well.

  • I agree totally. I came here looking for a reason why the style guide deliberately contravenes ISO 31. As wikipedia is truly international, that doesn't make sense to me. I will welcome your change Yaf201 13:59, 12 October 2005 (UTC)[reply]
The ISO standard is widely ignored, and its use is almost always considered unusual in many countries. I notice, for example, that the English and Japanese Wikipedias tend to use commas but also a mix of the other forms to a lesser extent; German, Dutch (Netherlands), Italian and Spanish use dots, French, Polish, Bulgarian, and Swedish use spaces. Portuguese uses a mix of dots and spaces, and more often than others will also tend to just show large numbers with no spacing. This information was gathered by looking at the front page and searching for "yen" and "giga" on each site. For some, I had to poke around to find more examples to confirm common usage. The point here is that stomping on common usage in favor of a standard, no matter how prestigious the standards body, is not what Wikipedia is about. If it were, we'd also exclude the use of words that are not listed in the OED.... I suggest that we simply try to make sure that within an article, there is a consistent usage that is appropriate for the subject. If you're discussing SI units, then it makes sense to use ISO numbers, but if you're discussing a topic relating to the English-speaking countries that use commas, I don't see why you would use anything but commas. -Harmil 16:28, 12 October 2005 (UTC)[reply]
That ISO 31 standard has not achieved much of a following in general usage outside Wikipedia, so there is no particular reason why Wikipedia to follow it. Can you cite particular style guides which might prescribe it for general use, or certain publications which do in fact follow this rule?
Part of the problem is that the standard itself, by its own terms, deals specifically with usage in connection the International System of Units (with maybe a few non-SI natural units and things like that; it doesn't deal with usage of English units, for example). It isn't presented as a general rule. It can be emulated in other usage, but the standard technically doesn't apply to any usage outside SI. Nobody looks to this standard for the expression of monetary units, or for the expression of population counts, for example.
However, using that format with SI units and not with other units (something occasionally seen in Wikipedia and elsewhere) is downright silly.
I wouldn't want to be the one responsible for making all the changes if were were to change the policy to require spaces.
When that format is used, the spaces should be non-breaking spaces. But that has rarely been done on those fairly rare occasions when that format has been used on Wikipedia. This is more important than any "thin-space" recommendation, for a character whose existence most editors aren't even aware of (and one still, I think, not well implemented in at least one of the major browsers, a problem which has been discussed in the past, resulting in spaces bigger than a normal space). There are also separate "thin space" and "non-breaking thin space" characters in Unicode, IIRC, but at least in the browser in which thin space works for me, the &thinsp; representation of this character is interpreted in a nonbreaking way.
A thin space, and even a normal-sized nonbreaking space, make editing difficult, because these characters are not normally available on our keyboards. They are also not available in the character list which now appears at the bottom of English Wikipedia edit pages (something that is also clumsy for more that isolated use of any of these characters).
There isn't that much ambiguity in the usage within the English language. Most of our problems with it come in edits by non-native English speakers, or more so by rough translations from some foreign-language source (including other Wikipedias). Similarly, there are problems with unconventional division not into thousands but into curious numbers called lakhs and crores by editors from India.
I don't like the second proposal, and think we should discourage the use of that exponents with "e" or "E" format. It may indeed be more familiar to computer geeks, but there are also many people taught in the old school, and the 10n is more recognizable to most computer geeks than the "e" notation is to people not brought up with that usage. The E works fine for computer languages using ASCII character set without superscripts and subscripts (and only a couple of those superscripts as characters, none negative, in various extensions of ASCII). I would like to see more use of the engineering notation variant, with exponents divisible by 3, but wouldn't want it as a guideline for general use to the exclusion of the one digit before the decimal point type of scientific notation. Gene Nygaard 17:08, 12 October 2005 (UTC)[reply]

The ISO 31 number standard is the normal standard in South Africa. Although the comma is widely used as the decimal separator, the point is readily recognised and never assummed to be a thousands separator. Using spaces instead of commas for thousands separators is instantly recognisable in all languages, including all variations of English. If wikipedia is going to deliberatly encourage the use of commas instead of spaces as thousands separators, the style guide should say why and accept the potential for ambiguity.
99 999 and 99.999 are unambiguous; 99,999 is not and should, in my opinion, be avoided. Strict adherence to ISO 31 would allow use of the comma as a decimal separator. I would suggest that, because of its different meanings in different countries, wikipedia style guide should deviate from ISO 31 by discouraging use of the comma in English language articles.

I also am not keen on the second proposal. I think the 10n format is more recognisable, but that is my subjective view. --Yaf201 08:56, 13 October 2005 (UTC)[reply]

Strict observation of ISO 31 is not what I propose but just the writing of large numbers separated by commas or points is what I discourage. This spaces is a strict option from ISO31 but &nbsp; or normal spaces is also OK and even no separation at all for not too large numbers (e.g. under a million). So I'd rather write The distance of the Moon is 384400 km. 384.400 km or 384,400 km appears to be in a low Earth orbit.
I agree here not te prescribe use of commas as the decimal sign in Engligh language articles. Skatebiker 09:42, 13 October 2005 (UTC)[reply]
That 99.999 is no more unambiguous than 99,999 is; many people do use the dot as a thousands separator, and I have changed numerous Wikipedia articles which have done so. Yet as I write this, you can still find it in hundreds of articles such as Aircraft carrier and Swisstopo and La Pampa Province. It's just that you are less likely to see 99.999 for 105 − 1 in English by primary English speakers than you are in some other languages such as German, but we often import information from languages using that convention into Wikipedia, or have it added by users more familiar with some other language. Gene Nygaard 22:11, 13 October 2005 (UTC)[reply]

My first attempt at using a non-breaking space failed and my example above had 99 at the end of one line and 999 at the beginning of another. So I ditched &nbsp; and instead used &#160; I copied this from a well known web page ie www.wikipedia.org!!!! It's a pity there isn't an easier way of putting this in on my keyboard. A space is not the ideal option for separating groups of digits, but it's much better than a comma or a dot Yaf201 11:49, 13 October 2005 (UTC)[reply]

I agree with Skatebiker and Yaf201 that the Manual of Style (MoS) definitely should not be encouraging diametric violation of ISO 31. Because the comma is widely used as the decimal point outside the USA, it should not be recommended as a thousands separator in Wikipedia MoS. Note that using a thousands separator is entirely optional (ISO 31-0, Sect. 3.3.1; BIPM, SI brochure, Sect. A1.4.2), and if used, is never applied to numbers having only four digits (NIST SP811, Sect. 11.11) unless aligning a column of numbers. Therefore, one can use either a space character or no thousands separator at all, but not a comma nor a dot. This mistake indeed needs to be corrected in the MoS and changed to something like the following. "A space character (regular space, &nbsp, or &thinsp) can be used as a thousands separator to separate groups of three digits, if desired, though this is not required. But a comma character should not be used as a thousands separator (because the comma is widely used as the decimal sign outside the USA). Whether a space or no space is used as a thousands separator will depend on the situation at hand, but since a thousands separator is optional, omission often tends to be preferable." --Simian, 2005-10-13, 21:10 Z

I hear a lot of writers are following a standard called written English. Most literate educated English-speakers have never even heard of the European decimal comma, ISO recommendations, and engineering notation (apologies to our more versatile South African friends). Figures and other elements of encyclopedic text should be exactly what people expect them to be, and not make them change their point of reference just to read.
Spaces as separators in numerals don't work right, anyways:
  • Using regular spaces as separators makes numbers break at the end of a line, which is unacceptable.
  • Entering non-breaking spaces using &nbsp; make wikitext laborious to write and hard to read.
  • A Unicode non-breaking space character can be typed as option-space on a Mac keyboard, but some common browsers will silently convert it to a regular space during any subsequent edit.
  • Using a thin space is the best typographic style for European thousands separators, but the character isn't supported correctly by any font that comes with Windows, can't be typed easily, and &thinsp; in wikitext has the same disadvantages as &nbsp;.
Please don't enter numerals in European format. —Michael Z. 2005-10-14 01:38 Z
Don't think ISO 31 is a European format. It's an international standard, widely used in some of the USA text books for decades. Nonetheless, you make some excellent points regarding on-line thousands separators. At the same time, we shouldn't push an idiosyncratic local practice upon an international audience, in violation of the international standard widely used, including partially within USA. So I think we can agree, based on your comments, that since the thousands separator is entirely optional, both in ISO 31 and in USA practices locally, then the best option appears to be omission in most cases. Many text books and documents in USA already omit the thousands separator to no ill effect. Let's all agree to quit recommending in the MoS that commas be inserted; they aren't required in USA. --Simian, 2005-10-14, 02:48 Z

I think Simian's suggestion is the best compromise. The dot and the comma are not acceptable for thousands separators in an international forum (if Wikipedia were purely American or British it would be a different matter). The various forms of spaces have typogrphical problems, so I now think that thousands separators should be avoided altogether and the decimal separator can be either the dot or the comma depending on the preference of the writer and/or the regional practice of the area / country being written about.

In the UK, digits are not normally grouped after the decimal point, even if they are before it, so one would write 9,999,999.9999999 wheras in ISO format, this would be 9 999 999.999 999 9. So I see no problems in writing 9999999.9999999, although in real life that degree of precision is unlikely to be required, except in scientific and technical fields where ISO 31 will apply and scientific notation is likely to be used --Yaf201 08:58, 14 October 2005 (UTC)[reply]

Ok good idea, do discourage the commas and dots other than the decimal sign. The breaking spaces is indeed an issue as in 'normal' HTML text one can use <nobr>number_with_spaces</nobr> to prevent breakup at the end of a line but Wiki swallows these <nobr> HTML tags. Maybe an option to allow these tags again (not only for numbers but for all text to prevent the problem with &nbsp; &thinsp;. Anyway do not mandate the thousands separator. Skatebiker 09:18, 14 October 2005 (UTC)[reply]

The ISO standard being "widely used in some of the USA text books" is far from it being widely used. Saying "we shouldn't push an idiosyncratic local practice" about the standard English-language thousands separator is like saying we should reconsider our parochial use of the Latin alphabet. People who read English know what the thousands comma means, including South Africans according to the discussion above. They don't all know that a comma can also be a decimal point. The ISO notation is based on the normal number format of European languages, and it is different from the normal English-language form.
Writing 9999999.9999999 is a problem, because it is poor writing style. Quick: is that about ten million or a hundred million? If the reader can't determine the order of magnitude without using a finger to count digits on the screen, then the editor has failed.
It's also incorrect that four-digit numbers should never have a comma. They should have a comma when they're in a table column below twelve-digit numbers, for example. —Michael Z. 2005-10-14 10:50 Z
Writing 9999999.9999999 is a problem, because it is poor writing style. Quick: is that about ten million or a hundred million? If the reader can't determine the order of magnitude without using a finger to count digits on the screen, then the editor has failed.
That's a fair point, Michael. To be honest, I'd be unlikely to use this degree of precision and I'd write somthing like "nearly 10 million". If I needed to be this precise, it would almost certainly be in a technical or scientific article when the ISO format of 9 999 999.999 999 9 would be appropriate. Would you write 9,999,999.999,999,9? Yaf201 14:43, 14 October 2005 (UTC)[reply]
The separation after the decimal point is of little utility, and is almost never seen with commas. We are generally much more in the order of magnitude of the number, than we are in the precision to which it is expressed.
In other words, we want to be able to tell whether it falls into the "millions" category, or if it is "thousand millions" or "billions", whatever we want to call it. And when you get to bigger -illions, that's best left to the reader, who can tell either tell herself or himself that 9,999,999,999,999 is in the "billions" or that it is in the "trillions" range, whichever is familiar to that reader, something that isn't so easy if someone else who might have different understandings of those words has already done it.
OTOH, once we get to the decimal point, we read it either in our own minds or in speaking it out loud as "point digitname digitname digitname". and we don't care so much if the precision is down to the millionths or billionths or whatever. Gene Nygaard 15:16, 14 October 2005 (UTC)[reply]
Users Skatebiker and Yaf201 are using faulty logic in assuming that since there are occasions in which the separators can be omitted, and because omitting them doesn't change the value of the number, that omitting them is an acceptable writing style for all purposes. It most certainly is not.
Mzajac is also correct on his other point. Hardly anybody claims (I don't know if I've seen it other than the arguments of some in this section) that using separators in four-digit numbers is unacceptable. Oh, sure, some people do express that rule for specific types of numbers. One common one is not to use separators in calendar years less than 10,000. But nobody says that you should never use it with fourdigit numbers, and it is broader than tables where consistent usage is normally desirable.
One of the biggest problems with the spaces format is that it is almost always pushed as a part of the use of the International System of Units, and those pushing its use there often recognize that they have no real authority for usage outside that context.
But there are also many people who feel strongly that having different rules in that context than for other numbers such as population counts would be silly, so they quite justifiable stick with the normal rules and do not follow the rules some SI proponents would like them to follow.
Of course, if SI is actually used to full advantage, there would be very little opportunity to use thousands separators in the first place. Judicious choice of prefixes, or the use of scientific or engineering notation, generally avoids the need for them
So even if some technical journals follow this rule, few people are going to learn it because there is only limited actual use of it in a technical context. Therefore, it would logically (and does in fact) have minimal effect on general usage.
For example, if SI were used to full advantage, we would not see things like "The average distance from the Moon to the Earth is 384,403 kilometers" (Moon), but rather "384.403 Mm".
We wouldn't see "distance of about 80,000,000 km" (Mars), but rather "distance of about 80 Gm".
We wouldn't see "about 120,000 parsecs across" and "10,000,000 kelvins" (NGC 4555); instead, we'd see "about 4 Zm across" and "10 MK".
As you can see, people who have little use for the convention aren't really in a strong position to be urging it upon everyone else. Gene Nygaard 12:21, 14 October 2005 (UTC)[reply]
I agree regarding four-digit numbers when aligning a column of numbers; and I have now inserted, into my original sentence, the phrase "unless aligning a column of numbers" (highlighted in green).
Michael, SI has been the federal measurement system of USA since 1992. You keep erroneously implying that an arbitrary, nonpreferred system is somehow a preferred measurement system of "English-language" countries, which is not the case. SI is the preferred, federal measurement system of USA since actually 1988; and SI specifically forbids using the comma as a thousands separator. Therefore, using the comma certainly isn't the normal or preferred "English-language form" -- and the MoS is just plain wrong, and needs to be fixed. And you're incorrect in thinking SI (e.g., ISO 31) notation is a "European format." SI is used by all countries worldwide. It is the format preferred by USA since 1988. By no stretch of the imagination is SI a "European format." Also a few others herein implied that SI is somehow only for scientific applications, while some other system is for nonscientific applications. Please eradicate this gross misconception. SI applies to all facets of measurement. It became the federal measurement system of USA since 1992 for commerce, trade, business, and nonbusiness -- not just scientific applications.
Let's agree to quit recommending the wrong format in the MoS. It's not the correct nor preferred system. Where required, &nbsp works fine in the interim until we develop a wiki markup for thin space, keeping in mind that the thousands separator is entirely optional and should be used sparingly. Also, Gene Nygaard is correct in saying the thousands separator can be omitted to the right of a decimal point, keeping in mind that it's optional, as stated in SI by BIPM. --Simian, 2005-10-15, 18:40 Z

How are issues like these finally resolved? It appears there are 6 individuals contributing to this discussion. 3 who don't like the current MoS entry and would like to see something more international and 3 who prefer the status quo. That probably means that the vast majority of wikipedians don't care and will carry on doing their own thing. In that case, should this entry in the MoS just be deleted and we accept that there will be a variety of number styles used across wikipedia? The intro to the style guide says that wikipedians are not bound by the style guide. I, for one, will never use commas as thousands separators (nor as decimal separators in English, come to that), whatever the style guide says - to me it is just plain WRONG. And I suspect that Messrs Harmil, Nygaard and Mzajac will never use anything but UK/US format. Maybe an acceptance of diversity is what's needed? --Yaf201 12:49, 14 October 2005 (UTC)[reply]

Even if this does fall into Category:Stupid human tricks along with things like driving on the left side of the road, and writing from right to left, that's not enough in itself to change existing guidelines.
Just as Wales should not have some roads on which you drive of the left side and some on which you drive on the right side, and the English language should not have some situations in which we write from left to right and some in which we write from right to left, Wikipedia should strive for a minimum of consistency on this issue, not a free-for-all "acceptance of diversity". I'd accept spaces, had that been the standard from the beginning (and ISO and others were pushing that format long before Wikipedia ever existed, so it could have been). But that isn't the case, and there is insufficient justification to change the existing guidelines now, and lots of problems associated with making such a change now. Gene Nygaard 13:14, 14 October 2005 (UTC)[reply]
What problems would changing the guidelines cause? No one is proposing a full scale re-edit of articles just to change number formats. I certainly don't believe that changing the MoS to advise against use of the comma will prevent it being used in future - just as the current guidelines will not prevent me using spaces or avoiding thousands separators altogther. On reflection, I am more convinced that a descriptive approach to this issue would be better than a prescriptive approach. After all, most wikipedians are out there writing and editing articles rather than worrying about number formats. I only came here because I am the weird sort of person who decided to read the MoS before jumping in feet first. I couldn't understand why use of commas was advised and I still can't. "We've always done it that way" has never been a good reason to me. --Yaf201 14:16, 14 October 2005 (UTC)[reply]

A related problem is that many of the standards-setters such as CGPM and ISO are lost in their own little world, so out of touch with the real world, that they make no effort to reach out to those who actually set the standards for the style used in newspapers, books, and the like.

Furthermore, they had so little clout in the early days of computing that, even though they prescribed an international symbol for ohms, until Unicode was introduced and became fairly well established, most of us had no convient way to make this symbol Ω on our computers. Sure, many web pages used clumsy kludges, such as using graphics files for this symbol (but though the other letters were scalable, those weren't, often making things look funny). Actually, it goes back even further than that; they didn't have much more clout with those making daisy wheels for typewriters, either.

Another related problem is that these organizations often charge outragous prices for their standards, ensuring that they won't be bought by anyone outside of their captive audience of those required to do so because various governments have adopted those standards as applicable to a particular activity. They aren't going to be purchased, or followed, by those with only a casual interest in the subject. Gene Nygaard 12:58, 14 October 2005 (UTC)[reply]

I can't comment on the connection of CPGM and ISO with reality. But it seems to me that we're not going to hit consensus on the number format issue. So why not look at this issue another way? Should the MoS be prescriptive or descriptive? Should it aim to clarify by imposing rules for us to follow or to clarify by providing explanations of what we have done? If the MoS itself says that contributors are not bound by its contents, then I think it should be the latter. The number section could just describe the various number formats that the reader is likely to encounter on wikipedia? --Yaf201 13:13, 14 October 2005 (UTC)[reply]

Skatebiker 08:24, 15 October 2005 (UTC):[reply]
Then I have a completely different idea. For each user logged in one can set preferences like skin, timezone, etc. So why not number format ? As Wikipedia is virtually completely script driven on PHP (therefore 'wikifies' the content which is edited by the user) it is therefore possible to 'wikify' numbers to the user's preferred number format as e.g. '''bold text''' 'wikifies' to bold text. Simple PHP regular expressions functions like preg_replace() do the job.
A number like 9,999,999,999.9999 will be 'translated' into the user's preferred format. But in numbers containing a single point or comma like 2,005 is may not work.

year zero

I suppose I open an old wound here, but I'm not going to search through 27 archives. Maybe there should (also) be a single index to all the archives. Anyway...

I'm abhorred. Wikipedia does not use a year zero? I know that that causes a problem with old dates because the Romans didn't yet know about the zero. But there have been more changes in dating, such as the change to the gregorian calendar, so why not take this next logical step. Surely, Wikipedia should prefer an ISO norm (ISO_8601#Dates) over an illogical tradition. At 1st century someone even removed the reference to that 'alternative'. This is sort of like only using feet and removing all translations into meters. Actually, it's even worse, because one can work quite decently with other systems than the metric system, but leaving out the zero would make modern science impossible. Even the simplest basics wouldn't work anymore. The invention of the zero is one of the greatest leaps ahead in human knowledge.

Suppose some aliens would pass by Earth, have a look at that great encyclopedia they see we have and happen to first read the 1st century article. Surely, they'd have to conclude that, since we haven't invented the zero yet, we're not worth contacting. :) And it looks extra stupid comsidering the table at the bottom. It looks like we have a great big gaping hole in our decimal system. How is it we have a '0' in our system but don't use it as a separate number? DirkvdM 05:45, 13 October 2005 (UTC)[reply]

Generally speaking, I like ISO standards, because they discourage us from believing that the way we do things is the way the rest of the world does them. I certainly have fallen foul of the American date format, missing a teleconference because i thought it had been scheduled for 5/6, which I read as 5th June not May 6. ISO 8601 is one way of avoiding that and current Wikipedia style of using month names is another. I'm happy with either.

Logically there should be a year zero, but I doubt little confusion actually arises because wikipedia doesn't use it. Maybe the wikipedia style guide should allow the use of any calendar eg, Gregorian, Julian, Jewish, Islamic etc as long as the ISO date is also given? Having said that, I personally don't like the fact that the ISO date is based on the Gregorian calendar - maybe it could have had a more culturally neutral basis? But I suppose we're stuck with it --Yaf201 09:23, 13 October 2005 (UTC)[reply]

Agreed it is just normal logic that a year 0 does exist as the natural number 0 does exist. Skatebiker 09:27, 13 October 2005 (UTC)[reply]

About using the gregorian calender as a basis; you have to pick one and a neutral one would have been one that no-one uses, which would be 'politically correct' but impractical. Now at least several hundred million people (?) don't have to change what they're used to. I'm afraid that using year 0 as a Wikirule is not going to happen because there will be too much opposition. But deleting a reference to it at 1st century certainly won't do, so I'll go and change it back. To change the text on this project page I'd like to have a little more consensus first, though, so I'll first wait for any further reactions. DirkvdM 18:26, 13 October 2005 (UTC)[reply]

If you really feel the need to do math with dates, just remember that the zeroth year of our calendar is called 1 AD; it shouldn't be too hard after that (also keep this in mind if you think that the twentieth century started in the year 2000). But using a different name for what ninety-nine percent of the world refers to as the year 1 BC would be completely contrary to the spirit of Wikipedia's conventions. —Michael Z. 2005-10-13 19:27 Z
The use of year zero was a convention of astronomers before it was included in the ISO 8601 data transmission format. Nonetheless, for a long time the Wikipedia software, though it used the all-digit YYYY-MM-DD format as its preferences option, it did not handle dates wikified in that format with a negative year properly, nor the display in that format of years wikified in other formats (at least one of these, I think it was both). In fact, I was the one who made the bug report to Bugzilla that finally got it fixed only a few months ago, after I had brought up the problems a few times on this talk page. Gene Nygaard 20:34, 13 October 2005 (UTC)[reply]
Michael, I acknowledge that tradition goes against logic here, and both need to be mentioned (if only so as not to confuse those who only know about the traditional way). So the notions that the 20th century started in 2000 or 2001 should both be mentioned where applicable. As well as the the first year of our calendar being '1 AD' or 'year 0' (note the difference in notation - the year before that would be '1 BC' or 'year -1' respectively). But you say the zeroeth year is 1 AD. The zeoroeth year? What is that? Ah, there's an article on zeroth. Apparently that's a computer term (where it does indeed make some sense). Not quite what you had in mind, though, I suppose. DirkvdM 08:58, 14 October 2005 (UTC)[reply]
Well, the basic definition in zeroth is exactly what I was thinking of: "The zeroth item is the initial item of a sequence, if that sequence is numbered beginning from zero rather than one." I meant that precisely 2000.5 years after the (nominal) date of the birth of Christ is the middle of the 2001st full year, the year we label 2001. In the same way, a one year old baby is in its second year of life, but no one argues that this is a lapse of logic or that "leaving out the zero" makes science impossible.
I agree that ISO dating should be mentioned and explained here. I've been using the ISO short date notation for a while because it is much less ambiguous than "01/01/01", but until reading this discussion I had no idea that it had a year zero, and used different numbering for years BCE. I'm quite surprised that the ISO people would move the start of their calendar a year earlier than the start of the traditional Western calendar. —Michael Z. 2005-10-14 10:27 Z
I suppose a central problem is the notion of a 'start of the calendar'. Time is continuous and where one puts the zero (or one) is completely arbitrary from a non-religious point of view. All other units have an absolute 'point zero', but with time one can not even place it at the Big Bang because that is just a theory and it is not even known when it took place. And it would make for very cumbersome dates. So I suppose ISO just took one system that happens to be in wide use and made that more logical. The only problem arises with years before year 1 where a precision of a year or less is needed. Before, say, -5000 that is rather unlikely to happen, so the only problem lies with a few thousand years of which so little is known that the difference is irrelevant.
A not-yet-one-year-old baby is in its first year of life, which is year zero (which is confusing, which is probably the reason that some shift it and use 'zeroth item'). (btw, you don't say a baby is zero years old because you use more precision that case - months, weeks, days, hours). This is however a different system than the one that puts 2000.5 years after year 1 in the middle of the 2001st full year' because that system doesn't use a year 0 (unless you put the birth of Christ at 1 January 0).
By the way, you seem to imply (earlier) that 99% of people don't acknowledge the year 0. But most people will first learn about the number system (with a 0) and then maybe later learn about the leaving out of the 0 by some systems. I was in my thirties when, to my surprise, I learned about this. It's like with the way kids learn language. First they learn the logic and then the exceptions, thus for a while using words like 'ringed' in stead of 'rang' and the like. DirkvdM 08:04, 15 October 2005 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Manual_of_Style/Dates_and_numbers&oldid=25606339"