[Bug time/34480] mktime fails to determine DST for America/Vancouver from tzdata 2026b

https://sourceware.org/bugzilla/show_bug.cgi?id=34480

eggert at cs dot ucla.edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |eggert at cs dot ucla.edu

--- Comment #8 from eggert at cs dot ucla.edu ---
(In reply to Aurelien Jarno from comment #7)
> Do you have a pointer to this reference implementation?

https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz

The situation here: the TZif file says that we are in a period of DST, but the
file does not say what the DST offset is. The period of DST is surrounded by
two periods of standard time, the earlier one (ending in March) at UT -08 and
the latter (starting in November) at -07. One possible solution would consider
all of the DST period to corresponded to a standard time of -08; another is
that it all corresponds to a standard time of -07. glibc splits the difference,
saying that the earlier part of the DST period corresponds to a standard time
of -08 and the latter to -07. All these solutions conform to POSIX, which does
not say what to do in this situation.

I suppose we could complicate glibc (and the reference implementation) to
consider the entire period of DST to correspond to -08 here. This would also
conform to POSIX. Not sure it's worth the trouble, though. It would slow down
the implementation slightly.

One more thing. According to the legal definition of time in British Columbia,
the results Aurelian Jarno reported for glibc and 2026a vs 2026b are both
incorrect, as both timestamps should be 00:00 at standard time which is -07.
This is due to a hack we put into TZDB 2026b to work around a CLDR bug, a hack
that causes the TZif file to not correspond to BC law
<https://lists.iana.org/hyperkitty/list/[email protected]/thread/IEZR4HYQXZTUMGRA7FEZJAKAOGFGOPIP/>.
We plan to remove the hack around November 1 so it should appear by TZDB 2027a
at the latest. After the hack is removed, glibc and the reference
implementation will report 00:00 standard time (-07) for both test timestamps.

In short, this is indeed not a bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.