[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