[tz] Extra transition for Europe/London with 2023d

[Paul Eggert]

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.