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

[Ihor Radchenko <yantar92@gmail.com>]

Paul Eggert <eggert@cs.ucla.edu> writes:

> On 4/23/22 01:25, Ihor Radchenko wrote:
>>> +  (should (string-equal
>>> +           "2022-03-24 23:30:01"
>>> +           (format-time-string
>>> +            "%F %T"
>>> +            (org-encode-time '(01 30 23 24 03 2022 nil -1 nil)))))
>>> ...
>> These tests will be executed using system value of TZ. I am not sure if
>> tests are not going to break, say, in southern hemisphere or at some
>> other bizzare values of TZ.
>> 
>
> Good point: that test won't work in a time zone where the local time 
> 23:30:01 does not exist due to a daylight-saving spring-forward transition.

Note that it is rather hypothetical case. It's not just about 23:30:01,
but also about March 24 date. I am now checking
https://en.wikipedia.org/wiki/Daylight_saving_time_by_country The day
saving changes in March are:
- Second Sunday
- Last Sunday
- Friday before last Sunday
- Last Friday
- 20 or 21 March (Iran)
- Fourth Sunday

March 24, 2023 will be the last Friday before last Sunday in March...

The conclusion is: it is all tricky and I would not bet on trying to
find a "safe" date for an arbitrary present time zone DST. It would be
better to set some test TZ for testing and be done with all this
ambiguity.

Best,
Ihor