[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