Updated Australian time zone names/strings

[Paul Eggert]

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