OK, how about this idea? If TZ='Australia/Sydney:' then use numeric abbreviations. The basic idea is to append a suffix that cannot possibly be part of a portable POSIX file name.
I guess we could, though I'm not overly enamoured with the "cannot possibly be part of a portable POSIX file name" part. We should certainly not be presuming that any such names can be used, and should not be naming zones in non-portable ways, but if someone decides to name a timezone file /path/to/EST:EDT (and it happens to work on his system) I'd prefer not to break things.
Of course, it can be documented that ':' is magic in TZ file names (or what would otherwise be a TZ file name) but it does seem a bit ugly.
Another possibility would be a separate environment variable that, if defined, would request numeric abbreviations. This has the advantage (and disadvantage) of providing for some system-level control: putting TZNUMERIC=1 (or whatever) in the system-wide startup file would buy numeric abbreviations no matter what TZ value a particular user set up (unless, of course, the user undid the TZNUMERIC). --ado
From: "Olson, Arthur David (NCI)" <olsona@dc37a.nci.nih.gov> Date: Thu, 3 May 2001 10:03:51 -0400
Another possibility would be a separate environment variable that, if defined, would request numeric abbreviations. This has the advantage (and disadvantage) of providing for some system-level control: putting TZNUMERIC=1 (or whatever) in the system-wide startup file would buy numeric abbreviations no matter what TZ value a particular user set up (unless, of course, the user undid the TZNUMERIC).
I can seem some problems with this approach. For example, I've written shell commands like this: LC_ALL=C TZ=GMT0 date in order to get a string like the following reliably, in all environments (even those where "date -u" doesn't work): Thu May 3 22:32:37 GMT 2001 But with TZNUMERIC, the output might look like this instead: Thu May 3 22:32:37 +0000 2001 and the extra data might mess up the output format. The Theory file says the following about TZ, explaining why the tz code uses TZ rather than some other environment variable. It was recognized that allowing the "TZ" environment variable to take on values such as "America/New_York" might cause "old" programs (that expect "TZ" to have a certain form) to operate incorrectly; consideration was given to using some other environment variable (for example, "TIMEZONE") to hold the string used to generate the time zone information file name. In the end, however, it was decided to continue using "TZ": it is widely used for time zone purposes; separately maintaining both "TZ" and "TIMEZONE" seemed a nuisance; and systems where "new" forms of "TZ" might cause problems can simply use TZ values such as "EST5EDT" which can be used both by "new" programs (a la POSIX) and "old" programs (as zone names and offsets). Isn't this argument still sound, and doesn't it argue against moving the functionality into a new environment variable like TZNUMERIC?
participants (2)
-
Olson, Arthur David (NCI) -
Paul Eggert