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

[Brooks Harris]

On 1/7/2024 5:48 PM, Paul Eggert wrote:
> 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.
I'll try again.
>
> 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.
There are couple intermingled topics in the thread.

-------------------
A) Regarding if zone eras with UNTIL times with only a year designation 
should be included in zic output.

I think they should be. Take for example America/New_York:

# Zone    NAME        STDOFF    RULES FORMAT    [UNTIL]
Zone America/New_York    -4:56:02 -    LMT    1883 Nov 18 12:03:58
             -5:00    US    E%sT    1920
             -5:00    NYC    E%sT    1942
             -5:00    US    E%sT    1946
             -5:00    NYC    E%sT    1967
             -5:00    US    E%sT

There are four transitions at the 1st-of-the-year, each changing the 
RULES field.

Why is this important? In my implementations I find the date of a 
transition, the transition type (STDOFF, dstoff, or leap-seconds), the 
value of the transition shift, and the time-of-day of the shift. Thus an 
application that has no access to metadata (TZIf, Posix-time or anything 
else) can confidently represent any point within that day from metadata 
contained in the timestamps themselves. I gave this example in a 
response to Guy's similar question in this thread:

Example - A "fall back" DST transition in America/New_York:

D2022-11-06T00:00:00U-04Zamerica/new_yorkAedtV2021aL27S01t-01a02cMuX UTC 01667707227
D2022-11-06T01:59:59U-04Zamerica/new_yorkAedtV2021aL27S01t-01a02cMuX UTC 01667714426
D2022-11-06T01:00:00U-05Zamerica/new_yorkAestV2021aL27S00t-01a02cMuX UTC 01667714427
D2022-11-06T23:59:59U-05Zamerica/new_yorkAestV2021aL27S00t-01a02cMuX UTC 01667797226
                     ^^^^                                   ^^^^^^^^^^
                   "gmtoff"                           DST transition metadata

To accomplish this the application must search the transitions backwards 
(previous transition) to discover STDOFF shifts and forward (next 
transition) to discover if and when a DST or leap-second transition is 
to occur. If these 1st-of-the-year transitions are not included in the 
transition list the searches will return the wrong transition and fail.

I've modified my implementation of outzone() and **optimize of 
writezone() to retain these 1st-of-the-year transitions. This results in 
their being included in the TZIf files but this does not alter the 
normal behavior localtime() because these are essentially "no-op" 
transitions.

-------------------
B) Regarding stdoff, gmtoff, and Isdst

gmtoff is the sum of STDOFF and any DST values in effect. This gives the 
appropriate and important offset to normalize to UTC but it confounds 
the two factors.

I think the STDOFF value is critical. It essentially defines the 
(approximate) longitude of the idealized time zone independent of any 
DST shifts applied. And, regardless of longitude, it also defines the 
*base* offset from UTC in the time domain whether or not any DST shifts 
are in effect.

As noted elsewhere, the isdst flag is insufficient in cases of "double 
summertime".  (And nothing says you couldn't have "triple summertime " 
or "quadruple summertime"). You'd really like a "dstoff" variable to 
carry this value, including negative DST (Dublin and such).

Then there is leap-seconds. This is a third offset factor indicating the 
leap-seconds value. Lets call it "lsoff".

So you'd have stdoff + dstoff + lsoff = gmtoff.

So in my view its not only a matter of arriving at gmtoff, which is 
critical of course, but that the other factors, stdoff, dstoff, and 
lsoff be included in the timestamp. To do this would significantly alter 
TZif, ideally would also be incorporated in Posix-time struct tm, and 
should probably also be added to ISO 8601 representations. I'm not sure 
if all this is feasible but I think if these topics are not addressed a 
truly unambiguous timestamp is not possible because the formats are 
incomplete.

By the way, the term "standard" is somewhat ambiguous where in some 
places it may refer to "wall clock time" whether DST is in effect or 
not, as noted in another thread on the list. Its ok within the context 
of TzDb because we are familiar with its meaning. But I think there 
really should be a better term, such as "normal time", or "primary offset".

Also, DST shifts might not actually refer to "daylight saving" shifts 
but might be used for some other reason. So, more generally, these might 
be seen as "secondary offsets" (secondary to the primary stdoff value).

>
> 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.
OK. From an interoperability point of view I see TzDb source data to be 
*the law*, whether backed by official documentation or invented for 
convenience or otherwise.  Without your "inventions" a lot of this might 
not work. Thanks!

Thanks,
-Brooks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20240109/2d04a864/attachment.htm>