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