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.

--
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>