Wikipedia talk:Manual of Style/Dates and numbers

Reversion

I'm going to revert the edit by lysdexia, which included substantive changes that haven't been discussed, such as the style "1.56234e29". My understanding is that it is customary to discuss substantive changes to the style guide before adding them.

Changes also included taking the commas out of large numbers (against stated style), changing "BC" to "BCE" (against custom of letting either stand), and changing "period" to "dot" (which is not needed). Maurreen 07:49, 14 Nov 2004 (UTC)

. Jongarrettuk beat me to it. Maurreen 07:50, 14 Nov 2004 (UTC)

20m or 20 m, etc.

So why is there no space after say "20m"? i thought 20m was the accepted form and 20 m was incorrect? that's the way we always did it at school. 20 metres, but 20m (no space) SpookyMulder

Maybe it's a national difference. I'd prefer that units are spelled out. For one thing, that avoids confusion between meters and miles. Maurreen 15:24, 16 Nov 2004 (UTC)

It's good typesetting practice to put a space between a number and unit. ISO 31 uses a space. In printed typesetting this would normally be a thin space ( ) but on HTML that doesn't have the "non-breaking" property of   (one could achieve a non-breaking thin space using a Unicode "word joiner" character but that isn't yet supported by many browsers). See the archives for this talk page, and also [1]. Gdr 16:51, 2004 Nov 16 (UTC)

See SI#SI writing style. For metric units, there should be a space between the number and the units. Also, there are official symbols (not called "abbreviations") for metric units, and we should ban the use of abbreviations that cound be confused with such symbols. (For example, ban the use of "m" as an abbreviation for "mile".) For non-metric units, there are often no standardised symbols, so it's probably a good idea to avoid abbreviations of units that are already fairly short (like "mile"), but I see no harm in using abbreviations for units that have long names (like "BTU" for "British Thermal Unit". —AlanBarrett 22:14, 17 Nov 2004 (UTC)

20 m (inserted by Gene Nygaard for comparison purposes)

20⁠ ⁠m (20⁠ ⁠m) seems to be supported by several browsers, including the Mozillas and Apple's WebKit (including Safari). I guess that "many browsers" primarily means Internet Explorer, as usual... However, I'm not sure I want to encourage the use of 24 characters between the value and the unit in wiki markup. — David Remahl 07:05, 21 Nov 2004 (UTC)

There is a Unicode character named "NARROW NO-BREAKSPACE" at U+202F ( ) which might work, except that my browser (IE6) fails to render it properly (like this). --Phil | Talk 11:54, Nov 25, 2004 (UTC)

You have a weird notion of "supported", when my Mozilla Firefox on Windows XP renders your supposed "nonbreaking thin space" with more space than just writing "20 m" as I have done in the comparison entry above. It didn't butcher it with boxes or anything, I did get space--but I wouldn't call that "supported".

However, a bigger problem is a misperceived need for a nonbreaking space here. We don't need to avoid a break between a number and its unit symbol, but we should avoid a break within a number itself (but Wikipedia style frowns on the space as a thousands separator) and to avoid breaks within a unit measure itself (that problem can usually be avoided by using a middot for a separator rather than a space (the middot is likely narrower than a full space as well as nonbreaking), as in N·s/kg rather than N s/kg, or the incorrect version still encountered on Wikipedia Ns/kg). Gene Nygaard 11:16, 10 Feb 2005 (UTC)

Eras

Stating use BP or MYA for prehistory is too vague. Use MYA, then kYA (thousand years ago - especially useful when talking about the Mesolithic), then BP. Then in late prehistory, start using BC, optionally for the Neolithic, definitely anything about the Bronze Age or Iron Age.

Another issue is that authorities differ on use of BCE. Some people use it interchangeably with BC. Some academics, however, (notably a certain prehistorian in my department), insist there is a year 0 CE (but not AD 0, 0 BC, or 0 BCE), meaning that if someone writes 404 BCE, it is ambiguous as to whether they meant 404 BC or 405 BC. The relevance of this discrepancy is limited almost solely to the Mediterannean after about the 8th Century BC, so in most cases the ambiguity doesn't matter.

Another thing which might need mentioning is that bc and ad mean totally different things from BC and AD. 1500 bc isn't the same as 1500 BC, nor is 1400 bc exactly a century after 1500 bc. Lower case bc and ad refer to uncalibrated radiocarbon dates, and should strictly speaking be quoted with a standard error. You will also see a (rather confusing) convention of giving uncalibrated radiocarbon dates in BP (as radiocarbon dating being of use doesn't overlap TOO much with the part of prehistory in which one starts talking about BP rather than BC) and calibrated ones in Cal AD and Cal BC.

Anyway, the article as it stands is a bit simplistic on eras, so some of this at least probably should go in. (Anonymous comment from 82.36.26.229)

I added kYA and a note about BCE not having a year 0. I didn't act on your other comments: the Manual of Style can't and shouldn't explain everything, lest its length prevent people from reading and following it. The details of prehistoric dating, and of calibrated and uncalibrated dating should have articles in the encyclopedia proper to which the Manual of Style can briefly refer (in the way it currently refers to detailed articles at New Year and Gregorian calendar). Perhaps you would like to expand the relevant sections at Prehistory and Radiocarbon dating? Gdr 11:36, 2004 Nov 17 (UTC)

I've reverted your additions. I think kYA is little known and do not think we should encourage using it. Instead of encouraging more usage of confusing abbreviations we should discourage them. This also applies to usage of BP, MYA, etc. (at least unless those terms are defined when first used in an article). On the BCE point, I'm not sure we need a comment to disambiguate from the usage by one prehistorian. Although, if there really is a body of academics who use the term differently from everyone else, perhaps we should change and require BC/AD. jguk 19:55, 17 Nov 2004 (UTC)

Requiring BC/AD is no solution. Until quite recently, virtually all Maya historians assumed that a year zero existed between BC and AD as can be seen by the ubiquitous statement that the epoch of the Long Count of the Maya calendar was in 3113 BC, whereas it is in 3114 BC when no year zero is used. One historian narrowed it a bit by explicitly stating, in print, that a year zero does exist between BC and AD in the Gregorian calendar but not in the Julian calendar. The current statement that "there was no year 0" in the Wikipedia timeline is acceptable, and the link serves as a disambiguation for other year zeros which do exist in astronomical year numbering, and Hindu and Buddhist calendars. — Joe Kress 20:32, Dec 1, 2004 (UTC)

I don't think anyone was seriously suggesting a 0 BC or AD 0. If what you say is true, it sounds like a genuine mistake. I was surprised at the claim that some claimed there was a 0 BCE or 0 CE, but am open to persuasion on the point. jguk 23:25, 1 Dec 2004 (UTC)

Traditional dates.

Perhaps these no special handling, but what is the best way to deal with dates that are tradional within a relgious or other group. Specifically the Mahabharata is tradionally said to have been composed in 1316 BCE. I want to indicate the status of this date, especially in lists where a long discussion of the date is inappropriate. Is "trad. 1316" clear? Also which is better, "c.", "c." or "about". Zeimusu 06:11, 2004 Nov 21 (UTC)

How about: "The Mahabharata is traditionally said to have been composed in 1316 BCE." Maurreen 06:42, 21 Nov 2004 (UTC)

I just want to note that we shouldn't use the abbreviation "trad." (at least without introducing the term in that article). Though it may seem obvious to you what it means, some people would see it as jargon. The Manual of Style (dates and numbers) suggests we use "c." when identifying an approximate date as opposed to any other abbreviation, but is not explicit in this. You may, however, prefer Maurreen's suggestion anyway. jguk 09:23, 21 Nov 2004 (UTC)

Maurreen's suggestion is good. It would be even better to cite the source for the tradition. For example, "according to Livy, the Roman Republic was founded in 509 BC" (it's a traditional date, but Livy is our best source for the tradition). Another example, from History of Japan: "February 11, 660 BC is the traditional founding date of Japan by Emperor Jimmu Tenno. This however is a version of Japanese history from the country's first written records dating from the 6th to the 8th centuries" Gdr 13:40, 2004 Nov 21 (UTC)

I've added a note to this effect to the project page. Zeimusu

Superscript ordinals

There seems to be a recent fad for superscripting the suffixes ordinal numbers, making century links read something like [[20th century|20<sup>th</sup> century]], for example. I think this looks particularly ugly, even when browsers don't mess about with the leading to make the text fit. I'd like to suggest we make it a policy not to do this. Opinions? — OwenBlacker 16:39, Nov 24, 2004 (UTC)

I agree, we should discourage superscripting such suffixes. —AlanBarrett 17:23, 24 Nov 2004 (UTC)

I agree with OwenBlacker - ban them. Then search for them and deleting them. No point in just discouraging them - people will only say it's not a ban and so has no effect. jguk 18:22, 24 Nov 2004 (UTC)

Yes, ban them. Gdr 11:28, 2004 Nov 25 (UTC)

ISO 8601

The Manual of Style allows dates to be stated in ISO 8601 style, requiring hyphens to separate the year, month, and day, which is the extended format in ISO 8601. When using this form, Wikipedia properly converts the year to the other acceptable forms, but only from year 0001. Although the 1988 first edition did not mention earlier years, the 2000 second edition requires that earlier years be given in astronomical year numbering, with a year 0000 immediately before 0001, and year -0001 immediately before 0000. However, the Wikipedia software does not properly convert these years into the Wikipedia timeline of 2 BC, 1 BC, and 1. Even ignoring the year 0000, the explicit use or a minus sign should signal the software to convert -0010 to 11 BC, but it actually converts -0010 to 9 BC.

In addition, the new edition explicitly requires all dates for years before 1583 to be given in the proleptic Gregorian calendar, yet the Wikipedia software does not convert them into the Julian calendar. Admittedly, most people would probably ignore this latter requirement, and give all early ISO 8601 style dates in whatever form they found them, usually in the Julian calendar. — Joe Kress 21:20, Dec 1, 2004 (UTC)

It would be disastrous for Wikipedia to display or require dates in the proleptic Gregorian calendar. Gdr 22:07, 2004 Dec 1 (UTC)

"22:00" or "22:00 hours"

Should times be written with or without "hours" following them? ("It happened at 22:00." or "It happened at 22:00 hours."?) — Flamurai 20:16, 10 Dec 2004 (UTC)

I would stongly recommend against including the word "hours". It's redundant: the colon, along with the context, will always make it clear that it's a time of day. In spoken English, it occassionally may be helpful to use "hours" to remove ambiguity, but it's never necessary in writing. Indefatigable 21:31, 10 Dec 2004 (UTC)

I agree; "22:00" is fine.

James F. (talk) 03:22, 11 Dec 2004 (UTC)

I concur. I think it's an issue of Americans not being used to the 24-hour format. — Flamurai 06:44, 11 Dec 2004 (UTC)

I think "hours" is a US military thing. We're international civilians here, so "22:00" is fine. Gdr 10:13, 2004 Dec 11 (UTC)

IX Century

We don't appear to say anything about the use of the form "'roman numeral' century". Is it to be avoided. It shows up a lot in Polish pages I have noted. Rmhermen 04:19, Dec 11, 2004 (UTC)

The well-established practice in English writing is to use Arabic numerals: "14th century". In French, and possibly other European languages such as Polish, Roman numerals are often used ("XIV^e siècle"). When you see a Roman numeral, it's probably a non-native user of English accidently bringing the habits from his or her native language, similar to forgetting the capitals on "proper adjectives", such as "english" or "asian". Roman numerals should be changed to Arabic for uniformity's sake. Indefatigable 05:10, 11 Dec 2004 (UTC)

I have been. I was just wondering if we needed to note this in the Manual of Style. Rmhermen 19:28, Dec 11, 2004 (UTC)

Yes, but not so much for uniformity (if that were such a worthy concern we'd be systematically Americanizing the spelling) as for immediate comprehensibility: Roman numerals beyond about VI are esoteric (and thus slowly decoded) for native speakers of English, being used almost exclusively for

pretension (Superbowl XXVII), or
being able to prove you provided a date, without having the average reader glance at it and say "gosh, i didn't realize how last-year this is" (All rights reserved, MCMLXXXIV), or
clockfaces (but i think that's completely last-century).

BTW, the Roman-numeral centuries are German, too, IIRC.

--Jerzy (t) 20:05, 2004 Dec 17 (UTC)

Percent symbol with space?

Assuming a context where it's inappropriate to write out "percent", what are (or what should be) the guidelines on how to format a number with a "%" symbol? Are there regional or journalistic vs scientific writing styles? I'm confused because NIST [2] (as well as ISO-31) requires a space between the number and the "%", yet you're much more likely to find "10%" instead of "10 %", even in articles that are clearly 'SI'. Femto 13:26, 14 Dec 2004 (UTC)

I think using a space is unusual. Maurreen 17:54, 14 Dec 2004 (UTC)

Those guides are already referenced for several other Wikipedia number style issues. So far they're the 'most correct' international English scientific style recommendations that I know of. Obviously, this doesn't appear to be the preferred way of writing the percent symbol, and I don't know which style to use, let alone how to copyedit existing articles. Could there be some clear and simple recommendation in the Manual of Style, and what should it say? Femto 22:46, 15 Dec 2004 (UTC)

The de facto standard in use in (as far as I know) all English speaking nations is to not use a space. However, there is no readability issue, IMO, either way.

If the Manual of Style should recommend anything, it should be not to use a space. However, is there a pressing need for the MoS to specify anything about this topic? We should avoid instruction creep in situations like this. So far, we have identified that:

Common written English usage is to format without a space
Scientific style guides specify the use of a space
This is an inconsistency.

However, IMO, for something to be included in the style guide, it should be to address actual problems, not just mere inconsistencies. I can't see a problem being identified above, unless one is of the mindset that inconsistencies and lack of clear instruction is a problem. If we leave well alone and don't put a ruling in the MoS, what are the consequences? That's what we have to address. To my mind, the consequences are:

Most Wikipedia editors continue to enter percentages as they always do, without spaces. This poses no readability nor intelligibility problems.
Some scientifically trained editors used to writing in the style specified by NIST, ISO et al. write percentages as they have been taught to do, with a space. This poses no readability nor intelligibility problems.
The overwhelmingly vast proportion of Wikipedia readers neither notice nor care.

As far as I can see, the only possible problem is that some over-zealously correct editor takes it upon themselves to reformat all percentages in Wikipedia to conform to their personal preference (spaced or spaceless), and a flamewar erupts. This might be a sufficient future possibility to put a line in the MoS saying 'Both forms are acceptable on Wikipedia', but I think that is the most the MoS needs to say on the subject, and I'm frankly not even convinced it needs to say even that. —Morven 00:40, Dec 16, 2004 (UTC)

I agree that the size of the style guide needs to be managed, but I disagree that a style issue has to become a problem to make it worthy of inclusion in the MoS, whose declared purpose is to "make things easy to read by following a consistent format" — There is a format inconsistency (if not a readability problem though, or even a very big one) that cannot be resolved by turning to other sources, but which would be easy to avoid. It should be of equal importance to work towards an uniform article style as it is to keep the rules simple.

The MoS includes many little rules of standard usage that are not necessary (in the sense that they are non-controversial and can be found elsewhere) but which are useful to have all in one place nevertheless. Among them is that, in a non-technical context, percentages should be written in natural language. But nothing about % in a technical context, even though there really are varying standards.

In my opinion the principle of least astonishment should be extended to what is not expected not to find on a page. I came earlier to this guide expecting to find examples on how to write common things such as the degree and percent symbols, but was disappointed there. My suggested edit would be to insert after "The reader should see a space between the value and the unit symbol: thus 25 kg and not 25kg.":

An exception are angular (but not temperature) degrees. It is also common practice not to put a space between a number and the "%" percent symbol (against some scientific styles).

and to include in the examples

There are 360° to a full circle.
The metal alloy melts at 71.7 °C (161 °F) and contains by weight 50% bismuth, 26.7% lead, 13.3% tin, and 10% cadmium.

Femto 13:05, 17 Dec 2004 (UTC)

I confess to not reading the whole debate before sticking in these two points:

Logically (he said, with a laugh at the idea of logic ruling any human behavior, let alone speech), the space is offensive. Percent is from Latin, something like "per centum" meaning "for [each] hundred". "16%" means

"16 out of a hundred" and thus
"percent" modifies "16" into "not really 16, but rather with a frequency of 16/100", whence
the odd-looking symbol "%" surely comes from "0/0" which presumably is
an impressionistic evocation of "/100", with the "obviously" needed 1 omitted as inferable and redundant, and the order of the remaining 3 symbols changed to speed cursive writing of them. (The fonts i am typing and reading in, and my %-key's label, represent % as simply circles or ovals, and a slash, but i still write it by hand as i was taught, joining the left circle to the top of the slash with a ligature, so they are really more like a "degrees" circle welded to a 7. The ligature helps the reader perceive % as a unit, and speeds writing by saving lifting the pen.)

So IMO omitting the space helps strengthen the association between the abstract symbol and its logical and historical meaning (16% is more like a mathematical expression than like "16 meters"), which helps the brain unconsciously assign the correct meaning to it with less competing mental noise like "Wait, what's the role of the space?" and "No, the thing after the space is unrelated to the thing after it." The number and the symbol constitute a unit of meaning (just as ".16" does) and perceiving that meaning is disrupted by separating them (as ". 16" would do).

The nature of standards is all over the map:

Some exist to encourage adherance to an already dominant practice.
Some are mechanisms to forge a mutually beneficial agreement within an industry without running afoul of anti-trust law.
Some are futile attempts by idealists to cram what is logical, or illogical but theoretically desirable, down the throats of illogical and self-defeating humans.

We should include

Wikipedia is not a marketing department for Official Standards.

Taking notice of standards is good; acting as if they were laws of nature or otherwise automatically deserving of adherance is just, uh, the kind of behavior that should be expected from people still suffering from the effects of a blow to the head.

--Jerzy (t) 19:26, 2004 Dec 17 (UTC)

Thank you for your comment. It convinced me that I shall not further pursue the issue whether the Manual of Style should contain examples of common and preferred usage in this case of conflicting styles to choose from. I will strengthen the advance of cultural diversity and aid your cause of clear and thematically coherent contributions to Wikipedia by not following any of the suggestions in its style guide. Femto 21:14, 17 Dec 2004 (UTC)

Links on non-full-length dates and centuries

What is the reason for necessarily linking to a date that is not directly relevant to the context of the article? Links should only be to articles relevant to the context of the article (aside from peculiarities like the date preference feature), and linking to all dates clutters and is makes linking less useful. - Centrx 02:39, 25 Dec 2004 (UTC)

I'm not sure whether there is a policy, but I agree with you. Maurreen

I would agree, except for the fact that this "linking" is what makes the Wikipedia "Preferences" you can set for display of dates on your browser work. Gene Nygaard 19:33, 28 Dec 2004 (UTC)

But that's irrelevant for just links to years, for example. Maurreen 19:48, 28 Dec 2004 (UTC)

Long-term, we might have the ability to transform calendars, as well as displays. Then it would be... a pain to go back through all the text and re-add the links.

James F. (talk) 03:43, 29 Dec 2004 (UTC)

Linking dates highlights that you are referring to a date rather than a number. It's not always obvious when some is referring to a date, particularly when dealing with dates in the first millennium, or with round number dates such as 2000 or 1500, jguk 23:17, 5 Jan 2005 (UTC)

So, then it should be policy that only numbers that are dates should be linked, otherwise there's nothing exclusive about the year linking, and any automated calendar system would be severely flawed..? - Centrx 21:50, 9 Jan 2005 (UTC)

Interesting numbers are located in article names such as 1 (number), 13 (number), 28 (number) and so on. I imagine there's only an occasional need to link to one of these anyway (a mathematical article???) and that where you are linking to them it is obvious from the context that you cannot be referring to the year. I'm not sure what you mean by an automated calendar system, so I can't respond to that point. Kind regards, jguk 22:17, 9 Jan 2005 (UTC)

Whether the article is referring to a date or just a number should be made clear by the writing, not by a link. Even if that is the purpose, it is not well served. Maurreen 04:50, 10 Jan 2005 (UTC)

The only good reason noted for linking to non-full length dates was that, in the "Long-term, we might have the ability to transform calendars, as well as displays", which is what I mean by automated calendar system, and if that system were in place then the problem would then become links to numbers that aren't dates. Other than that reason given here, it seems there is no good reason to link to non-full-length dates, and if that calendar reason is valid, then it seems that numbers should not be linked to. - Centrx 21:32, 22 Jan 2005 (UTC)

Proposed revision

I have put a proposed revision on Wikipedia:Manual of Style (dates and numbers)/proposed revision. I am proposing that we explicitly state that "The general philosophy behind these rules is that date and number styles should be chosen so as to be readily understandable to as many people as possible. Remember, you are writing for the reader, not for yourself!" However, the revision also includes some slight tweaks to policy. Slight, because although some articles following current policy would not comply with the revision, the number of those articles is quite small.

Put simply, I think what I call "the general philosophy" above is important to have in an encyclopaedia that seeks to have a wide international readership, with readers from all backgrounds and schoolings. The emphasis should be to try to produce articles that everyone understand. No doubt this aim cannot always be achieved, yet it is good target to aim for, jguk 20:17, 23 Jan 2005 (UTC)

Who will be the arbiter of this "general philosophy?" Perhaps we could have a general philosophy Czar who would travel around reverting everything that didn't square with their POV? :) Sunray 10:47, 2005 Jan 24 (UTC)

I would like to see the changes from the current version highlighted in some manner so that what you propose is easier to comprehend. —Morven 20:30, Jan 23, 2005 (UTC)

Oops, I arranged for that and forgot to tell anyone. I pasted the current article onto the proposed revision page when I created it, and then revised it to the proposal. The changes can be seen on this [3] diff. As I note, it is the basic philosophy that I think is most important. The remaining changes are a corollary of that, jguk 20:38, 23 Jan 2005 (UTC)

I disagree with this proposal. Also, because the proposal would be a major change, I will give it the publicity it deserves. Maurreen 01:09, 24 Jan 2005 (UTC)

There might be a few minor changes I would support, such as changing 'mi/h' to the more familiar 'mph'. But otherwise I would point out:

The correct abbreviation is 'e.g.' not 'eg'.
'4–7' is equivalent to '4 through 7', but neither is equivalent to '4 to 7'. (It would however be equivalent to '4 to 7, inclusive', but why bother with the extra word?)
I'm thinking anyone who bothers changing all the date references from [[February 12]], [[1809]] to [[12 February]] [[1809]] has too much time on his hands. —Mike 02:24, Jan 24, 2005 (UTC)

In reponse to your comments:

1. I think either is reasonable, but this is something that can easily be tweaked anyway.

2. I hadn't realised there was a difference. We don't use "through" in the UK, so it seems I got it wrong. Maybe "4 through to 7" would be better.

3. The revision says that all date references in an article should be consistent. That is, use either [[February 12]], [[1809]] or [[12 February]] [[1809]], but not both. The reason for this is to give consistency to users (eg unregistered users) who haven't expressed a date preference. If that's the policy, the page, which was very inconsistent beforehand, should reflect it.

I'm unable to address Maurreen's concerns as she does not say what they are, but, as noted above, in practice very few pages complying with current policy would be affected, jguk 08:02, 24 Jan 2005 (UTC)

I disagree with this proposed revision. Is it not merely a thinly-disguised way of banning the use of BCE/CE? Many Wikipedians use different ways of dating depending on the context. I have used BCE/CE for non-Christian topics relating to non-Christian regions. Such use is considered acceptable in both the Oxford Style Manual and the Chicago Manual of Style. The current Wikipedia:Manual of Style likewise permits both BC/AD and BCE/CE. It is the writer's call. The only stipulation is that there should be consistency in dating/numbering scheme within a particular article. There are many reasons for using BCE/CE (see the article on Common Era). One that is undoubtedly of interest to many Wikipedia editors is showing common courtesy to people of diverse cultures and religions. Sunray 10:47, 2005 Jan 24 (UTC)

I also disagree with most proposed changes:

I agree with your sentiment about date format inconsistencies, but date formats should really be a user preference. If you ask me, dates should be written in source inside a single set of double brackets, e.g. [[21 February 2004]] and the software should then correctly format and link the dates and years. Maybe you should make a feature request for that.
The BC and AD notation (and its local equivalents is obsolete even in many traditionally christian countries. I see no reason to give it precedence over the neutral BCE/CE notation. I can live with date articles living at the BC/AD titles, but it should be possible to use and link 300 BCE. Again, this could be a user preference.
Using mph instead of mi/h sounds reasonable. The whole imperial measurement system is wacky and there's no good reason to try to bring it in line with our SI standards.
I don't see why we would abandon the advice on billions. They can cause serious misunderstanding. Zocky 11:29, 24 Jan 2005 (UTC)

I think I have to along with the majority here, and disagree with the proposed changes, especially with regard to the BCE/CE question. (Incidentally, while 12.00a.m. and 12.00p.m. can confuse some people, I don't see any ambiguity. Is there a difference in usage between, say, the U.S. and the U.K.?) Mel Etitis (Μελ Ετητης) 11:57, 24 Jan 2005 (UTC)

The ambiguity is not one of inconsistent usage but rather one of theory vs practice. A.M. and P.M. mean in Latin "after midnight" and "after noon"; 12 hours "after midnight" is surely noon, and yet 12:00 a.m. is reckoned as midnight. I trace the problem to flip-type digital clocks which for mechanical expediency put each 12:00 in the same half-day as the following 59 minutes; this usage of 12:00 a.m. for midnight (and correspondingly, belonging to the day it commences) seems pretty universal now, at least over here in North America. --Sharkford 16:01, 2005 Jan 25 (UTC)

Enough of the folk etymology. A.M. stands for ante meridiem which means "before noon", not for "after midnight". Some used to recommend 12:00 M, but the problem there is this: does "M" stand for "meridiem" or for "midnight"? Gene Nygaard 16:33, 25 Jan 2005 (UTC)

Well yes, that's pretty much what I meant; there's some confusion, and many people (like Sharkford, and – if I'm honest – myself on occasion, when I'm in a hurry or not thinking) use them wrongly — but there's no ambiguity. The term "a.m." refers to the period between midnight and midday, so "12.00a.m." is midnight, "12.00p.m." is midday. (Mind you, one has to be careful not to rely too heavily on etymology, folk or otherwise — after all, "noon"'s Latin origin is the term for 3.00p.m., the ninth hour from sunrise.) Mel Etitis (Μελ Ετητης) 19:37, 25 Jan 2005 (UTC)

Urk. I can't believe I didn't double check that before I posted. Many thanks to the several of you that didn't let that stand. --Sharkford 19:51, 2005 Jan 25 (UTC)

Thumbs down. It is pretty bad when someone who proposes changes to this section of the manual doesn't have enough sense not to alienate people by messing with things not covered in the dates and numbers section, e.g. "eg".

My second reason is that while wholesale overhauls like this may be appropriate in a general article, when it comes to changing the Manual of Style it makes no sense to deal with a hodgepodge of unrelated items. One set of related items at a time--and you can usually discuss that here without showing how the whole dates and numbers section would look if rewritten. Gene Nygaard 13:20, 24 Jan 2005 (UTC)

I'm confused. What is wrong with the principle that date and numbers should be used in a way that they are easily understandable to as many people as possible? (Also, this is not a wholesale overhaul. Fewer than 1,000 articles (probably fewer than 500 articles) out of the 450,000 articles currently in the English Wikipedia would be out of kilter with the proposed revision.) jguk 21:19, 25 Jan 2005 (UTC)

I strongly, strongly opposed ALL of the preposed revisions (no offense meant to jguk, of course). Neutrality^talk 06:15, Jan 30, 2005 (UTC)

Zocky said dates should be written in source inside a single set of double brackets, e.g. [[21 February 2004]] and the software should then correctly format and link the dates and years.. I agree with that. I don't like the splitting of dates into two parts for the autoformatting to work. It seems like a software workaround to me. This splitting of dates into two links and then having relationship between the two links is not wysiwyg. It was only when I spent a long time removing multiple links to the same year, that somebody told me that this was a feature.

Look at List of asteroids (61001-62000). It has 1000 links to the article 2000 because it includes

[[May 28]], [[2000]]

[[May 27]], [[2000]]

[[May 26]], [[2000]]

[[May 25]], [[2000]]

etc

That is why it is mentioned in Wikipedia:Offline reports/This page links many times to the same article. I will support any requests for an improvement to date handling. Linking and date autoformatting are two different things and they should look different. Making it look like one link would be bad enough, making it look like two separate links is worse.

I also support the suggestion that dates should only be linked if relevant. And they should only be linked once, not every time. Bobblewik (talk) 20:46, 30 Jan 2005 (UTC)

That makes sense to me. Maurreen 11:28, 31 Jan 2005 (UTC)

I oppose the proposed revision as stated, and in particular its attempt to make the use of CE / BCE dates disallowed or disfavored. I agree with several other people who have expressed the view that this format has significant value. Indded it seems clsoer to the standard of a neutral POV than does the general use of AD/BC, much less the mandated use of that system. The "general principle" seems reasonable, if not vital, to me, but if this kind of thing is its proper consequence, then I oppose it.

By the way, i belive that "4-7" can mean either "Four through seven" (i. e. the numbers 4, 5, 6, and 7) or "four to seven" (i.e. a range in a numbered list of pages, items, paragraphs or the like) depending on the context. DES 19:42, 10 Feb 2005 (UTC)

BCE in Y/M/D format

How is BCE used in representing a date in year-month-day style? I have been working on several articles which employ BCE dates and want to employ a stylistically correct form before proceeding furhter. Denni ☯ 01:59, 2005 Jan 24 (UTC)

I don't know if there is a way to do BCE, however if you were to enter [[-0425]]-[[02-12]], this is the equivalent of "February 12, 424 BC". —Mike 02:34, Jan 24, 2005 (UTC)

This is what I have been doing up until now. However, the negative codes still come up redlinked. The Wiki software does not seem to recognize them as BC or BCE dates. (See, among similar, 50 (number)#In science) Denni ☯ 02:46, 2005 Jan 24 (UTC)

You're using an odd unrecognised format. Try [[-0425-02-12]], it becomes -0425-02-12. -- Tim Starling 03:04, Jan 24, 2005 (UTC)

Try these--isn't something horribly wrong? (View with preferences other than YYYYMMDD)

[[-0002-02-12]] -0002-02-12 should be 3 B.C., not 1 B.C.

[[-0001-02-12]] -0001-02-12 should be 2 B.C., not 0 B.C. which is never used

[[-0000-02-12]] and [[0000-02-12]] -0000-02-12 and 0000-02-12 both should be 1 B.C., not -1 B.C. and not 0 unless using this YMD format

[[0001-02-12]] 0001-02-12 correct as 1 (A.D.) -- Gene Nygaard 04:42, 24 Jan 2005 (UTC) modified Gene Nygaard 03:43, 10 Feb 2005 (UTC)

I mentioned this software bug above (#ISO 8601), but only got one response. Tim Starling's example of [[-0425-02-12]] resulted in February 12, 424 BC in the M-D-Y format, which is wrong. It should be February 17, 426 BC if the date were written in the ISO 8601 (2000) format and the date converted to the Wikipedia style of a Julian calendar date (because it is before October 15, 1582) using a BC year. ISO 8601 (2000) requires that all dates before 1582 be given in the proleptic Gregorian calendar and that a year 0000 be used. Thus 02-12 should be assumed to be in the Gregorian calendar, so that when it is displayed in the Julian calendar, the day of the month shifts by five days (in this case). Furthermore, because ISO 8601 (2000) requires a zero year, the digits in the year should increase by one, not decrease by one.

As pointed out by the lone respondent to my earlier post, this produces great problems for the general Wikipedia community, considering that the software engineer who programmed Wikipedia didn't even get it right. There are three possible solutions: (1) correct the software to follow the full ISO 8601 (2000) rules, (2) follow a modified set of ISO rules that assume that the 'ISO' date is given in the Julian calendar without a year zero (if before October 15, 1582), or (3) forbid the use of the ISO 8601 (2000) format before October 15, 1582.

The solution which would prevent most problems for those who are oblivious to converting calendar dates would be option (2). For this option, a minus sign before the year would simply be replaced by BC without any change in the digits of the year. An attempt to use a zero year could be converted to 1 BC, so both 0000 and -0001 would be interpreted as 1 BC. Using a minus sign for a BC year has been used by some chronologists and historians, but has also been decried by those who know that a minus sign means astronomical year numbering and hence wrong if the year is not shifted by one. — Joe Kress 07:15, Jan 24, 2005 (UTC)

This isn't ISO 8601 usage in any case. This is far outside the scope of the usage covered by ISO 8601. So there's no reason why this format cannot be used with Julian calendar dates. The software just needs to be fixed to subtract one from the absolute value of the year, not from the B.C. year with a negative sign stuck in front of it. Gene Nygaard 08:25, 24 Jan 2005 (UTC)

Christian Era vs. Common Era

I noticed that Japanese calendar refered to CE specifically as the Christian Era and not the Common Era. I would prefer the latter as it seems less POV (does not label a 2000 year period as belonging to a single religion) but checked the manual for what wikipedia says on the issue. While the manual does address BC/BCE and AD/CE, it does not address Christian Era vs Common Era. What is the concensus here? Asteron ノレツァ 00:47, Jan 25, 2005 (UTC)

My own preference is for "Christian Era", because it's more accurate. The dating system involved isn't common, as many countries and cultures use their own systems; it is, however, directly related to the Christian system of dating, and is as widespread as it is because of the dominance of Christian-based cultures. Mel Etitis (Μελ Ετητης) 09:28, 25 Jan 2005 (UTC)

Christian Era is the more common terminology. The reason it is also the "Common Era" is because (in the area and time in which the term was coined) almost everyone was Christian - so the Christian Era was Common to all. Of course, nowadays many, such as Mel Etitis above, question why such an obviously Christian terminology is still used, jguk 21:23, 25 Jan 2005 (UTC)

I think that you probably meant to refer to the area and time in which A.D. and B.C. were coined (though in fact they were coined at different times, and more recently than is often realised — but that's not the point), as Common Era is surely a recent coinage. As an atheist I don't in fact care whether the dating system is referred to by religion-specific terms (any more than I refuse to use the terms Tuesday, Wednesday, January, etc.). Out of politeness to those who do care, I use C.E. and B.C.E. though; I expand it to Christian rather than to Common Era because, as I said, I think that it's more accurate. Mel Etitis (Μελ Ετητης) 22:37, 25 Jan 2005 (UTC)

No, "Common Era" was coined by Christians. Of course Tuesday (Tiu's day), Wednesday (Woden's day), January (named after Januus) all have religious derivations. Acknowledging that many do not understand academic speak, and that only one term is used in UK English, I prefer BC and AD. If I used anything else here in London, most people just wouldn't understand what the heck I was going on about! I fear that in your attempts to be courteous to a few, you are inadventently becoming discourteous to the many who will be confused by your style, jguk 22:53, 25 Jan 2005 (UTC)

I'm unsurprised that Common Era was coined by Christians, but my comment was that it was recent (and thus not, I think, coined at a time when almost everyone was Christian); that's a trivial point though.
On the question of C.E./B.C.E. being "academic speak", I'd agree that it's a usage more commonly found in books (but then I rarely use it in conversation, and certainly not non-academic conversation...), but certainly not restricted to academic books. A very quick look through recent popular books that I have lying around (so not a scientific test, I grant you) indicated that it was slightly more common than the traditional alternative, and a quick Google suggests that it's widely used outside acadaemia. Besides, I think that anyone who read, for example, that Descartes was born in 1596C.E., or that the Battle of Hastings is widely thought to have taken place in 1066C.E. would have to be pretty dim to be misled (especially if they can look up C.E. in the same encyclopaedia). Mel Etitis (Μελ Ετητης) 09:25, 26 Jan 2005 (UTC)

Descartes' birth doesn't need CE or AD - it's assumed. The issue really only arises for events before 0 AD/CE. And putting 999 BCE may be confusing for people not familiar with it, whereas most people know BC. And since the entire calendar is based on Christian history, does it really matter whether abbreviations (rarely if ever expanded) use Christian terminology or an unfamiliar vaguely neutered version of it? Unless we adopt a new calendar, 999 BCE is barely any less Christian than 999 BC, whatever BCE stands for. Rd232 11:15, 26 Jan 2005 (UTC)

I'm not sure how the newer terminology is a neutered (however vaguely) version of the old (especially as in general you seem to be saying that there's no real difference in their Christian nature). Nor is it unfamiliar to me, nor to a great many other people. Perhaps that's a matter of geographical/cultural context, but I'm an academic in the U.K., and as I type I'm looking at a popular, non-academic book published by Barron's in the U.S., and we both use B.C.E. rather than B.C.. Mel Etitis (Μελ Ετητης) 20:25, 26 Jan 2005 (UTC)

Guideline suggestion: Avoid "January 14th" and "January of 2005"

I believe these guidelines should be placed in this document:

Avoid ordinal suffixes in dates: "February 14" rather than "February 14th" (Note that this should be a non-issue if full-length dates are linked properly, but could be an issue when the year is omitted)
No "of" should be used when referencing a month in a specific year: "January 2005" rather than "January of 2005" (This should definitely be included: I see this a lot, and we don't always link in this situation)

– flamurai^TM 05:06, Feb 4, 2005 (UTC)

The first point needs to be tweaked a little for clarity (such as "... dates: Use 'February 14' ..." Maurreen 07:24, 4 Feb 2005 (UTC)

What's the reasoning behind such a guideline? Is it just to achieve uniformity? (I ask largely because the format “14th February 1956” is pretty standard in the U.K.; indeed, I'd say that “14 February” looks to our eyes rather odd and machine-like — and “February 14” positively bizarre). Mel Etitis (Μελ Ετητης) 23:07, 9 Feb 2005 (UTC)

I concur wholeheartedly with both guidelines, but (to avoid possible misunderstandings) would tweak the wording further, thus: "... dates: Use 'February 14' or '14 February' rather than 'February 14th', '14th February', etc." (Post edit conflict PS: I'm surprised by User:Mel Etitis's comments; I didn't think that was the case. The reasoning, in any event, is so that the neat automagic wikilinked date format conversion gadget can kick in: see "Preferences".) –Hajor 23:47, 9 Feb 2005 (UTC)

I also concur with both guidelines. "February 14th" just doesn't work with the date preference settings -- it's left as is, rather than being converted to 14 February, February 14, etc. -- Arwel 00:11, 10 Feb 2005 (UTC)

Dates of birth and death suggested revision

suggestion: that the examples in this section reflect the format guidance in the Dates section. Proposed revision:

Abraham Lincoln (February 12, 1809 – April 14, 1865)
Charles Darwin (12 February 1809 – 19 April 1882)
- Date format to be that used by local English speakers at the location of the event in accordance with the guidance in the Dates section above.

...dave souza 22:55, 9 Feb 2005 (UTC)

But this is completely irrelevant if dates are properly wikilinked - I see both birthdates exactly the same. I frequently get annoyed when dates are pointlessly switched from one format to the other. We should be encouraging the wikilinking of all dates, rather than get sidetracked like this. -- Arwel 00:15, 10 Feb 2005 (UTC)

I agree that it is irrelevant. I don't think it's necessary to note this, either. It would fit with the overall English variant being discussed here. – flamurai (t) 01:25, Feb 10, 2005 (UTC)

The only people to whom this particular guideline would matter whatsoever would be people editing the article source, as those people would be the only ones ever to see the distinction between the above two examples. I think that it is best to have no guideline in this area. Moreover: Whenever I wikify a biographical article as part of new page patrol, I always wikify using true ISO 8601 format ([[1809-02-12]]) if possible. I do this for several reasons; one of which is that it is culturally neutral, and another of which is, quite simply, that it is the shortest form and the simplest to type. I'd strongly object to a guideline that wanted me to do a lot of extra work involving determining what date format was used at the location of the event (which could well differ between birth and death, indeed), and thus which of several date formats to use — especially given how pointless such work would actually be. Uncle G 02:38, 2005 Feb 10 (UTC)

Incidentally: The MOS up until now has given a divided ISO 8601 format ([[YYYY]]-[[MM-DD]]) as its sole example. This can cause confusion if an unspaced dash is used to separate dates of birth and death. Consider the above examples in divided ISO 8601 format and with an unspaced hyphen: [[1809]]-[[02-12]]-[[1882]]-[[04-19]]. It's liable to error in maintenance. However, the software actually also supports undivided ISO 8601 format, too. [[1809-02-12]]-[[1882-04-19]] is somewhat clearer and less prone to error. I've amended the page to mention this additional ISO 8601 form, so that people using ISO 8601 style can at least work out from it that they can eliminate the superfluous, unsightly, and confusing extra square brackets in this way. It certainly wasn't something that I was aware of when I first started editing. Uncle G 03:09, 2005 Feb 10 (UTC)

But that form still doesn't work correctly for B.C. dates—see my examples in #BCE in Y/M/D format above. Gene Nygaard 03:28, 10 Feb 2005 (UTC)

Suggestion: Template for geographic coordinates

I notice that latitude and longitude coordinates are given for various locations. Useful as they may be, they are not in a common style. Isn't it time to define this? Not only for style, but using a template it should be possible to do the same neat trick as for ISBN numbers. I.e. clicking on the ref would bring you directly to a navigatable map, or better, a page with external pointers to various map resources, with coordinates automatically embedded where possible. We should also specifiy which geodetic system, presumably WGS84 is the must suitable standard.

Taking Lima as an example, it is located at:

12°02’36” S 77°01’42” W

The Mapquest request for this coordinate for this is:

    http://www.mapquest.com/maps/map.adp?searchtype=address&formtype=address&latlongtype=degrees&latdeg=-12&latmin=02&latsec=36&longdeg=-77&longmin=01&longsec=42

There is challenge in making a template by ordinary means due to the handling of S/N E/W versus negative degrees. This can be done in a convenient manner simply by having four variant templates, one for each quadrant. So to specify the location of Lima, one can do:

   {{coor dms SW|12|02|36|77|01|42|}}

Which expands to:

Template:Coor dms SW

The seventh argument is for a possible separator between latitude and longitude, where sometimes for instance a <br> may be needed.

The crux is in the common template Template:Coordinate dms, where of course the functionality can be developed further.

Replacing dms with dm or d gives similar functionality for references for larger areas, where degree/minute, or even just degrees suffice. The default zoom factor for the map is tuned correspondingly.

See Template talk:Coordinate dms for a summary.

Note that the link should ideally be to a new page (like e.g. for ISBN 0471093033) providing external links to a number of different map resources for the same location. Presumably this requires some Wikimedia Special: magic, where a critical mass of usage is perhaps required to get it done.

-- Egil 05:15, 10 Feb 2005 (UTC)

This may not be exactly what you are intending, but have you seen Template:Mapit-US-cityscale? It takes coordinates in decimal degrees and produces external links that can use those coordinates. For example, {{Mapit-US-cityscale|42.3316|-83.0475}}, which are coordinates for Detroit, produces this:

Template:Mapit-US-cityscale

-older≠wiser]] 13:38, Feb 10, 2005 (UTC)

Thanks. This one generates an inline set of references. This is along the lines I was thinking, but my hope was to have it on a separate page, as mentioned, so that the coordinates could appear inline with no clutter. -- Egil 13:55, 10 Feb 2005 (UTC)

I've noticed one caveat: Templates cannot be used as arguments to other templates. This is a problem when infobox templates contain geographical coordiantes, and is reported as a bug. -- Egil 06:08, 11 Feb 2005 (UTC)

Why use a template for this function? ISBN references are detected by the MediaWiki software automatically. Why not put in a software enhancement request to do similar detection for coordinates? -- Netoholic @ 15:08, 2005 Feb 11 (UTC)

Reason 1: ISBN references are much easier to detect, syntax-wise. Having recently had some experience in tracking down coordinates, it seems like there is no end to the variations of how these are written.

Reason 2: The template ensures a uniform presentation of these refs, as is needed, see Reason 1.

Reason 3: Implementing MediaWiki detection requires an updated version of MediaWiki. That is definitely a big deal. Adding a template demonstrating the concept is not.

-- Egil 16:40, 11 Feb 2005 (UTC)

One difficulty in implementing that, it appears to me, would be the fact that the types of mapping alternatives available are dependent on political boundaries as well as the coordinates (a problem for the templates as well, but perhaps more managable if the editors somehow determine those polital boundaries in choosing appropriate templates). I disagree about the "separate page" idea as well, and would rather see External links generated on the article's page. Gene Nygaard 16:20, 11 Feb 2005 (UTC)

The idea of linking the location to a special page is a solution to that: The user can then select between a number of different resources. Not only maps, but topological info, satelite photos etc. Using the ISBN as model, notice how the ISBN special page offers you links to many booksellers and libraries. Not all of them are relevant for any given book, but you are given enough info to select a good one.

One other note: To be able to handle the specifics of how the various resources want their URLs to appear, the thing generating the list of maps definitely needs to be written in Perl or Python or something.

-- Egil 16:40, 11 Feb 2005 (UTC)

I just confused myself into thinking of generating a new page specific to each reference, rather than a general one, with coordinate information somehow incorporated into the links on that page. Each resource should indicate the area for which it is available. Gene Nygaard 16:51, 11 Feb 2005 (UTC)

There is one good thing about the Geolinks templates as they stand now: they keep external links in the External Links section of an article, which is clean. Not that this is an requirement or policy, but it is consistent with much of the 'pedia. -- hike395 08:26, 12 Feb 2005 (UTC)

See also

Reversion

20m or 20 m, etc.

Eras

Traditional dates.

Superscript ordinals

ISO 8601

"22:00" or "22:00 hours"

IX Century

Percent symbol with space?

Links on non-full-length dates and centuries

Proposed revision

BCE in Y/M/D format

Christian Era vs. Common Era

Guideline suggestion: Avoid "January 14th" and "January of 2005"

Dates of birth and death suggested revision

Suggestion: Template for geographic coordinates