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

[Paul Eggert]

On 2024-01-06 12:45, Guy Harris via tz wrote:
> there is no inherent reason why the TZif format, for example, should
> limit itself to supporting only the date/time functions that POSIX and
> the C standard currently happen to provide

Although an API *could* support deeper interrogation of TZif details, I 
doubt whether that'd be a good idea. The distinction between stdoff and 
tm_gmtoff is not always clear, any extra information you'd extract from 
the data could well be dubious (certainly there are dubious corners in 
this part of tzdata now), and improving tzdata and maintaining the 
result would require unnecessary work.

We saw an instance of this sort of thing in America/Nuuk last year. 
Before 2023d, summer 2023 was marked as daylight saving time, but 2023d 
changed that to standard time. Although nobody in the real world cared 
(because it didn't affect UTC offsets or even abbreviations), the change 
consumed nontrivial maintenance effort. And the only reason the change 
was needed was because of tm_isdst, a feature that should never have 
been made visible to users in the first place.

I wouldn't want even more unnecessary maintenance make-work to follow 
from exposing even more unnecessary details to users.