FW: Australian Timezone issues.

[Chris Bitmead]

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 at agsm.edu.au; cit at 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---