[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DRAFT][PATCH v2] org-encode-time compatibility and convenience help
From: |
Ihor Radchenko |
Subject: |
Re: [DRAFT][PATCH v2] org-encode-time compatibility and convenience helper |
Date: |
Tue, 26 Apr 2022 17:07:46 +0800 |
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