[PATCH v2 0/4] mktime tm_isdst compatibility improvements

[Florian Weimer]

* 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.

No, this part is synthetic.  The reported case was the UTC part of the
test.  I added the Asia/Kolkata tests just to have some coverage for the
daylight variable check that I added.

Despite this, I think the change in behavior you are proposing is
desirable.

Thanks,
Florian