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 CFA0022046 for ; Sun, 24 Mar 2024 22:43:31 +0100 (CET) Received: (qmail 17696 invoked by uid 550); 24 Mar 2024 21:38:48 -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 17664 invoked from network); 24 Mar 2024 21:38:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1711316598; x=1711575798; bh=pm3KwkunRp0Basb0FJQgcFWuzKb/P/ZPosFIG4XTkQY=; 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=kN+GMC/qRhRQTtbLJqvWedFndJYEGpHmZQZoArUI08o1zlWfWIwKYRHzARwBpM87J Iunf+ITpcwIuZSOK8B1yMeRQc0Qlqy6Do4zcLLHzGD1iAyDFVmdop2lOikvNUvHIpM jDtKNPBKjKCeXoVqQPclCb1r4gs1TOwaW1li1rP2CdLk8pqehoS9dcdDghUeiiRCj/ pHzR0eElSqFWhGVtebWs+MLdbFCs7IgMBKrxoQ418BbzmOeZOMGcggnDrsl2dpD0Aj Bf6RIrztbBPcxogx5L8Hhl9yBwNo9PwsdE/VkYW3cVoytN0Hd6mGAB4ac3WehSDb7R GINfv08M/ZPAA== Date: Sun, 24 Mar 2024 21:43:09 +0000 To: musl@lists.openwall.com From: Alexander Weps Cc: Daniel Gutson , Markus Wichmann Message-ID: In-Reply-To: References: <20240324180200.GW4163@brightrain.aerifal.cx> <20240324182458.GX4163@brightrain.aerifal.cx> <9c2qfe36CoPBfKjzn1lDDZ_hfyNJCZW6-6ZTZlQgHAPr2djicIMMweEqUoQoQsDWsBt4AAZBL8vZlcsVCL950rYhcPpMDvhzDWean3oVHbs=@pm.me> <20240324192258.GY4163@brightrain.aerifal.cx> <-svm5EdX4OFN9hKzgS2FP6N1lgUGjT7edQONkAfCywgsRitwT6Vw22W3sUUGY_pnKGIXBKlujMZhPCDkJAMCYbBA5uF-IYgzhj8WB0wBE-A=@pm.me> <20240324202211.GZ4163@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 Not to mention this breaks a tonne of existing functions and programs. If t= hese were just bad dates, it would be one thing... Bud due to such cycles it causes anything from infinite looping to stack ov= erflows. Sure it only does that in some cases, but if it happens it can crash a prog= ram. Not to mention that there is no recovery. It fails on tasks like create 10 consecutive days if it hits wrong spot. If= a programmer is creative enough he/she can check if incrementing date lead= to an earlier date and something is wrong, but what is correct recovery to= get that that consecutive date? Show me a recovery from this issue. Show me how I can reliably generate consecutive times/dates under such cond= itions. Show me how to generate start of each day. There is basically no reliable way how to do it under musl. I do not mind a complicated function to get these. But just simple enumerating all dates seems an impossible task in musl. Or = what do you suggest as a solution? Can you provide me with a code that enum= erates all dates up to seconds, minutes, hours, days, months, years resolut= ions? AW On Sunday, March 24th, 2024 at 21:50, Alexander Weps wrot= e: > See below. > > AW > > > > On Sunday, March 24th, 2024 at 21:22, Rich Felker dalias@libc.org wrote: > > > On Sun, Mar 24, 2024 at 07:57:39PM +0000, Alexander Weps wrote: > > > > > > 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 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. > > > > This "important information" does not tell us what the caller did to > > get the non-normalized input we received, even if you assume the > > caller just made a single change. > > > > For example if you see tm_mday=3D31 in a month with only 30 days, you > > don't know if the caller was trying to move one day forward from the > > last day of the month, or was trying to move one month back from the > > next month. > > > This is what is called limitations. > I actually investigated this limitation very closely. > > And it doesn't influence ordering if you don't handle it at all. > > > The reasonable, consistent, least-surprise thing to do is not to try > > to make guesses based on the individual fields and how you think the > > caller might have gotten to them, but instead to normalize completely > > to the ranges before even considering timezone shenanigans. > > > No. > > The reasonable, consistent, least-surprising thing to do is to take a min= imal subset of assumptions to make viable ordering. > So time can be predictably incremented and decremented and doesn't go bac= kwards to run into loops like these: > > 1946-12-01 02:59:17 CET > 1946-12-01 01:00:16 CET > > 1919-11-13 23:59:32 LMT > 1919-11-13 23:54:01 LMT > > Reasonable is also to behave similarly as other implementations. > > > > > You're making test cases which involve both 1 and 2 above, which ma= kes > > > > 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 eleme= nt > > > > 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. > > > > No, this happens regardless of the above. > > > Then provide an example. > > > > > 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 t= he > > > > 2011-12-29 corner case, but digging in on other things you think ar= e > > > > wrong, that are just fundamental to how local time works, is > > > > distracting from actually investigating that. Can we try to actuall= y > > > > figure out what's going on there? > > > > > > Sure. But that's not the only bug. > > > > Well I haven't seen any other credible claims of a bug in this thread. > > > I am not sure if this is a serious conversation. > > I have a struct tm created by mktime. So this is a valid structure that w= as produced by mktime. > I increment a field (be it second, minute, hour...) in that structure. > I call mktime to give me result of that calculation. > Result of mktime is a s struct tm that has earlier time than the original= struct tm. > > One of the primary purposes of struct tm and mktime is to make calculatio= ns. > > Currently the implementation in musl cannot take a date represented in st= ruct tm and iteratively increment it in second intervals to generated all d= ates up to some date. This basically means, that some calculations are impo= ssible to make. It cannot reliably take a date and add seconds, minutes, ho= urs, days... to that date and get the result. > > > Rich