Re: [swbz 29035] mktime vs non-DST

[Paul Eggert <eggert@cs.ucla.edu>]

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.