From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id gLgtA5ykWGIHSAAAgWs5BA (envelope-from ) for ; Fri, 15 Apr 2022 00:47:56 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id 4AubN5ukWGLNVAEAG6o9tA (envelope-from ) for ; Fri, 15 Apr 2022 00:47:55 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 4E34D36A00 for ; Fri, 15 Apr 2022 00:47:51 +0200 (CEST) Received: from localhost ([::1]:48318 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nf8Fi-0002ar-2F for larch@yhetil.org; Thu, 14 Apr 2022 18:47:50 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:32900) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nf8Ez-0002aR-MQ for emacs-orgmode@gnu.org; Thu, 14 Apr 2022 18:47:05 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:48678) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nf8Ex-0006uE-4A for emacs-orgmode@gnu.org; Thu, 14 Apr 2022 18:47:05 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 37CFE16007E; Thu, 14 Apr 2022 15:47:00 -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 LmDHBoLP6G3B; Thu, 14 Apr 2022 15:46:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 42E52160098; Thu, 14 Apr 2022 15:46:59 -0700 (PDT) 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 pxkTnR3jT3eJ; Thu, 14 Apr 2022 15:46:59 -0700 (PDT) Received: from [131.179.64.200] (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 2041116007E; Thu, 14 Apr 2022 15:46:59 -0700 (PDT) Message-ID: <52fb10fb-892a-f273-3be8-28793f27e204@cs.ucla.edu> Date: Thu, 14 Apr 2022 15:46:58 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones Content-Language: en-US To: Max Nikulin References: <5ed963b2-3fa8-48d8-627e-bc0571d15b43@gmail.com> <149de00f-115b-5367-414f-c7700ef8966b@cs.ucla.edu> <2dd15844-01b3-0144-740c-185ec8488a81@cs.ucla.edu> <4a23f3a4-fe8f-d396-49d8-10034803be63@gmail.com> From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <4a23f3a4-fe8f-d396-49d8-10034803be63@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=131.179.128.68; envelope-from=eggert@cs.ucla.edu; helo=zimbra.cs.ucla.edu X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: emacs-orgmode@gnu.org, 54764@debbugs.gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1649976471; h=from:from:sender:sender: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:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=v8CXpFfsGjk+1aV57Zd9T27wWqw9C2QKVwA+n16n/QE=; b=HRsqIkGM7LGaFu2OD7QBSRrAqTEm5Zv5ygu+lstOsFKSfBDp/E9w/JAHXDod0RKV9xopJs H3IFMYBckJYgq9JXekiOeuGnp+uqYTHsOR3KXGEFsbVvAmuk3OWghreu35n6YnBQ2IcBjt kpFzigBXyZ9gfte/v+iwFJfzzR+XJc2En4vH2/H0AHKdd1KJnn2xTikbo2Hb+kYHn1pefh fXfmDjh+4ZyDgUqBDuSTqprz5F3EueSGt6MzBVIZnTHXKCatvVSwx58/12Cw6CvGj7zeAf U9T3cpbKomHkj5yF+YUhUbeMzILqrlvmcbMV+LxM36Jn2wo2XwGpkSb8RyOXMg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1649976471; a=rsa-sha256; cv=none; b=BICzXMoSS6CyRqwQW6g7GBK664qf2rHOthmxZDA+lT9xILUzHHMjFZWSoxJfyVjueRUfwQ 4hleitR5+YGNzyUje9qZrA6Dgu6jqjAreefasu6TEXWqxpNNhJNOp5Xb50i3g34QeWt9yA 7je/Up0cgJBtpn945WgvU7MuX4OCDrgZSTvFcg2rTNjgGP7+/f8L1mA20N3unf3cLRf+y0 57o8bGxbS6fhLmzIQeFSm1ok8gP+BkVumaxGIrBvADhSvt9PV8kvy4VdZav3g2IcGlJhNu 7HN7Luz9ChD0CnSjVBcH4EAzSbPYh6+5jS8VA0WUfb/F5W24IeKAJAG5S5n7xg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -4.14 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 4E34D36A00 X-Spam-Score: -4.14 X-Migadu-Scanner: scn0.migadu.com X-TUID: 0VComrm4CqbG On 4/14/22 06:19, Max Nikulin wrote: > date-time +=20 > "America/Los_Angeles" input should not be reduced to timezone offset in= =20 > the output. It depends on the application. For some applications (e.g., generating=20 "Date:" lines in email), it is entirely correct to output a timestamp=20 like "14 Apr 2022 15:16:04 -0700", thus losing the fact that the=20 timestamp was generated with TZ=3D"America/Los_Angeles". > Zone internal object or identifier is important for calculation of othe= r date-time values based on the origin value. Again, that depends on the application. It's typically wrong to store an=20 old timestamp in a form like "1950-07-01 00:00 Europe/Lisbon", because=20 there is no standard for what "Europe/Lisbon" means. If you update your=20 copy of TZDB, or interpret such a timestamp on another computer, that=20 can change the interpretation of such a timestamp. In this particular=20 case, a change in TZDB release 2021b altered the interpretation of this=20 old timestamp because we discovered that DST was observed in 1950 in=20 Portugal. If you want to keep the TZDB identifier for advice about how to=20 interpret dates relative to a timestamp, that's fine. But you should=20 keep the UT offset in addition to the TZDB identifier, if you want your=20 app to be fully accurate and useful. For example, you should store=20 "1950-07-01 00:00:00 +0000 Europe/Lisbon" for a timestamp generated by=20 TZDB release 2021a, so that when you interpret the timestamp in release=20 2021b you'll have an idea of what you're dealing with. > I want hints like "in the case of ambiguity resolve to transition time = immediately before/immediately after transition" or "provide suitable tim= e prior to/after to transition". Although that might be nice it's not what mktime gives us, and I doubt=20 whether it's a good idea to try to implement it from scratch in Emacs. > I hope, they may work without explicitly providing time zone offset to = the input that anyway requires additional calculations.=20 It doesn't require additional calculations on the Emacs Lisp user's=20 part. All you need to do is save the UT offset, and use it later.=20 There's so little overhead to this that it's not worth worrying about. > =C2=B1n hours may mean =C2=B1n*3600 seconds or time with same minutes a= nd seconds=20 > values but hours value is changed by n even if a 30 min DST transition=20 > happens in between. Sorry, I don't understand what this sentence is intended to mean. > `parse-time-string' has another set of problems. Sure, but that was just an example. You can write your own date parser.=20 The point is that when you save a localtime timestamp, you should save=20 its UT offset too, in whatever notation is appropriate. > UTC offset is another feature and implementing the hints I have=20 > tried to describe may require implementing from scratch full stack of=20 > time handling functions. I doubt whether that's a good idea. I've written that sort of code, and=20 it's a lot more work than one might think and it's notoriously difficult=20 to do it correctly. You have better things to do. > So I still do not see any point in mandatory DST and ZONE fields in new= =20 > interface of `encode-time'. I think we're in agreement here. As I mentioned earlier, I plan to=20 modify Emacs encode-time so that you can pass it a 6-arg list as well as=20 an 9-arg list. Once this change is in, the DST and ZONE fields will not=20 be mandatory.