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

[Brooks Harris]

On 1/6/2024 11:34 AM, Michael H Deckers via tz wrote:
>
>    On 2024-01-05 23:31, Guy Harris via tz asked:
>
>> The binary file obviously allows code that reads it to get 
>> information of the form "at date/time DT, one or more of {the offset 
>> from UTC, whether tm_isdst should be zero or non-zero, the time zone 
>> abbreviation} changes".  The tzcode doesn't happen to have APIs 
>> to*provide*  that information, but that's a different matter.
>>
>> Is there software that needs to know about transitions that change 
>> none of those?
>
>
>> ...  So are there Java classes read those files and use them?
>>
>> Or are they files produced by Java code that*uses*  the data?
>
>
>    Yes, there is information on local civil times scales needed by many
>    datetime software interfaces that is already present in the tzdb 
> source files
>    but that is missing from the TZif files since the very beginning:
>
>    • the SAVE value (or the numeric RULES value) applicable at an instant
>      is not available via TZif files, and cannot in general be deduced
>      from its contents (see eg the SAVE value +01 h for Europe/Dublin 
> when
>      UT = 1916-10-01 + 02:25:21.1). It has even become more difficult
>      to guess these values from TZif files since they are allowed to 
> be negative.
>
>    • the RULEs applicable at a specific instant (if any). They are 
> available
>      in TZif files (in versions 2 and 3) only for recent instants, and 
> the start
>      of their applicability is only given indirectly in TZif files, 
> sometimes
>      requiring a redundant transition (which is the topic of this 
> thread).
>
>    I think it would be very useful to have an official output of the 
> tzdb data
>    compilation process (zic and associated tools) that makes these data
>    available for datetime software, even though they are not needed by
>    the POSIX datetime functions.
>
>    Michael Deckers.
>
I agree, this would help.

I think the difficulty originates with Posix-time itself which has no 
method to signal STDOFF, the isdst flag is insufficient to signal 
so-called "double summertime" or negative DST shifts and, of course, 
leap-seconds. This leaves TzDb responsible to 'trick' the Posix time 
(localtime() and mktime()) into yielding the Posix YMDhms representation 
(broken-down time) by manipulating gmtoff while holding stdoff to some 
fixed value. In common cases this works ok but in many situations, such 
as STDOFF shifts, STDOFF shifts simultaneous with DST shifts, or "double 
summertime" the TzIf values are essentially 'lying' to work around the 
Posix insufficiencies. Until Posix-time is improved TzDb will be forever 
inventing work-around manipulations of the Posix-time. One might hope 
the Posix folks might recognize this and find ways to address it.

In the meantime I think including these kinds of "no-op" transitions 
would improve things.

Zic does include many "no-op" transitions where only the abbreviation 
changes, such as New_York:
  -769395601 1945-08-14 18:59:59 isdst 1 gmtoff -14400 stdoff -18000 EWT
  -769395600 1945-08-14 19:00:00 isdst 1 gmtoff -14400 stdoff -18000 EPT

I see no harm to typical behavior of Posix-time by providing these other 
"no-op" transitions to assist applications that can make use of them.

-Brooks