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