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 692633858C3A for ; Tue, 25 Oct 2022 17:49:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 692633858C3A 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 192A21600A5; Tue, 25 Oct 2022 10:49:14 -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 CpPGkhB_g_Rs; Tue, 25 Oct 2022 10:49:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 30B471600A7; Tue, 25 Oct 2022 10:49:13 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.9.2 zimbra.cs.ucla.edu 30B471600A7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=78364E5A-2AF3-11ED-87FA-8298ECA2D365; t=1666720153; bh=1GqjfQ5mXW+GelcDBNQzvtzz2BY1Et5WwHQoQNJruq4=; h=Message-ID:Date:MIME-Version:To:From:Subject:Content-Type: Content-Transfer-Encoding; b=k1gKSl0Ph32Tpl5qnB0lStTu3wJTE4wIM5W2pBZUOgnt8LgvXkeA4TDsJ1pe3PtbY s7nK4aT91WvKtpw7qUfblfxsN3wQ/v+f4KeqTJsDDCZVIB9E1yDjIWeCuepWYR3Y43 QxXFdsmTA5hEon73OKWEnw3PzdFXolHRRzoHdm6U= 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 zc1o5LsyAyhy; Tue, 25 Oct 2022 10:49:13 -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 06ED51600A5; Tue, 25 Oct 2022 10:49:13 -0700 (PDT) Message-ID: <68a8ff7f-75af-7e58-5f6e-0357eb76fc6a@cs.ucla.edu> Date: Tue, 25 Oct 2022 10:49:12 -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> 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: <87r0yx0vtc.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_20,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-24 14:13, Florian Weimer wrote: > that's rather inconsistent with civilian use. It depends on which civilians you talk to. Irish legislation says that IST (UTC+01) is Irish Standard Time, and that Ireland observes "winter time" (i.e., negative daylight saving offset) during winter. Irish winter time is called "Greenwich mean time". See: https://github.com/eggert/tz/blob/main/europe#L359 https://www.irishstatutebook.ie/eli/1971/act/17/enacted/en/print There's something similar in Morocco, though in their case it's Ramadan time not winter time. > why isn't isdst zero during the winter as well? Because Irish daylight saving time is observed in winter not summer. Also, if tm_isdst were always zero, it'd be harder for mktime to disambiguate Irish timestamps. POSIX requires support for this sort of thing. Even if TZDB's Europe/Dublin entry were changed to disagree with Irish legislation, glibc would still need to support settings like this: TZ='IST-1GMT0,M10.5.0,M3.5.0/1' This POSIX-conforming TZ setting follows current Irish practice and specifies negative DST during winter. Perhaps we could mention this possibility in the manual. 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.