Re: Updated Australian time zone names/strings
Date: Thu, 5 Apr 2001 23:59:40 +1000 (EST) From: David J N Begley <d.begley@uws.edu.au>
since my last question everything has gone quiet:
There has been some activity recently. Let me try to summarize my understanding of the discussion. I'm not Australian, so everything I write should be taken as comments by an interested outsider who does not entirely understand the situation there. I see the following points of dispute: * How important are unique time zone abbreviations? Here I tend to agree with the point (most recently made by Chris Newman) that unique abbreviations should not be essential for proper operation of software. We have other instances of ambiguity (e.g. "IST" denoting both "Israel Standard Time" and "Indian Standard Time"), and they are not likely to go away any time soon. In the old days, some software mistakenly relied on unique abbreviations, but this is becoming less true with time, and I don't think it's that important to cater to such software these days. On the other hand, there is another motivation for unambiguous abbreviations: it cuts down on human confusion. This is particularly true for Australia, where "EST" can mean one thing for time T and a different thing for time T plus 1 second. * Does the relevant legislation indicate which abbreviations should be used? Here I tend to think that things are a mess, just as they are in many other countries. We Americans are currently disagreeing about which abbreviation to use for the newly legislated Chamorro Standard Time, for example. Personally, I would prefer to use common practice; I would like to refer to legislation only for examples of common practice, or as a tiebreaker. * Do Australians more often use "Eastern Daylight Time" or "Eastern Summer Time"? Do they typically prefix the time zone names with the word "Australian"? My own impression is that both "Daylight Time" and "Summer Time" are common and are widely understood, but that "Summer Time" is more popular; and that the leading "A" is also common but is omitted more often than not. I just used AltaVista advanced search and got the following count of page hits: 1,103 "Eastern Summer Time" AND domain:au 971 "Australian Eastern Summer Time" AND domain:au 613 "Eastern Daylight Time" AND domain:au 127 "Australian Eastern Daylight Time" AND domain:au Here "Summer" seems quite a bit more popular than "Daylight", particularly when we know the time zone is Australian and not US, say. The "Australian" prefix seems to be popular for Eastern Summer Time, but unpopular for Eastern Daylight Time. For abbreviations, tools like AltaVista are less useful because of ambiguity. Many hits are not really time zones, unfortunately, and many hits denote US time zones and not Australian ones. But here are the hit counts anyway: 161,304 "EST" and domain:au 25,156 "EDT" and domain:au 18,263 "AEST" and domain:au 10,416 "AEDT" and domain:au 14,538 "CST" and domain:au 5,728 "CDT" and domain:au 176 "ACST" and domain:au 29 "ACDT" and domain:au 7,539 "WST" and domain:au 68 "AWST" and domain:au This data suggest that Australians tend to omit the "A" prefix in practice. The situation for "ST" versus "DT" is less clear, given the ambiguities involved. * How do Australians feel about the abbreviations in the tz database? If you just count Australians on this list, I count 2 in favor and 3 against. One of the "against" votes (David Keegel) counseled delay, saying that both AEST/AEDT and EST/EST are widely used and understood in Australia.
So, what happens now?
The final decision is Arthur David Olson's, since he's maintaining the database. My own mild preference for now (given what's been said so far) would be to leave it alone.
Paul Eggert wrote: | * How important are unique time zone abbreviations? | | Here I tend to agree with the point (most recently made by Chris | Newman) that unique abbreviations should not be essential for proper | operation of software. I think this flies in the face of common sense and the old principle about being flexible in handling input while trying to make output as good as possible. The broken software consists of real mail clients out there that people are still using. Some of that software outputs email with dates in this form: Date: Thu, 21 Dec 2000 09:34:42 EST I have 217 recent messages in my mail folders with those dates. Many of them are from US sites and so are really -0500, but many of them are from Australian sites and mean either +1000 or +1100 with no way for software that wants to sort them to know about the Australian dates. I can't force people who write to me (who are often people I don't know) to replace their mail software just because I don't like the dates it generates. However, if the TZ data gave the Australian users unambiguous abbreviations for those zones, it would make life easier at little or no cost to anyone. | In the old days, some software mistakenly relied on unique | abbreviations, but this is becoming less true with time, and I don't | think it's that important to cater to such software these days. I don't agree, unless the cost is significant. As far as I can see, the cost here is nil. | On the other hand, there is another motivation for unambiguous | abbreviations: it cuts down on human confusion. This is | particularly true for Australia, where "EST" can mean one thing for | time T and a different thing for time T plus 1 second. This is an important point. | * How do Australians feel about the abbreviations in the tz database? | | If you just count Australians on this list, I count 2 in favor and 3 | against. One of the "against" votes (David Keegel) counseled delay, | saying that both AEST/AEDT and EST/EST are widely used and | understood in Australia. Since it seems to be agreed that AEST/AEDT are widely used and understood (and since it's clear that they can help to reduce confusion), surely this is an argument for the change. Since David Keegel is on the committee of one of the state chapters of AUUG (the Australian UNIX and Open Systems User Group), perhaps he could arrange for AUUG to conduct a survey of Australian system administrators so that we can get wider input into this question? I would suggest that the survey quote the main arguments that have been made for and against change and then invite people to state a preference. | > So, what happens now? | | The final decision is Arthur David Olson's, since he's maintaining | the database. My own mild preference for now (given what's been said | so far) would be to leave it alone. I know the decision is in Arthur David Olson's hands, but I would imagine that he will be responsive to the wishes of the affected parties. I'm keen to see more input into this.
<Caution: cross posted to both ietf-calendar and tz mailgroups. Please reply carefully> Since I'm a lurker on both the tz and ietf lists, occasionally I see that it's appropriate to mix the audiences. This thread from the tz list is whether the tz maintainers should be trying to uniquify the timezone abbreviations such as "EST" which can mean several different timezones around the world, depending on whether you ask an Australian or an American. Greg Black wrote:
Paul Eggert wrote:
| * How important are unique time zone abbreviations? | | Here I tend to agree with the point (most recently made by Chris | Newman) that unique abbreviations should not be essential for proper | operation of software.
I think this flies in the face of common sense and the old principle about being flexible in handling input while trying to make output as good as possible.
I'd certainly prefer unique and unambiguous abbreviations (AEST) as well as unique names "Australia/Sydney" based on the Continent/Largest City. Anytime we can reduce confusion and make something easier for people *and* computers to understand, we should.
|| The final decision is Arthur David Olson's, since he's maintaining | the database. My own mild preference for now (given what's been said | so far) would be to leave it alone.
I know the decision is in Arthur David Olson's hands, but I would imagine that he will be responsive to the wishes of the affected parties. I'm keen to see more input into this.
The tz database is the closest thing to a "standard" timezone listing. As such, there's a lot of benefit if it does the "right" thing. I've cc'd the ietf list since they are effectively "users" of this sort of data and might have some input. dmadeo
Date: Fri, 06 Apr 2001 13:08:42 +1000 From: Greg Black <gjb@gbch.net>
The broken software consists of real mail clients out there that people are still using. Some of that software outputs email with dates in this form:
Date: Thu, 21 Dec 2000 09:34:42 EST
But that software is not necessarily broken; it conforms to the standards, so long as by "EST" the intended time zone is -0500.
I have 217 recent messages in my mail folders with those dates. Many of them are from US sites and so are really -0500, but many of them are from Australian sites and mean either +1000 or +1100 with no way for software that wants to sort them to know about the Australian dates.
That certainly has been a problem in the past, but I think it's declining as people gain more experience with the problem. It would be helpful if someone could survey the incidence rate of this problem in general, and whether it's still a problem in practice. In a quick attempt to do this, I just checked all 4444 of the email messages sent to the tz list between 1986-11-24 and 2001-04-04, which I got from <ftp://elsie.nci.nih.gov/pub/tzarchive.gz>. I found 161 messages sent from an .au domain, the first one dated 1990. None of them had the bug that you describe. All 161 messages used the +0000 notation for time zones. (One message dated 1994 got the offset wrong, and used "-0900" instead of "+0930".) Admittedly the tz list is self-selected, but this still suggests that the problem is relatively rare in practice.
Paul Eggert wrote: | > Date: Fri, 06 Apr 2001 13:08:42 +1000 | > From: Greg Black <gjb@gbch.net> | > | > The broken software consists of real mail clients out there that | > people are still using. Some of that software outputs email | > with dates in this form: | > | > Date: Thu, 21 Dec 2000 09:34:42 EST | | But that software is not necessarily broken; it conforms to the | standards, so long as by "EST" the intended time zone is -0500. | | > I have 217 recent messages in my mail folders with those dates. | > Many of them are from US sites and so are really -0500, but many | > of them are from Australian sites and mean either +1000 or +1100 | > with no way for software that wants to sort them to know about | > the Australian dates. | | That certainly has been a problem in the past, but I think it's | declining as people gain more experience with the problem. | | It would be helpful if someone could survey the incidence rate of this | problem in general, and whether it's still a problem in practice. OK, I re-scanned my recent mail folders (25663 messages) and found 58 messages of Australian origin with just `EST' as shown above. Without revealing too much, I can say that some were from an ISP, most were from AUUG executive members, academics at Australian universities and people at government offices, with a few from hotmail. I know hotmail have fixed their system now. The others should all know better, but seem not to have things working as they should. I've noted the opposition to the proposal for change and, while not agreeing with it, acknowledge that my viewpoint seems most unlikely to carry the day so I shall desist from pushing it any further here.
Date: Fri, 06 Apr 2001 13:08:42 +1000 From: Greg Black <gjb@gbch.net>
Since David Keegel is on the committee of one of the state chapters of AUUG (the Australian UNIX and Open Systems User Group), perhaps he could arrange for AUUG to conduct a survey of Australian system administrators so that we can get wider input into this question? I would suggest that the survey quote the main arguments that have been made for and against change and then invite people to state a preference.
That sounds like a good idea to me. Mr. Keegel, what do you think? (It's always easy to volunteer someone else's time, eh? :-)
Date: Fri, 06 Apr 2001 13:08:42 +1000 From: Greg Black <gjb@gbch.net> Message-ID: <nospam-986526522.67277@maxim.gbch.net> | I can't force people who write to me (who are often people I | don't know) to replace their mail software just because I don't | like the dates it generates. No you can't - nor can you force people to set their clocks correctly so you can sort mail by date either. Basically "sort by date" is always going to get things wrong, for one reason or other, if you want to perform that kind of sort, you're just going to have to live with that. | However, if the TZ data gave the | Australian users unambiguous abbreviations for those zones, it | would make life easier at little or no cost to anyone. No it wouldn't. You can no more force those people sending from one of the very few mailers that still has that broken behaviour to update their timezone names than you can get them to update their mailers. If you believe that you can get something fixed, it would be far better for everyone to have the mailers they use fixed so they generate Date headers that conform to the RFCs, than to try to have them "fixed" via the back door (by changing the timezone string that the mailer gets handed) so that they now violate the RFCs (EST is legal in the Date header, AEST is not). The right way to achieve that is to bug the people who maintain the mailer in question of course - not those who are merely its users. If the people in question (those sending you this broken mail) won't install an updated version of the mailer they use, then it is unlikely anything that is done is going to fix the problem for you - at the very least you'd need to wait until there is yet another change to the AU timezone rules, which might encourage some people to install updated tzdata files. | I don't agree, unless the cost is significant. As far as I can | see, the cost here is nil. For nil cost you get nil effect. Something has to change, and someone has to make that change - that has costs. | | On the other hand, there is another motivation for unambiguous | | abbreviations: it cuts down on human confusion. This is | | particularly true for Australia, where "EST" can mean one thing for | | time T and a different thing for time T plus 1 second. | | This is an important point. Perhaps - whether having the abbreviation the same is better, or distinct is better, depends entirely upon the application for which it is to be used. If you're attempting to parse it, and decide what offset from UTC it means, then distinct would be better (that's what sorting broken Date headers requires). But that isn't a sane thing to be doing with timezone abbreviations in any case. For simply specifying a time having them the same works much better, as you never get odd things like "Sat Apr 7 13:59:33 AEDT 2001" which would be a date/time/zone combination that simply doesn't exist. When it is written as "Sat Apr 7 13:59:33 EST 2001" you don't even think about the timezone, other than to see "that's the one that applies where I am" so you simply see ("about 2pm Saturday wall clock time). Its the convenience of the latter that makes me think that the choice of "Summer Time" to go with "Standard Time" was very deliberate, so the abbreviation would remain the same. kre
From: Robert Elz <kre@munnari.OZ.AU> Date: Sat, 07 Apr 2001 14:07:13 +1000
For simply specifying a time having them the same works much better, as you never get odd things like "Sat Apr 7 13:59:33 AEDT 2001" which would be a date/time/zone combination that simply doesn't exist.
Oddities are rarer, but they still occur at times. For example, "Sun Aug 27 02:30:00 2000 EST" is a time stamp that didn't exist in Sydney, as the clock jumped from 01:59:59 to 03:00:00 that morning. Also, using a different abbreviation disambiguates time stamps within one hour of the fall-back transition. For example, with the current tz database and TZ='Australia/Sydney', the string "Sun Mar 25 02:30:00 2001 EST" is ambiguous, as it could mean either 2001-03-24 15:30:00 UTC or 2001-03-24 16:30:00 UTC. This ambiguity would not exist if Sydney used a different abbreviation for summer time. A practical example of this can be found in the accident reports published by the Australian Transport Safety Bureau. My guess is that the officials there dislike abbreviations ending in "DT" as the phrase "Summer Time" is more common, and they don't feel the need for the leading "A" as their reports are only about Australian accidents. However, they do need an unambiguous abbreviation so that their accident reports are precise. So they use EST/ESuT. See, for example, <http://www.basi.gov.au/occurs/ob9800604.htm>; it talks about a fatal crash of a flight with scheduled departure at 1500 ESuT and scheduled arrival at 1830 EST.
Its the convenience of the latter that makes me think that the choice of "Summer Time" to go with "Standard Time" was very deliberate, so the abbreviation would remain the same.
That's an interesting theory, but I think it more plausible that it was simply an accident. Other locales that use the phrase "Summer Time" do not have this problem (e.g. GMT/BST, CET/CEST) because (for historical reasons) they do not use the phrase "Standard Time". As far as I know, only Australia combines the American phrase "Standard Time" with the the British phrase "Summer Time". Perhaps this was because Australia imported the idea of time zones from America (as Britain wasn't wide enough to need them), while importing the daylight-saving terminology from Britain (as Australia used wartime daylight-saving before the United States did).
You can no more force those people sending from one of the very few mailers that still has that broken behaviour to update their timezone names than you can get them to update their mailers.
That's quite true. A similar problem occurs in New Zealand, but for a different reason. There, people mistakenly sometimes set their computers' equivalent of TZ to 12 hours behind UTC instead of 12 hours ahead of it, and then move their clock ahead by 24 hours to work around some of the problems with the incorrect offset. Their email headers say -1200, though, and this causes their mail to get mis-sorted. I chalk up most of these problems to inadequate time zone software more than to inadequate mail software. For example, a few people are still stuck with POSIX time zones and must set TZ='NZST-12...'. It is easy to go wrong and set TZ='NZST+12' instead.
Date: Fri, 6 Apr 2001 23:38:21 -0700 (PDT) From: Paul Eggert <eggert@twinsun.com> Message-ID: <200104070638.XAA27517@sic.twinsun.com> | A practical example of this can be found in the accident reports | published by the Australian Transport Safety Bureau. Yes, there are cases where absolute precision is required - I think they'd be better off using numeric offsets than inventing their own abbreviations, but as long as they're defining what works for them, it probably doesn't matter. | My guess is that | the officials there dislike abbreviations ending in "DT" as the phrase | "Summer Time" is more common, and they don't feel the need for the | leading "A" as their reports are only about Australian accidents. On the leading "A" in general, "A" meaning "Australia" is only ever used in places where everyone would know it is Australia anyway, A is such a common letter (AEST could be "American Eastern Standard Time" - since it covers all of North America, and I think Central America, probably even parts of South America, though it wouldn't be Eastern there... - it could also be African Eastern Standard Time, if East Africa ever decided to have a common name for their timezone.) "AU" (or AUS) is Australia, not just "A". Of course, inside Australia, people do sometimes use AEST to mean Aus EST when used by people who know there is an EST in North America, and who are trying to be (usually unnecessarily) clear - but take AEST as a string to someone (not on this list or other like it) in Europe, or anywhere in the Americas, and ask them to guess what it represents, and the chances of many of them guessing "A" for Australia is pretty small. | That's an interesting theory, but I think it more plausible that it | was simply an accident. That could be too, of course. | I chalk up most of these problems to inadequate time zone software | more than to inadequate mail software. For example, a few people are | still stuck with POSIX time zones and must set TZ='NZST-12...'. It is | easy to go wrong and set TZ='NZST+12' instead. People get the things wrong for all kinds of reasons - a month or so I sent some mail out that identified itself as coming from 1993 - I had run the battery on the laptop I was using completely dry, and that apparently caused its clock to lose all idea of the date when I rebooted with a changed battery (or AC, I no longer remember). I didn't notice, and didn't think to reset the clock... Then there's easily confused syntax (as in the + / - zone offset stuff). Then there are broken mailers that don't do the right thing even when the user is really trying to get it all right, and is prepared to do all the work. Then there are the users who simply don't care - they don't care in the slightest if the time on their computer, or its timezone, are anything like correct (sometimes deliberately even setting the time backwards so limited use evaluation licences keep on working...) and have the attitude that if the time is OK to them, no-one else should be concerned about it (I get mail sometimes that contains "I know the time is wrong, I might fix it one day" from correspondents that know I complain in replies if the date field is ludicrous). kre
participants (4)
-
David Madeo -
Greg Black -
Paul Eggert -
Robert Elz