On 1/7/24 18:08, Guy Harris wrote:
tzname[] is still there, although they note that if another thread does tzset() or something that behaves as if tzset() were called, the behavior of accesses to tzname[] is undefined
There's another problem with tzname that I forgot to mention. If you run localtime and it returns tm_isdt==0, then tzname[0] is well-defined but tzname[1] is not. This is true even in single-threaded apps. Similarly, tzname[0] is not well defined when localtime returns tm_isdst>0. For example, suppose TZ="America/Los_Angeles", T is during December 1, 1945, and we run localtime(&T). tzname[0] must be "PST", but tzname[1] might plausibly be "PPT" (the most recently-observed DST), and it might plausibly be "PDT" (the nearest DST in the future). The TZif file doesn't tell you which is correct. In this particular case the .zi file "northamerica" suggests that "PPT" is correct, but this detail is something I invented when I wrote that part of the .zi file. It doesn't have anything to do with US or California laws that I know about. This sort of invention is not something that I worried about when I invented it, because it didn't affect any info visible via the POSIX APIs, so I didn't bother to comment this sort of thing when it occurs in the data, which it does many times. As I recall, tzcode doesn't update tzname[1] when tm_isdst==0, so tzname[1] simply has whatever value it had before localtime was called. Anyway, whatever value tzname[1] has, it's garbage if TZDB Zones are being used. It's a misfeature of the POSIX API (or any other API) to expose this information, because there is no "correct" value and nobody really needs a "correct" value anyway.