emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Max Nikulin <manikulin@gmail.com>
To: 54764@debbugs.gnu.org
Cc: eggert@cs.ucla.edu, emacs-orgmode@gnu.org
Subject: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones
Date: Thu, 7 Apr 2022 19:37:43 +0700	[thread overview]
Message-ID: <5ed963b2-3fa8-48d8-627e-bc0571d15b43@gmail.com> (raw)

Consider the following change of `encode-time' calling convention: last 
3 elements of the TIME argument as a list should be optional. I mean 

      (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
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).

             reply	other threads:[~2022-04-07 12:41 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-07 12:37 Max Nikulin [this message]
2022-04-09  7:52 ` Paul Eggert
2022-04-10  3:57   ` Max Nikulin
2022-04-13 14:40   ` Max Nikulin
2022-04-13 18:35     ` Paul Eggert
2022-04-14 13:19       ` Max Nikulin
2022-04-14 22:46         ` Paul Eggert
2022-04-15  2:14           ` Tim Cross
2022-04-15 17:23           ` Max Nikulin
2022-04-16 19:23             ` Paul Eggert
2022-04-21 16:59               ` Max Nikulin
2022-04-19  2:02             ` Paul Eggert
2022-04-19  5:50               ` Eli Zaretskii
2022-04-19 22:22                 ` Paul Eggert
2022-04-20  7:23                   ` Eli Zaretskii
2022-04-20 18:19                     ` Paul Eggert
2022-04-20 18:41                       ` Eli Zaretskii
2022-04-20 19:01                         ` Paul Eggert
2022-04-20 19:14                           ` Eli Zaretskii
2022-04-20 19:23                             ` Paul Eggert
2022-04-20 19:30                               ` Eli Zaretskii
2022-04-21  0:11                                 ` Paul Eggert
2022-04-21  6:44                                   ` Eli Zaretskii
2022-04-21 23:56                                     ` Paul Eggert
2022-04-22  5:01                                       ` Eli Zaretskii
2022-04-23 14:35                       ` Bernhard Voelker
2022-04-20 15:07               ` Max Nikulin
2022-04-20 18:29                 ` Paul Eggert
2022-04-25 15:30                   ` Max Nikulin
2022-04-25 15:37                     ` Paul Eggert
2022-04-25 19:49                       ` Paul Eggert
2022-04-30 11:22                         ` Max Nikulin
2022-05-01  2:32                           ` Paul Eggert
2022-05-01 17:15                             ` Max Nikulin
2022-04-13 15:12   ` Max Nikulin
2022-04-16 16:26   ` Max Nikulin
2022-04-17  1:58     ` Paul Eggert
2022-04-20 16:56       ` Max Nikulin
2022-04-20 19:17         ` Paul Eggert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5ed963b2-3fa8-48d8-627e-bc0571d15b43@gmail.com \
    --to=manikulin@gmail.com \
    --cc=54764@debbugs.gnu.org \
    --cc=eggert@cs.ucla.edu \
    --cc=emacs-orgmode@gnu.org \
    --subject='Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones' \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).