--- Begin Message ---
|
Subject: |
encode-time: make DST and TIMEZONE fields of the list argument optional ones |
|
Date: |
Thu, 7 Apr 2022 19:37:43 +0700 |
|
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 |
Consider the following change of `encode-time' calling convention: last
3 elements of the TIME argument as a list should be optional. I mean
IGNORED, DST, and ZONE.
(encode-time '(0 30 20 07 04 2022 nil -1 nil))
(encode-time '(0 30 20 07 04 2022)) ; currently causes an error
Since Emacs-27 time fields as separated arguments are considered
obsolete for calls of `encode-time'. Org mode keeps compatibility with
Emacs-26 where passing all time components as a single list is not
supported. Moreover, some time ago an attempt to use new style argument
in the Emacs git repository (the change was never committed to the Org
repository) caused a bug with handling of daylight saving time. See
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54731
for more details, the commit reverted the changes is 8ef37913d3.
I have tried to create a compatibility wrapper for Org mode that chooses
calling convention of `encode-time' in dependence of Emacs version. I
have realized that there are enough call sites where components of time
are gathered from scratch and not obtained from e.g. prior call of
`decode-time'. It is inconvenient to add 3 extra mandatory components at
the each place. I am reluctant to add a helper that accepts 6-components
list and adds 3 fields to the end of the list. I am afraid that it may
affect e.g. agenda performance.
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.
Old-style separate arguments for time components permits optional fields
ended with ZONE. I do not mind that it should be deprecated since it is
the source of surprise similar to the mentioned bug. Daylight saving
time field matters only as a list component and ignored as a separate
argument (by the way, it should be stressed in the docstring). It is too
easy to confuse list and separate arguments in the code since both ways
works but with a subtle difference: nil does not mean ignore the value.
(encode-time '(0 30 20 07 04 2022 nil nil nil)) ; wrong!
(encode-time 0 30 20 07 04 2022 nil nil nil) ; no problem
In the Org code it is unsure which way to call `encode-time' is more
convenient. In a half of the cases a list is obtained from another
function, but another half is timestamp built from computed components.
Unless the inconsistency with DST I would say that both ways to call the
function should be supported.
So my proposal is to not force Org mode to use new calling convention
for `encode-time' till DST and ZONE list components will became optional
ones in a released Emacs version. For a while minor changes in a couple
of places in Org code should make it immune to accidental usage of new
calling convention (modulo compatibility).
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones |
|
Date: |
Mon, 25 Apr 2022 12:49:28 -0700 |
|
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 |
On 4/25/22 08:37, Paul Eggert wrote:
Yes, I plan to omit the patches that were objected to, and install the
rest. Once that's done you should be good to go for Org. (Alas my
workstation died over the weekend, but I should have things up and
running again soon...)
Got my workstation up, installed the patches into Emacs master, and am
closing the Emacs bug report.
I'll be happy to review the revised org-encode-time implementation,
whenever you think it could use a review. (Sorry, I've lost track of
what the proposal is.)
--- End Message ---