FW: FW: Australian Timezone issues.
Olson, Arthur David (NCI)
olsona at dc37a.nci.nih.gov
Tue May 11 13:14:46 UTC 1999
From: Chris Bitmead [SMTP:chris.bitmead at bigfoot.com]
Sent: Tuesday, May 11, 1999 4:30 AM
Cc: Robert Elz
Subject: Re: FW: Australian Timezone issues.
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.
> | 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?
More information about the tz