Re: [DRAFT][PATCH v2] org-encode-time compatibility and convenience helper

[Ihor Radchenko <yantar92@gmail.com>]

Max Nikulin <manikulin@gmail.com> writes:

>> This whole timezone staff is complex. I got lost in the emacs devel
>> discussion half-way through. From point of view of API, I would prefer a
>> single function with docstring explaining the necessary caveats.
>
> To have namely a single function that accepts both a list or multiple 
> arguments, it is necessary to introduce a new name to Emacs. 
> `encode-time' has a subtle difference in behavior depending on the 
> calling style and fixing this issue may break some code. That is why I 
> decided to offer a macro.

I did not mean "single function" to be a function specifically. Macro is
perfectly fine. Sorry for the confusion.

> I have not figured out which kind of high-level API I would like to have 
> instead of `encode-time', and I believe, it is acceptable to rely on 
> default normalization and ambiguity resolution as the status quo. 
> Problems may happen during 2 days of 365 and people usually expect some 
> glitches for these days. There are too many caveats to explain them in 
> docstring.

I understand. But, it may be helpful to mention the existence of such
caveats, ideally with a link where the user can learn more.

> I am attaching an updated version of the draft. I have added a macro for 
> testing of particular time zones.
> From 8fdcca3f3b0cf3e890149eb79ea6c7970b7d2cfa Mon Sep 17 00:00:00 2001
> From: Max Nikulin <manikulin@gmail.com>
> Date: Fri, 8 Apr 2022 23:10:50 +0700
> Subject: [PATCH] org-macs.el: Introduce a helper for `encode-time'

LGTM. I think you can go ahead and continue with the followup patch
making use of the new macro.

Best,
Ihor