From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from zimbra.cs.ucla.edu (zimbra.cs.ucla.edu [131.179.128.68]) by sourceware.org (Postfix) with ESMTPS id 31D3B3858D28 for ; Thu, 18 Aug 2022 21:58:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 31D3B3858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=cs.ucla.edu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=cs.ucla.edu Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 40445160073; Thu, 18 Aug 2022 14:58:06 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id pIo6S8cYNbwM; Thu, 18 Aug 2022 14:58:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 756BE160091; Thu, 18 Aug 2022 14:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id IoKc0StCv8yJ; Thu, 18 Aug 2022 14:58:05 -0700 (PDT) Received: from [100.115.92.201] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 7F5A4160073; Thu, 18 Aug 2022 14:58:04 -0700 (PDT) Message-ID: Date: Thu, 18 Aug 2022 14:57:43 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Subject: Re: [swbz 29035] mktime vs non-DST Content-Language: en-US To: DJ Delorie Cc: libc-alpha@sourceware.org, Carlos O'Donell References: From: Paul Eggert In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2022 21:58:08 -0000 A couple of things about those examples. First, mktime is not "broken" if it returns a time_t that differs from the time_t that you passed to localtime before fiddling with localtime's resulting struct tm by changing its is_dst flag. That's normal and expected mktime behavior, and many (perhaps most) mktime implementations do that, and this is illustrated by the New York examples. Second, and more important, the reason users are complaining is that they want to answer questions like "What time is it 30 days after time T?" by calling localtime on T, adding 30 to the resulting tm_mday, and then calling mktime on the modified struct tm. This process fails in recent glibc if the modified struct tm happens to have the wrong tm_isdst flag because DST began or end sometime within the 30-day period. With this in mind, DJ's Tokyo examples (which is the only place where Gnulib's behavior disagrees with old glibc) illustrate why the differences between old glibc and Gnulib (a) largely don't matter, and (b) when they do matter, Gnulib is better. Here's why: (a) In Tokyo, adding 30 to tm_mday (or whatever) to a contemporary timestamp cannot yield a timestamp with the wrong tm_isdst because Tokyo hasn't observed DST since 1951, so DJ's examples of Tokyo "broken dst" (which is not really broken) largely don't matter. (b) In the *extremely* unusual case where someone takes a circa-1951 Tokyo timestamp with tm_isdst=1 and adds 25000 to tm_mday to get a contemporaneous timestamp, Gnulib mktime will treat this consistently with how it treats New York (and with how it treats adding only 365 to Tokyo tm_mday), whereas old glibc will treat it inconsistently. Of course this use case is implausible, but the use case of adding 10 years to a circa-2021 timestamp in Fiji is more plausible, and there again old glibc is inconsistent whereas Gnulib is consistent.