[swbz 29035] mktime vs non-DST
Paul Eggert
eggert@cs.ucla.edu
Thu Aug 18 21:57:43 GMT 2022
A couple of things about those examples.
First, mktime is not "broken" if it returns a time_t that differs from
the time_t that you passed to localtime before fiddling with localtime's
resulting struct tm by changing its is_dst flag. That's normal and
expected mktime behavior, and many (perhaps most) mktime implementations
do that, and this is illustrated by the New York examples.
Second, and more important, the reason users are complaining is that
they want to answer questions like "What time is it 30 days after time
T?" by calling localtime on T, adding 30 to the resulting tm_mday, and
then calling mktime on the modified struct tm. This process fails in
recent glibc if the modified struct tm happens to have the wrong
tm_isdst flag because DST began or end sometime within the 30-day period.
With this in mind, DJ's Tokyo examples (which is the only place where
Gnulib's behavior disagrees with old glibc) illustrate why the
differences between old glibc and Gnulib (a) largely don't matter, and
(b) when they do matter, Gnulib is better. Here's why:
(a) In Tokyo, adding 30 to tm_mday (or whatever) to a contemporary
timestamp cannot yield a timestamp with the wrong tm_isdst because Tokyo
hasn't observed DST since 1951, so DJ's examples of Tokyo "broken dst"
(which is not really broken) largely don't matter.
(b) In the *extremely* unusual case where someone takes a circa-1951
Tokyo timestamp with tm_isdst=1 and adds 25000 to tm_mday to get a
contemporaneous timestamp, Gnulib mktime will treat this consistently
with how it treats New York (and with how it treats adding only 365 to
Tokyo tm_mday), whereas old glibc will treat it inconsistently.
Of course this use case is implausible, but the use case of adding 10
years to a circa-2021 timestamp in Fiji is more plausible, and there
again old glibc is inconsistent whereas Gnulib is consistent.
More information about the Libc-alpha
mailing list