From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 97BCA3858421 for ; Mon, 24 Oct 2022 21:13:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 97BCA3858421 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1666646006; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UAJYAg4VIV4Ck3zW//FYih1+8rU+WMs6iA3R8jmRynQ=; b=HzGWc63chke+dODVNvnUNu2n6ESNu5DsJ5+a4qrLRCe050j48T7nXg85VUmaUSB8Ba6WSi pJ5of0TNvNLwZQoaJXPPDHgBXDZTlzXGHPNongW9UykNTbqSS1h6W/pNmx0Uc+ePEhxgUm XIUTBU4+uMrE2ulgRL+tr6d8WwpzjAI= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-245-izvCaquNPBeR4QhVcC4cew-1; Mon, 24 Oct 2022 17:13:22 -0400 X-MC-Unique: izvCaquNPBeR4QhVcC4cew-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 1DF0E811E7A; Mon, 24 Oct 2022 21:13:22 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.16.74]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5D2191401C25; Mon, 24 Oct 2022 21:13:21 +0000 (UTC) From: Florian Weimer To: Paul Eggert Cc: libc-alpha@sourceware.org Subject: Re: [PATCH] manual: Add more documentation for the tm_isdst member of struct tm References: <87zgdl4c75.fsf@oldenburg.str.redhat.com> <806730c1-81d4-6601-8ecf-d1b8b322c324@cs.ucla.edu> Date: Mon, 24 Oct 2022 23:13:19 +0200 In-Reply-To: <806730c1-81d4-6601-8ecf-d1b8b322c324@cs.ucla.edu> (Paul Eggert's message of "Mon, 24 Oct 2022 12:44:58 -0700") Message-ID: <87r0yx0vtc.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: * Paul Eggert: >> +When clocks move backwards (due to time zone changes, or due to the >> +transition from daylight saving time to standard time), functions >> +converting to a broken-down time value such as @code{localtime} may >> +produce the same @code{tm_hour}, @code{tm_min}, @code{tm_sec} values fo= r >> +different input times. The @code{tm_isdst} field is used to >> +disambiguate these different points in time. >=20 > Unfortunately tm_dst cannot always disambiguate these points. Although > disambiguation works when the ambiguity is due to a DST fall-back=20 > transition, it cannot disambiguate in other cases. For example, with > TZ=3D'Europe/Volgograd', the timestamp 2020-12-27 01:30 is ambiguous but= =20 > both times have tm_isdst =3D=3D 0; this is because Volgograd permanently > switched from +04 to +03 that day so standard time was in use both=20 > before and after the clocks were changed. Huh. I genuinely thought that you'd use tm_isdst to disambiguate such cases. >> For example, for some time zones, the >> +role of positive and zero @code{tm_isdst} values are swapped in some >> +years. > > The role is not swapped. Some TZ settings have a negative DST offset; > that is, their UT offset is smaller when tm_isdst is positive, than > when tm_isdst is zero. I don't know what to make of this: $ zdump -v Europe/Dublin | grep 2022 Europe/Dublin Sun Mar 27 00:59:59 2022 UT =3D Sun Mar 27 00:59:59 2022 GMT= isdst=3D1 gmtoff=3D0 Europe/Dublin Sun Mar 27 01:00:00 2022 UT =3D Sun Mar 27 02:00:00 2022 IST= isdst=3D0 gmtoff=3D3600 Europe/Dublin Sun Oct 30 00:59:59 2022 UT =3D Sun Oct 30 01:59:59 2022 IST= isdst=3D0 gmtoff=3D3600 Europe/Dublin Sun Oct 30 01:00:00 2022 UT =3D Sun Oct 30 01:00:00 2022 GMT= isdst=3D1 gmtoff=3D0 #include #include #include #include And this: int main (void) { if (setenv ("TZ", "Europe/Dublin", 1) !=3D 0) err (1, "setenv"); time_t secs =3D 1666644387; struct tm *tm =3D localtime (&secs); if (tm =3D=3D NULL) err (1, "localtime"); printf ("%04d-%02d-%02dT%02d:%02d:%02d %d\n", tm->tm_year + 1900, tm->tm_mon + 1, tm->tm_mday, tm->tm_hour, tm->tm_min, tm->tm_sec, tm->tm_isdst); } prints (all of this is on Fedora): 2022-10-24T21:46:27 0 As far as I can tell, that's rather inconsistent with civilian use. Directive 2000/84/EC also calls this =E2=80=9Csummer time=E2=80=9D. I thought it was due to a Volgograd-style disambiguation (but didn't actually check). If this doesn't come from that and merely serves to express that IST is *not* daylight saving time (which is at least debatable), why isn't isdst zero during the winter as well? And if Ireland doesn't obey Daylight Saving Time in recent times, shouldn't tzset set the daylight variable to 0 if the TZ data is trimmed to post-1970 dates? Thanks, Florian