[tz] Extra transition for Europe/London with 2023d
Derick Rethans
derick at derickrethans.nl
Sat Jan 6 09:40:28 UTC 2024
On Fri, 5 Jan 2024, Paul Eggert via tz wrote:
> On 2024-01-02 13:53, Brooks Harris via tz wrote:
> > I suggest TzDb may want to have a look at this topic. I think If these
> > improvements were made it would not alter the typical current behavior of
> > localtime(); the YMDhms representations and sequences would remain the same.
> > But the addition of these transitions are more complete and honest to the
> > underlying TzDb source data and this is important for some types of extended
> > functionality I'm pursuing.
>
> It's never been a goal of zic to pack as much as possible information about
> the input into the TZif binary output file. Instead, the goal has been to
> optimize the output file size, as long as optimization doesn't change
> localtime's behavior. (Look for the word "optimize" in zic.c for more about
> this.)
But didn't this change to Europe/London do the opposite? It added a
1996-01-01 transition that wasn't needed (from GMT, to GMT):
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)]
FWIW, I don't think it is only Europe/London where this happened. Having
a look at that now.
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
More information about the tz
mailing list