Created attachment 16904 [details] Simple reproducer When mktime is called for the America/Vancouver from tzdata 2026b with tm_isdst = 0, it forces tm_isdst to 1 for dates <= 2026-06-05, but keeps it to 0 for dates >= 2026-06-06. This didn't happen with tzdata 2026a, which however consider an endless non-DST/DST alternation. This can be seen with the attached reproducer. When executed with TZ=America/Vancouver on tzdata 2026a, it outputs: mktime(2026-06-05 00:00:00) mktime(2026-06-05 01:00:00) = 1783238400 mktime(2026-06-06 00:00:00) mktime(2026-06-06 01:00:00) = 1783324800 difference: 86400 With tzdata 2026b it outputs: mktime(2026-06-05 00:00:00) mktime(2026-06-05 01:00:00) = 1783238400 mktime(2026-06-06 00:00:00) mktime(2026-06-06 00:00:00) = 1783321200 difference: 82800 However both tzdata versions produce the same result when tm_isdst = -1. All that said, POSIX 2024 clarifies the mktime behaviour: when tm_isdst is 0, the implementation should interpret the input as standard time and not attempt to determine if DST is active. Maybe that is the correct fix here.
Not a bug, see https://lists.iana.org/hyperkitty/list/tz@iana.org/thread/WVINVKKZEKUHQV7OYHW7JMALAZGAMWNL/
(In reply to Andreas Schwab from comment #1) > Not a bug, see > https://lists.iana.org/hyperkitty/list/tz@iana.org/thread/ > WVINVKKZEKUHQV7OYHW7JMALAZGAMWNL/ I agree the submitted bug in the Debian BTS has a buggy code attached. But this is not the reproducer I attached to this bug. Here it involves only mktime, which behaves differently from on day to another, for a date that does not correspond to a transition in the timezone. mktime should either fix tm_isdst or not fix it (POSIX 2024 says it shall not), but this decision should not depend on the time passed.
(In reply to Aurelien Jarno from comment #0) > All that said, POSIX 2024 clarifies the mktime behaviour: when tm_isdst is > 0, the implementation should interpret the input as standard time and not > attempt to determine if DST is active. Maybe that is the correct fix here. But what does that actually mean in this context? America/Vancouver has permanent DST. Does POSIX require that the time_t value produced is different for tm_isdst == 0 and tm_isdst == 1? To avoid producing a difference, mktime would have to determine whether DST is in effect, I think.
(In reply to Florian Weimer from comment #3) > (In reply to Aurelien Jarno from comment #0) > > All that said, POSIX 2024 clarifies the mktime behaviour: when tm_isdst is > > 0, the implementation should interpret the input as standard time and not > > attempt to determine if DST is active. Maybe that is the correct fix here. > > But what does that actually mean in this context? > > America/Vancouver has permanent DST. Does POSIX require that the time_t > value produced is different for tm_isdst == 0 and tm_isdst == 1? To avoid > producing a difference, mktime would have to determine whether DST is in > effect, I think. Quoting POSIX.1-2024: " If the timezone is one that includes Daylight Saving Time (DST) adjustments, the value of tm_isdst in the tm structure controls whether or not mktime() adjusts the calculated seconds since the Epoch value by the DST offset (after it has made the timezone adjustment), as follows: If tm_isdst is zero, mktime() shall not further adjust the seconds since the Epoch by the DST offset. If tm_isdst is positive, mktime() shall further adjust the seconds since the Epoch by the DST offset. If tm_isdst is negative, mktime() shall attempt to determine whether DST is in effect for the specified time; if it determines that DST is in effect it shall produce the same result as an equivalent call with a positive tm_isdst value, otherwise it shall produce the same result as an equivalent call with a tm_isdst value of zero. If the broken-down time specifies a time that is either skipped over or repeated when a transition to or from DST occurs, it is unspecified whether mktime() produces the same result as an equivalent call with a positive tm_isdst value or as an equivalent call with a tm_isdst value of zero. " I can try to implement that if it makes sense to do so.
(In reply to Aurelien Jarno from comment #4) >> If the timezone is one that includes Daylight Saving Time (DST) adjustments > > I can try to implement that if it makes sense to do so. If understand the challenge correctly, POSIX assumes a world where a region has only one TZ rule that applies to all times. So it makes sense to have this condition. Things are less clear what this means in the tzdata world, where a region can have DST in one year, but not in the year when you're trying to convert a time. With a single rule, POSIX can also easily determine what the DST offset is without determining whether DST is in effect. We can't do that, either. If we assume that system tzdata is always correct, it's probably best drop the adjustment code altogether from glibc. It won't be possible for advanced users to work around incorrect transition dates due to outdated system information, though. It's also not clear how we would even implement that because tzdata does not use tm_isdst == 1 for permanent DST like in America/Vancouver. Not sure if this makes sense. We should probably discuss it on the mailing list?
It matches the behaviour of the reference implementation.
(In reply to Andreas Schwab from comment #6) > It matches the behaviour of the reference implementation. Thanks for checking. Do you have a pointer to this reference implementation?
(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/tz@iana.org/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.