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

[Alexander Weps <exander77@pm.me>]

On Monday, March 25th, 2024 at 19:02, Rich Felker <dalias@libc.org> wrote:

> On Mon, Mar 25, 2024 at 09:42:53AM -0400, Rich Felker wrote:
>
> > On Mon, Mar 25, 2024 at 01:24:57PM +0000, Alexander Weps wrote:
> >
> > > See below.
> > >
> > > AW
> > >
> > > On Monday, March 25th, 2024 at 14:13, Rich Felker dalias@libc.org wrote:
> > >
> > > > 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.
> > >
> > > You confuse day of month which is represented in tm_mday with
> > > calendar day that is interpreted by strftime.
> > >
> > > You said to set tm_mday = 31, which would be January 1st after normalization.
> > > December 31s is 30th day of month represented as tm_mday = 30.
> >
> > OK, I meant tm_mday=31-1.
>
>
> Um, no, where did you get that idea? I just assumed you were right
> because I always forget which tm_* are off-by-1, but tm_mday is
> one-based not zero-based:
>
> int tm_mday; // day of the month -- [1, 31]
>
> (per the standard). So how did you end up getting the wrong thing? Are
> you even running the code you say you are?
>

I have to sincerely ask if you are feeling ok?
You seem not able to follow this conversation.

What idea do you mean?
Also you have the codes. You can like "I don't know" run them yourself?
You question I run those codes without trying to run them yourself? Again?!
What is going on?

Maybe I reiterate some basic facts for you and that will put you back on track.

This was an example from an article provided earlier in this thread (by somebody).
We are in TZ=Pacific/Apia.
The 30th December was skipped in 2011. There was no December 30th.
So, there were only 30 days in December.
30th day of the month December was December 31st.

And run those examples yourself. I have no idea why I am being questioned if they generate the output when you can easily verify it yourself.

> Rich