Jean Louis <bugs@gnu.support> writes: > ... > Should be part of C library to observe those things.
Sure. My previous proposals are all relying on `encode-time' which uses time.h from system libraries and utilizing TZDB that is taking care about all this insanity. We, however, might need to be careful about applying date increments. In `org-read-date' and `org-timestamp-change', which are implemented in Elisp without considering these complexities. (maybe also other functions; these are just the ones I can think about) What should we do when: 1. It is close to DST transition 2:59 -> 2:00 -> 2:01 -> ... -> 2:59 -> 3:00 and the users asks to create a timestamp +1h from now or, worse, a timestamp +1h from now in a different time zone 2. A user asks +1w date shift and the time zone has a 1-day jump during DST? what about +7d? +1d? 3. What will be +1d 2:30am timestamp refer to when there DST transition as in (1)? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
