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 904DB2022A for ; Tue, 26 Mar 2024 23:06:25 +0100 (CET) Received: (qmail 27727 invoked by uid 550); 26 Mar 2024 22:01:34 -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 27695 invoked from network); 26 Mar 2024 22:01:34 -0000 Date: Tue, 26 Mar 2024 21:59:14 +0000 (UTC) From: Thorsten Glaser X-X-Sender: tg@herc.mirbsd.org To: musl@lists.openwall.com In-Reply-To: Message-ID: References: <4YlR0YRqzZlDIOVv6SP8UDoop89n8u7BvQl_7eXNTvDZnogXMxG1z-TLGIBf-O4edUphddXGfADbk_d7Uzb37g5JoH7vOIvvNRMFDxPWZok=@pm.me> <20240325122113.GB4163@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 Alexander Weps dixit: >> Not at all, glibc=E2=80=99s mktime just throws the towel with >> EOVERFLOW saying that the requested time does not exist. > >How is this not compliant with POSIX? POSIX indicates that this is valid only if the date is not representable in time_t, and it has different handling for dates that fall into gaps, see the other mails from me, as well as below. >This is perfectly valid behavior, that is both expected and can be >handled in code easily. No, it=E2=80=99s a bug in glibc. >I have to ask, but have you actually used mktime from the application end? Of course. >I am not sure what you mean by correct. Struct tm is neither correct >nor incorrect. It can be in three states: >1) Set by user. >2) Normalized by mktime. >3) Not fully normalized by mktime. Huh? No. >If I get -1, I know the struct tm does not represent valid time_t and I >handle it and move on. Define =E2=80=9Cmove on=E2=80=9D. With POSIX=E2=80=99 mktime interface, if = you get -1 and EOVERFLOW, then moving further into the same direction will never give you not -1 again, because -1 is what you get when your tm_year was too far out of the representation (e.g. 2039 on a system with a 32-bit time_t). EOVERFLOW means that the time cannot be represented in time_t, not that the time cannot be represented in struct tm. And for these gaps, the time_t values are consecutive (1325239199/1325239200). >This is perfect example (TZ=3DPacific/Apia): > >before: 2011-12-31 00:00:00 +14 0 >after1: 2011-12-31 00:00:00 +14 1325239200 >after1: 2011-12-30 00:00:00 +14 -1 No, this cannot give -1 per POSIX. >Musl instead of giving sane results starts running in the circle at some p= oint: >after2: 2011-12-29 00:00:00 -10 1325152800 >after3: 2011-12-29 00:00:00 -10 1325152800 That=E2=80=99s because it does this correctly. >Doesn't work, this will not give the same time next day, this fails on >STD/DST changes. > >Because same time next day is not always 86400 apart. I know. But the basic assumption that there even is such a thing as =E2=80=9Csame time next day=E2=80=9D made by you is invalid. POSIX listed several examples (29=E1=B5=97=CA=B0 February next year as well as gaps in timezone offsets). One thing you can do is to add 86400, localtime(), then check that at least tm_mday, tm_hour and tm_min (Issue 8d4, line 48052) are what you expect, and handle cases where they aren=E2=80=99t manually. But having added 86400, you have two starting points from which to manually approach this (the original value and the newer value). (Perhaps a location could even skip more than 24 hours in a discontinuity.) bye, //mirabilos --=20 =E2=80=9CHaving a smoking section in a restaurant is like having a peeing section in a swimming pool.=E2=80=9D =09=09=09=09=09=09-- Edward Burr