From: Jonathan Lennox <lennox@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....