[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <-svm5EdX4OFN9hKzgS2FP6N1lgUGjT7edQONkAfCywgsRitwT6Vw22W3sUUGY_pnKGIXBKlujMZhPCDkJAMCYbBA5uF-IYgzhj8WB0wBE-A=@pm.me>
Date: Sun, 24 Mar 2024 19:57:39 +0000
From: Alexander Weps <exander77@...me>
To: musl@...ts.openwall.com
Cc: Daniel Gutson <danielgutson@...il.com>, Markus Wichmann <nullplan@....net>
Subject: Re: Broken mktime calculations when crossing DST boundary
See below.
AW
On Sunday, March 24th, 2024 at 20:22, Rich Felker <dalias@...c.org> wrote:
> 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).
I use normalized tm struct in a sense that calling mktime on that stuct tm doesn't do any change it.
Struct tm with tm_isdst = -1 is inherently non-normalized by my definition.
But I am up to use your definition.
>
> 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.
You are describing the musl behavior, more specifically what I see in mktime & __tm_to_secs.
I don't think this is correct behavior.
You basically throw away important information and later claim that you don't have it and it's impossible to deduce it.
If this is what you call normalization than normalization is what breaks it.
>
> 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.
If you consider normalization in 1. a correct behavior and you have some notion that normalized tm_* values represent a specific date time that could be present or not present within a timezone.
>
> 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
You made it non order preserving by your choices. You have just shown that the implementation is broken by choices that were made.
You can make valid ordering of all struct tm if you consider all of the fields.
This is not even relevant to normalization. You can do it on all struct tm just as they are.
Normalization should be there to make it easier to do it, not make it impossible to do it.
>
> timegm(tm1) < timegm(tm2)
>
> but after mktime(tm1) and mktime(tm2):
>
> timegm(tm1) > timegm(tm2)
This is not related. So far everything discussed by me related to localtime of a single timezone.
I have not made any claims about time being consistent while converting between timezones.
I claim that time is consistent within a timezone like Europe/Prague with regard to all changes described by zonefile (CET, CEST, GMT...).
>
>
> 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?
Sure. But that's not the only bug.
>
> Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
