From: Rich Felker <dalias@libc.org>
To: Alexander Weps <exander77@pm.me>
Cc: musl@lists.openwall.com, Daniel Gutson <danielgutson@gmail.com>,
Markus Wichmann <nullplan@gmx.net>
Subject: Re: [musl] Broken mktime calculations when crossing DST boundary
Date: Sun, 24 Mar 2024 15:22:58 -0400 [thread overview]
Message-ID: <20240324192258.GY4163@brightrain.aerifal.cx> (raw)
In-Reply-To: <9c2qfe36CoPBfKjzn1lDDZ_hfyNJCZW6-6ZTZlQgHAPr2djicIMMweEqUoQoQsDWsBt4AAZBL8vZlcsVCL950rYhcPpMDvhzDWean3oVHbs=@pm.me>
On Sun, Mar 24, 2024 at 06:36:40PM +0000, Alexander Weps wrote:
> It is tiring, because you are not correct.
>
> You are also talking about a slightly different thing.
>
> If you have normalized time T1 in struct tm and you add something,
> normalize, you should always get normalized time T2, what is higher
> than T1.
> If you have normalized time T2 in struct tm and you subtract
> something, normalize, you should always get normalized time T1,
> which is lower than T2.
>
> I agree than for non normalized time (tm_isdst = -1 etc.) this would
> not apply. I agree that the decision how to deduce it is
> implementation specific and I don't really hold it against musl. I
> rewrote everything without tm_isdst = -1.
You're mixing up what non-normalized means. There are basically two
meanings, neither of which has to do with tm_isdst=-1 (forget it
because it's not relevant to any of this).
1. The value of one of the tm_* values it outside of its calendar
range (e.g. tm_min=70). These are reduced prior to any
consideration of timezone mess, producing a nominally valid
calendar date.
2. The normalized (in sense 1 above) time in the tm_* values does not
exist due to daylight time change (spring-forward) or change in the
timezone rule for the territory.
You're making test cases which involve both 1 and 2 above, which makes
them more confusing to reason about.
> But there cannot be a case where you have normalized time add
> something, normalize and create normalized time that is lower and
> vice versa.
>
> If you claim otherwise, provide counter example.
What I've told you is that, if you compare the broken-down tm element
by element ignoring what zone rule it's under, there will always be
instances where mktime is non order preserving, *regardless of what
choices the implementation makes*. One way of writing this precisely
is that there will always exist tm1 and tm2 where
timegm(tm1) < timegm(tm2)
but after mktime(tm1) and mktime(tm2):
timegm(tm1) > timegm(tm2)
This is really not profound. It's just a case of "local times are
lossy in the absence of also taking into account the associated UTC
offset or local time rule in effect".
I think you've found one real bug where something goes wrong with the
2011-12-29 corner case, but digging in on other things you think are
wrong, that are just fundamental to how local time works, is
distracting from actually investigating that. Can we try to actually
figure out what's going on there?
Rich
next prev parent reply other threads:[~2024-03-24 19:22 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-24 13:36 Alexander Weps
2024-03-24 16:59 ` Alexander Weps
2024-03-24 17:04 ` Rich Felker
2024-03-24 17:12 ` Alexander Weps
2024-03-24 18:00 ` Alexander Weps
2024-03-24 18:02 ` Rich Felker
2024-03-24 18:16 ` Alexander Weps
2024-03-24 18:24 ` Rich Felker
2024-03-24 18:36 ` Alexander Weps
2024-03-24 19:01 ` Joakim Sindholt
2024-03-24 19:05 ` Alexander Weps
2024-03-24 19:06 ` Alexander Weps
2024-03-24 19:13 ` Alexander Weps
2024-03-24 19:13 ` Alexander Weps
2024-03-24 19:22 ` Rich Felker [this message]
2024-03-24 19:57 ` Alexander Weps
2024-03-24 20:22 ` Rich Felker
2024-03-24 20:50 ` Alexander Weps
2024-03-24 21:43 ` Alexander Weps
2024-03-24 23:51 ` Thorsten Glaser
2024-03-25 0:36 ` Alexander Weps
2024-03-25 11:52 ` Alexander Weps
2024-03-25 12:21 ` Rich Felker
2024-03-25 12:55 ` Alexander Weps
2024-03-25 13:08 ` Rich Felker
2024-03-25 13:13 ` Alexander Weps
2024-03-25 13:13 ` Rich Felker
2024-03-25 13:24 ` Alexander Weps
2024-03-25 13:42 ` Rich Felker
2024-03-25 13:48 ` Alexander Weps
2024-03-25 13:50 ` Alexander Weps
2024-03-25 18:02 ` Rich Felker
2024-03-25 18:28 ` Alexander Weps
2024-03-25 18:53 ` Rich Felker
2024-03-25 18:57 ` Alexander Weps
2024-03-25 19:38 ` Rich Felker
2024-03-25 19:47 ` Rich Felker
2024-03-25 20:05 ` Alexander Weps
2024-03-25 20:12 ` Alexander Weps
2024-03-25 20:00 ` Alexander Weps
2024-03-25 20:23 ` Rich Felker
2024-03-25 20:31 ` Rich Felker
2024-03-25 23:19 ` Thorsten Glaser
2024-03-25 23:16 ` Thorsten Glaser
2024-03-25 13:44 ` Alexander Weps
2024-03-25 22:40 ` Thorsten Glaser
2024-03-25 22:59 ` Alexander Weps
2024-03-25 23:34 ` Thorsten Glaser
2024-03-26 12:45 ` Alexander Weps
2024-03-26 21:59 ` Thorsten Glaser
2024-03-27 0:14 ` Alexander Weps
2024-03-27 0:38 ` Alexander Weps
2024-03-27 1:35 ` Thorsten Glaser
2024-03-27 2:45 ` Alexander Weps
2024-03-27 4:42 ` Thorsten Glaser
2024-03-26 18:56 ` Alexander Weps
2024-03-25 23:13 ` Rich Felker
-- strict thread matches above, loose matches on Subject: below --
2024-03-22 19:56 Alexander Weps
2024-03-23 6:41 ` Markus Wichmann
[not found] ` <528SeRFaPfDw7fA4kqKDlio1U4RB_t9nmUemPcWw9_t1e2hBDpXYFmOqxAC37szgYvAVtmTuXWsmT64SSN3cSQFVdrQqXUAgkdTMPZQ0bg0=@pm.me>
2024-03-23 10:38 ` Markus Wichmann
2024-03-23 11:59 ` Alexander Weps
2024-03-23 12:00 ` Alexander Weps
2024-03-23 12:31 ` Rich Felker
2024-03-23 13:49 ` Alexander Weps
2024-03-23 15:31 ` Rich Felker
2024-03-23 16:54 ` Alexander Weps
2024-03-23 18:57 ` Alexander Weps
2024-03-23 19:33 ` Alexander Weps
2024-03-23 20:18 ` Rich Felker
2024-03-23 20:40 ` Alexander Weps
2024-03-24 0:36 ` Eric Pruitt
2024-03-24 2:04 ` Rich Felker
2024-03-24 3:32 ` Daniel Gutson
2024-03-24 11:05 ` Alexander Weps
2024-03-24 13:24 ` Alexander Weps
2024-03-23 12:01 ` Alexander Weps
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240324192258.GY4163@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=danielgutson@gmail.com \
--cc=exander77@pm.me \
--cc=musl@lists.openwall.com \
--cc=nullplan@gmx.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).