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 577E43858410 for ; Tue, 25 Oct 2022 18:27:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 577E43858410 Authentication-Results: sourceware.org; dmarc=pass (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 B18161600A5; Tue, 25 Oct 2022 11:27:34 -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 gl6Z_LVRnwwN; Tue, 25 Oct 2022 11:27:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id B80BF1600A7; Tue, 25 Oct 2022 11:27:32 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.9.2 zimbra.cs.ucla.edu B80BF1600A7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=78364E5A-2AF3-11ED-87FA-8298ECA2D365; t=1666722452; bh=BTOHMeNFCzfdWLsop/CkMYe3rITfVBkueKxRlx/ZBhU=; h=Message-ID:Date:MIME-Version:To:From:Subject:Content-Type: Content-Transfer-Encoding; b=UC/nfuB6TECcsbOwZOy5Aqn4jTD2NDYCGIWq+ZLQ/N9fDetTr0HfhULVuIXMVXJXM yJiEcokWtugt4X4MbOGCCXo3SO19oqGBOWMpengl1+4Mr3fhjqc2pJDRV+1+Ykpg6o l/mBlvgLaTlMf3J2U/rwYHPhdGGKZr9tBvY8MWoE= 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 lir5ugwCdsEp; Tue, 25 Oct 2022 11:27:32 -0700 (PDT) Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 8D8331600A5; Tue, 25 Oct 2022 11:27:32 -0700 (PDT) Message-ID: Date: Tue, 25 Oct 2022 11:27:32 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.3 Content-Language: en-US To: Florian Weimer Cc: libc-alpha@sourceware.org References: <87zgdl4c75.fsf@oldenburg.str.redhat.com> <806730c1-81d4-6601-8ecf-d1b8b322c324@cs.ucla.edu> <87r0yx0vtc.fsf@oldenburg.str.redhat.com> <68a8ff7f-75af-7e58-5f6e-0357eb76fc6a@cs.ucla.edu> <87h6zrwzdg.fsf@oldenburg.str.redhat.com> From: Paul Eggert Organization: UCLA Computer Science Department Subject: Re: [PATCH] manual: Add more documentation for the tm_isdst member of struct tm In-Reply-To: <87h6zrwzdg.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,JMQ_SPF_NEUTRAL,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2022-10-25 11:07, Florian Weimer wrote: > I think in other cases, tz goes with actual practices on the ground There is no real practice on the ground here, as nobody outside of libc nerds cares (or should care) whether tm_isdst is zero or positive. > I'm just trying to follow the line of thought. It's the same line of thought that Morocco uses. The ordinary time is the time observed most of the year. The unusual time is daylight saving time (or "alternative time", as POSIX sometimes puts it) and is observed during winter, or during Ramadan, or whatever. Other countries have done similar things in the past. >> PS. While we're on the subject of documentation, perhaps we should >> also mention that mktime can use tm_gmtoff to disambiguate >> otherwise-ambiguous time stamps. This is reliable even for situations >> like Volgograd in 2020, and it conforms to POSIX. A bit tricky to >> document, though. > > Huh. How can we do this tm_gmtoff thing without breaking C > compatibility? I'm worried that a conforming application might not > initialize tm_gmtoff (or rather __tm_gmtoff) properly. It doesn't break compatibility if tm_gmtoff is inspected only when tm_isdst doesn't resolve the ambiguity. At that point, if tm_gmtoff matches the tm_gmtoff of one of the two plausible timestamps, mktime can use that info to choose which one. It's OK if the input tm_gmtoff is uninitialized, as mktime could choose that one anyway. (Though it's officially undefined behavior to access uninitialized memory, in practice it's OK here.) With this approach, mktime is always the inverse of localtime even in cases like Volgograd, which is a clear win. Cute, huh? Though not currently documented.