Re: [musl] Broken mktime calculations when crossing DST boundary

[Rich Felker <dalias@libc.org>]

On Mon, Mar 25, 2024 at 10:40:01PM +0000, Thorsten Glaser wrote:
> >> > Causing a program to loop or stack overflow.
> 
> That’s because your application violates the constraints
> that bind both, not just the libc, to the spec.

It's not a constraint violation. mktime is required to accept inputs
where the fields of the broken-down time don't fall within their
respective ranges, and normalize them.

Rather, the calling code is just making incorrect assumptions about
the unspecified way that happens, and it only happens to "work" on
glibc because glibc is erroring out in the middle of a computation,
giving a partial result, rather than fully normalizing it.

> >Output from musl:
> >
> >2011-12-29 01:00:00 -10
> >
> >    tm.tm_mday += 1;
> >    t = mktime(&tm);
> >
> >2011-12-29 01:00:00 -10 <-- date is the same after incrementing
> 
> This is… not as incorrect as you state.
> 
> The steps here are:
> 
> • 2011-12-30 01:00:00 ← input
> • 2011-12-30 01:00:00 ← input after normalisation (!)
> • conversion to time_t (1325206800), application of timezone offset
> • detection of the discontinuity between 2011-12-29 23:59:59 and
>       2011-12-31 00:00:00
> • arbitrary choice of selecting either endpoint
> 
> tbh I’d expect this to end up in 1325239199=2011-12-29 23:59:59
> instead of 2011-12-29 01:00:00 though, at least from reading the
> latest Issue 8 proofreading draft. WDYT dalias?

No, there is no clamping involved and I don't see how that would be
useful or conforming. This is all underspecified, but basically,
mktime is required to interpret out-of-range values for some fields as
a denormalized time of sort and normalize it via a sort of division
algorithm to a valid calendar time.

What happens is that, when the local time is in the gap not covered by
either adjacent timezone rule, we make an arbitrary choice to
interpret it as a denormal in the later of the two adjacent rules,
which then normalizes into a time in the earlier range. Here,
2011-12-30 gets interpreted as "1 day below 2011-12-31", which is
2011-12-29.

Rich