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

[Paul Eggert]

On 2024-01-02 03:29, Derick Rethans via tz wrote:
> Previously, the following transitions existed:
> 
> 1994-03-27 01:00:00 UT (           764730000) =   1 [  3600 1   4 'BST' (0,0)]
> 1994-10-23 01:00:00 UT (           782874000) =   2 [     0 0   8 'GMT' (0,0)]
> 1995-03-26 01:00:00 UT (           796179600) =   1 [  3600 1   4 'BST' (0,0)]
> 1995-10-22 01:00:00 UT (           814323600) =   2 [     0 0   8 'GMT' (0,0)]
> 1996-03-31 01:00:00 UT (           828234000) =   1 [  3600 1   4 'BST' (0,0)]
> 
>                                             POSIX string: GMT0BST,M3.5.0/1,M10.5.0
>                                             std:   2 [     0 0   8 'GMT' (0,0)]
>                                             dst:   1 [  3600 1   4 'BST' (0,0)]
> 
> 
> But now, they include an extra one for Jan 1st, 1996, with the March 31st one
> now not being the last one:
> 
> …
> 1994-03-27 01:00:00 UT (           764730000) =   1 [  3600 1   4 'BST' (0,0)]
> 1994-10-23 01:00:00 UT (           782874000) =   2 [     0 0   8 'GMT' (0,0)]
> 1995-03-26 01:00:00 UT (           796179600) =   1 [  3600 1   4 'BST' (0,0)]
> 1995-10-22 01:00:00 UT (           814323600) =   2 [     0 0   8 'GMT' (0,0)]
> 1996-01-01 00:00:00 UT (           820454400) =   2 [     0 0   8 'GMT' (0,0)]
> 
>                                             POSIX string: GMT0BST,M3.5.0/1,M10.5.0
>                                             std:   2 [     0 0   8 'GMT' (0,0)]
>                                             dst:   1 [  3600 1   4 'BST' (0,0)]

It seems to be more complicated than that. In 2023c there's an explicit 
transition at 1996-03-31 01:00. In 2023d this transition is instead at 
1996-01-01 01:00.

As you mentioned, both transition sets induce the same set of timestamps 
from localtime, so in that sense they're both correct.

It seems to me, though, that neither transition is needed, and a TZif 
file lacking both transitions would also be correct. This is an 
optimization that could be added to tzcode someday.


> As far as I know so-far, the only effect it has on PHP users is 
> that they will now see an extra transition

It sounds like PHP is making an incorrect assumption, namely, that each 
entry in a TZif file is a transition that should be shown to users. This 
assumption is incorrect for current TZcode. For various reasons there 
can be an entry in a TZif file's transition table in which the 
timestamps before and after the entry have the same UTC offset, the same 
time zone abbreviation, and the same is_dst flags. This is not a 
user-visible transition and should not be shown to users.

In thinking about it a bit, it should be possible to change zic.c so 
that each entry in the transition corresponds to a change in the 
observed timestamp behavior (either UTC offset or abbreviation or 
is_dist). This would require a bit of nontrivial hacking, though.


> I couldn't find anywhere in tzfile.5 or theory.html whether the last
> generated transition must match a transition as specified with the POSIX
> string (as it did with 2023c and earlier), but I vaguely remember having
> read such a thing when I implemented the POSIX string parsing logic.

There is no such requirement.

Perhaps you're thinking of the requirement that the last entry in a TZif 
file's explicit transition table must have a time type that is 
consistent with the following TZ string. Although this is a requirement, 
it's weaker than what you suggest.