From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id oASLOTXiVmLjiAAAgWs5BA (envelope-from ) for ; Wed, 13 Apr 2022 16:46:13 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id KCQ2MjXiVmKALAAAG6o9tA (envelope-from ) for ; Wed, 13 Apr 2022 16:46:13 +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 E426D2D143 for ; Wed, 13 Apr 2022 16:42:48 +0200 (CEST) Received: from localhost ([::1]:37510 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1neeCk-0001pr-Kn for larch@yhetil.org; Wed, 13 Apr 2022 10:42:46 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53168) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1neeBj-0001ni-Pj for emacs-orgmode@gnu.org; Wed, 13 Apr 2022 10:41:46 -0400 Received: from mail-lf1-x132.google.com ([2a00:1450:4864:20::132]:40765) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1neeBO-0007jP-8U for emacs-orgmode@gnu.org; Wed, 13 Apr 2022 10:41:43 -0400 Received: by mail-lf1-x132.google.com with SMTP id t25so3943135lfg.7 for ; Wed, 13 Apr 2022 07:41:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=WLq7rsligAMQ9iRjaLWsUczLioU2+eyU8NOUVGbpmQk=; b=aDN4Em1UEojmrCqMT7voEmYmjtLiV0dAvvotAmAw3/wM7avZT1LWouR1B84Iqv/KKH 6w3wU5LzeY9FjCBrjqldPoFWJKEAMZ26JIre4c1kk12Z3NqPWqAMm838btd9hW6jiVv6 WuV0RfvvSqj+yVQopW0wUpTVQUEeLIYHFZwR9NvhgsxAg++KZwG4TNusTa4jHARhJEax e9McBZ+mdygSM7pHRjWfu9/9yqUszkDlWSnVQ2SvkJMir6HygFv5HXQa5O/+OrG1rpuz 4ZMeY+9veDLRwudmB+nccSCmDEwAfQVJMqdXey74DCOkDhFdhJgYy9iKXN+1gK3WcyVJ k4KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:message-id:date:mime-version:user-agent :subject:content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=WLq7rsligAMQ9iRjaLWsUczLioU2+eyU8NOUVGbpmQk=; b=fQuSu1TN7yvwDQame0nTxHhNKmnjxLlPzSxev9CRbfeg1J9E07R/SIolf9BP+Ca+u4 i1b44BRRkg+Okk5/aFpqzxMc7iklPZ+IKJy0sWGHQWih6iSRI3K5Cerkd6TIWK39Vbng zmZljZLcjzUpvHKLQynlh23fvWwt7REU3w6Ze2k5X6gg1cqoxjS9Y3DTUOAJNA+jPFgl HeqcYOtsMCoiS9KRvO2H9KDGYPVtjxUo62dJhJhEP3+nMvYsYR67Bds26f0rS3E2Xo5r 3tR9QLNpG5Tk4fohH9x24aDOcxrP6cGDZtwxPbFi7K0XINDoKFwZwy0uc5mIVdqkbeD6 6ZFA== X-Gm-Message-State: AOAM533T03u9oAdhQpjKS/AfdllZYreYEb6xzVC75gjORBU58cu12X7R o0l/F6EXJgLsYUaehz/RV+s= X-Google-Smtp-Source: ABdhPJzd9ZCwtX0CgN0r4qV+HvFK493ZAZQokVfpiTNSu64tg20QLq8NeLt/CMC9lYWxG66JnUsXXw== X-Received: by 2002:a05:6512:398b:b0:46c:e5c3:9b55 with SMTP id j11-20020a056512398b00b0046ce5c39b55mr2283619lfu.601.1649860877022; Wed, 13 Apr 2022 07:41:17 -0700 (PDT) Received: from [192.168.0.101] (nat-0-0.nsk.sibset.net. [5.44.169.188]) by smtp.googlemail.com with ESMTPSA id k40-20020a0565123da800b0044aa117f1aasm4168267lfv.119.2022.04.13.07.40.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 Apr 2022 07:40:45 -0700 (PDT) Message-ID: Date: Wed, 13 Apr 2022 21:40:17 +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: Paul Eggert , 54764@debbugs.gnu.org References: <5ed963b2-3fa8-48d8-627e-bc0571d15b43@gmail.com> <149de00f-115b-5367-414f-c7700ef8966b@cs.ucla.edu> From: Max Nikulin In-Reply-To: <149de00f-115b-5367-414f-c7700ef8966b@cs.ucla.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=2a00:1450:4864:20::132; envelope-from=manikulin@gmail.com; helo=mail-lf1-x132.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 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=1649860969; 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:dkim-signature; bh=WLq7rsligAMQ9iRjaLWsUczLioU2+eyU8NOUVGbpmQk=; b=BEswftfm2+xBjBs/JWchOG6yysCLjUUPttnRUT2B1Iwi61/uUCALLJVwrkbR/ScJk21Cqn APxjRa6xdHZU4S4GL3KanXLMXn3Oqy+IzK/qdbvoJCbrCR94GQVTtUlhty3YTNni5Flrqz p0vWtLTZMaIDh2ZFka0PsVy9zV5oB5d4cdAzpTuJYlnkDJFlvKpwUVTES5lflfZBKPeSWL P8r5BCUCEvmEet/3PWiYKC+GNuLG45VbCT2rJt5ez+KR9FyqGS4i5c+D2NpdpWpTFdXDQb NXMjHyqGZGQf2XLD+OAR/ILsMm5zH+CQe1oxEeCtFyaKSU0HzJ1u/T+S/6T8RQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1649860969; a=rsa-sha256; cv=none; b=N68Zd0cQ8R/uzHGr7Q0KGdUd/IetegRjC9o+tOni6U4lVk8PcTcA8Jc7Yc0X2Ag5IXt2JR +T65bczCbmMShZFTvb8IXv+i0ylAP8gLI52TVT8rWAqf4ekXA7cDdk8IYAYcQkT1koyUvT +st90aL1jsM8lAvYJXi8nwGexpMC38+B8Q5C/DIzB3AqsNE7Xf/hHHSVGvJQDXrd2cefx5 J9LwYUs2lFGu0liM9VsnUAIfiqCFEl8curf0pp9jEjbaioBRsYXOD7O/OGlkgIoiYiQsy9 X0gza2engpxnsf8Fxc9zoBV2KeHLdz++z9p/Yx8v8Irdg4bruqWLpYxPO6r6aQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=aDN4Em1U; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=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: 5.65 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=aDN4Em1U; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=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: E426D2D143 X-Spam-Score: 5.65 X-Migadu-Scanner: scn0.migadu.com X-TUID: j18VKqeq9h6L On 09/04/2022 14:52, Paul Eggert wrote: > On 4/7/22 05:37, Max Nikulin wrote: > >>  From my point of view it is better to change implementation of >> `encode-time' so that it may accept 6-component list SECOND...YEAR. It >> should not add noticeable performance penalty but makes the function >> more convenient in use. > > Unfortunately it makes the function more convenient to use incorrectly. > This was part of the motivation for the API change. The obsolescent > calling convention has no way to deal with ambiguous timestamps like > 2022-11-06 01:30 when TZ="America/Los_Angeles". Org mode surely has bugs > in this area, although I don't have time to scout them out. Handling DST is a step forward, it is an important case. Unfortunately there are enough peculiarities in the time zoo. I do not think new interface can be used correctly in the following case of time transition with no change of DST: #+name: encode-time-and-format #+begin_src elisp :var time=nil :var tz=() :var dst=-1 (let* ((seconds-year (reverse (mapcar #'string-to-number (split-string time "[- :]")))) (time-list (append seconds-year (list nil dst tz)))) (format-time-string "%F %T %Z %z" (encode-time time-list) tz)) #+end_src zdump -v Africa/Juba ... Africa/Juba Sun Jan 31 20:59:59 2021 UT = Sun Jan 31 23:59:59 2021 EAT isdst=0 gmtoff=10800 Africa/Juba Sun Jan 31 21:00:00 2021 UT = Sun Jan 31 23:00:00 2021 CAT isdst=0 gmtoff=7200 #+call: encode-time-and-format(time="2021-01-31 23:30:00", tz="Africa/Juba", dst=-1) #+RESULTS: : 2021-01-31 23:30:00 CAT +0200 #+call: encode-time-and-format(time="2021-01-31 23:30:00", tz="Africa/Juba", dst=()) #+RESULTS: : 2021-01-31 23:30:00 CAT +0200 #+call: encode-time-and-format(time="2021-01-31 23:30:00", tz="Africa/Juba", dst='t) : Debugger entered--Lisp error: (error "Specified time is not representable") I do not see a way to get 23:30 EAT +0300. For you example with regular DST transition there is no any problem: #+call: encode-time-and-format(time="2022-11-06 01:30:00", tz="America/Los_Angeles", dst=-1) #+RESULTS: : 2022-11-06 01:30:00 PDT -0700 #+call: encode-time-and-format(time="2022-11-06 01:30:00", tz="America/Los_Angeles", dst=()) #+RESULTS: : 2022-11-06 01:30:00 PST -0800 #+call: encode-time-and-format(time="2022-11-06 01:30:00", tz="America/Los_Angeles", dst='t) #+RESULTS: : 2022-11-06 01:30:00 PDT -0700 > PS. Org mode usually uses encode-time for calendrical calculations. This > is dicey, as some days don't exist (for example, December 30, 2011 does > not exist if TZ="Pacific/Apia", because Samoa moved across the > International Date Line that day). And it's also dicey when Org mode > uses 00:00:00 (midnight at the start of the day) as a timestamp > representing the entire day, as it's all too common for midnight to not > exist (or to be duplicated) due to a DST transition. Generally speaking, > when Org mode is doing calendrical calculations it should use > calendrical functions rather than encode-time+decode-time, which are > best used for time calculations not calendar calculations. (I realize > that fixing this in Org would be nontrivial; perhaps I should file this > "PS" as an Org bug report for whoever has time to fix it....) Then `encode-time' should only accept time zone as time offset and should not allow default or named value that may be ambiguous. However my opinion is that is should be possible to provide hints to `encode-time' to get deterministic behavior in the case of time transitions. > diff --git a/lisp/org/org-compat.el b/lisp/org/org-compat.el > index 819ce74d93..247373d6b9 100644 > --- a/lisp/org/org-compat.el > +++ b/lisp/org/org-compat.el > @@ -115,6 +115,27 @@ org-table1-hline-regexp > (defun org-time-convert-to-list (time) > (seconds-to-time (float-time time)))) > > +;; Like Emacs 27+ `encode-time' with one argument. > +(if (ignore-errors (encode-time (decode-time))) > + (defsubst org-encode-time-1 (time) > + (encode-time time)) > + (defun org-encode-time-1 (time) > + (let ((dst-zone (nthcdr 7 time))) > + (unless (consp (cdr dst-zone)) > + (signal wrong-type-argument (list time))) > + (let ((etime (apply #'encode-time time)) > + (dst (car dst-zone)) > + (zone (cadr dst-zone))) > + (when (and (symbolp dst) (not (integerp zone)) (not (consp zone))) > + (let* ((detime (decode-time etime)) > + (dedst (nth 7 detime))) > + (when (and (not (eq dedst dst)) (symbolp dedst)) > + ;; Assume one-hour DST and adjust the timestamp. > + (setq etime (time-add etime (seconds-to-time > + (- (if dedst 3600 0) > + (if dst 3600 0)))))))) I am against this workaround. It fixes (to some extent) usual DST transitions, but it adds another bug Australia/Lord_Howe Sat Apr 2 14:59:59 2022 UT = Sun Apr 3 01:59:59 2022 +11 isdst=1 gmtoff=39600 Australia/Lord_Howe Sat Apr 2 15:00:00 2022 UT = Sun Apr 3 01:30:00 2022 +1030 isdst=0 gmtoff=37800 Australia/Lord_Howe Sat Oct 1 15:29:59 2022 UT = Sun Oct 2 01:59:59 2022 +1030 isdst=0 gmtoff=37800 Australia/Lord_Howe Sat Oct 1 15:30:00 2022 UT = Sun Oct 2 02:30:00 2022 +11 isdst=1 gmtoff=39600 > + etime)))) > + > ;; `newline-and-indent' did not take a numeric argument before 27.1. > (if (version< emacs-version "27") > (defsubst org-newline-and-indent (&optional _arg)