[tz] Extra transition for Europe/London with 2023d
brian.inglis at systematicsw.ab.ca
brian.inglis at systematicsw.ab.ca
Wed Jan 3 09:05:57 UTC 2024
On 2024-01-02 12:29, Derick Rethans wrote:
> 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.
Generated data rather than installed, and what selections, options, and
parameters are you using to generate that data, including those for make and zic?
I am using tzcode 2023d zdump and zic, and tzdata 2023d make and zic parameters:
make DATAFORM=rearguard PACKRATDATA=backzone PACKRATLIST=zone.tab \
VERSION_DEPS= tzdata.zi
mkdir -p zoneinfo/ zoneinfo/posix/ zoneinfo/right/
zic -b fat -d zoneinfo -L /dev/null tzdata.zi
zic -b fat -d zoneinfo/posix -L /dev/null tzdata.zi
zic -b fat -d zoneinfo/right -L leapseconds tzdata.zi
Which data format version(s) are you reading and listing?
> 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
> …
>> 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)]
It is possible with your make and zic selections, options, and parameters, that
a bug generates unnecessary extra transition(s).
What generates your 2023.4 data file?
It might be useful for zdump to support a rawer -d debug/dump format showing
rawer data in useful radixes to diagnose these cases.
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry
More information about the tz
mailing list