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