From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id EFB8622900 for ; Sun, 24 Mar 2024 20:58:01 +0100 (CET) Received: (qmail 22204 invoked by uid 550); 24 Mar 2024 19:53:18 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 22167 invoked from network); 24 Mar 2024 19:53:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1711310268; x=1711569468; bh=SI42J5EAo/SEXscdurXWCl9y9yv9zkPmEi0/HxIheTM=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=ZCHGvCNmQw353O4z9LxQ0RTDhjQSboSrlu5DZXieiM3heyqXzIqSXws3Fo+m2j4j2 ib7jzfdQA8BSMOpmVDH4IQojPIsLym0Ss3UGdINwPaVhoko/TYDgDhQfJLNr1MqEkf j1Qj93RgxImUiQe3dYZBVG5qF+l1As1v8x0T7BxDv1Znm/Sn7Ndw22G2zmbN7433r3 vLuZ/ceC659AKJx3ii0vSU8YOdBi6LubOCnKxEHvEIPKf8Kdm4MClWRkJrNStPxb7Y IbNl5ZQKGax8B1sEsqkKoZd+NKte6k0yTLxi5kOAhjbLn2WaQhOExV5MHhgP32FvL4 Zj7sR3/7+vzYA== Date: Sun, 24 Mar 2024 19:57:39 +0000 To: musl@lists.openwall.com From: Alexander Weps Cc: Daniel Gutson , Markus Wichmann Message-ID: <-svm5EdX4OFN9hKzgS2FP6N1lgUGjT7edQONkAfCywgsRitwT6Vw22W3sUUGY_pnKGIXBKlujMZhPCDkJAMCYbBA5uF-IYgzhj8WB0wBE-A=@pm.me> In-Reply-To: <20240324192258.GY4163@brightrain.aerifal.cx> References: <20240324170436.GV4163@brightrain.aerifal.cx> <0_9-JV2MW3avVvzhE9vjqKqCX0fEZy0uUuZKIohFGEFDBY912nwZyxZe560H0cf_b8L2gD8e0eUAUp2Q3e1rmra3XEppx9HPhhFeulwLYZA=@pm.me> <20240324180200.GW4163@brightrain.aerifal.cx> <20240324182458.GX4163@brightrain.aerifal.cx> <9c2qfe36CoPBfKjzn1lDDZ_hfyNJCZW6-6ZTZlQgHAPr2djicIMMweEqUoQoQsDWsBt4AAZBL8vZlcsVCL950rYhcPpMDvhzDWean3oVHbs=@pm.me> <20240324192258.GY4163@brightrain.aerifal.cx> Feedback-ID: 20507743:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] Broken mktime calculations when crossing DST boundary See below. AW On Sunday, March 24th, 2024 at 20:22, Rich Felker 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 =3D -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 =3D -1. > > > You're mixing up what non-normalized means. There are basically two > meanings, neither of which has to do with tm_isdst=3D-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 =3D -1 is inherently non-normalized by my definitio= n. 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=3D70). 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 mktim= e & __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 no= tion 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 fie= lds. 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 impos= sible 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 bet= ween timezones. I claim that time is consistent within a timezone like Europe/Prague with r= egard 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