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.