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---