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

This is an archive of past discussions about Wikipedia:Manual of Style. 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 85

←

Archive 87

→

On the meaning of recommend

Sorry for splitting hairs, but my understanding of the connotation of the word is closer to "suggest" than to "must do". Therefore, I've always felt free to ignore the recommendation to use non-breaking spaces between units as I don't like it. However, recently I've seen several FAC's opposed on the grounds that they don't use non-breaking spaces. Give me a break! ;-) I recommend that if we are going to treat style guidelines as if they were The Law, we should at least use clear language. We could do like the IETF and use the words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" as defined in RFC 2119. --Itub 09:06, 18 October 2007 (UTC)

I agree with you about both points (non-breaking spaces, clarity). Lightmouse 09:24, 18 October 2007 (UTC)

There is a certain amount of disagreement, here and elsewhere, about how "binding" the MOS and other similar meta-pages are meant to be. It may be impractical to settle on one definitive vision here. I would argue that the most reasonable approach is to take them as "things you should do unless there is a compelling reason not to", where the word "compelling" is very important. For instance, I can't think of a compelling reason not to use non-breaking spaces for numbers with units in prose (my memory was that MOSNUM included an exception for tables and such, but it isn't there now and I can't find that it ever was), other than it looking odd in the edit box (conversely, I think it is a silly thing to hold up a FAC over). But then, I would also say that the current wording of MOSNUM on this issue is too soft and ambiguous; perhaps I more strongly support this usage of nbsp than most. In any event, I would agree that the MOS should be more careful in its use of words like "recommend", and preferably take some of the ambiguity out of them. — Aluvus t/c 10:12, 18 October 2007 (UTC)

"recommend" is a bit wishy-washy. Fnag aton 11:51, 18 October 2007 (UTC)

I agree with you on both points, and nonbreaking spaces should not even be recommended as a general rule. They should only be used in unusual situations. They should never be used when the unit names re spelled out in full.

I may have missed any discussion agreeing on it, but the current wording is far more egregious than it used to be. Did anybody actually agree to the expansion here in the changed wording, from the old wording that talked about a non-breaking space between a number and a unit symbol? If not, that ought to be fixed.

Does any reputable style guide have anything about using nonbreaking spaces in that case. One thing I do know, is that this is not anything recommended for units of measure in measuement style guides such as the BIPM's SI brochure and NIST's Guide for the Use of the International System of Units (SI).

It seems as though some of the people who came up with that notion are under he impression that we never use numbers and symbols more complicated than "7 mi" or "40 W".

On the other hand, nonbreaking spaces rather than regular spaces should always be required within a number itself (e.g., 3 7/12 or 0.453 592 37–a format that occurs quite often, despite being deprecated here in the MoS), and either nonbreaking spaces or centered dots for multiplication within the symbols for a unit of measure (e.g. W/(m K)).

Note that the latter is not even covered by our current wording about non-breaking spaces, because these spaces are not separating "numerical and non-numerical elements". Yet, while we have a few people running around insisting on those nbsp cluttering up the edit pages where they aren't needed, hardly anybody makes sure they are there where they need to be. Gene Nygaard 04:27, 19 October 2007 (UTC)

Nor is the one within the numbers covered in the current wording; the spaces between "3" and "5" and between "2" and "3" in 0.453 592 37 is not separating "numerical and non-numerical elements". Gene Nygaard —Preceding comment was added at 13:54, 19 October 2007 (UTC)

Article titles for units

There is inconsistency in article titles for units. We have the following styles:

I came across this when I saw editors using both Knot (speed) and Knot (unit). I could not decide which was better. Should there be more consistency? Lightmouse 11:59, 18 October 2007 (UTC)

There is a wide variety of how much ambiguity there is in the word without any disambiguation. Furthermore, there are specific prior discussions of the naming in various things such as the move of Pascal to Pascal (unit) and its disambiguation page to Pascal.

Most of those which represent only one unit do have a redirect from the "(unit)" disambiguation. For knot, the (speed) article is the original disambigation.

Some of the little-used ones are probably badly named, including the improper dot in Tmc ft., and of dubious reason for existence in the same case (the same example).

The foot (unit of length) is an ugly hangover from the old days, one that I wouldn't mind seeing changed, leaving the old one as a redirect. The simplest way to avoid that clumsiness is to use the redirect from feet. Its format was apparently emulated in some of the obscure disambiguations you mention.

Some do need to disambiguate the same name being used for different units, used to measure different quantities.

Some units are so hopelessly ambiguous that they should be outlawed from use in all Wikipedia articles except those describing them, such as a ton of different tons, many with their own articles in addition to the tonnage article. Let's go with all megagrams, gigagrams, and the like to replace the three or more different mass units masquerading under that ambiguous name for starters! Gene Nygaard 05:03, 19 October 2007 (UTC)

Well, dammit, when did somebody change the redirect from feet to go to the body part? It used to work as I described it. Gene Nygaard 05:05, 19 October 2007 (UTC) I've changed the last chang back to go to the disambiguation page for now, should eventually go back where it was, see Talk:Feet. Gene Nygaard 05:38, 19 October 2007 (UTC)

The format knot (speed) is better than knot (unit) because it is more likely to remove ambiguity. For example pound (unit) could mean any one of pound (mass), pound (force) and pound (currency). Thunderbird2 14:02, 20 October 2007 (UTC)

I have been bold and moved the articles so they use the form suggested by Thunderbird2. Lightmouse 13:23, 24 October 2007 (UTC)

A space before and after the en dash?

Articles on people have their birth and death dates in parentheses after their name (November 24, 1859 – January 24, 1917) or (November 24, 1859–January 24, 1917). An unanswered question comes up though. Should there be spaces around the en dash? The MoS shows both styles. This isn't a big deal, I hope, but there should be a preference. Also, birth and death places should never be included in the parentheses with the dates, right? Psych less 17:22, 20 October 2007 (UTC)

If you dig through it thoroughly, it says no spaces around the en dash, unless one or both dates contain any spaces, so (November 24, 1859 – January 24, 1917) is correct, but (1859–1917) if only the years are known. Note the space after "c." in (c. 1859 – 1917), so spaces also go around the en dash. You are right that WP more or less discourages places inside the parentheses of the opening sentence. There was a clear prohibition until recently, when it was softened (despite the absence of a clear consenus to do so). There are a few editors who do not mind having the places in the opening, and might even bite if you move them to the body of the article, but I have moved many places out of the opening; these are mainly articles that have been copied from the 1911 Britannica, or were written by people who grew up reading the 1911 Britannica, so it seems right to them. Chris the speller 19:41, 20 October 2007 (UTC)

I think i is a wacky distinction. I've seen no reason to change someone else's usage, nor to worry about my own. It is especially so since we are not dealing with fixed printed pages, but rather than dynamic pages with line breaks added on the fly, and because the people who run around changing things like his for us do not think of the consequences such at a very silly-looking and distracting en dash starting a line, because it broke before it (check out Chris the speller's examples in the paragraph above; some of you will likely see that problem with your current screen settings, and if not, you can add or subtract some characters from a line and hit preview to see it for yourself). If you are going to specify such a rule with dynamic line breaks, please fix it to specify that a non-breaking space be placed before the en dash. And not normally after it, perhaps in some unusual circumstances.

Of course, the whole non-breaking stuff on the project page as it is now is nonsense, as discussed above, and has probably been changed and extended to strange areas without discussion. Gene Nygaard 02:05, 21 October 2007 (UTC)

The en dash looks awful when unspaced between items that have internal spaces. I don't see what the problem is. MOS is quite clear about it, and it's a simple rule to follow (also widely accepted out there). If page breaks are an issue, just insert a non-breaking space, as you're meant to in a host of situations. Tony (talk) 07:37, 24 October 2007 (UTC)

A spaced en dash would look God-awful ugly in "The non – San Francisco part of the world":

The non – San Francisco part of the world

That's an example given at Dash#Compound adjectives—with no spaces around the en dash there, of course. —Preceding unsigned comment added by Gene Nygaard (talk • contribs) 14:26, 28 October 2007 (UTC)

I wasn't aware that that section had been added to MOS. It's a different context, isn't it, from the date exemplified at the start of this section? On that section, I don't mind non–San Franscisco as an alternative to non-San-Fransisco, but would personally use the latter. I see that Scientific American, a journal that is superbly edited, IMV, tried the (unspaced) en dash in triple compounds for a while, but seems to have dropped it. Takes a while to get used to it. Tony (talk) 14:50, 28 October 2007 (UTC)

Certainly a compound of spaced items joined by an unspaced en dash is inelegant and awkward to parse.

As for the hard space (an easier name than non-breaking space), it is often essential in HTML documents because of the unpredictable ways such documents get displayed (affected by browser, viewing settings, size of window, and style and size of font). This problem is compounded at Wikipedia, since our editors are uneven in skill and diligence. Dynamic pages indeed!

We should, I think, educate editors about hard spaces and similar resources, pressing home the general theory behind them. Merely prescribing specific occasions for their use both looks mindlessly legalistic, and works against acceptance and recall. The theory of hard spaces is not rocket science: let's have a better section showing the techniques and motivations for their use – at WP:MOS where it belongs. We should press for an improved way of inputting hard spaces in Wikipedia editing, too.

All that said, we can sometimes reduce the need for hard spaces, making life easier for everyone. Why, for example, must there be a space after c. (for "circa") before a date? Not only does it need to be hard itself, it often calls into being other hard spaces – before an en dash, for example (see discussion above). Oxford Guide Style (OGS) wants c. to be set close the number that follows it, presumably for a reason of this sort.

In the end, I strongly favour pressing more of our guidelines into a central, enhanced, and well-crafted WP:MOS. There are many reasons for this, but the main one is that editors simply will not wade through reams of restrictive legalism in multiple pages – the majority of which are foreign territory even to core editors of WP:MOS. Things can be kept tight yet comprehensive there: but it will, I fear, require protocols for rational development and efficient discussion that so far elude us.

– Noetica^♬♩ Talk 10:04, 24 October 2007 (UTC)

I'm a centralist, within reason, so I support Noetica's call for conflating this page into MOS. Much of the job has already been done. There are a few issues, though. Do we need the geographical coordinates stuff in the central MOS? The calendar stuff is not there either. I suppose that, as long as MOS is well organised and signposted, there's no particular technical limit to its size, unlike the limits placed on normal articles for the sake of readability. The table of contents, surely, comes into its own in a resource such as a centralised MOS. I note that MOSHEAD has recently been conflated, and the setting out of the information much improved in the process.

I suppose I'm the user who has brought this on, by adding most of the revamped MOSNUM to MOS several months ago. There was not one objection to this when I flagged my intentions, either here or at MOS. My thinking was that numbers and dates are important enough to be included centrally.

Again, I support the call for making hard spaces easier to key in, and promulgating the need for greater use of them by WPians. Rob Church, a developer, might have been a good person to contact; but he appears to have left after difficulties with other users. I sent him an email. Tony (talk) 03:26, 29 October 2007 (UTC)

Some of us do prefer the places in the birth/death parenthetical in the lead, and there are thousands and thousands and thousands of bio articles doing that, so I don't see any clear actual consensus against it. I don't terribly mind it when those places aren't there, but really, the issue is so minor, I don't think the MOS needs to arm-twist either way. As for "non–San Franscisco"/"non – San Franscisco", ~~that's a no-brainer. That should be a hypen not an en-dash, and we don't space hyphens that way. I don't care if one magazine does it. They're simply being goofy.~~ — SMcCandlish [talk] [cont] ‹(-¿-)› 15:48, 24 November 2007 (UTC)

It's been pointed out to me, out-of-band, that the Chicago Manual of Style actually advocates en dash usage in the SF example. That kind of blows my mind, and I can't find (so far) any other alleged authority agreeing with them, but even so I feel compelled to strike the above comment. MOS could say "there are two ways of doing this and we don't care which as long as it is consistent within the article", but I do not advocate that position myself. I think it looks completely bizarre, and the CMoS seems to conflict with itself, in advising en dash use when and on the basis that the two terms are not a compound but are being compared/contrasted ("the France–Germany border"), and then in not quite the same breath forgetting that there was a logical reason for this usage and then advocating using en dashes for a typographic effect in the genuinely-compound (San Francisco) case in question. But I can't deny that they do so advise. My current position is that this is an outlier, and that MoS is not compelled to agree with CMoS on every minor detail, esp. since that work often conflicts with other style guides on nitpicky points like this. I.e., I'm "almost neutral", in that I won't pitch a fit if MoS is wishywashy on it, but I would strongly prefer that it not be, and not go along with CMoS on a "just because" basis. We defy CMoS on logical bases pertaining to consistency and encyclopedicness here and there, so this could be (I do not at presently insist that it is) one of those exceptional cases. I dislike these "you can do it this way or that way" MoS un-stances for the most part, but actually advocated one myself, so I am not in a position to be a hardliner about this. Argh; I just realized I'm engaging in an off-topic discussion; this should be at MOS not MOSNUM. — SMcCandlish [talk] [cont] ‹(-¿-)› 07:02, 28 November 2007 (UTC)

Units of measurement

As per the consensus at Wikipedia_talk:Manual_of_Style#Units_of_measurement, I will be updating this guideline soon to match the new wording at the main MoS. If you have any comments on this change, please comment on the MoS talk page. Thank you. Tim Vickers 03:05, 29 October 2007 (UTC)

Nice work, Tim. Tony (talk) 03:27, 29 October 2007 (UTC)

Now updated. Tim Vickers 17:07, 29 October 2007 (UTC)

Contradiction between WP:MOSDATE and WP:MOSLINK

There seems to be a minor contradiction in the guidance offered by WP:MOSDATE and WP:MOSLINK.

According to Wikipedia:Manual of Style (dates and numbers)#Autoformatting and linking:

Piped links to pages that are more focused on a topic are possible ([[1997 in South African sport|1997]]), but cannot be used in full dates, where they break the date-linking function.

According to Wikipedia:Manual of Style (links)#Intuitiveness:

Years should not be linked to articles, such as 2003 in music or 1985 in film, especially when part of a date.

Both guidelines agree that links to "Year in Topic"-type articles should not be used inside full dates; however, whereas WP:MOSDATE suggests that such links are acceptable in some circumstances, WP:MOSLINK discourages them in all cases. Although both pages are guidelines and should be treated with common sense, contradictions can generate confusion.

I have left a notice regarding this discussion at Wikipedia talk:Manual of Style (links). – Black Falcon ^(Talk) 03:00, 1 November 2007 (UTC)

Well, I'd much rather go with what is in MOSLINK. One of the problems with piped year-links is that hardly anyone clicks on them, because they look the same as those ridiculous links to plain year articles. Tony (talk) 03:43, 1 November 2007 (UTC)

I agree. This problem has been addressed in at least one of the projects. See: WP:ALBUM#Dating:

Quote: Do not use piped links to "years in music" e.g. [[1991 in music|1991]], instead add (see 1991 in music) where you feel it is appropriate.

Lightmouse 15:16, 1 November 2007 (UTC)

My view is that MOSLINK has its head in a dark place; but I address this more fully below in the related topic proposing changed language here. "Year in X" links often have legtimate purposes. — SMcCandlish [talk] [cont] ‹(-¿-)› 15:43, 24 November 2007 (UTC)

Superscript, unicode, html

I thought that there was a Wikipedia preference for a particular version of superscripts and times symbols. Certainly, I always prefer a version that looks wysiwyg in edit mode. Following a recent comment on my talk page, I looked for guidance and can't find any. Perhaps I just picked up the idea of a prefered version by seeing other editors changing the version. I am sure I have seen bots do it.

Can somebody explain what we are supposed to do with superscript, unicode and html characters? Lightmouse 15:09, 1 November 2007 (UTC)

In some cases, like changing × to a simple symbol, or α to α, the change is innocuous. But changing superscripts like 2 to ² isn't good for math articles. The font comes out different in many cases, so an equation like x²=y⁷⁵ looks strange. Moreover, when the internal TeX system creates HTML, it uses the method: <math>x^2</math> is rendered as x 2 by the Mediawiki TeX engine. So it's better, in math articles, not to replace superscripts by Unicode characters. — Carl (CBM · talk) 16:59, 1 November 2007 (UTC)

There have also previously been complaints that using superscripted-characters instead of often produces characters that are too small to read, which I have found to be generally true for IE. ² is typically just readable, ³ is typically too small. I would suggest sticking to . Conversely of course, screws up the line spacing a bit. — Aluvus t/c 19:20, 1 November 2007 (UTC)

My practice is to use the superscript characters only for unit symbols, and otherwise. There is also css code that can mitigate the line spacing issue, that could be added to user stylesheets or the site stylesheets if there is a consensus to do so —Random832 16:27, 2 November 2007 (UTC)

I'd like to see this get fixed in the site-wide CSS, as it is not a numbers issue alone, but also affects any line with a superscripted inline template like {{fact}}. It would just be a fine adjustment of CSS line-height and would come at the cost of pages being slightly longer, due to using up marginally more whitespace per line. Many would find it more readable with that change anyway, though. Oh, and I agree: Stick with , not the Unicode chars. — SMcCandlish [talk] [cont] ‹(-¿-)› 15:41, 24 November 2007 (UTC)

We already use plenty of line-height, we use 11⁄2-spacing. - what would fix it would be to reduce that for the tag, so that the superscripted material occupies the space between lines.—Random832 21:09, 29 November 2007 (UTC)

This div has a line-height of 1.5, the default, in case any of your stylesheets are overriding it. There are some superscripts throughout. Superscripts in red have no other CSS applied to them, other superscripts have a line-height of 0.Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis x^y nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est x^{y^z} laborum. Suspendisse porta, leo id pellentesque imperdiet, justo nunc posuere felis, vitae viverra dolor pede et wisi. Ut metus augue, rutrum pharetra, elementum nec, porta et, mauris. Praesent auctor cursus sem. Proin ut orci. Maecenas orci. Integer tempor hendrerit nulla. In massa orci, placerat sed, sagittis in, varius at, est. Ut x^y erat. Proin at sapien quis ipsum imperdiet pulvinar. Donec vehicula metus ac sapien. In eu urna. Suspendisse dapibus, ante ut facilisis dignissim, velit mauris congue odio, x^{y^z} nec suscipit sapien eros quis nisl. Aenean est. Etiam pharetra metus vitae est. And, as you can see with the staggering x^{y^{z^{t^etc}}}, a line-height of 0 will not result in the content failing to get space when it is needed.—Random832 21:20, 29 November 2007 (UTC)

Suggested addition

"Do not use an inappropriately high level of precision in coordinates. In latitude (or, longitude at the equator), one degree is about 110km, one minute 1.85km, and one second 30m. Longitude values are closer together further from the equator: at about 50 degrees latitude, one degree longitude is 72km, one minute is 1.2km, and one second is 20m."

I considered adding this in the section about coordinates, but figured i should get feedback on how to word this and where it should go. Also, maybe there should be additional guidance (large areas like countries, states, etc, should only be specified to degrees, cities only to minutes, but specific points of interest can be specified to seconds, or a fraction of a second, if known) —Random832 16:22, 2 November 2007 (UTC)

It would need to be more general; this is not a problem with coordinates, its a problem with over-precision more generally. I.e., don't give numbers like 23.349349293249 unless there is a really, really good reason to do so (as there is with pi, with molecular weights, etc., but not with the length of a bridge. Or with geographic coordinates except in some really unusual cases.) — SMcCandlish [talk] [cont] ‹(-¿-)› 15:36, 24 November 2007 (UTC)

Fraction hyphenation

This rule surprised me - this seems like an uncommon way to do things, and while i could think of some circumstances where you would hyphenate ("a three-eighths-inch wrench"), they're generally the ones where the fraction is hyphenated with something else - you (or, at least, I) wouldn't write "One and three-quarters" or "three-quarters of an inch" —Random832 17:01, 2 November 2007 (UTC)

Your examples of when to hyphenate fall under a different usage: that of compound attributive epithets, which are normally hyphenated (seven-year itch, much-needed break, but the break was much needed). North American writers are a little less likely to hyphenate where the item is unlikely to be ambiguous or unclear, although most do, at least in formal registers; and it must be said that many writers in other varieties of English fail to hyphenate in these circumstances when they should.

To return to your basic question—three eighths versus three-eighths, the reason for hyphenating is that it's easier to read, and in some cases overcomes ambiguity. The issue is most poignant when broken at line's end: "... three

eights of the standard measurement ..."

as opposed to:

ambiguity. The issue is most poignant when broken at line's end: "... three-

eights of the standard measurement ..."

Tony (talk) 23:35, 2 November 2007 (UTC)

I don't see any ambiguity. There is a quantity called an "eighth", of which there are three. "three eighths" for 0.375 is no more ambiguous than "three dozen" for 36. What else could it possibly mean?—Random832 21:12, 29 November 2007 (UTC)

Neutrality of disambiguation pages concerning SI vs binary prefixes

It has been suggested here that it would be best to keep disambiguation of units like kb or MB strictly neutral by restricting any mention of the mega vs mebi debate to the articles themselves (kilobit and megabyte for the stated examples). I think it's a good idea, as it avoids unnecessary repetition of the same old arguments. Any thoughts? Thunderbird2 18:48, 4 November 2007 (UTC)

I'm for it. The disambiguation pages are supposed to be summations anyways, and simply stating that they're a measurement of memory or storage as suggested gives a good summation. --Marty Goldberg 18:57, 4 November 2007 (UTC)

Sounds fair enough. Fnag aton 19:03, 4 November 2007 (UTC)

How about this example then (modelled on existing TB page, as suggested by the originator of the proposal):

Terabit (Tb), a unit of information, commonly used to quantify computer memory or storage capacity
Terabyte (TB), a unit of information, commonly used to quantify computer memory or storage capacity

Thunderbird2 20:24, 4 November 2007 (UTC)

This would be better, it gets rid of the "commonly" which for the kibibyte entry would have to be "rarely" or "uncommonly".

Terabit (Tb), a unit of information used to quantify computer memory or storage capacity
Terabyte (TB), a unit of information used to quantify computer memory or storage capacity

Fnag aton 21:36, 4 November 2007 (UTC)

Good point, but the bit especially has other uses too (eg communications). How about "a unit of information used, for example, to quantify ..." Thunderbird2 21:53, 4 November 2007 (UTC)

Yes indeed, that's good. Fnag aton 22:58, 4 November 2007 (UTC)

I have edited the following disambiguations: ZB, EB, PB, TB, GB, MB and KB. Thunderbird2 23:50, 5 November 2007 (UTC)

And now: EIB, TIB, GIB and MIB. Thunderbird2 00:08, 6 November 2007 (UTC)

Proposal to make use of seasons unambiguous

My arguments are outlined here Discussion in Village Pump - Policy —Preceding unsigned comment added by 131.172.4.43 (talk) 01:34, 5 November 2007 (UTC)

An interesting one. I back the sentiment of this proposal, but not its letter. In other words, the use of "spring 2009" is ambiguous and should be discouraged for that reason. But saying Jan-Mar 2009 is too specific, so that's no good either. A good guideline would be something like

change to an unambiguous description of the season (but only if you're absolutely sure).

The trouble is I can't think of a snappy way of saying "spring in the northern hemisphere" without spelling it out in full. Any suggestions? Thunderbird2 12:34, 5 November 2007 (UTC)

I thought about this one for a while w/r/t Mac OS X v10.5, which for a while had a release date of "Spring 2007". I eventually came to the conclusion that simply putting that phrase in quotes, and attributing it to a company press release or representative, is the most accurate option avaiable to us given the expectations of WP:NOR and WP:V. It's tempting to try and explain hemispheres and such but I think our readers will understand this. -/- Warren 13:20, 5 November 2007 (UTC)

Thing is though, this confuses the hell out of people from the southern hemisphere. They shouldn't have to jump through hoops to find out reliable information just because this place is northern hemisphere-centric. —Preceding unsigned comment added by 131.172.4.43 (talk) 17:33, 5 November 2007 (UTC)

I've discovered by looking around that often the ambiguity is removed in an article because it is in the context of a specific location (e.g., a named university campus or named city). Where that's not the case, use of a direct quote seems like the best solution if no better information is available, but surely an editor with better information should not be discouraged from making it unambiguous? As an example consider this article. It's nothing to do with IT or video releases, but it illustrates the problem. Essentially, in order to interpret the date "Spring 2007" correctly, the reader needs to know that the Victoria & Albert Museum is in the northern hemisphere. Many British editors and readers would know that, but an average reader in (say) South Africa or New Zealand may not. Isn't that the generic problem behind the proposal? The question is, how to convey that information unambiguously to the reader. There must be people out there who have encountered this problem before - but how did they solve it? Thunderbird2 17:46, 5 November 2007 (UTC)

This one's gone rather quiet. I offer two more pieces of evidence. First, in Economic history of Brazil there is reference to "spring of 1994" and to "summer of 1998". I honestly have no idea what that means (the equator passes through the middle of Brazil), thus illustrating the need to break the ambiguity in that article at least. Second, in Astronomy on Mars there is reference to (for example) "Northern Spring" and "Southern Summer". Why not adopt this convention in case of (resolvable) ambiguity? Thunderbird2 (talk) 19:16, 18 November 2007 (UTC)

Brazil gets its winter from the southern hemisphere. But maybe that should be clarified. (SEWilco (talk) 04:51, 20 November 2007 (UTC))

Ahh! Now that is an excellent idea. I fully support it.

-Zaij —Preceding unsigned comment added by 131.172.4.43 (talk) 11:46, 19 November 2007 (UTC)

Well, I see the problem, but not the solution. An article that read 'By the Spring of 1944, the war in Germany ...' would not read well as 'By the Northern Spring of 1944, the war in Germany ...' Hmains (talk) 04:35, 20 November 2007 (UTC)

Don't leave us hanging in mid-sentence. Go on, what happened next? I can't wait to hear how this turns out. (SEWilco (talk) 04:44, 20 November 2007 (UTC))

It would be best to avoid seasonal dating, but it is OK when the context makes the meaning apparent. When it is ambiguous the hemisphere should be indicated (when it matters; in gardening "Spring" might be sufficient). (SEWilco (talk) 04:49, 20 November 2007 (UTC))

The phrase "If it ain't broke, don't fix it" is applicable here. Thus 'By the Spring of 1944, the war in Germany ...' is fine like it is because it's already unambiguous. But if you make that 'By the Spring of 1944, the economy of Brazil ...' then you have a problem. Thunderbird2 (talk) 08:31, 20 November 2007 (UTC)

I just noticed that WP:SEASON already addresses this. Isn't the problem caused by editors not following the existing guidelines? Thunderbird2 (talk) 17:39, 22 November 2007 (UTC)

I think you're right Thunderbird2. But I think the problem is very wide spread. Is there any way we can raise editors awareness to this issue? Also I still have a probelm with the fact that people think that because companies are ambiguous and use seasons as release dates (movies and TV season in particular) then it is okay for wiki to be ambiguous. For example 2007-08 United States network television schedule has the US Fall Schedule. I understand that the TV networks use this term a lot and within the USA it is well understood when they are talking about, but with TV shows being showed in Australia (sometimes) within the same week as in the US a lot of people in Aus use wiki to get info on the shows (not to mention people who illegally download the shows). Given this I (as reader from Aus) would not mind pages such as this using Fall frequently BUT there should be a clear note after the first usage that says something to the effect of "Fall schedule typically refers to the months of..." Shniken1 (talk) 23:52, 22 November 2007 (UTC)

This page can't raise general awareness; too few editors are aware of it. WP:SEASON says all we can reasonably say. (I may be septentriocentric, but attempting to edit for someone who does not clue in that U.S. Fall schedule refers to the hemisphere in which the United States lies is the work of Sisyphus. Leave it to the Simple English wikipedia; that's what they're for.) Septentrionalis PMAnderson 06:38, 23 November 2007 (UTC)

Speak in terms of quarters, where appropriate if you have specific month ranges and they don't overlap quarters. Doesn't come up often. Use early-mid-late where that works, which is almost any where. I do this stuff all the time. I see a "summer 2008" and change it to mid 2008", a "winter 2006/2007" (which actually isn't ambiguous if you force Aussies to think about it, since their winter doesn't overlap years, but why make them think about this?) to "late 2006 – early 2007", and so on. Trivial, really. I don't think we need to have a huge thing about this in any of the MOS pages. — SMcCandlish [talk] [cont] ‹(-¿-)› 15:31, 24 November 2007 (UTC)