Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Tim Cross]

Ihor Radchenko <yantar92@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".