[tz] Extra transition for Europe/London with 2023d

[Paul Eggert]

On 2024-01-06 01:40, Derick Rethans wrote:
> 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)]

That 1996-01-01 transition *is* needed, in the sense that if you omit it 
the resulting TZif file would have the wrong behavior: the TZ string 
"GMT0BST,M3.5.0/1,M10.5.0" would apply to all timestamps after 
1995-10-22 01:00 and thus would incorrectly induce a transition from GMT 
to BST at that point, along with another transition from BST back to GMT 
at 1995-10-29 02:00.

Also, if you omit that transition the TZif file doesn't conform to RFC 
8536 secton 3.3 
<https://datatracker.ietf.org/doc/html/rfc8536#section-3.3> because its 
last transition type would disagree with the TZ string evaluated at that 
transition. (This requirement was put into the RFC precisely to avoid 
this sort of confusion.)

So Europe/London needs *some* explicit transition after 1995-10-22 
01:00:00 UT. It's just that zic is free to choose the one it chose in 
2023c, or the one it chose in 2023d, or a host of other explicit 
transitions (they'd all work).


On 2024-01-06 02:03, Derick Rethans via tz wrote:
> I wonder though, is there no test suite for this?

The test suite I run is 'make public'. It does a regression test on all 
the Zones, making sure that zdump reports exactly the changes expected, 
up through the year 2050. It's an end-to-end test: it doesn't care how 
the TZif file implements a user-visible transition.

It of course would be possible to add further tests of intermediate TZif 
forms. However, this is work that I hope someone else would do, as it's 
not the primary goal of tzcode to export timestamp information other 
than what's visible to localtime, or to commit to a particular TZif form 
when another would do.


On 2024-01-06 02:15, Derick Rethans wrote:
> On Fri, 5 Jan 2024, Paul Eggert wrote:
>> > 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.
> 
> Ah, right, that's what it was. Can you point to the source perhaps as I 
> still cannot find that.

tzfile.5 says:

'If nonempty, the POSIX-style TZ string must agree with the local time 
type after the last transition time if present in the eight-byte data; 
for example, given the string "WET0WEST,M3.5.0/1,M10.5.0" then if a last 
transition time is in July, the transition's local time type must 
specify a daylight-saving time abbreviated "WEST" that is one hour east 
of UT.'

There is similar wording in Internet RFC 8536 section 3.3.


> *However*, the Europe/London change then now violates this:
> 
>  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)]
> +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)]
> 
> The new explicit transition type (2) is no longer consistent with the 
> next transition in the POSIX string (which would be type 1, to to go DST 
> on 1997-03-30?

But the new transition is consistent.

It's not a question of the next transition implied by the POSIX string. 
It's a question of what the POSIX string says about the transition 
itself. The example in tzfile.5 should make this clear.