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

[Stephen Colebourne]

On Sun, 7 Jan 2024 at 02:21, Guy Harris <gharris at sonic.net> wrote:
> So, are there any cases where code would need information such as is provided by getRawOffset() for reasons *other* than "I'm trying to implement something that I could just do by calling the appropriate java.time method rather than duplicating what it does"?
> And are there any cases where code would need information such as is provided by inDaylightTime() for reasons other than the aforementioned?

It really doesn't matter if there are use cases or not - the API is
available and will not be removed. Developers have been free to use
them for 20+ years and will continue to do so, whether there are
better choices they could be making or not.

> > isDaylightSavings() returns true in summer for Dublin in Java - always has done.
>
> So I presume from that answer that isDaylightSavings(some time) is not always the same as the tm_isdst value in the structure returned by localtime(some time).
> If so, why was it decided to have it work differently?

In my opinion, it was TZDB that decided to change the meaning of the flag.

Stephen