I agree this is perhaps not a trivial undertaking. It really depends on the quality of date and time libraries that exist in the lisp ecosystem. For example, in Rust I found my timezone woes in one of my own apps were trivial due to the chronos package, but likewise the reliance of Go depending on its underlying time and date type actually introduced a weird timezone and DST bug in my own app.

Is/are there lisp packages which handle the complexity involved in time and date difference calculations and DST changes? That would perhaps be the first question. It makes things tremendously easier and would reduce much of the work (perhaps to just the argument of the format and parsing the datetime stamp and making org-agenda aware of which timezone it's in.).

To Jean Louis' point: using timestamps without timezones is a don't in much of computing these days and perhaps hearkens back to the simpler age emacs and org originated in.  =]  (kidding!).

My lips-fu is not adequate to taking this on myself so the issue of who would want ot work on it over other features is perhaps the bigger question. Could someone scope out the work and approach at least. I imagine it is tricky and non-trivial, but perhaps less complex if good libraries exist as above.

I'd simply make the timezone format a slowly to be evolved to standard over time with exceptions as noted in my first note. not having tz in timestamps was a "assume local" assumption and under-specification (or considered "hidden".).

Daryl.


On Fri, Jan 13, 2023 at 8:34 PM Tim Cross <theophilusx@gmail.com> wrote:

Daryl Manning <daryl@wakatara.com> writes:

> Following on from thread at https://www.reddit.com/r/orgmode/comments/zrppqw/
>
> [First off, I just wanted to say thank you to everyone that works on org-mode. It is a wonder.]
>
> While I realize a few kicks at this can may have been taken, I wanted to (re-)propose Timezone support in org-mode. The
> world is much less local these days and we're all more remote and coordinating globally these days.
>
> *Background*
>
> 1. org-time-stamp-formats TZ currently only affects display and exports
> 2. org-agenda itself is not TZ aware
> 3. Several discussions on this have taken place over time
> 4. Concerns raise included breaking backwards compatibility
>
> *Proposal*
>
> 1. org-mode sets an optional variable (org-timezone-aware t) which enables TZ
> 2. org-agenda needs a way to determine which timezone it is in
> 3. Once enabled, any timestamp not exhibiting a TZ in it is considered "local time" wherever that is (I do not think UTC
> would work for this)
> 4. org-agenda can calc local based on TZ differences
>
> I understand this is by no means trivial and quite gnarly with DST and such to figure out but I do believe libs exists to
> deal with that heavy lifting. Currently, it does feel like a hole in org-mode as a 21st century organizer (disclaimer:
> digital nomading so might feel it more keenly). Also, just interested in making org-mode a more awesome tool for
> everybody.
>
> I'd love an understanding of the alluded to reservations raised in the reddit thread and in the mailing list threads
> mentioned that the format change might break things (I was unsure if that was referring to say, how time ranges were
> handled, or how say date ranges got dealt with (for example, say a flight from Singapore to Vancouver which takes off in
> one time zone and lands in another - something that is often in my cal.).
>

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.

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.

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. 

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. The problem with this is that it is likely to
break the core feature of org files i.e. that they are in plain text. I
guess we could possibly do somehting clever with overlays such that UTC
date/times are rendered/presented in local time format. However, we
would then also require some type of interface for users to enter
dates/times (to ensure they are converted to the correct UTC internal
format).

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.