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.