[PATCH v2 0/4] mktime tm_isdst compatibility improvements

[Paul Eggert]

On 2025-01-02 09:42, Florian Weimer wrote:

> I'm still not sure what to do about the forced DST adjustment logic.
> Should we really remove all that code?  Should we change the default of
> the tunable and disable the code by default?

After some thought I have a better idea: let's fix mktime so that it 
matches user expectations better, without needing a new glibc tunable. 
(The tunable was iffy anyway; why should this be a system-wide thing 
rather than per-process or per-program?)

 From the test case, it appears that a user was disappointed because 
when mktime was incorrectly given a contemporaneous timestamp marked 
with daylight saving time (tm_isdst=1) in an Indian environment 
(TZ="Asia/Kolkata") that lacks DST today, mktime obediently thought 
"well, India had daylight saving time in 1945 so I guess this timestamp 
must have come from a World War II era timestamp along with user 
arithmetic to add 80 years" and therefore subtracted an hour from the 
requested time. This disappointed the user, who wanted mktime to ignore 
the incoming tm_isdst instead.

To better match user expectations, let's change mktime so that it 
doesn't reach back 80 years. One year is enough - if there are no DST 
transitions in the past year (or the future year) for a timestamp, most 
likely the user doesn't want DST regardless of tm_isdst.

I came to this idea after going through half a dozen other ideas and 
implementations, all of which were worse. I won't bore you with all the 
false alleys.

In the process of doing this, I discovered and fixed some bugs in 
mktime.c and committed them to Gnulib during the past three months or 
so. I also committed to Gnulib all the mktime.c changes made to glibc 
since the last time we merged.

Now comes the fun part. Let's merge the Gnulib improvements back to 
glibc, so that the two mktime.c copies are identical again. I plan to 
propose a series of patches to do that, as a followup to this email. The 
last patch will contain your test case, to show that we've fixed the 
Asia/Kolkata problem satisfactorily.

Obviously this merge back to glibc will need to wait until after the 
next glibc release. However I thought I'd publish it now so that you can 
see what's up.