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

[Tim Cross]

Ihor Radchenko <yantar92@posteo.net> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>
>> I agree this would be a great feature to add. However, after having
>> looked at it in some detail, I realise that not only is it not a trivial
>> task, it is actually a very large and complex task and will require
>> extensive work which will almost certainly result in breakage with
>> regards to backwards compatibility.
>
> Not really. Our timestamp format, in fact, provides sufficient
> flexibility to add extra metadata to timestamps.
>
> In anticipation to add time zones in future, I have added the following
> to the Org timestamp spec (see
> https://orgmode.org/worg/org-syntax.html#Timestamps):
>
> DATE TIME REPEATER-OR-DELAY
>
> TIME (optional)
> An instance of the pattern H:MMREST where H represents a one to two digit 
> number (and can
> start with 0), and M represents a single digit. REST can contain anything but 
> \n or
> closing bracket.
>
> Note that REST imply that almost arbitrary suffix can be in TIME without
> braking the existing Org timestamp parsing code.
>
> REST, among other things may be
> https://en.wikipedia.org/wiki/ISO_8601#Time_offsets_from_UTC or a valid
> value of TZ POSIX variable. Exact details can be discussed.
>
> Note that TZ should be fully supported by `encode-time' (ZONE):
>
> (SECOND MINUTE HOUR DAY MONTH YEAR IGNORED DST ZONE)
>
> We do not need to worry about internal representation and conversions
> and simply rely on Emacs.
>
>> At the risk of over simplifying the matter, I would suggest the big
>> challenge here is that there are two somewhat competing (and
>> conflicting) use cases. On one hand, you want a high level abstraction
>> which makes working with dates and times easy and clear. TO some extent,
>> that is what we have now. On the other hand, we need something far more
>> complex which is able to handle multiple time zones. This means being
>> able to handle both base timezone offsets as well as offset adjustments
>> for things like daylight savings time. There is a lot of hidden
>> complexity here. You have to handle the fact that daylight saving
>> chang-over dates/times are dynamic i.e. not necessarily the same every
>> year. This adds the additional complexity of having to somehow track
>> historical information regarding such changes, which isn't as readily
>> accessible in a consistent manner on all platforms.
>
> We do not care about the details as long as Emacs can handle this. As
> long as the user supplies DST and ZONE somehow, we can rely on Emacs'
> support and system TZ implementation.
>
>> Then there is the other 'messy' stuff. For example, when calculating
>> time ranges and number of days, hours/ minutes between two dates you
>> need to remember to add/remove the hour if the range crosses over a
>> daylight savings period. Similarly you need to ensure you make the
>> correct adjustment when changing timezones (consider emacs on a laptop
>> for someone who travels a lot between different time zones). Not only do
>> you need to take into account the different timezone offset, you also
>> need to look at the date and then adjust according to the timezone
>> offset for the current timezone at the time of the timestamp rather than
>> just considering the current time offset.  
>
> Again, we don't need to worry about this. Once we use `encode-time',
> operations on time should just work. This is what we do anyway in most
> of Org code.
>
>> I expect what is needed is an 'internal' UTC based representation which
>> is used for all calculations and an 'interface' layer, which converts
>> the UTC representation into the local display representation for
>> consumption by humans.
>
> This is what we already to via `encode-time' and `decode-time'.
> Check out `org-time-string-to-time'.
>
>> However, the real challenge here is that this is a very large piece of
>> work and it needs someone who is prepared to take it on. I suspect until
>> someone who needs to scratch this itch sufficiently comes along, this is
>> a feature which will be unlikely to make it to the top of the todo
>> list. There are simply far too many existing feature improvements and
>> additions people will prefer to work on before taking on this
>> one. Things are made more difficult because it isn't the sort of task
>> which can be achieved with small increments over time. This is more
>> likely to be something which needs to be developed in a feature branch,
>> which once it reaches a sufficient level of completeness can be used and 
>> verified working for a wide variety of environments before then working
>> out how to fold it back into the core system and handle whatever change
>> management will be necessary. 
>
> Not as much as you describe. Not small work either though.
> Most of the machinery is already in place, except some leftover pieces
> from early Org days.

Hi Ihor,

I think you may only be looking at the representation and not
considering the actual mechanics which will be required to make this all
work.

Consider for example an agenda file where the TODO items have been added
while I am here in Australia (currently +11:00 w/ DST). Tomorrow I fly
to Europe where I will be working for the next 6 weeks. I need all my
TODOs with active timestamps to be updated to Berlin's TZ. How does this
work?

The representation of the timestamps is the easy part. It is the
management, display, calculations, etc where the complications
arise. From looking at the supported time related functions in Emacs,
while most of the key ones do have support for passing in time zone
data, there seems little (if any) code to support the lookup and
retrieval of time zone data - in particular, ability to lookup time zone
data for a specific date, not just a location.