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 D95693858432 for ; Tue, 25 Oct 2022 18:07:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D95693858432 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=1666721262; 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=xlVXSGEST12cXt4V2Ff7L9QWrD2cnCFIy342SFXF48I=; b=UMorSVfngq7sdrj2qDF/6UW0AZ1qIlg3XsN5G4pDlbkeOwy38Gta0US/6VLM9BicIQJ5Uz mVcAIRlyOHu+lZVQMbMVGDTLw2nXAW1kKt4iewm/jEl0YrLQiPOL0XdX20QycpcgP6Mrbn admmMoDKH9FDPtyv2WPU4NeOey7Ufig= 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-557-g6ZRz8gtNNmv_zZL0y86cQ-1; Tue, 25 Oct 2022 14:07:41 -0400 X-MC-Unique: g6ZRz8gtNNmv_zZL0y86cQ-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id DEA61101E148; Tue, 25 Oct 2022 18:07:40 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.16.74]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5DC11492B0A; Tue, 25 Oct 2022 18:07:40 +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> Date: Tue, 25 Oct 2022 20:07:39 +0200 In-Reply-To: <68a8ff7f-75af-7e58-5f6e-0357eb76fc6a@cs.ucla.edu> (Paul Eggert's message of "Tue, 25 Oct 2022 10:49:12 -0700") Message-ID: <87h6zrwzdg.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.10 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: > 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=20 > 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 I think in other cases, tz goes with actual practices on the ground, not what the internationally recognized government says what the time should be. Just saying. > 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. This seems to be a bit of a jump? Is it an inference from the fact that summer time is called =E2=80=9CIrish Standard Time=E2=80=9D, and that the A= ct gives permission to change or abolish winter time, but not standard time? So winter time is presented as an exception. Daylight saving time is also presented as an exception, therefore winter time is daylight saving time? I'm just trying to follow the line of though. > PS. While we're on the subject of documentation, perhaps we should > also mention that mktime can use tm_gmtoff to disambiguate=20 > otherwise-ambiguous time stamps. This is reliable even for situations > like Volgograd in 2020, and it conforms to POSIX. A bit tricky to=20 > 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. Thanks, Florian