Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones

[Max Nikulin <manikulin@gmail.com>]

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)