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

[Tom Gillespie]

Without wading too far into this at the moment,
timezones are an extremely tricky problem with
a whole bunch of design considerations. I am
reproducing the heading comment from laundry's
timestamp.rkt in its entirety here. Best!
Tom

https://github.com/tgbugs/laundry/blob/master/laundry/grammar/timestamp.rkt

; the org spec is currently silent on how org will handle dates beyond
; 0000 and 9999, the relevant standards for expanded representations
; are ISO 8601-1:2019,5.2.2.3 and ISO 8601-2:2019,8.4.3. The problem
; with expanded representations is that they require all parties to
; agree ahead of time how wide the year is and prefix with + and
; leading zeros, I am not sure that this is as robust as we would like
; 0000-01-01 is january first of the year zero, -0001-01-01 is jan
; first of the year 1BCE, and +10000-01-01 for jan 1 of 10000CE 5
; digits must be prefixed by the plus sign, the standard is not
; entirely clear, but I think that we could do PLUS digits HYPHEN
; or DIGIT-4 HYPHEN and everything would work out

; on a separate but related note, org timestamps are always in local
; time and do not currently support timezones, which is a problem

; further absurdities that are related to the timezone issue: the
; date/time implementation as a text format completely fails if
; authoring on another planet

; given my objective to ensure that org documents can be interpreted
; without having to stick stupid things like #+planet: mars in the
; header or risk your earthling readers getting incorrect dates --- I
; suggest that org switch to storing all dates and times in earth zulu
; time or with an offset as it stands, the timezone setting of the
; computer drafting the document must be known to determine what day
; it was etc. users could still draft using <2020-12-16> but C-c C-c
; would add the correct offset? actually this is tricky, because there
; are two cases, one where the location is clear, "napoleon on [1812-01-01]"
; and the other where it is not, the issue is that a single date refers
; to as many different time intervals as there are timezones and without
; knowing the timezone you don't know the date, similar issue if we were
; to try to convert to sols
; https://www.eecis.udel.edu/~mills/missions.html
; https://www.eecis.udel.edu/~mills/ipin.html
; https://en.wikipedia.org/wiki/Timekeeping_on_Mars
; HOWEVER having applied a bit more brain power to the problem, let's
; just assume that clock synchonization will happen between earth and
; mars so that the unix epoch could be synchronized between the frames
; probably with multiple reference stations in free fall and/or in deep
; space to account for gravitaitonal differences etc. so actually the
; only issue would be a practical notational one, or a UI one, since we
; can use timestamp with timezone or just straight epoc for this to work
; earth vs martian year/day is a much harder issue
; the org spec is currently silent on how org will handle dates beyond