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 2CDB822346 for ; Sun, 24 Mar 2024 19:00:40 +0100 (CET) Received: (qmail 12045 invoked by uid 550); 24 Mar 2024 17:55:57 -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 12013 invoked from network); 24 Mar 2024 17:55:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1711303227; x=1711562427; bh=zIqlxgBICmLaRkY0pToEVf9V1OIN09pUJB9CuZN1F1U=; 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=B5+BoVhuR1kYhDTh2O8j4farufje8BD6+lWtR8tG82oKi+pgSJVeoG+ulELyyqhHa G4Z3v+RaRrhe8m145RTORRgWwMa8+hXMQ5OqN+4Y0EdWNUwHwhkR2tN8L+8MyMJNEE DpTTOQlAywDzOjVf1X8URhiyFxy2VV8hMu8pbCoCsLlXWbHxh67Lwi9GGOu6eBCBj9 8wTtDGnZlLJVfw7w6ZuH8lVCF9aWBd5OLxFzAxDX7UmkxyqkP7RvL+UacKUKcob4Bo jSiUV+xFClHBcohTAzt4FJlff1PhmfhDRlNEACg/cVXYSJTQCLAUMirdyRHAYZtSFg lxmRQgsUwzB7Q== Date: Sun, 24 Mar 2024 18:00:06 +0000 To: musl@lists.openwall.com From: Alexander Weps Cc: Daniel Gutson , Markus Wichmann Message-ID: In-Reply-To: <0_9-JV2MW3avVvzhE9vjqKqCX0fEZy0uUuZKIohFGEFDBY912nwZyxZe560H0cf_b8L2gD8e0eUAUp2Q3e1rmra3XEppx9HPhhFeulwLYZA=@pm.me> References: <20240324170436.GV4163@brightrain.aerifal.cx> <0_9-JV2MW3avVvzhE9vjqKqCX0fEZy0uUuZKIohFGEFDBY912nwZyxZe560H0cf_b8L2gD8e0eUAUp2Q3e1rmra3XEppx9HPhhFeulwLYZA=@pm.me> 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 So I started from: 1900-01-01 00:00:00 Adding 59 seconds each cycle (to speed things up). And I already have some cycles in Musl even for Europe/Prague. 1946-12-01 02:59:17 CET 1946-12-01 01:00:16 CET <-- There should be: 1946-12-01 02:00:16 GMT This looks like an issue involving negative DST change. There were 3 STD/DST changes in 1946 in Europe/Prague: 1945-10-01 01:00:00Z +01:00:00 standard CET 1946-05-06 01:00:00Z +02:00:00 daylight CEST 1946-10-06 01:00:00Z +01:00:00 standard CET 1946-12-01 02:00:00Z +00:00:00 daylight GMT 1947-02-23 02:00:00Z +01:00:00 standard CET And it works in glibc. I was able to run it all the way from 1900 to 2200. Glibc correctly went from CET to GMT and then back: 1946-12-01 02:59:57 CET 1946-12-01 02:00:56 GMT ... AW On Sunday, March 24th, 2024 at 18:12, Alexander Weps wrot= e: > Adding seconds cannot make time go backwards. If that is how it was inter= preted, than the interpretation is erroneous. > > I think I will do some test. > > If you start with 1900-01-01 00:00:00 and start adding seconds and callin= g mktime, you should reliable get to 2200-12-31 59:59:59 in all timezones. = Same goes for minutes, hours, days, years. > > If that's not the case then the interpretation in musl is wrong. > > This is a basic elementary functionality of mktime. > > There can't be any going back in time a cycles. > > AW > > > > On Sunday, March 24th, 2024 at 18:04, Rich Felker dalias@libc.org wrote: > > > On Sun, Mar 24, 2024 at 01:36:42PM +0000, Alexander Weps wrote: > > > > > Also thanks for the Pacific/Apia example. Not only that it fails for = that date: > > > Pattern: * * * * * * > > > Initial: 2011-12-29_23:59:59 > > > Expected: 2011-32-31_00:00:00 > > > Actual: 2011-12-29_00:00:00 > > > My cron tool again going back in time. > > > > > > It fails one other test. > > > > > > I have to run my tests on multiple timezones. > > > > > > And it works in glibc. > > > > > > And that's after I removed tm_isdst and rewrote half the code to acco= mmodate. > > > > > > Can We agree on some simple premise that with no uncertain STD/DST > > > settings (tm_isdst =3D 0 or tm_isdst =3D 1), incrementing seconds by = 1 > > > and calling mktime should never cause time to go back? > > > > > > Well, behold Pacific/Apia: > > > > > > I set 2011-12-29 23:59:59: > > > > > > tm_sec: 59 > > > tm_min: 59 > > > tm_hour: 23 > > > tm_mday: 29 > > > tm_mon: 11 > > > tm_year: 111 > > > tm_wday: 0 > > > tm_yday: 0 > > > tm_isdst: 1 > > > tm_gmtoff: 0 > > > tm_zone: (null) > > > > > > Calling mktime to see if everything is correct: > > > mktime(&tm); > > > > > > before: 2011-12-29 23:59:59 -10 > > > tm_sec: 59 > > > tm_min: 59 > > > tm_hour: 23 > > > tm_mday: 29 > > > tm_mon: 11 > > > tm_year: 111 > > > tm_wday: 4 > > > tm_yday: 362 > > > tm_isdst: 1 > > > tm_gmtoff: -36000 > > > tm_zone: -10 > > > > > > Incrementing seconds and calling mktime: > > > tm.tm_sec +=3D 1; > > > mktime(&tm); > > > > > > after: 2011-12-29 00:00:00 -10 > > > tm_sec: 0 > > > tm_min: 0 > > > tm_hour: 0 > > > tm_mday: 29 > > > tm_mon: 11 > > > tm_year: 111 > > > tm_wday: 4 > > > tm_yday: 362 > > > tm_isdst: 1 > > > tm_gmtoff: -36000 > > > tm_zone: -10 > > > We went from: > > > 2011-12-29 23:59:59 -10 > > > To: > > > 2011-12-29 00:00:00 -10 > > > > > > By adding 1 second. The tm_isdst was not set to -1. > > > > > > This is totally unreliable. > > > > From what I understand, you've set the input to a time that doesn't > > exist in the local timezone: 2011-12-30 00:00:00. This could be either > > 1 second after 2011-12-29 23:59:59, as you intended, or 1 day before > > 2011-12-31 00:00:00. The latter is how it was interpreted. However, it > > does not seem to have correctly set tm_gmtoff to reflect how it was > > interpreted. We should check this out because that's probably an > > actual bug. > > > > Rich