FW: Australian Timezone issues.
Note that Chris is not on the time zone mailing list; be sure that any replies are directed to Chris. --ado -----Original Message----- From: Chris Bitmead [SMTP:chris.bitmead@bigfoot.com] Sent: Sunday, May 09, 1999 11:12 AM To: tz@elsie.nci.nih.gov Subject: Australian Timezone issues. I understand this is the appropriate email address for addressing issues with the standard UNIX timezone files. Has any thought been given to having the Australian EST timezone renamed to AEST? The conflicting name with the American EST has caused too much grief for too long. AEST is the proper abbreviation anyway in an international context and is reported on international radio broadcasts that refer to Australian timezones. The current practice of using plain EST simply breaks everything. For example, when a database dumps a time 'Sun May 9 11:07:06 EST 1999 in Australia, and then the database reads the time back in, it assumes that EST is New York time and everything gets screwed up. Another example, typing date in Australia's EST zone gives Sun May 9 11:07:06 EST 1999 But typing TZ=EST date Sat May 8 20:07:06 EST 1999 Inconsistent or what? As far as I know it is only Australian zones which suffer from this stupidity. It basicly renders timezones partly useless in Australia, because the timezone abbreviation of EST is ambiguous, and whenever interpreted, it's always done wrongly as NY time. This means that a lot of UNIX software simply doesn't work properly in Australia. Frankly I count the standard UNIX date program amoungst the many because the time it reports as EST is different to the date it reports when TZ=EST. What would have to be done to get this changed in the zoneinfo files? -- Chris Bitmead http://www.bigfoot.com/~chris.bitmead mailto:chris.bitmead@bigfoot.com
At 02:38 +1000 1999-05-11, Olson, Arthur David (NCI) wrote:
Note that Chris is not on the time zone mailing list; be sure that any replies are directed to Chris.
--ado
-----Original Message----- From: Chris Bitmead [SMTP:chris.bitmead@bigfoot.com] Sent: Sunday, May 09, 1999 11:12 AM To: tz@elsie.nci.nih.gov Subject: Australian Timezone issues.
I understand this is the appropriate email address for addressing issues with the standard UNIX timezone files.
Has any thought been given to having the Australian EST timezone renamed to AEST? The conflicting name with the American EST has caused too much grief for too long.
AEST is the proper abbreviation anyway in an international context and is reported on international radio broadcasts that refer to Australian timezones. The current practice of using plain EST simply breaks everything.
For example, when a database dumps a time 'Sun May 9 11:07:06 EST 1999 in Australia, and then the database reads the time back in, it assumes that EST is New York time and everything gets screwed up.
Another example, typing date in Australia's EST zone gives Sun May 9 11:07:06 EST 1999 But typing TZ=EST date Sat May 8 20:07:06 EST 1999 Inconsistent or what?
As far as I know it is only Australian zones which suffer from this stupidity. It basicly renders timezones partly useless in Australia, because the timezone abbreviation of EST is ambiguous, and whenever interpreted, it's always done wrongly as NY time.
This means that a lot of UNIX software simply doesn't work properly in Australia. Frankly I count the standard UNIX date program amoungst the many because the time it reports as EST is different to the date it reports when TZ=EST.
What would have to be done to get this changed in the zoneinfo files?
-- Chris Bitmead http://www.bigfoot.com/~chris.bitmead mailto:chris.bitmead@bigfoot.com
This is only part of the problem. "EST" ("Eastern Standard Time") is used whether daylight saving is in effect or not, and since not all the applicable region observes daylight saving, EST can mean two different things *at the same time*. In New South Wales, at least, it is even enshrined in law that references to "standard time" be construed differently depending on whether summer time is on force or not! See: http://www.austlii.edu.au/au/legis/nsw/consol_act/sta1987137/s10.html On the other hand, I thought the tz database did not attempt to specify unique time-zone abbreviations. (If only all time references would be qualified simply by a UT offset!) _______________ Alex LIVINGSTON Macintosh and Lotus Notes Support / Information Technology (IT) Australian Graduate School of Management (AGSM) The University of New South Wales (UNSW) / [Sydney] NSW 2052 / AUSTRALIA E-mail : alex@agsm.edu.au; cit@agsm.edu.au (IT) Facsimile: +61 2 9931-9349 / Telephone: +61 2 9931-9264 Time : UTC+11---[last Mar. Sun.---UTC+10---[last Oct. Sun.---UTC+11---
Alex LIVINGSTON wrote:
At 02:38 +1000 1999-05-11, Olson, Arthur David (NCI) wrote:
Note that Chris is not on the time zone mailing list; be sure that any replies are directed to Chris.
How can I join the time zone mailing list?
This is only part of the problem. "EST" ("Eastern Standard Time") is used whether daylight saving is in effect or not, and since not all the applicable region observes daylight saving, EST can mean two different things *at the same time*. In New South Wales, at least, it is even enshrined in law that references to "standard time" be construed differently depending on whether summer time is on force or not! See:
Are these just Australian problems? The reason I ask is that I am using an SQL database that purports to work fine everywhere _except_ Australia, where the instructions are that you have to rebuild the database from the source code with different Australian specific options set which disobeys all the normal rules. Also, I had a quick browse amoungst the tz files for other parts of the world and they seemed to have unique ids for time zones.
On the other hand, I thought the tz database did not attempt to specify unique time-zone abbreviations. (If only all time references would be qualified simply by a UT offset!)
UT offsets don't work because of summer time rules. I thought that was the whole point of these abbreviated timezones "EST" is that this small 3 letter token encompassed a whole lot of rules and historical data in a short abbrev. Can I suggest that the goal of the timezone database is not to name the zones according to govt regulations (which will inevitably conflict with other govts. After all, timezones are by their very nature a cross-jurisdiction concept), but rather to make computer software that works. If timezone abbrevs are not unique, why have them? I mean if they are not unique they are just utterly utterly useless.. Please CC any replies to me until I figure out how to get on the timezone mailing list.
At 11:37 +1000 1999-05-11, Chris Bitmead wrote (quoting me):
On the other hand, I thought the tz database did not attempt to specify unique time-zone abbreviations. (If only all time references would be qualified simply by a UT offset!)
UT offsets don't work because of summer time rules. I thought that was the whole point of these abbreviated timezones "EST" is that this small 3 letter token encompassed a whole lot of rules and historical data in a short abbrev.
Of course UT offsets work all the time! That's the whole point: specify the one applicable at the time. Do you need to know the UT offset at any other time than the instant being identified? Even time-zone abbreivations are *usually* different if daylight-saving is in effect; do you think they *should* be able to be the same for a certain geographic region regardless of whether daylight saving is in force or not (like the north American "ET", "PT", etc.)? The only circumstances I can think of when this would be useful would be giving times of day without date specification (e.g. business hours). But in such cases either "local" time can be assumed (and no time-zone qualification is necessary) - when geographic location is plain - or it should be made clear exactly what is meant by specifying UT offsets and giving some indication, taking into consideration the likely readership, of when each applies, e.g. "UT+10 from the Sunday nearest March 28 to the Saturday nearest October 27, UT+11 otherwise, at time of writing (1999)" or "UT-04 when daylight-saving is in force in the US, UT-05 otherwise". Even the latter case doesn't cover all bases, as the time zone of the locale is still subject to change (didn't Georgia recently decide to switch zones?). For long-term accuracy (of geographically tied references), specifying the relevant locale is the only way. _______________ Alex LIVINGSTON Macintosh and Lotus Notes Support / Information Technology (IT) Australian Graduate School of Management (AGSM) The University of New South Wales (UNSW) / [Sydney] NSW 2052 / AUSTRALIA E-mail : alex@agsm.edu.au; cit@agsm.edu.au (IT) Facsimile: +61 2 9931-9349 / Telephone: +61 2 9931-9264 Time : UTC+11---[last Mar. Sun.---UTC+10---[last Oct. Sun.---UTC+11---
Yep, you make a lot of good points. So would you advise the database developers not to dump dates with with the time zone abbrevs, but rather use offsets? BTW, what precicely is "locale". Is that "EST" or is that "Australia/Sydney". But still, I'm not fully convinced. I can imagine a database table storing say the times we are going to have a conference call. People access the database to see when their meetings are. People don't want to see "UTC+10" as the zone, because most people don't know what timezone offset they are in, and they don't often want to keep track when summer time begins and ends. If they want a meeting at 9:00am, they mean according to the local conventions. They want to see "AEST" or whatever. So if I'm in Sydney and get a message from this database saying "Conference call at 10:00am EST", and I cut and paste that time in an email to my friend in New York saying "is the conference call still on for 10:00am EST"? confusion will take place. What am I supposed to say? "Conference call 10:00am my time"? Then he will have to know the UTC offset of Sydney and summer time conventions, which he won't know. If I say 10:00am AEST, then (a) he knows what I mean and (b) he can use some tool to convert that time to EST (NY) time. I guess my point is: a) time zone description pnumonics are good for humans. b) UT offsets are good for computers, but bad for humans. c) The whole point of time zones is to satisfy humans, not computers. d) Therefore, if at all possible timezone abbrevs should exist, should be unique and should work properly. e) Yes, I think the abbrev should apply to the local conventions of a geographic region regardless of whether summer time is in effect. The only people who would care about the non-summer time when summer time is in effect are sophisticated enough people to use UT offsets. Am I way off base? I don't care if the timezone abbrev used were to be "Australia/Sydney". A bit wordy, but if that's what it takes then fine, at least it works. But having the string "EST" buried in the zone file for Australia/Sydney still seems majorly broken. Alex LIVINGSTON wrote:
At 11:37 +1000 1999-05-11, Chris Bitmead wrote (quoting me):
On the other hand, I thought the tz database did not attempt to specify unique time-zone abbreviations. (If only all time references would be qualified simply by a UT offset!)
UT offsets don't work because of summer time rules. I thought that was the whole point of these abbreviated timezones "EST" is that this small 3 letter token encompassed a whole lot of rules and historical data in a short abbrev.
Of course UT offsets work all the time! That's the whole point: specify the one applicable at the time. Do you need to know the UT offset at any other time than the instant being identified? Even time-zone abbreivations are *usually* different if daylight-saving is in effect; do you think they *should* be able to be the same for a certain geographic region regardless of whether daylight saving is in force or not (like the north American "ET", "PT", etc.)? The only circumstances I can think of when this would be useful would be giving times of day without date specification (e.g. business hours). But in such cases either "local" time can be assumed (and no time-zone qualification is necessary) - when geographic location is plain - or it should be made clear exactly what is meant by specifying UT offsets and giving some indication, taking into consideration the likely readership, of when each applies, e.g. "UT+10 from the Sunday nearest March 28 to the Saturday nearest October 27, UT+11 otherwise, at time of writing (1999)" or "UT-04 when daylight-saving is in force in the US, UT-05 otherwise". Even the latter case doesn't cover all bases, as the time zone of the locale is still subject to change (didn't Georgia recently decide to switch zones?). For long-term accuracy (of geographically tied references), specifying the relevant locale is the only way.
_______________ Alex LIVINGSTON Macintosh and Lotus Notes Support / Information Technology (IT) Australian Graduate School of Management (AGSM) The University of New South Wales (UNSW) / [Sydney] NSW 2052 / AUSTRALIA
E-mail : alex@agsm.edu.au; cit@agsm.edu.au (IT) Facsimile: +61 2 9931-9349 / Telephone: +61 2 9931-9264 Time : UTC+11---[last Mar. Sun.---UTC+10---[last Oct. Sun.---UTC+11---
Date: Mon, 10 May 1999 12:38:43 -0400 From: "Olson, Arthur David (NCI)" <olsona@dc37a.nci.nih.gov> Message-ID: <43E124CC389ED111B18D00805FEA1E63BC4D2C@nihexchange2.nih.gov> | Has any thought been given to having the Australian EST timezone renamed | to AEST? No. Or at least, I certainly hope it has not. | AEST is the proper abbreviation anyway in an international context According to whom? And then what would be the "proper" abbreviation for the North American EST in an international context? | and is reported on international radio broadcasts that refer to | Australian timezones. Yes, it would be, as do other countries long distance radio report longer time zone names than they use locally. | For example, when a database dumps a time 'Sun May 9 11:07:06 | EST 1999 in Australia, and then the database reads the time back in, it | assumes that EST is New York time and everything gets screwed up. Any code that does that is simply broken. Time zone names are a hint to humans. They simply aren't unambiguous. The two Aust zone abbreviations that are the same as their US equivalents (EST and CST) aren't the only ambiguous ones around (and then there are all the places that have no real concept of a timezone name at all - and the tz database just invents one for them - most of the countries in South East Asia are given "ICT", which seems to be "Indo China Time" which, as a label, means nothing locally at all). | But typing TZ=EST date This is a historical anomaly, it is retained for compatability only (and even then, that particular example isn't very compatible with anything, a traditional timezone string would have also had time offsets in it). | This means that a lot of UNIX software simply doesn't work properly in | Australia. Only if it is broken. | Frankly I count the standard UNIX date program amoungst the | many because the time it reports as EST is different to the date it | reports when TZ=EST. You give ambiguous input, you can expect to get ambiguous ouput. If you want to specify Australian time, use TZ=Australia/Sydney or whatever, and for North American, use TZ=America/New_York. You need to be more precise than just "eastern" anyway to represent historical times accurately. | What would have to be done to get this changed in the zoneinfo files? First get the relevant four Australian states to change their time legislation (or at least the one which most bothers you), so they label the time zone "Australian Eastern Standard Time" instead of just "Eastern Standard Time" (and in fact "Eastern Summer Time" which also gives EST as its abbreviation). Then it would make sense to change it. Alternatively, convince the whole world that time zone names ought always have a country, or region prefix - perhaps we could have "American Eastern Standard Time" (not US, as it applies in Canada, and perhaps parts of Mexico and other parts of Central America as well) and Australian Eastern Standard Time, and both could be AEST ... Time zone names are just an inherantly local phenomenon - anything, anywhere, which intends to write, and then parse, a date string needs to be sure that the string contains the numeric zone offset (or is simply written in UTC and doesn't bother with zone information at all). kre
Robert Elz wrote:
| Has any thought been given to having the Australian EST timezone renamed | to AEST?
No. Or at least, I certainly hope it has not.
why?
| For example, when a database dumps a time 'Sun May 9 11:07:06 | EST 1999 in Australia, and then the database reads the time back in, it | assumes that EST is New York time and everything gets screwed up.
Any code that does that is simply broken. Time zone names are a hint to humans. They simply aren't unambiguous. The two Aust zone abbreviations that are the same as their US equivalents (EST and CST) aren't the only ambiguous ones around (and then there are all the places that have no real concept of a timezone name at all - and the tz database just invents one for them - most of the countries in South East Asia are given "ICT", which seems to be "Indo China Time" which, as a label, means nothing locally at all).
Well I'll report that to the database developers. If that is the official way it is, and it's not just Australia in this boat, then I guess things have to change in how people write code. This is a quote from the POSTGRESQL database documentation... "If the compiler option USE_AUSTRALIAN_RULES is set then EST refers to Australia Eastern Std Time, which has an offset of +10:00 hours from UTC. Australian time zones and their naming variants account for fully one quarter of all time zones in the Postgres time zone lookup table."
| reports when TZ=EST.
You give ambiguous input, you can expect to get ambiguous ouput. If you want to specify Australian time, use TZ=Australia/Sydney or whatever, and for North American, use TZ=America/New_York.
But there doesn't seem to be a portable way to find out the string "Australia/Sydney" on your computer. Everything would be fine and dandy if strftime() returned the zone as "Australia/Sydney", but that's not what it does, it returns the mnumonic EST buried inside the zone file. If the mnumonic was "Australia/Sydney" then fine, but it's not.
You need to be more precise than just "eastern" anyway to represent historical times accurately.
Well, current times would be a start.
Alternatively, convince the whole world that time zone names ought always have a country, or region prefix - perhaps we could have "American Eastern Standard Time" (not US, as it applies in Canada, and perhaps parts of Mexico and other parts of Central America as well) and Australian Eastern Standard Time, and both could be AEST
Do we have to convince the world, or merely UNIX operating system vendors? After all, as you say zone names are ambiguous now, so nobody can be relying on them for other than (potentially inaccurate) information. So making them unique could only improve things no?
Time zone names are just an inherantly local phenomenon - anything, anywhere, which intends to write, and then parse, a date string needs to be sure that the string contains the numeric zone offset.
Even humans which don't carry time offsets and summer time rules around in their heads?
Date: Tue, 11 May 1999 08:28:23 +0000 From: Chris Bitmead <chris.bitmead@bigfoot.com> Message-ID: <3737EA27.549635D8@bigfoot.com> | This is a quote from the POSTGRESQL database documentation... | "If the compiler option USE_AUSTRALIAN_RULES is set then EST refers to | Australia Eastern Std Time, which has an offset of +10:00 hours from | UTC. Australian time zones and their naming variants account for fully | one quarter of all time zones in the Postgres time zone lookup table." You might want to ask them why they're bothering with time zone names at all. | But there doesn't seem to be a portable way to find out the string | "Australia/Sydney" on your computer. No, nor can there be. The very idea of the TZ variable is so that users can define the zone in which they prefer time values to be displayed. It makes no sense for the system to attempt to tell you what value you should use. If all you want is to use "local" time, then TZ ought not be being used at all (except in those brain damaged system V implementations where that is the only way to tell the libraries what zone should be used, in which case the default value is supposed to be set in some system wide initialisation file). | Do we have to convince the world, or merely UNIX operating system | vendors? After all, as you say zone names are ambiguous now, so nobody | can be relying on them for other than (potentially inaccurate) | information. So making them unique could only improve things no? If you could believe that it would work, and be reliable. Applications cannot depend upon the system using one of the "standard" timezone labels in any case - if you want to, you can easily change your own copy of the zonezone database to say "AEST" or "Australia/Sydney" or "Sydney (Australia)" or just about anything else you like. I don't recally whether tz still supports the TIMEZONE env var, if it does, any user can trivially set that string to anything they like. If an application is depending upon that value being "sane" it is quite simply broken. Applications that need to write and then parse, an ascii time value, absolutely must use a numeric depictation of the timezone (just as you will find in the Date header of this message - and of the message you sent). | Even humans which don't carry time offsets and summer time rules around | in their heads? No, 99% of the time the human should just use the system defined local time, and not attempt to override it at all. For the rest, then should use the location defined TZ value (Australia/Sydney and the like). If what you're saying (here and above) is that there isn't an easy way for the users to discover what that magic string can be, for the odd occasions when they need to use it (eg; to discover the time now in Fiji, I do "TZ=xxx date", but what do I give for "xxx"), then with that I agree, and it would be nice if there was a nice interface to the database to make things like this easy. But that is totally unrelated to doing anything at all with timezone abbreviations. kre
Robert Elz wrote:
You might want to ask them why they're bothering with time zone names at all.
Well it appears that they are working around the problems that arguably should fixed by the system timezone files. For example they recognise "AEST" as Australian Eastern Standard Time and "CAST" as Central Australian Standard Time..
| But there doesn't seem to be a portable way to find out the | string | "Australia/Sydney" on your computer.
No, nor can there be. The very idea of the TZ variable is so that users can define the zone in which they prefer time values to be displayed. It makes no sense for the system to attempt to tell you what value you should use.
Yes but there needs to be a default time zone for a machine. If the user has set TZ, no problem you just go getenv(), but if you are relying on the system default like 97% of people do, you can't find out what zone to use.
If all you want is to use "local" time, then TZ ought not be being used at all (except in those brain damaged system V implementations where that is the only way to tell the libraries what zone should be used, in which case the default value is supposed to be set in some system wide initialisation a file).
"some file" are the key words here. You can't write portable code to find out the user's zone unless they have explicitly set TZ which people rarely do.
No, 99% of the time the human should just use the system defined local time, and not attempt to override it at all. For the rest, then should use the location defined TZ value (Australia/Sydney and the like).
If it's admitted that the abbreviation is of no value, then why not abandon it and just report Australia/Sydney as the zone? The fundamental point is that the data that comes _out_ of the system ("EST"), is invalid when it is put back _in_. If the user sees "EST" come out of a piece of software (Unix date, or a database), they expect it to mean the same thing when they put it back in. Is that such an unreasonable assumption for a person to make? -- Chris Bitmead http://www.bigfoot.com/~chris.bitmead mailto:chris.bitmead@bigfoot.com
participants (4)
-
Alex LIVINGSTON -
Chris Bitmead -
Olson, Arthur David (NCI) -
Robert Elz