Ihor Radchenko <yanta...@posteo.net> writes: > 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)?
Yep, these are exactly the sorts of issues I was worried about wrt adding time zone support. Challenge here is I'm not sure there is one right answer. It will depend on individual use cases. I guess the best we can do is select what seems to be the most 'sane' approach and document th elimitations (and possibly how to work around them). The key is likely to avoid user surprise. Limitations are often better accepted when flagged up front and when 'discovered' later. Initially, my thoughts on the 3 above are "I have no clue what the sane default is" - all options seem to have equal pros and cons. Guess the best we can do is go with the simplest solution and 'suck it and see".
