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 CE32D382458A for ; Wed, 26 Oct 2022 19:05:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CE32D382458A 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 D4EB61600A8; Wed, 26 Oct 2022 12:05:08 -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 bJ-IYi8UQkgx; Wed, 26 Oct 2022 12:05:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 024A21600AA; Wed, 26 Oct 2022 12:05:08 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.9.2 zimbra.cs.ucla.edu 024A21600AA DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=78364E5A-2AF3-11ED-87FA-8298ECA2D365; t=1666811108; bh=bRHXgxnfY5q7BdTLWQ03XOMUVH2q0WEp+hb4QW5n/JM=; h=Message-ID:Date:MIME-Version:To:From:Subject:Content-Type: Content-Transfer-Encoding; b=SMGeRYzxCXEro03Di0+rvJAx/xJSjwqKBipU+CA2l3vMtiDQXTLDskiCsJyMf+33l 3GFKuVPyBTXtfsUXhN0sQIM13wrcbdJcq6iafk9uR+RHyjuoqEMKc00y2UPcwnUjY9 fv80EeKibq+1wga2m8caT6rLJ6eCkadutPzamwuU= 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 eXL5koxrseJn; Wed, 26 Oct 2022 12:05:07 -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 D12371600A8; Wed, 26 Oct 2022 12:05:07 -0700 (PDT) Message-ID: <6b01632f-047c-c18f-5616-4037bfe706fa@cs.ucla.edu> Date: Wed, 26 Oct 2022 12:05:07 -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> <874jvqvnih.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: <874jvqvnih.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.6 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-26 04:21, Florian Weimer wrote: > * 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. Oh, by "practice on the ground" I meant ordinary people and mass media and the like, not software developers who have to deal with the tm_isdst mess. > Maybe we should just document that applications should set this field to > -1 when constructing struct tm data? Yes, if you're deriving struct tm data from the outside world and you have no idea what tm_isdst etc. should be, your apps should set tm_isdst to -1. However, if the outside world tells you tm_gmtoff (which is pretty common these days, e.g., see the "Date:" line in this email), then your apps should also set tm_gmtoff to what the outside world tells you, before you call mktime. > In case of Ireland it seems an artificial complication, though. The > perception seems to be that IST is summer time, not standard time My impression is different, in that people in Ireland typically say "summer time" or "winter time". They typically do not say "standard time" or "daylight saving time". And as it happens, summer time = standard time in Ireland. Part of the confusion here is that the British English phrase "summer time" is not the same thing as the American English phrase "daylight saving time". The two phrases mean the same thing for UK and US timekeeping, but not for Irish timekeeping. Since the Irish typically use British English, they refer to their timekeeping correctly. I think this confusion is partly why POSIX sometimes says "alternative time" instead of "daylight saving time" - it's trying to avoid using either British or American English and thus avoid the confusion. Though I wish POSIX would stick to just one phrase rather than using two, since the two phrases in POSIX mean the same thing. I expect the problem here is that the C Standard says "daylight saving time" and POSIX copies from that when it has to, and uses "alternative time" when it doesn't. Though the use of two terms in POSIX simply adds to the confusion....