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@phpc.social @xdebug@phpc.social twitter: @derickr and @xdebug