FW: Australian Timezone issues.

[Robert Elz]

    Date:        Tue, 11 May 1999 08:28:23 +0000
    From:        Chris Bitmead <chris.bitmead at bigfoot.com>
    Message-ID:  <3737EA27.549635D8 at 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