On Tue, 2 Jan 2024, brian.inglis--- via tz wrote:
On 2024-01-02 04:29, Derick Rethans via tz wrote:
Hi, I have just updated the tzdb for PHP, and one of our tests started failing, and it turned out due to an unexpected data change: 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)]
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. As far as I know so-far, the only effect it has on PHP users is that they will now see an extra transition when they enumerate them (the 1996-01-01 is inserted). I think I am mostly flagging this up because this was an unexpected change. Check your installed data or paths and conversion code!
I am not using any installed data, and both of these were created by zic, which is what I would consider the reference implementation.
There was a leap second at that time, and regularly during the 1990s, so you seem to be using right/Europe/London:
No, I am not. The new rule for 1996-01-01 says:
1996-01-01 00:00:00 UT ( 820454400) = 2 [ 0 0 8 'GMT' (0,0)]
The first "2" is the "tzh_typecount" value. It is 2, just like in the previous entry for 1995-10-22 01:00:00 UT:
1995-10-22 01:00:00 UT ( 814323600) = 2 [ 0 0 8 'GMT' (0,0)]
You can also see that the offset stays "0" for both, and both have the abbreviation "GMT". In the 2023c data file, that entry correctly has typecount 1 (for 1996-03-31):
1996-03-31 01:00:00 UT ( 828234000) = 1 [ 3600 1 4 'BST' (0,0)]
It is distinctly a change in data as output by zic, as my diff of the created binary also show: The change from (0x31, 0x5D, 0xD9, 0x10) 828234000 to (0x30, 0xE7, 0x24, 0x00) 820454400 is exactly as what my tool (https://github.com/derickr/timelib/blob/master/docs/show-tzinfo.c) shows, the change from 1996-03-31 to 1996-01-01: -0x00, 0x00, 0x00, 0x31, 0x5D, 0xD9, 0x10, 0x02, 0x01, 0x02, 0x01, 0x02, 0x01, 0x02, 0x01, 0x02, +0x00, 0x00, 0x00, 0x30, 0xE7, 0x24, 0x00, 0x02, 0x01, 0x02, 0x01, 0x02, 0x01, 0x02, 0x01, 0x02, … And the other change changes the associated typecount from 0x01 to 0x02: -0x02, 0x01, 0x02, 0x01, 0x02, 0x01, 0xFF, 0xFF, 0xFF, 0xB5, 0x00, 0x00, 0x00, 0x00, 0x0E, 0x10, +0x02, 0x01, 0x02, 0x01, 0x02, 0x02, 0xFF, 0xFF, 0xFF, 0xB5, 0x00, 0x00, 0x00, 0x00, 0x0E, 0x10, No where comes the 'right''s leap second into play. If I turn these on by setting -L leapseconds when calling `zic`, then the output changes to the following, as expected (well, except for 1996-01-01 vs 1996-03-31): 1994-10-23 01:00:19 UT ( 782874019) = 2 [ 0 0 8 'GMT' (0,0)] 1995-03-26 01:00:19 UT ( 796179619) = 1 [ 3600 1 4 'BST' (0,0)] 1995-10-22 01:00:19 UT ( 814323619) = 2 [ 0 0 8 'GMT' (0,0)] 1996-01-01 00:00:20 UT ( 820454420) = 2 [ 0 0 8 'GMT' (0,0)] … 1994-07-01 00:00:18 UT ( 773020818) = 19 1996-01-01 00:00:19 UT ( 820454419) = 20 1997-07-01 00:00:20 UT ( 867715220) = 21 … <snip>
but there is no change visible with zdump on default or POSIX 2023d:
$ zdump -Vc1994,1998 Europe/London zdump -Vc1997,2025 -Vc1994,1998 Europe/London
zdump apparently doesn't show this behaviour. I'm fairly certain that the output of zic itself changed. If I replace the "zic.c" from 2023d with 2023c (and associated source files), the data that my tool shows indeed reverts back to the expected: … 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)] 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