[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DRAFT][PATCH] org-encode-time compatibility and convenience helper
From: |
Ihor Radchenko |
Subject: |
Re: [DRAFT][PATCH] org-encode-time compatibility and convenience helper |
Date: |
Sun, 24 Apr 2022 11:35:28 +0800 |
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