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

[Guy Harris]

On Jan 7, 2024, at 5:14 PM, Paul Eggert <eggert at cs.ucla.edu> wrote:

> The Rule line says "S" so I think "EEST" is correct there. It is part of an EET/EEST pair.

I.e., "S" for "summer" rather than for "standard".

> If memory serves, tzcode addresses this by putting the most recently-used standard-time abbreviation into tzname[0], and the most recently-used DST abbreviation into tzname[1]. That's consistent with the macOS behavior you reported. For timezones specified by POSIX TZ strings this conforms to POSIX. But for timezones like Europe/Moscow, this is a thread-unsafe mess -- which is partly why tm_zone was invented and it's also why theory.html advises against the use of tzname.
> 
> I suspect that the draft next POSIX doesn't address this issue, though it should.

It has tm_zone, so I guess they address it in that fashion.  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, so they address that part by say "yup, it's thread-unsafe, Here Be Dragons".

The only lack of thread safety for tm_zone with localtime_r() is "If the tm structure member tm_zone is accessed after the value of TZ is subsequently modified, the behaviour is undefined."