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

[Guy Harris]

On Jan 5, 2024, at 3:31 PM, Guy Harris via tz <tz at iana.org> wrote:

> On Jan 5, 2024, at 2:16 PM, Stephen Colebourne via tz <tz at iana.org> wrote:
> 
>> See https://github.com/jodastephen/tzdiff/blob/master/data/Europe-London.txt
>> for the kind of data Java needs (transitions and rules).
> 
> So are there Java classes read those files and use them?
> 
> Or are they files produced by Java code that *uses* the data?
> 
> That file appears to list:
> 
> the first entry in Zone Europe/London ("LMT: -00:01:15");
> 
> a bunch of transitions, the first one being at 1847-12-01T00:00-00:01:15 and the last one being at 1997-10-26T02:00+01:00, with the date and time shown in ISO 8601 format (with 1997-10-26T02:00+01:00 meaning year 1997, month October, day 26, at 2:00 local time), "Gap" presumably meaning "the clock is turned forward" and "Overlap" presumably meaning "the clock is turned back", and with "to XXX" meaning "the offset from (proleptic?) UTC switches to XXX, with "Z" meaning "the offset from UTC is zero");
> 
> two rules that are, I guess, presumed to cover all times after 1997-10-26T02:00+01:00.
> 
> Most of those transitions are generated by rules for GB-Eire, but those rules are *not* in that file, even though they *are* in the europe source file.  What is the criterion for when it switches from showing transitions to showing rules?

It appears from the documentation of the java.time ZoneRules class:

	https://docs.oracle.com/javase/8/docs/api/java/time/zone/ZoneRules.html

that the "rules" are a collection of transitions and then a rule, in a fashion that seems similar to a TZif file's list of transitions and its POSIX-style TZ string.

Is there anything provided by an ZoneRules instance corresponding to a tzid that could not be derived from the raw contents of the TZif file for that tzid?  ("Raw contents" so as to distinguish "what's in the file" from "what are in the file *and* are made available by the APIs in the current version of the tzcode"; the latter can be changed without changes to TZif files, we'd just need to provide APIs to expose them.)