From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <emacs-orgmode-bounces+larch=yhetil.org@gnu.org>
Received: from mp10.migadu.com ([2001:41d0:2:bcc0::])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	by ms5.migadu.com with LMTPS
	id 4KXLCCNDwmMWFgAAbAwnHQ
	(envelope-from <emacs-orgmode-bounces+larch=yhetil.org@gnu.org>)
	for <larch@yhetil.org>; Sat, 14 Jan 2023 06:52:35 +0100
Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	by mp10.migadu.com with LMTPS
	id mAntByNDwmOCEwAAG6o9tA
	(envelope-from <emacs-orgmode-bounces+larch=yhetil.org@gnu.org>)
	for <larch@yhetil.org>; Sat, 14 Jan 2023 06:52:35 +0100
Received: from lists.gnu.org (lists.gnu.org [209.51.188.17])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by aspmx1.migadu.com (Postfix) with ESMTPS id B3CFAEC38
	for <larch@yhetil.org>; Sat, 14 Jan 2023 06:52:34 +0100 (CET)
Received: from localhost ([::1] helo=lists1p.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.90_1)
	(envelope-from <emacs-orgmode-bounces@gnu.org>)
	id 1pGZSJ-00088y-IV; Sat, 14 Jan 2023 00:51:52 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10])
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <tgbugs@gmail.com>) id 1pGZSE-00087t-GL
 for emacs-orgmode@gnu.org; Sat, 14 Jan 2023 00:51:46 -0500
Received: from mail-yw1-x112c.google.com ([2607:f8b0:4864:20::112c])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.90_1) (envelope-from <tgbugs@gmail.com>) id 1pGZSC-0007xy-FX
 for emacs-orgmode@gnu.org; Sat, 14 Jan 2023 00:51:45 -0500
Received: by mail-yw1-x112c.google.com with SMTP id
 00721157ae682-4d4303c9de6so162028937b3.2
 for <emacs-orgmode@gnu.org>; Fri, 13 Jan 2023 21:51:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=179ZuMYI5fWd7cXlz9eepXI2U99uAde624IqO5CLoZI=;
 b=q21DeF5X0kKpgaXMDm5Gh6g5e/YIGLIRtHiKMcU3TxRMxhpnh40cYNYnHgfn2LZlzP
 DlKf42/iLPXf8i7H4aa8J9bt0qa9HjUbXBVOwrJMa2Kji6mTtzq5fa+S58A9MlV9nYHh
 +grjoJZ8pm/WNZDGAyiqXHrS5CjkYOpB84Jund4mXTgQCTWzBOtOEIFjwLrJDc6MNMQ+
 u1UvtvEPt1tIE/zeb8VAM/WO9NtI5xuKMKKIA1nJwHQC3NnLwulHYgVXS1xjIxaQ//BO
 dWgEdboAs2oKQtKYHUnxIRXBqeBxwHIj/ZpHX/buF8QkucLGBtuKebyJaWBbQLS9HbeH
 E3CA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=179ZuMYI5fWd7cXlz9eepXI2U99uAde624IqO5CLoZI=;
 b=BUIzxBIvGIEZBwjxh6IXdGIIQoAxY6k4dewyNIGdaqoi5kDPiVMsfO9aFosxGeVdar
 VTAUgwXT+BfuDB/jX5XR2kaJJKxXVTEcNg4o52Dxyk9pQRgL5qlJYUKdxO1OYYtSI7mu
 NrdafMzbrOl6x6yRj8S++kpwtEuYnVluUJ6cJCDS/y1GmDS/F55g11deu1yj+u7hnbU4
 vES1qn48Jr1jmTVy0OOxqnuVXecEePTgBIFRC/IcqRtDDhTou99cE2x1cdVEgJAg6Cvf
 3WftJfVIAAWEX0gvLFU5v/2TCL0azkOn2/+jcP/xnY9xW2kALr7NurSD3jYKgt6S1sIF
 bzwA==
X-Gm-Message-State: AFqh2kr4vOZ/H+HShUEWvqtNWh5SkNA/zPmTZqCqHCK4xd8LwutizkvL
 +ZXoVpV4HkKGb1zpVEU87TYAH3eO3hNnYz3Cq/pVG/T6SmA=
X-Google-Smtp-Source: AMrXdXtVs1CO23i73cKQRgMPIgPz4QQXk3MKwRq340SisCkii8+ilkcamM5vyEI8diNFcx9ExAo/Xo9qb8UHgf2nxao=
X-Received: by 2002:a0d:cc51:0:b0:4dc:8fc4:2ac0 with SMTP id
 o78-20020a0dcc51000000b004dc8fc42ac0mr834598ywd.117.1673675502592; Fri, 13
 Jan 2023 21:51:42 -0800 (PST)
MIME-Version: 1.0
References: <CAL9aZkusXaNVCu7+nO-ic8SHhwVdOiXYtDyF=Gz7h+NoLaOZXQ@mail.gmail.com>
 <CAJcAo8uF3m=oBOW1WVK8b9KNHgoEaND0_rcC1SAuTexx+XOSog@mail.gmail.com>
In-Reply-To: <CAJcAo8uF3m=oBOW1WVK8b9KNHgoEaND0_rcC1SAuTexx+XOSog@mail.gmail.com>
From: Tom Gillespie <tgbugs@gmail.com>
Date: Sat, 14 Jan 2023 00:51:31 -0500
Message-ID: <CA+G3_PPcwS21HrGt9nYNJZ2+z7L_wLP5v_qcR0cCcjQ+BA5t0w@mail.gmail.com>
Subject: Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and
 org-agenda
To: Org-mode <emacs-orgmode@gnu.org>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=2607:f8b0:4864:20::112c;
 envelope-from=tgbugs@gmail.com; helo=mail-yw1-x112c.google.com
X-Spam_score_int: 0
X-Spam_score: -0.1
X-Spam_bar: /
X-Spam_report: (-0.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
 URI_DOTEDU=1.999 autolearn=no autolearn_force=no
X-Spam_action: no action
X-BeenThere: emacs-orgmode@gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "General discussions about Org-mode." <emacs-orgmode.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-orgmode>,
 <mailto:emacs-orgmode-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/emacs-orgmode>
List-Post: <mailto:emacs-orgmode@gnu.org>
List-Help: <mailto:emacs-orgmode-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-orgmode>,
 <mailto:emacs-orgmode-request@gnu.org?subject=subscribe>
Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org
Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org
X-Migadu-Country: US
X-Migadu-Flow: FLOW_IN
ARC-Authentication-Results: i=1;
	aspmx1.migadu.com;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=q21DeF5X;
	spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org";
	dmarc=pass (policy=none) header.from=gmail.com
ARC-Seal: i=1; s=key1; d=yhetil.org; t=1673675554; a=rsa-sha256; cv=none;
	b=dcgKK9MKfKYNq09TdiZKn2Shzf9kpRiwhuoXQk2NOMbfYktKWe221SkcAnFTcDFv7UGBpa
	gg75XDDRh7FUTfhRleEt8xwTIYXlaN3TjlY2UzwmNLW0UhkoaG0LtLGQTgkk4n4GvrwsX8
	UkyoAo3n0ovVnY0TyovKdl+o5mrW6djMlZB8MTgAk19zLSXbEnkcy1rtRILh3eBu4DAoUy
	D+eIdoITHZFIw25vggm+zmrROsH6XjAyo4f/W/M3kw6TNEoeQ/I7m50tS/nnz1uVbM/ZfW
	LQonmSta0HORDAPyVFDqS6I9wV3BROHgwlCPyABRuASdoK5bMEb86/LacmBmCA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org;
	s=key1; t=1673675554;
	h=from:from:sender:sender:reply-to:subject:subject:date:date:
	 message-id:message-id:to:to:cc:mime-version:mime-version:
	 content-type:content-type:in-reply-to:in-reply-to:
	 references:references:list-id:list-help:list-unsubscribe:
	 list-subscribe:list-post:dkim-signature;
	bh=179ZuMYI5fWd7cXlz9eepXI2U99uAde624IqO5CLoZI=;
	b=ogv8c2p4gzM6tOOzq8A8uhwkj/Cls80wKzUAhkU0VPulDRTo83xSRMt9Rzca6X1IIk9fNS
	VEq5c7vQCXPcTZGLbLlUohUvyb1d76ZGSVcMjlkC279ptFK1aToutc86/k8rOHJa/LbiuS
	r1lPMYR3M4q3DkbEntoWAQsW6C+66h9xXZacng7/goMNTz37VwB7Zcb4HsnBsSqLoYv/zq
	Z7hB+9GrQdjlKJPnXe8dJ+UfK1gUnwr5MVDKOiceBLVxu4z/5IkaNtMzvSb8Yt+EUtc9k/
	Wodo+L1kmQvcHipJaXw9XCafdlBSSiTWjH2RdiOc6BPyJi3m4+2YUEW3yRY+zw==
X-Migadu-Queue-Id: B3CFAEC38
X-Migadu-Scanner: scn0.migadu.com
Authentication-Results: aspmx1.migadu.com;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=q21DeF5X;
	spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org";
	dmarc=pass (policy=none) header.from=gmail.com
X-Migadu-Spam-Score: -7.85
X-Spam-Score: -7.85
X-TUID: m6Lo3QEFEhYh

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