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

2022-05-04 Thread Max Nikulin

On 04/05/2022 16:56, Ihor Radchenko wrote:

Max Nikulin writes:

1 unexpected results:
FAILED  test-org-clock/clocktable/ranges


Thank you, Ihor. I run tests in containers with UTC timezone, so I did 
not notice such failure. So unit tests reveal a problem with tests.


`org-read-date-analyze' returns additional nil -1 nil now to allow 
passing its result directly to `encode-time'. 
`org-test-clock-create-timestamp' replaces nils by 0, so default 
timezone becomes UTC.


I will try to fix the test helper later.



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

2022-05-04 Thread Ihor Radchenko
Max Nikulin  writes:

> The attached patch set is assumed to be complete.

Thanks!

> I have no chance to thoroughly test it. Existing unit tests pass for 
> Emacs-26 and Emacs-27. Nothing has changed for Emacs-25, as for the 
> "main" branch one test fails. I have not tried Emacs-28 or the current 
> git version.

I tried to test your patch applied onto main with all the supported
Emacs versions (note that we do not need to support Emacs 25 anymore.
Emacs 28 is out). One test is failing:

Emacs 26, 27, 28, and 29:

1 unexpected results:
   FAILED  test-org-clock/clocktable/ranges

> In comparison to the previous patch version I have expanded the 
> docstring and added a bit more tests. I have tried to support recently 
> committed to Emacs 6-elements list for `encode-time', but I do not like 
> the following compile-time warning:
>
>> In toplevel form:
>> org-macs.el:1397:23:Warning: encode-time called with 1 argument, but requires
>> 6+

Since it is expected to fail in some Emacs versions, you can just wrap
the call into with-no-warnings:

(ignore-errors (with-no-warnings (encode-time '(0 0 0 1 1 1971

Best,
Ihor