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=-3.0 required=5.0 tests=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 44582217F5 for ; Tue, 26 Mar 2024 00:18:17 +0100 (CET) Received: (qmail 17485 invoked by uid 550); 25 Mar 2024 23:13:31 -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 17453 invoked from network); 25 Mar 2024 23:13:30 -0000 Date: Mon, 25 Mar 2024 23:16:05 +0000 (UTC) From: Thorsten Glaser X-X-Sender: tg@herc.mirbsd.org To: musl@lists.openwall.com In-Reply-To: <20240325134252.GE4163@brightrain.aerifal.cx> Message-ID: References: <20240324192258.GY4163@brightrain.aerifal.cx> <-svm5EdX4OFN9hKzgS2FP6N1lgUGjT7edQONkAfCywgsRitwT6Vw22W3sUUGY_pnKGIXBKlujMZhPCDkJAMCYbBA5uF-IYgzhj8WB0wBE-A=@pm.me> <4YlR0YRqzZlDIOVv6SP8UDoop89n8u7BvQl_7eXNTvDZnogXMxG1z-TLGIBf-O4edUphddXGfADbk_d7Uzb37g5JoH7vOIvvNRMFDxPWZok=@pm.me> <20240325122113.GB4163@brightrain.aerifal.cx> <20240325131318.GD4163@brightrain.aerifal.cx> <20240325134252.GE4163@brightrain.aerifal.cx> Content-Language: de-Zsym-DE-1901-u-em-text-rg-denw-tz-utc, en-Zsym-GB-u-cu-eur-em-text-fw-mon-hc-h23-ms-metric-mu-celsius-rg-denw-tz-utc-va-posix 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 I wrote (in another mail): > tbh I=E2=80=99d expect this to end up in 1325239199=3D2011-12-29 23:59:59 > instead of 2011-12-29 01:00:00 though, at least from reading the > latest Issue 8 proofreading draft. WDYT dalias? Looking at the spec again, my expectation was wrong, the=E2=80=A6 | [=E2=80=A6] and the broken-down time corresponds to a time that was (or w= ill | be) skipped over or repeated due to the occurrence of such a change, | mktime() shall calculate the time since the Epoch value using either | the offset in effect before the change or the offset in effect after | the change. =E2=80=A6 doesn=E2=80=99t yield this. In fact, further down, we have: | If a geographical timezone changes its UTC offset such that =E2=80=9Cold | 00:00=E2=80=9D becomes =E2=80=9Cnew 00:30=E2=80=9D and mktime() is given = 00:20, it treats that | as either 20 minutes after =E2=80=9Cold 00:00=E2=80=9D or 10 minutes befo= re =E2=80=9Cnew | 00:30=E2=80=9D, and gives back appropriately altered struct tm fields. This entirely specifies how this is to be handled=E2=80=A6 (more below). Rich Felker dixit: >Hopefully that will clarify things for you. On musl you will see: > >normalized input: 2011-12-29 00:00:00 -10 >+1day per mktime: 2011-12-29 00:00:00 -10 >+1day via time_t: 2011-12-31 00:00:00 +14 >-1day per mktime: 2011-12-28 00:00:00 -10 >-1day via time_t: 2011-12-28 00:00:00 -10 > >normalized input: 2011-12-31 00:00:00 +14 >+1day per mktime: 2012-01-01 00:00:00 +14 >+1day via time_t: 2012-01-01 00:00:00 +14 >-1day per mktime: 2011-12-29 00:00:00 -10 >-1day via time_t: 2011-12-29 00:00:00 -10 > >You can see what you get on glibc. Debian 11 (glibc 2.31) amd64: $ TZ=3DPacific/Apia ./mktime_rel "2011-12-29 00:00:00" normalized input: 2011-12-29 00:00:00 -10 mktime day+1: Value too large for defined data type +1day via time_t: 2011-12-31 00:00:00 +14 -1day per mktime: 2011-12-28 00:00:00 -10 -1day via time_t: 2011-12-28 00:00:00 -10 $ TZ=3DPacific/Apia ./mktime_rel "2011-12-31 00:00:00" normalized input: 2011-12-31 00:00:00 +14 +1day per mktime: 2012-01-01 00:00:00 +14 +1day via time_t: 2012-01-01 00:00:00 +14 mktime day-1: Value too large for defined data type -1day via time_t: 2011-12-29 00:00:00 -10 Same on sid. Looking at the spec excerpt from above, I think returning EOVERFLOW is not permitted here, so glibc has something to fix=E2=80=A6 MirBSD/i386: $ TZ=3DPacific/Apia ./mktime_rel "2011-12-29 00:00:00" normalized input: 2011-12-29 00:00:00 -10 +1day per mktime: 2011-12-30 00:00:00 -10 =E2=86=90 how? probably bug in = old tzcode +1day via time_t: 2011-12-31 00:00:00 +14 -1day per mktime: 2011-12-28 00:00:00 -10 -1day via time_t: 2011-12-28 00:00:00 -10 $ TZ=3DPacific/Apia ./mktime_rel "2011-12-31 00:00:00" normalized input: 2011-12-31 00:00:00 +14 +1day per mktime: 2012-01-01 00:00:00 +14 +1day via time_t: 2012-01-01 00:00:00 +14 -1day per mktime: 2011-12-30 00:00:00 +14 =E2=86=90 how? probably bug in = old tzcode -1day via time_t: 2011-12-29 00:00:00 -10 I think I=E2=80=99ll have a bug to fix there ;) But that code is ancient and doesn=E2=80=99t yet know about all those new standards=E2=80=A6 Looking at the spec excerpt from above again, what we have is a discontinuity=E2=80=A6 $ TZ=3DPacific/Apia date -d @1325239199 Thu Dec 29 23:59:59 -10 2011 $ TZ=3DPacific/Apia date -d @1325239200 Sat Dec 31 00:00:00 +14 2011 =E2=80=A6 and an incoming request via struct tm of, let=E2=80=99s say: 2011-12-30 01:00:00 From=20the excerpt above, mktime can now treat this as either 1 hour after =E2=80=9Cold 2011-12-30 00:00:00=E2=80=9D or 23 hours before =E2=80=9Cnew 2011-12-31 00:00:00=E2=80=9D. Old 2011-12-30 00:00:00 becomes new 2011-12-31 00:00:00, so in the first case, the expected result is indeed 2011-12-31 01:00:00 (independent of whether one is going up or down!), and 23 hours before new 2011-12-31 00:00:00 becomes 23 hours before old 2011-12-30 00:00:00 becomes 2011-12-29 01:00:00. Which is what musl returns, which means indeed musl DTRT here. bye, //mirabilos --=20 =E2=80=9CIt is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.=E2=80=9D =09-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2