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), 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. * 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. * There are three other Emacs timestamp changes I should mention that might be relevant to Org mode: ** 1. Although in Emacs 28 functions like (time-convert nil t) return a timestamp resolution of 1 ns, in Emacs 29 I plan to fix them so that they return the system clock resolution, which is often coarser than 1 ns. This is done in the 4th attached patch. ** 2. In Emacs 29 format-time-string should support a new format "%-N" which outputs only enough digits for the system clock resolution. (This is the same as GNU "date".) This is done in the 5th attached patch. ** 3. Emacs 29 current-time and related functions should generate a (TICKS . HZ) timestamp instead of the old (HIGH LOW MICROSECS PICOSECS) timestamp. This change has been planned for some time; it was announced in Emacs 27. As far as I know Org mode is already ready for this change but I thought I'd mention it again here. This is done in the last attached patch. * 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. In the meantime, one can disambiguate such timestamps in Elisp by using numeric time zones, e.g.: (format-time-string "%F %T %z" (encode-time '(0 30 23 31 1 2021 - -1 TZ)) "Africa/Juba") yields "2021-01-31 23:30:00 +0200" if TZ is 7200, and "2021-01-31 23:30:00 +0300" if TZ is 10800. And perhaps this is the right way to go in the long run anyway.