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

Paul Eggert eggert at cs.ucla.edu
Sun Jan 7 22:48:25 UTC 2024


On 2024-01-07 12:01, Brooks Harris wrote:

> Zic and TzIf reflect this change as a shift in gmtoff, not stdoff:
> 
>     57722399 1971-10-31 02:59:59 isdst 0 gmtoff   3600 stdoff      0 BST
>     57722400 1971-10-31 02:00:00 isdst 0 gmtoff      0 stdoff 0 GMT
> 
> That's what I mean by "adjusted" for Posix sake. It gives the proper UTC 
> offset, yes, but not for the right reason. The underlying reason was an 
> STDOFF shift, presumably stated in the law behind it.

I'm still not following this, unfortunately.

The use cases you gave mostly involved comparing local-time timestamps 
when their UT offsets are known, and obviously gmtoff suffices for that. 
You mentioned one use case for which the POSIX API is ill-designed 
(namely, "find the next gmtoff transition"), but gmtoff suffices for 
that too: we don't need stdoff there either.

Also, it's often not the case that the underlying reason was stated in 
the law behind it. The laws often don't specify this information, or the 
laws simply aren't available (we're relying on secondary sources), and 
in these cases I just made up internal details like stdoff to make the 
POSIX-visible timestamp info correct.

APIs should not be exposing juryrigged internal details to the user, as 
many of these details are simply my invention and do not reflect known 
legislation.



More information about the tz mailing list