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

[Rich Felker <dalias@libc.org>]

On Mon, Mar 25, 2024 at 12:55:28PM +0000, Alexander Weps wrote:
> > If you take your test program and switch it to initialize with
> > tm_mday=31, then do -=1 instead of +=1, you'll find that it gives
> > 2011-12-29 01:00:00 -10 as well, only now it seems like the correct,
> > expected thing to happen. Any change to "fix" the case you're
> > complaining about would necessarily break this case.
> 
> So (- day, +day):
> 
> Musl:
> 2011-12-31 01:00:00 +14
> 2011-12-29 01:00:00 -10
> 2011-12-29 01:00:00 -10
> 
> Glibc:
> 2012-01-01 01:00:00 +14
> 2011-12-31 01:00:00 +14
> 2012-01-01 01:00:00 +14
> 
> Seems like musl doesn't even interpret the initial struct tm
> correctly in that case. It is off by day.
> 
> Because December only had 30 days, 31s day after normalization is
> January 1st.

This is nonsense. December has a day 31, which you can clearly see
from the glibc output. For this particular year in this zone, with the
zone rule change, there are "only 30 days" in December, but they are
numbered 1-29 and 31, not 1-30.

What did you do that got glibc to output 2012-01-01? I guess you wrote
code to do some wacky arithmetic *after* the original code you already
had, rather than *changing* the code to start with 2011-12-31 as I
suggested to get a look at what's happening.

> > In any case, the core issue you're hitting here is that time zones are
> > HARD to work with and that there is inherent complexity that libc
> > cannot save you from. You only got lucky that what you were trying to
> > do "worked" with glibc because you were iterating days forward; if you
> > were doing reverse, it would break exactly the same way.
> 
> I am not really commenting on this, until you sort out the above
> inconsistencies.

I already have but you refuse to look.

Rich