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.133.124]) by sourceware.org (Postfix) with ESMTPS id D0E523857366 for ; Wed, 26 Oct 2022 11:21:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D0E523857366 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=1666783292; 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: in-reply-to:in-reply-to:references:references; bh=t2bEduQ8FD6oAhziX3yPkJH2eeztnRZznchdE20S83g=; b=KLlvM3BDLLGCpn6WUBrGVgsqeBYBCXF25cche0iXTQJ8lsOi7b6gM9eqzrr6aj+y8rZWQ0 G9CVQR6BVQ/577dRvfazSs3E/C5+pkTkS5oW/FkL/GF98IUuwU7ONFGPuRrzWnuEcfzcix A/XeT+FJ5BjH89LXTYa00FBleJKC+S8= 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-122-Nyvqv3-cMgu9Mn3TAb1yFQ-1; Wed, 26 Oct 2022 07:21:29 -0400 X-MC-Unique: Nyvqv3-cMgu9Mn3TAb1yFQ-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 37372800B23; Wed, 26 Oct 2022 11:21:29 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.16.74]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 81E0540C2140; Wed, 26 Oct 2022 11:21:28 +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> <87r0yx0vtc.fsf@oldenburg.str.redhat.com> <68a8ff7f-75af-7e58-5f6e-0357eb76fc6a@cs.ucla.edu> <87h6zrwzdg.fsf@oldenburg.str.redhat.com> Date: Wed, 26 Oct 2022 13:21:26 +0200 In-Reply-To: (Paul Eggert's message of "Tue, 25 Oct 2022 11:27:32 -0700") Message-ID: <874jvqvnih.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.1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain 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: > 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. That's not my experience. We have heard from customers that they use non-negative values in their applications. Maybe we should just document that applications should set this field to -1 when constructing struct tm data? >> 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. In case of Ireland it seems an artificial complication, though. The perception seems to be that IST is summer time, not standard time, and winter time is not the exception. >>> 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. Okay, I don't like it, but it seems to be sort-of okay-ish. Thanks, Florian