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

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 70

←

Archive 72

→

First sentence of "Years, decades, centuries"?

MOSNUM "Years, decades and centuries" starts: "This section describes how to link to years, decades and centuries. See sections that follow regarding when such linking is appropriate.". But actually it describes how to write years, decades and centuries, whether or not they are links. Perhaps it should be worded: "This section describes how to write dates expressed as years, decades and centuries. See sections that follow regarding when linking of these dates is appropriate.". Our discussions concern all mentions of centuries, etc, whether these are links or not. PamD 19:34, 12 July 2007 (UTC)

Yes, i had noticed that, and i agree with you. Johnbod 19:36, 12 July 2007 (UTC)

Seems non-controversial. I went ahead and fixed it (well, to a slightly stripped-down version of the above). Stephen Turner (Talk) 00:25, 13 July 2007 (UTC)

Well, only having started to look properly at this submanual in the past day, my impression is that the top has been taken over by date-link obsessives. It seems to go on and on about it at the expense of a focus on style. And it's all spattered with blue, which is such a distraction and looks messy. In the summary of this submanual that I'm preparing for the main MOS, and will post on its talk page in the next week or two for feedback, style won't be crowded out by this linking thing. Tony 00:32, 13 July 2007 (UTC)

Date Ranges

Good - it would be nice if we could also address the question of ranges of years: 1354-5, 1354-55, or 1354-1355 - about which it currently says nothing. See two sections in the archives here and here. Johnbod 02:16, 13 July 2007 (UTC)

Indeed; it should say not to abbreviate, in my opinion, because that's lazy and not encyclopedic language. — SMcCandlish [talk] [cont] ‹(-¿-)› 05:08, 13 July 2007 (UTC)

By not abbreviating, do you mean don't use two digits for the close of year ranges? I'm afraid I'd rather make that the norm. So much easier to read. But not one digit. Year ranges, of course, must be separated by an en dash. Tony 11:47, 13 July 2007 (UTC)

Yes, I mean that, and disagree that it is easier to read, but that's beside the point. This usage is utterly unworkable. Proof: "1454–51 BCE" is hopelesslessly, undeniably ambiguous, indicating either a span of a handful of years or alternatively of approximately a millennium-and-a-half. The longer-span interpretation is the only one that makes any sense, because there is no other way to express it, yet without prohibiting abbreviated usage, there is a very strong chance that 1454–1451 BCE was actually intended! Don't be lazy; doing so on Wikipedia often has grotesque consequences. — SMcCandlish [talk] [cont] ‹(-¿-)› 14:34, 13 July 2007 (UTC)

I don't think an example in BCE can be used to argue against using two digits for end of range in AD/CE dates. What proportion of Wiki articles involve BCE dates? This is the tail wagging the dog. I consider that 2 digits for in-century date ranges AD is clearest, easiest to read. Not one digit (ie use 1996–98 not 1996–8),not 3 digits (ie 1896–1931 not 1896–931). Dates need to be written out in full for BCE, where they work differently and can confuse readers because they work "backwards". PamD 14:51, 13 July 2007 (UTC)

...and, your BCE example is not even ambiguous. The 1500 years span would be written 1451 BCE–51 [CE] anyway. 19xx–xx notation seems natural and very common, especially for two consecutive years (see here or here). MoS is supposed to document the common usage (except if not obviously wrong), not impose it. Duja► 15:07, 13 July 2007 (UTC)

I was about to write almost exactly what Duja did. Tony 15:15, 13 July 2007 (UTC)

I think he meant 1451 BCE-51 BCE, which I suppose confirms his point about ambiguity. I am essentially in favour of two digits (1921-23) being standard for the CE, but think Pam is probably right about BCE dates. Johnbod 16:21, 13 July 2007 (UTC)

What?!? How can you be unaware that the year 51 BCE exists? of course one would write 1451 BCE – 51 CE if one meant to span the BCE/CE divide; that is not at issue here at all, in any form. I think you have completely misread what I wrote. I also do not follow the logic of the extended objection; it seems to mean "because a majority of dates will be CE, it's just fine and dandy if date specification certainty for every ancient history article is totally hosed because I'm too lazy to type '1971-1972' instead of '1971-72' or '1971-2'". <frown> That sounds probably more personal than intended; I'm simply trying to point out that convenience has understandability-fatal costs in encyclopedia articles. This is not the Rolling Stone magazine. Our topics span every possible date range understandable by human beings, and our date specification standards must reflect that. PS: The purposes of the MOS is emphatically not to "document the common usage" (that is what style guides like The Chicago Manual of Style are for; rather, it is to document prescriptive practices for Wikipedia articles, from a varied base of style guides, disambiguation (the main point here), usability and accessability, and other conventions and concerns, to produce the most encyclopedic prose we can. — SMcCandlish [talk] [cont] ‹(-¿-)› 16:16, 13 July 2007 (UTC)

The full date solution just looks odd to me; I see no objection to having a different standard for BCE dates. Johnbod 16:32, 13 July 2007 (UTC)

I must take SMc to task about these accusations of laziness, as in the section above: at issue is readability and concision—from the reader's perspective, not the typist's. Tony 16:36, 13 July 2007 (UTC)

What on earth is unreadable about "1972-1979"? If it is felt that abbreviation is so essential and useful (despite the problems it introduces; and a different standard for BCE and CE will be very problematic, because no one will know or understand it other than WP:MOSNUM geeks like us!), why all the opposition to "1972-9" as opposed to "1972-79"? It comes across as confusingly hypocritical. (Clarification: I don't mean this is in a personal way; I'm describing ideational structures, not human individuals.) — SMcCandlish [talk] [cont] ‹(-¿-)› 16:46, 13 July 2007 (UTC)

Firstly, "1788-9" is I think very rarely seen in respectable print; secondly it looks bad when mixed with "1778-83". Consistently using 2 digits for CE is easy enough to explain. Whether anyone takes any notice is a different matter. Most WP editors never use BCE dates anyway, and at least those that do would find an answer here if they looked. No doubt gnomes & bots could patrol also. Johnbod 17:02, 13 July 2007 (UTC)

I think that a range such as 1878–81 helps emphasize the length of the range, and is therefore easier to read correctly than 1878–1881. That is, by removing repeated and redundant info (the second 18) it allows the eye to focus on the significant part of the date. Indeed I could make a case for 1992–4 on the same grounds, that it emphasizes that the span is less than 10 years. But I'm willing to live with two digit abbreviated end-points only, and limit them to CE dates only, to avoid the ambiguity mentioned above. DES ^(talk) 21:32, 13 July 2007 (UTC)

I have to state very clearly that I think this "abbreviate for CE dates only" proposed solution would be a mistake, because it assumes that readers (as opposed to editors) will read and learn the manual of style; the case study I started this side debate with is illustrative of the problem. If readers casually encounter things like "1971-75" (AD) for 1971-1975, then "658-52 BC" will necessarily be ambiguous for them, and I think that is a dreadful result, even if (e.g. for the purposes of formal citation in school papers) the extra-dedicated reader can eventually find something here at MOSNUM clarifying it for them. More along this line is the very strong likelihood that many editors will in fact write "658-52 BC" when they mean "658-652 BC", because very few editors can literally memorize every single recommendation of the MOS, and those that are internally inconsistent are notoriously difficult for the WP community to truly absorb. No bot can fix an ambiguous date like that, since it will require going back to the original sources cited, some of which may not be available except after months of interlibrary loan waitlisting. I.e. the problem I'm raising here is by no means trivial at all, regardless how dismissive some would like to be about it. PS: Just because you do not edit articles that have something to do with the BCE date range doesn't mean that no one does; many editors specialize in such topics; there are thousands of non-stub articles dealing with the Classical world on Wikipedia. — SMcCandlish [talk] [cont] ‹(-¿-)› 23:32, 13 July 2007 (UTC)

In my exerience (after a quick tour of some Pharaohs etc. to confirm) this would only be adding to the MOS what most editors are doing anyway, both for BC and AD. Most AD dates use two figures, though as I said in the archive, I have had one editor change my two to four figures, and another change them back. Johnbod 00:14, 14 July 2007 (UTC)

I intend to propose a change in the wording to the effect that the closing year in date ranges is "normally" written with two digits, except [then provide exceptions]. Tony 01:55, 14 July 2007 (UTC) And here it is (an excerpt from the draft summary for the main MOS):

*Year ranges, like all ranges, are separated by an en dash (do not use a hyphen or slash: “2005–08”, not “2005-08” or “2005/08”). A closing CE/AD year is normally written with two digits (“1881–86”) unless it is in in a different century from that of the opening year (“1881–1986”). The full closing year is acceptable, but abbreviating it to a single digit (“1881–6”) or three digits (“1881–886”) is not. A closing BCE year is given in full.

Comments? Tony 03:21, 15 July 2007 (UTC)

fine so far, but I think BCE needs covering. Johnbod 17:03, 15 July 2007 (UTC)

It looks fine ~~for AD dates. Perhaps we need to add this qualification: "The closing year, for dates AD/CE, is normally written with two digits....".~~ - revised version addresses my concern. Only further suggestion would be as discussed in next section. (Previous comment wasn't unsigned, but got separated from sig in the splitting out of "2004/05"!). PamD 07:42, 16 July 2007 (UTC)

2004/5

Incidentally, one of the style guides I looked at specified that "/" is used for a period such as "financial year 2004/05" (or academic year, etc). I don't know whether that's worthy of a mention. PamD 17:09, 15 July 2007 (UTC)

Good point. Johnbod 17:22, 15 July 2007 (UTC)

The slash is proscribed in the current text. Are you suggesting that it be (1) allowed for consecutive years only, (2) allowed for any year range, or (3) proscribed as now? (I'd go with (3) only, or if pressed, with (3) and (1), which would be a substantive change to policy). Tony 02:12, 16 July 2007 (UTC)

I would be ok with (1) for the sort of thing it is common for - sports seasons, academic and financial years. As below, perhaps it should be permissable in tables only. Johnbod 02:20, 16 July 2007 (UTC)

I don't mind the slash for consecutive years, but it's a change in the policy on this page and on the main MOS, which proscribes slashes altogether. The exception can be inserted here and at the main MOS if people feel strongly enough ...? Tony 03:23, 16 July 2007 (UTC)

I've mini-sectioned, & moved your last up, which I hope is ok. I don't feel strongly myself, but then I never do that sort of article, or table. Johnbod 03:41, 16 July 2007 (UTC)

My take on it is this: the likes of 2004/5 is not a range but a year—it simply has a different starting and ending date to the regular ones (i.e. 1 Jan & 31 Dec respectively). So:

No, it should not be allowed for consecutive years only i.e. ranges thereof.
No, it should not be allowed for any year range.
No, it should not be proscribed as now.

I say allow it for these non-calendar years. J ɪ m p 05:06, 17 July 2007 (UTC)

Yes that it is my feeling too - better expressed. Only for regular defined periods of a year that do not coincide with the calendar year. Johnbod 15:14, 17 July 2007 (UTC)

Do we allow ranges of these years - eg "a steady increase in the financial years 1993/4–1995/6"? Or specify that "to" has to be used? And is it "2003/04" or "2003/4" - both are used in the above discussion. PamD 16:31, 17 July 2007 (UTC)

Can't see why not. J ɪ m p 03:13, 18 July 2007 (UTC)

This "/"-style is also commonly used in sport[s] where a year-long season crosses a calendar-year boundary, as in snooker. I.e., I agree with User:Jimp. — SMcCandlish [talk] [cont] ‹(-¿-)› 16:11, 26 July 2007 (UTC)

Further comment: I think that "2004/5" and "2004/05" should be deprecated in favor of "2004/2005", because the former two, though longer, are ambiguous. Many Americans especially use that shorter form to mean "May 2004". I see that all the time. Given that the largest bloc of readers of en.wikipedia is American, this would seem to be an obvious problem to avoid. — SMcCandlish [talk] [cont] ‹(-¿-)› 16:17, 26 July 2007 (UTC)

I agree. Not totally convinced that "/5" will often be taken as the month, but 2004/2005 removes all doubt. Chris the speller 19:07, 26 July 2007 (UTC)

2004-05

Looking to the ISO 8601 standard "1901-05" means "1901 May", so you need to specify "1901-1905" for a date range to remove that ambiguity.

Since the use of Month/Year dates in that format is not (surely to God) permissable in article text, there should be no ambiguity. Johnbod 00:40, 16 July 2007 (UTC)

Yep, and in any case would be hyphenated, not en dashed (although that distinction might not be conveyed to the quick reader). Should numerical month-year expressions be discouraged in the point elsewhere on the page that deals with ISO dates? I suspect so. Tony 02:12, 16 July 2007 (UTC)

I suppose people want to use them in tables - "date joined team", "date released" and so on. It ought to be easy enough to avoid confusion in those cases. Johnbod 02:20, 16 July 2007 (UTC)

Objection

I object to the guideline decided here. I think it should be left to a user's convenience whether to write down "1910-1915" or "1910-15". I do not object to rejecting the "/", I do not object to not allowing one or three digits, but this strikes me as a pointless tiresome rule, and more homework for editors over absolutely nothing. I personally deeply dislike using "1910-15", and I should not be expected to change this perfectly acceptable format because some users dislike it, especially since there is no question of it being "wrong" (while I share the view that it is simply lazy). The guideline should say that either of the two is acceptable, as long as they don't both show up together in the same article.

And let me add: there should be a limit on changing rules as we go, because some decision taken in some relatively obscure place, without proper exposure, can affect virtually the entire body of articles and waste a lot of energies in the process of correcting what does not need to be corrected. Dahn 18:58, 17 July 2007 (UTC)

Thanks for your comment, Dahn. The lazy thing is pure bunkum, IMV. As I've pointed out elsewhere (to SMcCandish, who was pushing this line), the change is from the reader's point of view. Otherwise, why would the very same people push for the hard-work thin spaces below (which looks to be inappropriate for implementation, sadly).

Please be aware that the proposal is to make two-digit closing year ranges only the preferred option, not a mandatory one. Subsequent wording directly refers to the use of four digits in that role. I'm sorry that you hate the two-digit option, but it's a standard usage (and much favoured where there are lots of numbers floating around in a text). Tony 02:38, 21 July 2007 (UTC) PS Please note that hyphens are unacceptable as range separators: "1910–1915", or "1910–15", not "1910-1915", or "1910-15"; see MOS. Tony 02:43, 21 July 2007 (UTC)

Template:daterange

Perhaps {{daterange}} should follow whatever the standard is. (SEWilco 22:13, 20 August 2007 (UTC))

I can't see what the point of this template is. Does it save typing? Does is avoid repetition of the year, if it's the same? (no) Tony 05:53, 21 August 2007 (UTC)

Commas in numbers

Why is text like this used?

"... large number such as 156,234,000,000,000,000,000,000,000,000 can be .... .... and a small number such as 0.0000000000234 can be written ..."

Shouldn't the 0.0000000000234 be written as 0.000,000,000,023,4 if commas are supposed to be used in large (I take that to mean large number of digits) numbers.

ISO 31-0 mandates digits be grouped into threes, with each group separated by a space, and with either a comma or a point as the whole-number to decimal-fraction delimiter.

This would give 156 234 000 000 000 000 000 000 000 000 and 0.000 000 000 023 4 (or 0,000 000 000 023 4 of course) respectively. Both are uncluttered and clear, and consistent. —The preceding unsigned comment was added by 85.210.61.32 (talk • contribs).

Commas are normally used instead of spaces in both British and American English, although only before the decimal point. Not in scientific literature any more, but in most contexts commas are still the normal way of writing large numbers. Stephen Turner (Talk) 00:00, 15 July 2007 (UTC)

I've never seen the commas in a small number. Looks odd, probably because I'm just not used to it. Your proposal is logical, but I don't think it's going to wash. Tony 02:01, 15 July 2007 (UTC)

I wouldn't support such a mandate. I think in the English world that the commas are just the norm in more places than the spaces. —MJCdetroit 04:01, 15 July 2007 (UTC)

I would prefer it with spaces. It is uncluttered and unambiguous

I'd prefer it with thin spaces as an optional alternative to commas, but they're a nuisance to key in ( ). Should it be an explicit option?

156 234 000 000 000

On a related issue, is there a problem in explicity allowing thin spaces between the common mathematical operators (+ – × = etc) and between values and units? Tony 01:31, 16 July 2007 (UTC)

Thin spaces are my preference. The nuisance that they are to key in is made worse by the fact that some machines have to be told it's Unicode ({{Unicode| }}) for this to work but the nuisance could be eased somewhat by writing a template (and/or adapting an extant one). However, since commas are the norm (and because of the nuisance), this could only be an optional alternative to commas rather than the preferred (or mandated) style. J ɪ m p 02:45, 17 July 2007 (UTC)

I like what you're saying. But if it's explicitly mentioned as an option (my preference), do we have to go into all that Unicode stuff, or can it be tossed off in a brief phrase? Also, strikes me that thin spaces have many standard uses, not the least between units and values, and mathematical symbols (perhaps, dare I say it, even between the clock-time and the am or pm, like “2:30 pm”—nice, eh?). I just wonder whether a separate point about the use of thinspaces as an alternative to normal spaces “where spaces are explicitly required in this manual” should be made, thus avoiding the need to mention it locally. Tony 08:20, 17 July 2007 (UTC)

Sounds good. No, you wouldn't want to go into all that unicode stuff on this page—that's how-to stuff whereas Ms of S are meant to be made of what-to stuff (all's needed is a link). J ɪ m p 03:11, 18 July 2007 (UTC)

Re: "However, since commas are the norm" ... It might be "your" norm, but it certainly isn't everyone elses. The word "norm" means "standard" in many European countries, and in this context the standard is ISO 31-0 which for numbers with many digits puts the only punctuation mark as the separator between the whole number and the fractional number. That is, "exactly one" can be represented by either "1,000" or "1.000" and "one-thousand" is always "1 000". Any website with an International audience would be wise to go for that common ground. 81.179.99.43 2007-07-19 15:05 (UTC)

Commas are the norm in the English-speaking world, and that's what matters in the English Wikipedia. Of course other Wikipedias wouldn't use them, but in the English Wikipedia we should stick to normal English language usage. Stephen Turner (Talk) 17:23, 19 July 2007 (UTC)

To me (as a native English user from the UK) commas in numbers look somewhat archaic - I'm personally used to spaces. --Neo 09:26, 24 August 2007 (UTC)

(outdent) Yes, (thin) spaces, to me, are much preferable; but the problem is that silly Internet Explorer 6 won't accept thin spaces, and thin spaces in any case are cumbersome to key in. Full spaces are just too lumpy. We're left with commas. Tony 11:55, 24 August 2007 (UTC)

Abbreviations for months

Why do some people insist on spelling out every 'month' date, i.e. "17 October 2005" instead of "17 Oct 2005" and then cite this page? I see nothing on this page that says that dates must be spelled out in full...Ryoung122 07:33, 16 July 2007 (UTC)

In section "Incorrect date formats", it states 'Always express a month as a whole word' and 'Do not use abbreviations like "Feb" ...', which seems pretty clear. Chris the speller 13:33, 16 July 2007 (UTC)

I never knew until now that abbreviated months also respect readers' preferred date order: compare [[17 Oct]] 17 Oct with [[Oct 17]] Oct 17. Nevertheless, I agree with spelling them out. Stephen Turner (Talk) 15:12, 16 July 2007 (UTC)

Actually, they don't. On my system, your examples are order-preserved (i.e., they show up as "17 Oct" and "Oct 17". Urhixidur 15:24, 16 July 2007 (UTC)

They do for me. I suspect this depends on the skin. I'm using monobook. DES ^(talk) 18:16, 16 July 2007 (UTC)

Do you have date preferences set, Urhixidur? What do October 17 and 17 October show up like? Stephen Turner (Talk) 01:55, 17 July 2007 (UTC)

both follow my date preferences, using unmodified monobook set to number first Modest Genius ^talk 19:58, 3 September 2007 (UTC)

Abreviation for ante meridiem and post meridiem

a dot m dot

I know this issue has been discussed before, without resolution, but I want to raise it again. I see everywhere the dots omitted in real life, and want to give WPians the option of either using the dots or freeing the initialism of them. This will be in my draft summary for the main article, for the consideration of everyone here.

But I'm unsure of the spacing issue. Pretend that we allow both dotted and undotted:

(1) At precisely 2:30 p.m., the whistle blew without fail.
(2) At precisely 2:30p.m., the whistle blew without fail.
(3) At precisely 2:30 pm, the whistle blew without fail.
(4) At precisely 2:30pm, the whistle blew without fail.

(1) is endorsed currently, by explicit rule and examples. (2) is not proscribed currently, but I don't like the look. Both (3) and (4) are currently proscribed. Somehow (4) looks good to me while (2) looks too dense.

At the moment, I feel that (1), (3) and (4) should be allowed.

Advice? Tony 02:30, 15 July 2007 (UTC)

Sounds good to me. (2) had never occurred to me. Johnbod 02:58, 15 July 2007 (UTC)

I've not done a proper survey, but my feeling is that 2:30 p.m. is most common in British English, and 2:30 PM is most common in American English. pm in lower case without dots feels wrong to me. Stephen Turner (Talk) 04:28, 15 July 2007 (UTC)

I haven't heard a reason for having more than one style. Does (1) offend some group? Loosening the standards would make WP look sloppier and set us up for edit wars, and I don't see where encouraging new variations helps editors or readers. Chris the speller 13:30, 15 July 2007 (UTC)

Offend some groups? Unsure that it has to come to that before an alternative is explicitly allowed. I really don't like the dots (particularly ugly in (2), which is currently permitted by the silence on spacing). I'll put up with the dots if no one else agrees that undotted should be allowed, but I firmly feel that the unspaced shouldn't be allowed with dots—it's just too crowded. The "reasons for having more than one style" is the same as for analogous issues (Br and Am Eng, 12- and 24-hour clocks, plus many more). I see "pm" without the dots everywhere in real life. Tony 01:37, 16 July 2007 (UTC)

I prefer the 24-hour format every time. Is 12:00 a.m. exactly midday or midnight? What about 12 p.m.? Is midnight of July 15 at the beginning or the end of the day? All of that is avoided by using 00:00 and 12:00 (and 24:00 for special occasions).

The date ambiguity of midnight is covered in the existing text, although clumsily. I prefer the 24-hour clock too, but there's no way people will agree to the proscribing of the 12-hour clock. Tony 01:37, 16 July 2007 (UTC)

(2) and (4) look odd to me and I rarely see times written in those ways. Since p.m. and a.m. are abbreviations, they certainly shouldn't be run into the number (an issue addressed in several preceding topics), and technically they should be abbreviated – although personally I'm comfortable with either. However, I frequently see "PM" and "AM" and they seem to be as widely accepted as "BC" and "AD" (and so on). Perhaps it should be "with periods" when in lower case and without when capitalized – and consistent usage throughout an article? Askari Mark (Talk) 17:08, 16 July 2007 (UTC)

How about this:

12:00 am	≡ 00:00
12:00 noon	≡ 12:00
12:00 pm	≡ 24:00

It avoids all the draw backs of the 12-hour clock, respects the actual meaning of am & pm, and makes so much sense. The major problem is, of course, I've just made it up ... oh well. Long live the 12-hour clock, though, warts and all. The 12-hour clock, I think, is what most of us English speakers relate to best, however, a distinction can be made. When talking about events confined to a localised context the 12-hour clock does fine but when talking about events of global significance I'd prefer the 24-hour clock for ease of translation to various time zones. J ɪ m p 04:44, 17 July 2007 (UTC)

You just have to provide the date when you write 12 midnight, unless it's obvious. What could be simpler? It's better explained in my new text on this:

"“Noon” and “midnight” are used rather than “12 pm” and “12 am”; the date of “midnight” is ambiguous and will need to be specified unless this is clear from the context."

If a contract is stated to run from midnight July 1 to midnight July 31, would you not believe that to be valid from midnight at the begin of July till midnight at the end of July 31? So how does adding a date make midnight unambiguous? −Woodstone 11:16, 17 July 2007 (UTC)

You're quite right, more precision is required than just providing a date. Thank you for picking this up. How's this?

"“Noon” and “midnight” are used rather than “12 pm” and “12 am”; whether “midnight” refers to the start or the end of a date will need to be specified unless this is clear from the context." Tony 11:26, 17 July 2007 (UTC)

Sounds good to me. I don't reckon we want to go into a whole lot of detail on this one since the cases where it'd be relevant you'd expect to be few & far between. J ɪ m p 02:52, 18 July 2007 (UTC)

consensus on the ay em pee em issue?

Looks like my wish to allow unspaced (2:30pm) has bitten the dust; and it seems that US usage is both upper and lower case. So we need to determine what's in and what's out. Here are another four options, concerning upper and lower case, dotted and undotted, but all spaced. Please voice your preferences.

(1) At precisely 2:30 pm, the whistle blew without fail.
(2) At precisely 2:30 p.m., the whistle blew without fail.
(3) At precisely 2:30 PM, the whistle blew without fail.
(4) At precisely 2:30 P.M., the whistle blew without fail.

First preference (1)
Second preference (1) and (2)
Third preference (1), (2), (3) and (4). Added after Johnbod's comment below: I think the caps stand out more than the numbers, which is a problem for me. Tony 03:27, 17 July 2007 (UTC)

The same Johnbod 03:34, 17 July 2007 (UTC)

How about (5) At precisely 14:30, the whistle blew without fail. :-)

Actually, would lean towards (1) since I've traditionally seen lowercase (uppercase may be a computer-era thing), and skipping punctuation would be faster to type.

However, the best solution would be to set up a user preference feature in the Wiki software, similar to how dates are handled e.g. how userprefs change the display of 16 July 2007. Dl2000 03:46, 17 July 2007 (UTC)

... similar to how dates are handled but without requiring the things to be linked. As for my preferences ... well, they're already listed in order of my preference so that's easy. J ɪ m p 04:10, 17 July 2007 (UTC)

So we'll take that as first pref (1) second (2), third (3) and fourth (4), I assume. Tony 04:49, 17 July 2007 (UTC)

Yep, or in other words, in this context my aversion to capitals is stronger than my aversion to full stops (P.S. not fond of the unspaced versions either). J ɪ m p 04:56, 17 July 2007 (UTC)

Some points: (i) We don't have any significant influence over what features are in the Mediawiki software. We should concentrate on advising usage given the current state of the software. (ii) "Would be faster to type" is not really a good reason for recommending one or the other, in my opinion. We should be looking at respected style guides to see what is recommended in formal writing. (iii) I write (1) in casual usage, but never in formal usage, so I would only recommend (2) here. Although I would let the Americans have the alternative of (3) if their style guides advise that format. Stephen Turner (Talk) 14:28, 17 July 2007 (UTC)

Stephen, these are worthwhile points, but I want to say that North American style guides tend to say to put the final punctuation within the quotes, where WP has bucked that illogical usage and gone with that of the other English-speakers. So while US style guides may carry some weight, they're not the definitive factor. Tony 14:31, 17 July 2007 (UTC)

First preference (2)
Second preference (2) and (2)
Third preference (2)

Americans have no trouble understanding or typing a.m. or p.m., and any assumed American/Commonwealth difference is probably imaginary, or at least wildly overestimated. Certainly people on both sides of the pond can understand "pm" or "p.m.", but I know which looks overly casual, and which looks encyclopedic. Chris the speller 19:35, 17 July 2007 (UTC)

Agree with this latest comment. Writing a.m. and p.m. is fine, not confusing and in line with other abbreviations (e.g., i.e.) according to other elements of the style guide. I can see no pressing reason to relax the guideline. Adding a remark confirming common practice in WP, to leave a space before them is justified. −Woodstone 20:20, 17 July 2007 (UTC)

"am" and "pm" without space or dots is what seems natural to me, but I seem outvoted. Style guide examples: The Times and Guardian both use am/pm with no space; Britannica online uses space and then small caps AM/PM. ODNB: no visible style guide, but most use seems to be "10.30 p.m." format. Can't find any times in Grove Music! I suppose this points towards "space and dots, lower case" as seems to be becoming consensus. But not capitals, please! PamD 23:22, 17 July 2007 (UTC)

I'm comfortable with any of the first three options, but capitals look more like an acronym, so (4) looks inappropriate and unappealing. The most "proper" option would be (2) – since it's an abbreviation – so that would be my first choice, followed by (1), and then (3) perhaps a somewhat more distant third. Askari Mark (Talk) 00:46, 18 July 2007 (UTC)

Summary thus far

Pam, I don't think this is a raw vote, but rather an attempt to form consensus.

Assuming that "spaced" is now not at issue, here's a summary of our attitudes thus far among the eight of us (hope I've got it right):

Option 1—lower case, undotted (2:30 pm) is the first preference of Johnbod, Jimp, Epbr123 (strongly), Pam and Tony; second preference of Askari; and not favoured by Chris, Woodstone and Stephen (although Stephen admits to using it "casually")
Option 2—lower case, dotted (2:30 p.m.) is favoured by Chris (strongly), Stephen (strongly), Askari, Woodstone; second preference of Pam, Jimp, Johnbod and Tony; no one ruled it out
Option 3—upper case, undotted (2:30 PM) is favoured by no one; tolerated by Stephen if US style guides are found to permit it, and not favoured by Pam (strongly), Askari, Jimp, Johnbod, Tony, Chris, Woodstone
Option 4—upper case, dotted (2:30 P.M.) is favoured by no one and not favoured by Pam (strongly), Askari (strongly), Jimp, Tony, Stephen, Chris, Johnbod, Woodstone

Others are welcome to enter this debate; but hurry, it can't drag on forever. At the moment, the results suggest that (1) and (2) be explicitly allowed, I think. Thus, the only change would be (1) the explicit allowance of lower-case undotted (currently not explicitly proscribed, and confused in the tabled example by the spaced/unspaced issue), and (2) the insistence on the space. Tony 04:15, 18 July 2007 (UTC)

The guideline states 'Times in the 12-hour clock end with lower case "a.m." or "p.m."'. By stating exactly what is allowed, it implicitly proscribes everything else, no? The only question it does not answer is whether "a.m." is preceded by a space, and we seem to have settled that. So the remaining question is whether to overturn the existing guideline and introduce alternative styles. I remain opposed to that. We already have a use for "am", as first-person singular present case of the verb "to be". Chris the speller 15:43, 18 July 2007 (UTC)

I prefer Option 1. The others look messy. Epbr123 19:08, 18 July 2007 (UTC)

Chris; whilst your arguments from the maintenance of the current consistancy and "which looks overly casual, and which looks encyclopedic" are strong; your argument from potential confusion with the first-person singular present case of the verb "to be" I've gotta say is kind of weak: it may confuse a robot (a poorly programmed one) but a human literate enough to read an encyclopædic article in English ... I doubt it.

Also, I just thought I'd throw these in not that I'd want to see this.

(6) At precisely 2:30 PM, the whistle blew without fail.
(7) At precisely 2:30 P.M., the whistle blew without fail.

J ɪ m p 02:18, 19 July 2007 (UTC)

Jimp, on the first-person singular present case of the verb thing, kind of weak is a correct observation, especially if you recognize it as a weak attempt at humor. I better put a smiley-face in there next time. As for my poorly programmed robots, touché, but I'm still proud of them. ;-) Chris the speller 03:10, 20 July 2007 (UTC)

Jimp, small caps are definitely an improvement on the normal caps, but I think it's too much bother to include them.

Chris, you're right and I was wrong, the current text does proscribe Option (2). That is what looks like changing unless there's a sudden reversal of opinion here. To exemplify what Jimp is saying, the grammar of "7:45 am happy to oblige" doesn't quite work, does it. The dotters used the same argument to try to proscribe the widely used "US" as opposed to their "U.S."—looks like a pronoun, they said. But "in the us" and "us foreign policy" don't work as pronoun, even when wrongly used in lower case to make this point. There's been a clear and inescapable trend towards losing dots in English, in the US and elsewhere—for decades, in fact, since the demise of the typewriter. I see the allowance of "am" and "pm" as part of that trend. Tony 04:22, 19 July 2007 (UTC)

MOS:ABBR

What about actual sources?

I'll bring mine to the party. The Chicago Manual of Style 15th ed., which I believe is the most comprehensive style guide on the planet – my copy weighs 3.2 lbs. (400 kg), at over 950 pages – says to use "a.m.", lower case, regular font, and with periods, or (in typesetting to use small-capitals without periods, but not regular capitals: "PM" (in normal caps), "am" (which is a normal English word; see elsewhere on this talk page for this periodlessness problem with "is" and "gal", etc.), and especially "P.M." (normal or small caps) are "wrong". All of these things are prescriptivist as hell, but Chicago's take that upper case (whether regular or small-caps) acronyms and the like are not dotted is pretty well supported in general usage. No one but my grandmother would write N.A.S.A. PS: I have to observe that all of this stuff is culturally in wild flux. I have books that are not as old as me that refer to "327 B.C." (not "BC"), and I even have one that used "B.C.E." - must've had a stodgy editor, willing to accept the new terms, but not to give up personally internalize punctuation methods. Hmm. Reminds me of someone... Maybe I should become an editor. Oh, I already am. I just don't get paid for it. <heavy sigh>. — SMcCandlish [talk] [cont] ‹(-¿-)› 21:48, 28 July 2007 (UTC)

PS: By contrast, Strunk and White's Elements of Style uses periods with every abbreviation and acronym, period, but it is considered stodgy (and I don't mean the 1920's edition, I mean the new 4th ed., revised by Edward A. Tenney and Oliver Struck, who I assume to be Wm. Strunk Jr.'s son). Fowler's Modern Usage (newest ver, Burchfield's Oxford rev. 3rd ed.) doesn't (that I've found so far) address the topic directly, but examples in prose throughout show a "period-happy" style as well (and it is a British edition, not American). My conclusions are that traditional style guides prefer periods, period; general ones like Chicago have a hybridized approach with some fairly compelling (and real-world-usage-based) logic, and the science market style manuals, like the ALA are very "death to periods!" in attitude. If I can find my copy, I'll see what the Wired Guide to Online Style from around the peak of the dot-com bubble ays (not "authoriative" from a prescriptivist point of view, but probably the only book of its kind, not counting entirely virtual competitors that are newer (but necessary probably delve a lot into post-blog (which also means post-IM, post-texting) style concerns, most of which I for one consider to be degradatory not progressive. — SMcCandlish [talk] [cont] ‹(-¿-)› 21:48, 28 July 2007 (UTC)

Global coverage of non-breaking spaces, the nowrap template, and thin spaces

None of these three issues is dealt with properly in the manual. All three are mentioned once, I think, but their application, whether optional or mandatory, should be global. We have:

"Preferably, use   for the space (25 kg) so that it does not break lines. This can be accomplished with the {{nowrap}} template".

It might have been a little kinder by adding: "Thus, {{nowrap|34 kg}} yields 34 kg".

And we have an obtuse reference to thin spaces that's a little negative in the context:

"The SI/ISO notation style uses a non-breaking thin space instead of a comma [in large numbers]".

I propose that these three issues be explicitly covered at the top in a separate section.

First, I want to sell you the idea of at least raising the profile of thin spaces in the manual. They look much nicer, IMO, and make reading linked items slightly easier by being closer than normal, but not bunched. They are a traditional technique for spaced items, and ISO requires it in some places. On WP, these two functions—non-breaking and thin space—cannot be achieved using both html codes together; however, they can be combined in the nowrap template. Here's an example:

Let me show you a few examples of how neat thin spaces look. The first in each example is unspaced (proscribed, quite rightly, by MOS); the second and third have a thin space and a normal space, respectively, both using the nowrap facility.

4:45pm
4:45 pm
4:45 pm

4:45p.m.
4:45 p.m.
4:45 p.m.

3.5mm
3.5 mm
3.5 mm

2+2=4,
2 + 2 = 4
2 + 2 = 4

p≤0.01
p ≤ 0.01
p ≤ 0.01

Here's a proposed wording for the top of the manual. I've gone for a recommendation to use non-breaking and a "look, it's available" for both the nowrap template and thin spaces.

Spacing

Non-breaking spaces

In compound items in which numerical and non-numerical elements are separated by a space, non-breaking spaces are recommended to avoid the displacement of those elements at the end of a line.
A non-breaking space can be achieved by keying in the html code " " instead of a normal space; thus, "19 kg" yields a non-breaking "19 kg".
Non-breaking spaces can also be achieved by using the {{nowrap}} template; thus, “{{nowrap|19 kg}}” produces a non-breaking "19 kg".

Thin spaces

Thin spaces are smaller than normal spaces, and may be used as an alternative to separate:
- the numerals and the undotted “am” and “pm” in 12-hour clock notation ( 12:29 am, rather than 12:29 am with a normal space)
- a year and the abbrevations “BCE/CE”, “BC/AD”, “BP” and “MYA” ( 542 BCE)
- “c.” and a year ( c. 846)
- a value and an abbreviated unit of measurement ( 34 km)
- the elements in scientific notation ( 10⁹ × 7.62)
- groups of three digits in large numbers, as an alternative to commas ( 26 183 044), and
- the elements in common mathematical operations ( 2 + 2 = 4).
Thin spaces should always be non-breaking. To make a non-breaking thin space, use the {{thinnbsp}} template, inserting the compound item using vertical bars instead of spaces; thus, "{{thinnbsp|34|kg}}" produces a non-breaking thin-spaced " 34 kg".
The {{thinnbsp}} template accepts most common elements. A notable exception is the equals sign, which is input by the htlm code "=", rather than "="; thus, {{thinnbsp|4|×|2|=|8}} produces a non-breaking thin-spaced 6 × 2 = 8. If the template is confused a character, look up the code for it.

Tony 07:23, 19 July 2007 (UTC)

Thin spaces have the drawback of not being well supported in certain important fonts and browsers: they actually are wider than normal spaces there. Christoph Päper

Comments on the proposal?

Please write them here. Tony 15:18, 19 July 2007 (UTC)

Looks good. What's the procedure for trying to get the {{nowrap}} template and/or " " added to the collection of markup which is offered in the box below "Save page" (could someone tell me what it's called, for future reference?) when one is editing? I can see its usefulness for many situations, but we need to make things accessible to all editors. People won't necessarily consult the small print of MOS but might, once they're aware of it, use one of these options for dates, times, etc where a space really shouldn't split over lines. PamD 07:48, 19 July 2007 (UTC)

Would love to, and had thought of asking Jimp about this. It's below the "edit box", I think. Tony 08:10, 19 July 2007 (UTC)

You are thinking of the Edit Tools. — Aluvus t/c 19:59, 19 July 2007 (UTC)

Still looks good. Now how do we get "space", "thin space", and "nowrap template" added to the editing toolbox (just realised that's probably the name for it?), so that they are easily available to people with average-to-lousy memories? PamD 15:51, 19 July 2007 (UTC)

In Opera 9, the examples using thinspace look exactly the same as those using a regular space (Opera ignores the difference). In IE 6, they display as a box (IE does not understand the character). The only browser on my system that renders the thinspace as intended is Firefox. That seems like a major issue to me. This seems to get at why it is a problem. — Aluvus t/c 19:59, 19 July 2007 (UTC)

Consider me sold on the issue of "raising the profile of thin spaces in the manual". I'm all for them. I'd like to see a non-breaking thin space as the recommended space for all those uses mentioned by Tony above (there may be others). I do like the idea of working this into something more significant.

The procedure for adding stuff to the edit tools: we'd have to get in touch with the developers.

On this computer also thin spaces come out as boxes. However, this problem can be solved using {{unicode}} (at least on this machine). The problem is that {{unicode}} and {{nowrap}} seem to dissagree with each other. {{nowrap|4:45{{unicode| }}pm}}, for example, justs gives nonsense; nor does {{unicode|{{nowrap|4:45 pm}}}} do any better.

Therefore, I've written a new template, {{thinnbsp}} (that stands for thin non-breaking space ... just had a nicer look to it than nbthinsp & it's easier to type). This new template solves both problems. It's also nice in that you don't have to type  —the non-breaking thin spaces are inserted automatically between the given parameters. Currently the template can insert up to twelve dozen thin spaces ... it could easily be extended if ever there be the need. See the following for examples of use.

`{{thinnbsp\|4:45\|pm}}`	gives	4:45 pm
`{{thinnbsp\|3.5\|mm}}`	gives	3.5 mm
`{{thinnbsp\|2\|+\|2\|=\|4}}`	gives	2 + 2 = 4
`{{thinnbsp\|''p''\|≤\|0.01}}`	gives	p ≤ 0.01
`{{thinnbsp\|12\|000\|000\|000\|000\|km}}`	gives	12 000 000 000 000 km

Note the html code in place of the equals sign (but see below).

J ɪ m p 02:09, 20 July 2007 (UTC)

Jimp, you're brilliant. Except for the equals sign, this solves the problem better than I thought possible. The only bug is the equals sign. I see that {{nowrap}} specifies that to include an equals sign in your non-breaking item, you have to add "1=" at the start of that item. Seems to indicate that the equals sign has some other (blanking-out?) function here and in your new template. I wonder whether there's a ready-made solution; tried "1=" in yours, but it doesn't help. Tony 02:33, 20 July 2007 (UTC)

Afraid the equals sign problem is pretty standard fair for templates. This is because they are used for naming parameters. Using 1= won't work because this would be to define the first parameter as empty. You could use 1== but that sets the first parameter to =. In this case it's the fourth parameter we want to equal =. Now, {{thinnbsp|2|+|2|4==|4}} doesn't work but numbering all of the parameters does.

{{thinnbsp|1=2|2=+|3=2|4==|5=4}} gives 2 + 2 = 4 as desired.

This is easier on the memory &/or avoids having to look code up but could get kind of tedious for large sets of parameters. J ɪ m p 03:03, 20 July 2007 (UTC)

OK, I've updated the proposed text above accordingly. I think the ?html code for the equals sign ("=") is an easier solution than the one you've worked out just above here, and may not have to be looked up if it's displayed in the Spacing section of the policy. Tony 04:08, 20 July 2007 (UTC)

Don't be too quick with "The only element ..." statements. Like any template {{thinnbsp}} is going to get confused by such characters as pipes (|), curly brackets ({ & }) and ordinary spaces ( ). J ɪ m p 05:05, 20 July 2007 (UTC)

OK, thanks, have a look now. Tony 05:50, 20 July 2007 (UTC)

Your template still produces a regular space in Opera, but no matter. Of greater concern is IE 6, where the spaces in your 12 trillion km example are basically invisible, rendering the number unreadable. There's also the nontrivial issue of the complexity of using (much less finding) this template; it's hard enough to get people to use the non-breaking-space to separate units from numbers. Going to all this trouble to insert a space is not likely to catch on quickly. After all, the space bar on most keyboards is quite readily accessible.

The large increase in complexity (and decrease in page-source readability) involved in using this template just does not seem justifiable for the sake of having a slightly smaller space. Particularly when one of the cited applications, equations, falls on its face when presented with something as common as an equals sign. Or when, as far as I can tell, Internet Explorer has no proper understanding of thinspace anyway. I'm genuinely not trying to rain on your parade (having used thinspaces in a number of non-Web documents in the past), but quite frankly none of this makes any sense at all. As much as I might like to have the option of using thinspaces here and there, the technical realities clearly get in the way. — Aluvus t/c 06:19, 20 July 2007 (UTC)

I don't go with your reasoning about the additional input involved, or the exceptional treatment required of the equals sign. No one is forcing anyone to use it. If Opera were a common browser, I'd be worried, but I've never heard of it. IE 6 is more of a problem. Jimp, do you have a response about IE 6? Tony 07:39, 20 July 2007 (UTC) PS Just tried it on IE 5.2 for the Mac (it's yucky compared with Safari): it renders the thin spaces as normal spaces. That's a minor problem, because it's likely to be fixed in later versions of IE. But this IE 6 (Windows, is it?) that renders the thin spaces as nothing—that's not so good. Tony 07:46, 20 July 2007 (UTC)

What I'm trying to tell you is that virtually nobody will use this template, because it is a lot more work to use this template than to just type a space. The fact that it breaks in a critical way when faced with the equals sign makes it useless for equations (for which there is always LaTeX anyway). IE for Mac will never be updated again, nor will IE 6 (discounting some mega-huge security vulnerability), so anything broken in those browsers is broken permanently. I can't test IE 7, but I wouldn't be surprised if it has the same issues with thinspace. Someone certainly needs to find out before anything about thinspace goes into the MOS. — Aluvus t/c 01:18, 21 July 2007 (UTC)

Again, extra keying in doesn't wash; otherwise, why would we suggest (and people already use) the code for non-breaking spaces? They're certainly more work than tipping the space bar once. But unless Jimp can come up with a technical solution, I think your point about IE 6 kills off thin spaces for the moment. Damn. Tony 01:51, 21 July 2007 (UTC)

My thoughts are the same as Aluvus’, particularly since I also use IE. Looking at Jimp’s five ‘thinnbsp’ examples, the first three read okay, but the fourth appears completely run together, and the fifth is practically unreadable (with no space at all showing between the 2 and the first zero). Assuming these issues can be worked out (such as with a slightly “fatter” thinnbsp, I would want to make sure that editors understand it’s an option to &nbsp, state which browsers have a problem with it, and ask for consistent usage in a given article. Askari Mark (Talk) 01:53, 21 July 2007 (UTC)

Thanks, Askari; but please read my previous entry here. Tony 01:59, 21 July 2007 (UTC) PS Does the same problem occur with the nowrap template? Since I now propose to implement only the first subsection above, concerning non-breaking spaces, we should consider removing the reference to the template if it's buggy. Tony 02:57, 21 July 2007 (UTC)

Why would people bother using such a template? Why do we bother editing Wikipedia at all? Decreased readability of source code ... but increased readability of the article: what do readers read? How do people find it? How do we find anything? We see examples of a thing's being used, we see references to it on pages like this. The more it's used the better known it becomes and the better known it becomes the more it's used. The fact that certain characters including equals signs have to have special treatment is less than ideal but I don't see it as a huge problem especially considering that this a problem not just with this template but with all Wikimedia templates. However, if thin spaces don't work on IE 6, then this is a problem. In fact, the main reason I made the template was to try getting rid of the boxes. On the version of IE I'm using {{unicode}} does the trick. Do I have a solution ... I wish I had ... or maybe I do. How's the six-per-em space work for you? Here's an example: with and without the unicode template. Works fine for me (with the unicode template): producing exactly the same as &ampthinsp; does.J ɪ m p 07:52, 22 July 2007 (UTC)