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

[Stephen Colebourne]

On Sat, 6 Jan 2024 at 21:52, Guy Harris via tz <tz at iana.org> wrote:
>
> However, I'd still like to see what the people who use the source files to get STDOFF and SAVE information - and, for that matter, rule information - to give examples of how this is useful.

The various Java APIs all expose both the standard offset and the
actual offset, and say that daylight savings is when the two differ.

ZoneRules:
- getOffset(Instant) - gets the actual offset from UTC at an instant
on the timeline
- getStandardOffset(Instant) - gets the standard ("winter") offset
from UTC at an instant on the timeline
- getDaylightSavings(Instant) - gets the duration added to standard
offset to get the actual offset
- isDaylightSavings(Instant) - derived from whether standard and
actual are equal
- getTransitions() - the historic list of transitions, describing
discontinuities in the local timeline
- getTransitionRules() - the list of transition rules, describing
discontinuities in the local timeline in the future
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/time/zone/ZoneRules.java

Code in https://github.com/openjdk/jdk/tree/master/src/java.base/share/classes/java/time/zone

> So what do the (presumed) Booleans "dstLegal" and "dstSummer" mean here?
They allow the JSON file to express the difference between negative
DST and "are the clocks > standard offset" DST.

For clarity, the idea implies that the JSON is an alternative output
file of the project, just not a binary one.

On Sat, 6 Jan 2024 at 20:31, Paul Eggert via tz <tz at iana.org> wrote:
> What matters to users is "What time is it?". Questions like "Is daylight
> saving time observed now?", "Is daylight saving ever observed?" and
> "What is the standard time now, ignoring any DST observance?" are
> timekeeping nerds' means to that end, not the end itself, and are best
> left to tzcode's internals.

I understand you wish this were true. But it hasn't been true ever
since Java had a date-time API parsing the TZDB source files. Java
does expose those things, and will continue to do so. The idea I'm
putting forward is a better way to expose that data, which ensures
that the maintainer and consumer can easily see the data and whether
it has changed (deliberately or accidentally).

Stephen