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

[Guy Harris]

On Jan 9, 2024, at 1:11 PM, Brooks Harris <brooks at edlmax.com> wrote:

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

Where was it ever an issue about the handling of UNTIL times with only a year designation?  UNTIL times with only a year designation have, I think, an implied date of the first day of January in that year; I'm not sure what the implied time is.  As such, as far as I know, they are treated no differently from any other entry.

> 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.

In 1919, the US repealed DST.

In 1920, it appears that the America/New_York IANA timezone decided to stick with DST; that's why the "-5:00    US    E%sT    1920" entry ends in 1920 - that timezone switched to the DST rules of New York City rather than the rules of the US as a whole.  Apparently, in 1920, "New York and dozens of other cities adopted their own metropolitan daylight saving policies":

	https://www.smithsonianmag.com/history/100-years-later-madness-daylight-saving-time-endures-180968435/

However, the NYC rules don't have a transition until March, so that, from the point of view of converting times (or adjusting clocks), no change occurred until the last Sunday in March 1920.  I infer from the JSTOR paper linked to by the Smithsonian article that New York State mandated advanced time in 1918, which was somewhat of a no-op at that time, as federally-mandated advanced time also went into effect in 1918; however, New York State may not have repealed it in 1919 when federally-mandated advanced time was repealed.  1920 is only relevant because it's the first year in which New York State and "default US" rules (or lack of same) differed.

This all means that it's not clear what the transition date should be for that change in America/New_York.  As Paul noted, the same results would occur for all time conversions for many different UNTIL values - "until 2AM local time on the last Sunday of March 2020" would also work.

> 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.

There was no shift on 1920-01-01.  There was, in America/New_York, a transition on 1920-03-28 at 2:00 AM local time, advancing the clock by one hour.

There wasn't even a shift in STDOFF on 1920-01-01; there was only a shift in rules, which would have occurred on that date if that was the effective date of the 1919 repeal of DST.  The only shift was in the rules, and the rules only differed, in their effects, starting 1920-03-28 at 2:00 AM local time.

You may be thinking of "no-op" transitions, which change neither the offset from UTC, nor the designation strings, nor the "is_dst" flag value.  An entry with an UNTIL date that's just a year is neither guaranteed to correspond to a no-op transition nor to correspond to a transition that changes one or more of those values.

> 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.

The longitude is *quite* approximate, given that 1) time zones can be rather wide and 2) time zone boundaries do not necessarily correspond to meridians.

In what scenarios would that be critical?

> 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.

And in what scenarios would that be critical?

> 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).

Is this required to support sending SMPTE local-time timestamps, which apparently do *not* shift at the instant of a time shift, so as not to introduce discontinuities in the middle of a video segment.  I.e., SMPTE local-time timestamps are in a time scale that is *neither* local time *nor* UTC, so you need two offsets in order to convert the SMPTE timestamps to local time or to UTC.

> 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.

Which is the case in TZif files produced when zic is handed a -L flag that specifies a list of past and expected future leap seconds.

> 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.

"Otherwise" here meaning "well, that's what clocks in those regions are doing".  The goal is to reflect how clocks behave in timezones; this follows "the law" because, in most cases, clocks follow the law.  However, if there's a region where the law says one thing and a significant number of people do something else, we may well have two different - and partially or completely overlapping - IANA timezones.