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

[Derick Rethans]

On Fri, 5 Jan 2024, Paul Eggert wrote:

> On 2024-01-02 03:29, Derick Rethans via tz wrote:
> > Previously, the following transitions existed:
> > 
<snip>
> 
> 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.

I thought that the explicit transition at 1996-03-01 00:00 was intended, 
as that is also the exact time the POSIX rule inserts a transition at 
the same time.

My surprise was more that there is a "new" entry at 1996-01-01 for 
Europe.London, and several others for other timezones, as you can see in 
https://gist.github.com/derickr/80c0a834211656bc9301507c4d3757d1

> > 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.

It's not really a problem, as that API mainly exists for debugging 
purposes. The actual conversions handle them just fine. And IMO, it 
being a debugging feature made this new problem showed up, so I rather 
keep it :-)

> > 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.

Ah, right, that's what it was. Can you point to the source perhaps as I 
still cannot find that.

*However*, the Europe/London change then now violates this:

 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)]
+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)]

The new explicit transition type (2) is no longer consistent with the 
next transition in the POSIX string (which would be type 1, to to go DST 
on 1997-03-30?

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
Host of PHP Internals News: https://phpinternals.news

mastodon: @derickr at phpc.social @xdebug at phpc.social
twitter: @derickr and @xdebug