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

[Max Nikulin <manikulin@gmail.com>]

On 19/04/2022 09:02, Paul Eggert wrote:
> Here are the main points I see about making timestamps work better in 
> Org mode, and related patches to how Emacs handles timestamps.
> 
> * Max would like encode-time to treat a list (SS MM HH DD MM YYYY) as if 
> it were (SS MM HH DD MM YYYY nil -1 nil),

Thank you, Paul, it is exactly what I had in mind when I created this bug.

> as that would be more 
> convenient for how Org mode deals with ambiguous local timestamps. This 
> is relatively easy to add for Emacs 29+, and is done in first of the 
> attached proposed patches to Emacs master.

I would say that Org just does not care concerning ambiguous local time. 
Anyway there are other similar cases besides DST.

> * As I understand it, Max would like a function that emulate Emacs 29 
> encode-time with one argument, even if running in Emacs versions back to 
> Emacs 25. I suppose such a function would also need to implement Emacs 
> 27+ encode-time's support for subsecond resolution. E.g., 
> (org-encode-time '((44604411568 . 1000000000) 55 0 19 4 2022 - -1 t)) 
> should return (1650329744604411568 . 1000000000) even in Emacs 25 and 26.

I am just afraid of possibility of recurrent attempts to modernize 
time-related code within Emacs including Org code in a such way that can 
not be directly ported to the Org repository. Discrepancy of the code 
increases maintenance burden. The main purpose of a compatibility 
wrapper is to prevent grep-driven refactoring. Another point of the 
helper function is to allow to remove from Emacs support confusing 
old-style `encode-time' arguments with ignored DST value. In Org 
timestamps are often built from scratch, so separate argument are still 
convenient.

Org timestamps have minute precision, even seconds are trimmed. So at 
least explicitly I did not ask for subsecond timestamps. I admit however 
that they might emerge in some code paths.

Notice that nobody from Org developers & maintainers commented the patch 
demonstrating the idea of such wrapper.

> * My last topic in this email is Max's request for a feature that I'm 
> not planning to put into Emacs 29 as it'll require more thought. This 
> addresses the problem where your TZ is "Africa/Juba" and you want to 
> encode a timestamp like "2021-01-31 23:30" which is ambiguous since at 
> 24:00 that day Juba moved standard time back by an hour. Unfortunately 
> the underlying C mktime function does not allow disambiguation in the 
> rare situation where standard time moves further west of Greenwich. 
> Addressing this problem would require rewriting mktime from scratch in 
> Elisp, or using heuristics that would occasionally fail, or (my 
> favorite) extending glibc mktime to treat tm_isdst values other than 
> -1,0,1 to support disambiguating such timestamps.

I do not urge such changes. I have not checked if mktime is a part of 
POSIX and C standard. If it is so, I am not in favor of adding more 
values for the tm_isdst field since they are not related to DST.

I started this branch of discussion to convince Paul that requirement of 
9 fields is not really encourage more correct usage of `encode-time' in 
comparison to 6 values.

More convenient interface for processing of local time moments requires 
significant amount of work, maybe some prototypes. It should be 
considered separately from this bug.

I still believe that optional DST and ZONE values is an improvement of 
the `encode-time' interface with no real drawbacks. It minimizes the 
chance of passing nil as "no DST" when actual value is unknown and 
developers are not ready to add a bunch of code to determine proper TZ 
offset for each case of time transition.