Updated Australian time zone names/strings

[Robbin Kawabata]

> From eggert at twinsun.com  Thu May  3 15:43:17 2001
> From: Paul Eggert <eggert at twinsun.com>
> 
> > From: "Olson, Arthur David (NCI)" <olsona at 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?

Also, TZNUMERIC would violate POSIX.  POSIX says date.1 and strftime() 
should use the TZ variable.  The %Z specifier for date.1 and strftime() 
(which prints the timezone abbreviation), should key off the TZ variable.

Robbin