bug or feature? mktime sets tzname to historical zone names

[Paul Eggert]

> From: Jonathan Lennox <lennox at cs.columbia.edu>
> Date: Sat, 16 Jun 2001 20:29:35 -0400 (EDT)
> 
> mktime() *also* sets tzname, to the time zone in effect at the time
> of mktime()'s argument.

If the TZ environment variable has the POSIX-style value
"EET-2EEST,M3.5.0,M10.5.0/3", then POSIX requires that mktime must
behave as though it called tzset, and tzset must set tzname[0] to
"EET" and tzname[1] to "EEST".  From what you write, the Olson code
conforms to POSIX in this respect.

If TZ uses an Olson extension like "Europe/Riga", then POSIX does not
define the behavior.  However, some programs rely on
tzname[!!tm->tm_isdst] being set for the requested time, and (from
what you write) the Olson code is compatible with these programs.

tzname[!tm->tm_isdist] is a bit trickier.  Few programs rely on this
value, and the few that I've seen have all been broken, one way or
another.  In the Olson model, every instant of time can (in principle)
have a separate time zone abbreviation, time zone abbreviations do not
come in standard-time/daylight-saving-time pairs, and it's possible
for a DST abbreviation to have no corresponding standard-time
abbreviation and vice-versa.  Hence in the Olson model, programs
should not rely on tzname[!tm->tm_isdst] having useful information
after functions like mktime and localtime are invoked.


> Is this:
> * a bug, which should be fixed in tzcode?
> * a feature, and thus I need to make sure this behavior is maintained by any
> changes I make to the guts of tzcode when adding the thread-safe functions?
> * undefined behavior, since mktime() behaves "as though it called tzset()",
> but tzset() is poorly defined in the presence of changing time zone
> abbreviations?

It's defined behavior for POSIX-style TZ settings.

For non-POSIX-style settings, I would say that only the one member of
tzname is defined; the other member is not.  But this should probably
be documented somewhere....