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.1 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE 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 99C892025B for ; Sun, 24 Mar 2024 03:04:24 +0100 (CET) Received: (qmail 32050 invoked by uid 550); 24 Mar 2024 01:59:42 -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 32009 invoked from network); 24 Mar 2024 01:59:41 -0000 Date: Sat, 23 Mar 2024 22:04:29 -0400 From: Rich Felker To: Alexander Weps Cc: musl@lists.openwall.com, Markus Wichmann Message-ID: <20240324020429.GU4163@brightrain.aerifal.cx> References: <20240323123148.GR4163@brightrain.aerifal.cx> <5zS95V9QjlCRMv6JvbMFzFIOvxQTigAsEvu0YNSYzcu1ZHdki6sue6yqDXeWlRcSe_jhCQxHdHc0fvKu-3H7lCvyAeYgQTsK7KWMepbly3Y=@pm.me> <20240323153146.GS4163@brightrain.aerifal.cx> <-44SZR0LbVoyD5lp_9VrAFnIjGNbDvibCVUYEprqMToPidjopTHM4aLZuhjomrGJtvpGrc_gjrgK6roKWwunjEkk1y-BKRhtlGpWjnslQNA=@pm.me> <20240323201804.GT4163@brightrain.aerifal.cx> <6rPmS4jev9oFFibDdpKZ0mVRWLV3rhRcfqaUKu-5lPP7lc8zz8UH_kgPFA4r8wh1-qrYKfzVBpB0Ss6z4VMANASybmKZMeB9i3W3auYfhMI=@pm.me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6rPmS4jev9oFFibDdpKZ0mVRWLV3rhRcfqaUKu-5lPP7lc8zz8UH_kgPFA4r8wh1-qrYKfzVBpB0Ss6z4VMANASybmKZMeB9i3W3auYfhMI=@pm.me> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Broken mktime calculations when crossing DST boundary On Sat, Mar 23, 2024 at 08:40:50PM +0000, Alexander Weps wrote: > Yes, the behavior is the same here glibc and musl and it can't > reliably determine start of the day etc. Which is I assume expected. > > That's why there is tm_isdst = -1. > > I don't see any reliable way to determine beginning of the day without it. It's rather inherent to the horribleness of DST that determining the "beginning of the day" is not easy. In fact, it might not even be well-defined, depending on where your timezone puts its transition (it could happen right at midnight just to be evil; that it doesn't is only a matter of polite convention). > If I want to get beginning of the day I do it this way: > > before: 2010-10-31 14:00:00 CET > tm_sec: 0 > tm_min: 0 > tm_hour: 14 > tm_mday: 31 > tm_mon: 9 > tm_year: 110 > tm_wday: 0 > tm_yday: 303 > tm_isdst: 0 > tm_gmtoff: 3600 > tm_zone: CET > > tm.tm_isdst = -1; <-- setting tm_isdst = -1 > tm.tm_hour = 0; > mktime(&tm); > > after: 2010-10-31 00:00:00 CEST > tm_sec: 0 > tm_min: 0 > tm_hour: 0 > tm_mday: 31 > tm_mon: 9 > tm_year: 110 > tm_wday: 0 > tm_yday: 303 > tm_isdst: 1 > tm_gmtoff: 7200 > tm_zone: CEST > > Is there a way, how to reliable get beginning of day etc. without > tm_isdst = -1. Depending on how you want to define it, yes, but it may need a second call to mktime. First, call mktime with 00:00:00 and tm_isdst=0. If the result has tm_isdst==0, you're done. If not, try again with the original struct tm input but tm_isdst changed to 1. The only way this procedure will fail is if the time 00:00:00 *does not exist* on that particular day. Note that if DST ends such that there are two times 00:00:00 on a particular day, this will pick the second (non-DST) one, as the first one might only be the new day temporarily, then jump back to the old day, which does not strike me as a good "beginning of the day". You could flip the order you try them around if you prefer to count it. Rich