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

[Alexander Weps <exander77@pm.me>]

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

> On Mon, Mar 25, 2024 at 06:57:49PM +0000, Alexander Weps wrote:
>
> > I am not sure which one you mean, all latest codes even includes
> > headers and main...
>
>
> https://www.openwall.com/lists/musl/2024/03/25/3
>
> > I have no idea what to tell you.
>
>
> The first version I found that's actually compilable is:
>
> https://www.openwall.com/lists/musl/2024/03/25/11
>
> It roughly behaves as expected on musl, except possibly not applying
> the tm_isdst=0, which is what was making the output confusing on
> glibc -- that threw the input back across the rule change cutoff.
>
> With tm_isdst=1 and tm_mday=31, on glibc, I get:
>
> before: 2011-12-31 00:00:00 WSDT 0
> after1: 2011-12-31 00:00:00 WSDT 1325239200
> after2: 2011-12-30 00:00:00 WSDT -1
> after3: 2011-12-31 00:00:00 WSDT 1325239200
>
> The -1 in the after2 line indicates that mktime failed with an error
> (and should not have modified tm; that's arguably a bug in glibc).The

No, -1 means that was not able to make seconds since beginning of epoch.
It has nothing to do with modifying tm...

Also, can you share the whole code, you did some changes and I don't reproduce the result. Which sample it is based on?

I set tm_isdst=1 and tm_mday=31 in the example above and I get:

$  gcc foo.c -o foo && TZ=Pacific/Apia ./foo
before: 2011-12-31 00:00:00 +13 0
after1: 2012-01-01 01:00:00 +14 1325329200
after2: 2011-12-31 01:00:00 +14 1325242800
after3: 2012-01-01 01:00:00 +14 1325329200

I do not get any -1 results.

$  musl-gcc foo.c -o foo && TZ=Pacific/Apia ./foo
before: 2011-12-31 00:00:00  0
after1: 2011-12-31 01:00:00 +14 1325242800
after2: 2011-12-29 01:00:00 -10 1325156400
after3: 2011-12-29 01:00:00 -10 1325156400

> partial modification that it made reflects the initial normalization
> (type 1 in my notation) but not the rule change normalization (type 2
> in my notation) since glibc has failed the operation for an input date
> that does not exist on the calendar (it does not do type 2
> normalization at all; it just rejects it).
>
> Running this same change on musl, I get:
>
> before: 2011-12-31 00:00:00 0
> after1: 2011-12-31 00:00:00 +14 1325239200
> after2: 2011-12-29 00:00:00 -10 1325152800
> after3: 2011-12-29 00:00:00 -10 1325152800
>
> which again is what I expect. From one side, the move-by-1-day changes
> the time to the next calendar day in that direction. From the other
> side, it's unable to change it.

Glibc works without any issues as shown above on my machine. Both forward and backward.

Your results are off by one hour. And you start with WSDT (+14). Without mktime. The initial date produced by glibc should be +13 as Pacific/Apia is +13.

>
> I'll look into why the tm_isdst=0 application was not happening.
>
> Rich
>
>
>
>
>
> > On Monday, March 25th, 2024 at 19:53, Rich Felker dalias@libc.org wrote:
> >
> > > On Mon, Mar 25, 2024 at 06:28:14PM +0000, Alexander Weps wrote:
> > >
> > > > 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?
> > >
> > > The first few pieces of code you posted did not work because they
> > > depended on other code you did not include, so I stopped trying to run
> > > them.
> > >
> > > > 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.
> > >
> > > Which piece of self-contained, actually-runnable code would you like
> > > me to look at that demonstrates something wrong? (i.e. not something I
> > > have already said is behaving as expected)