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.