From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id YtH+BYkI2WOQkgAAbAwnHQ (envelope-from ) for ; Tue, 31 Jan 2023 13:24:41 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id gF8hBIkI2WNmfwEAG6o9tA (envelope-from ) for ; Tue, 31 Jan 2023 13:24:41 +0100 Received: from lists.gnu.org (unknown [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 AF4E117B92 for ; Tue, 31 Jan 2023 13:24:26 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pMpdF-0007WZ-9s; Tue, 31 Jan 2023 07:21:01 -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 ) id 1pMpdA-0007R2-U3 for emacs-orgmode@gnu.org; Tue, 31 Jan 2023 07:20:57 -0500 Received: from mail-wr1-x42c.google.com ([2a00:1450:4864:20::42c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pMpd0-0002Q8-5A for emacs-orgmode@gnu.org; Tue, 31 Jan 2023 07:20:50 -0500 Received: by mail-wr1-x42c.google.com with SMTP id t7so5664823wrp.5 for ; Tue, 31 Jan 2023 04:20:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wakatara.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=4CeHDVhyqi/MFLUO7Kb8+kKedo4MPPC9ANqn7kO/9IA=; b=UuAxe371ZSqD7F+c9WPtl5JaTtP9ZotZj6ZAJFNZOJAg+PsiRw4mgXQY3BpfWsdW11 x4YX+h3uq8/jPVZJ76NSFd4rSW2xj+Zgcw1T8BCJmmdS4Q77HjjoVIC8zWurwQs1E1/9 0jFcBER6TiYcMeB3ChYBYaHvn/9qPDyIOMEFwqvNBwYa7a+YVXh6HMjcEZPlzhYxhAYa +lWGbjgxWIqH0RgKYHDUA2GPvTFerQw6jDfbjvkz63VuPRh2y6aliwyymZXw0Jq12icx i2AMtqSIyAX0Chzh6fuITnbCJPDXGrJiNiIR1jE83ZymUUcpxq/9HTDqYXX6Y8PeICZM n9aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc: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=4CeHDVhyqi/MFLUO7Kb8+kKedo4MPPC9ANqn7kO/9IA=; b=3OaLQ5cgp5hUbknU0ZmcyA1dGeui3GqF8cl/fVyQg+8Gp0iu+Iiyle1p07VLShWwDN 5g5nNq4x4rfw9YodUGpV5eOBBZbhlGrZTENIw24xTX+CKoLllQ3YKnYWt4xMD29LoXZv 4cR6MAr+2wLWo+LQvSiUeL29HfvR+5SV33+O228P16RGGR4EIlh2MUe3Gf3APW1Bg/fI zeUU1TcHOIfbhIOFYnsz0hcIppMqxvn8W3qAUvauROG5sGhClhhk3UVVbU6V7lCkr6wP hJMUPayYX48p7Rpep1QKKLGkj4iXb6eRVpoBMf8JRSFDcG9rP1NY6tUSWggCwOeQOgB1 I4Fg== X-Gm-Message-State: AO0yUKVTegBrBVcktgSrKWqtMo8T6v8vi9Elxgq2XpX6sN5TjLfvyOkR NvSu/IQ/GOS7jchTOXYRwp3xSnkmnR/YgJBkqN2lOA== X-Google-Smtp-Source: AK7set8GVIKPu88CZOMQO8Lz6l1te3OYBTuPi9eVlJWPJMPGWktpMtmyE9ULSEpfGNCdtJd0Ee45ZT2Qj3aRasu4rdE= X-Received: by 2002:a5d:61c1:0:b0:2bf:edf8:de1 with SMTP id q1-20020a5d61c1000000b002bfedf80de1mr159079wrv.640.1675167635667; Tue, 31 Jan 2023 04:20:35 -0800 (PST) MIME-Version: 1.0 References: <63c66048.630a0220.427bf.a5f6@mx.google.com> <87r0vtiks0.fsf@localhost> <63c671c0.a70a0220.61aa5.56b8@mx.google.com> <87fsc88aq9.fsf@localhost> <63c7dd3d.170a0220.6b4d6.f84f@mx.google.com> <877cxk6oeu.fsf@localhost> <63c86454.170a0220.80970.652d@mx.google.com> <63c8f5a6.170a0220.ea8cf.7f96@mx.google.com> <63c9b654.170a0220.d82d2.4254@mx.google.com> <87mt6e86sr.fsf@tsdye.online> <63c9d976.620a0220.a7d40.113b@mx.google.com> <87tu0mjb24.fsf@tsdye.online> <63ca1283.170a0220.5bc81.0fdd@mx.google.com> <87pmb9k8oi.fsf@tsdye.online> <3035CDD5-41DD-4516-9E4E-9E0DF16BE2E0@gmail.com> <87lelo8c9r.fsf@localhost> <2150768.1675077958@archlinux> <87tu063ox2.fsf@localhost> In-Reply-To: <87tu063ox2.fsf@localhost> From: Daryl Manning Date: Tue, 31 Jan 2023 19:19:59 +0700 Message-ID: Subject: Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda) To: Ihor Radchenko Cc: Greg Minshall , Sterling Hooten , "Thomas S. Dye" , Tim Cross , Jean Louis , rjhorn@alum.mit.edu, emacs-orgmode@gnu.org Content-Type: multipart/alternative; boundary="000000000000dd151205f38e5bd2" Received-SPF: pass client-ip=2a00:1450:4864:20::42c; envelope-from=daryl@wakatara.com; helo=mail-wr1-x42c.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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-Seal: i=1; s=key1; d=yhetil.org; t=1675167875; a=rsa-sha256; cv=none; b=KHnNtyvSBtKrH2CBipSkFNfzlzAg1nbV39gJC75D3JNX9hOTjzWKtBudex4XVo/1s9S8+V bcrh62EYV4PcQL0Q3WHc2pztG9nXUd/tUAOLbURYcnHZnRXbX0g32bVmqg0Xp/s1cq/tkK oMBezSBYHTTm9hHQPvW3Mo1eymiKxXKsbKNstyM+Yr+OumJqTfoEDMsmGPO410Dt+klln6 HDzVfBJieb0N2tLKRXHlqp+Z4IDqaAyksx2FhjOuFSbM6mrsf3gQJofQ2yBliGBHucL1PU 2IdzPp/zJ+IsZbULllhZa0n6pHNMgIeCvIBS8ZC5TocqQ6NDHzV3gRHHoojkYw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=wakatara.com header.s=google header.b=UuAxe371; 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=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1675167875; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc: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=4CeHDVhyqi/MFLUO7Kb8+kKedo4MPPC9ANqn7kO/9IA=; b=jeE5N1JI/VmbLbbeYdp4SMGvptBHnT3gJHigruD4bwZ8NzwqfMGX81tV1SMqHqpp2v+d11 RdbsV1kZTiWfk/tJzWHUyXqQhYTZiIh/ney563Om9yNFcyhj+7miZvJTNefthuG1tE2Px+ 0Diuf1UPEXCXrLgIEzoRnKvZ3wjrmN8ZRhGqF+4LmYZPiSpDuCv4J2jYAG07TajyWLwRlz ME4xlDWSox+FeW3sw2Y52SURE7ivUdCHYoBhjIlTz6HDVkag1eMtM9Yvz7+24xSCqz1vmu HDEtK1zR1IotQkEQEWJ0CW2erMxyAKWtozip75V3q5IWc5h1ef7upjoH6aUd8w== Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=wakatara.com header.s=google header.b=UuAxe371; 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=none X-Migadu-Scanner: scn1.migadu.com X-Migadu-Spam-Score: -0.55 X-Spam-Score: -0.55 X-Migadu-Queue-Id: AF4E117B92 X-TUID: EWrBOBQ9hK9q --000000000000dd151205f38e5bd2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dense poll. I had a question about this format which is what I assume I'd be using if using org-mode with this on a day-to-day basis if given the choice. (from 2. Timestamp with time zone specifier) 2022-11-12 10:00 @EST+5 # TZ syntax Normally, when I'm communicating things like standard and daylight savings time via mail or verbally, I'd use this if writing emails or what have you. ie. 2023-01-31 10:00 EST (or EDT) Is the +5 offset in the example from the poll here to disambiguate the EST from other ESTs (I realize from https://en.wikipedia.org/wiki/List_of_time_zone_abbreviations these are not always unique) or is the idea that someone would have to specify the timezone offset each entry rather than saying EST or EDT? thanks, Daryl. On Tue, Jan 31, 2023 at 6:48 PM Ihor Radchenko wrote: > Greg Minshall writes: > > > just a thought/reminder. there are "semantics" and "encoding". a spec > > like ISO-8601 specifies both. the important thing for org-mode is to > > use an encoding that > > > > 1. is easily parsable/understandable by the mere mortal > > > > 2. allows expression of all the semantics of the underlying spec/specs > > (be that ISO-8601, this new IETF spec, the Library of Congress spec, > > etc.) > > > > 3. and, importantly, is designed to *try* to follow updates to the > > underlying spec/specs (which will inevitably happen) > > I agree with these three points. > > Following the previous discussion and the various links provided, I have > reviewed the main discussed timestamp standards and would like to > propose the new Org timestamp syntax that will allow specifying time > zone information. > > I will not follow the standards fully because the available standards > are not designed to be easily understood by humans. I will also omit > the ideas from the standards that are unrelated to time stamps (but > still outline them below, and keep them in mind for > forward-compatibility). I will, however, try to use the syntax close to > the standards where possible. > > 1. https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/ > proposal is extending ISO8601/RFC3339 with time zone information. In > addition to UTC offset defined in ISO8601, it allows specifying the > time zone identifier and auxiliary information. > > Examples: > > 2022-07-08T02:14:07+02:00[Europe/Paris] > (both offset, and time zone are specified) > Note that we cannot use "[]" symbols because they are incompatible > with current timestamp syntax that must not contain closing "]>" > inside the timestamp. > > 1996-12-19T16:39:57-08:00[America/Los_Angeles][u-ca=3Dhebrew] > (preferred calendar is specified in addition to time zone) > Note: calendar spec is out of scope of time zone discussion - if we > decide to add it in future, we can simply add new parts to > timestamps, just like repeater interval and warning period. > > Further, the draft proposes an idea, which have also been discussed > in this thread: making use of redundant UTC offset + time zone > information to detect possible unexpected changes in time zone rules: > > 2022-07-08T00:14:07+00:00[!Europe/London] > ("!" identifies that +00:00 offset, if not consistent with > Europe/London at the timestamp time, must be signalled to user or > generally not ignored) > > 2. https://www.loc.gov/standards/datetime/ does not contain any new > ideas relevant to time zones, although it has many other ideas wrt > approximate/incomplete timestamps. I will outline them later, but > they do not directly affect the proposed new Org timestamp syntax. > > |-----------------------------------| > | The proposed new timestamp syntax | > |-----------------------------------| > > I propose two forms of time zone information in Org timestamps > > 1. Timestamp with explicit UTC offset > > YYYY-MM-DD [optional day name] HH:MM[^ \]>]*?[+-=E2=88=92]HH[MM]? > YYYY-MM-DD [optional day name] HH:MM[^ \]>]*?Z[ \]>] > > "-" is latin "HYPHEN-MINUS" (code 0x2D) > "=E2=88=92" is unicode "MINUS SIGN" (code 0x2212), as prescribed by IS= O8601 > we will not actually use it when generating timestamps, but allow it > to keep some compatibility with ISO standard. > > "Z" in the second format refers to "Zulu" time (another name for UTC) > and must be either the last character in the timestamp or the > last character before space. Not sure if many users are familiar with > "Z" convention, but it is (1) in ISO; (2) succinct for users who are > familiar with it. We will prefer +00 number offset in auto-generated > timestamps. > > Examples: > 2022-11-12 12:00+02 # 12:00 UTC+2 > 2022-11-12 14:00+0230 # 14:00 UTC+2:30 > 2022-11-12 14:00-0230 # 14:00 UTC-2:30 > 2022-11-12 14:00Z # 14:00 UTC > > The offset is a subset of what is defined by ISO8601. > > Note that unlike ISO8601, ":" is not allowed in the offset specifier. > This is to disambiguate with the time intervals in Org timestamps: > [2022-11-12 8:00-9:00] in Org is a time range from 8am to 9am. > > For time ranges, we will only allow a single offset and time zone > specifier for both start and end times: > [2022-11-12 8:00-9:00+08] > If different time zones are necessary to specify the start/end times, > users can still use full timestamp range syntax > [2022-11-12 8:00+03]--[2022-11-12 22:00+08] > > The format is also forward-compatible with extending Org timestamps > for second/sub-second precision: 2022-11-12 14:00:05.0012+0230 will > remain valid if we decide to adopt such format. > > 2. Timestamp with time zone specifier > > YYYY-MM-DD [optional day name] HH:MM[^ ]* @[!]?<[^ \]>]> > > For now, time zone name will only be processed when it follows TZ > POSIX format. If necessary, the proposed syntax will still allow > extensions to TZ POSIX. > > Examples: > 2022-11-12 12:00 @Asia/Singapore # tzdb syntax > 2022-11-12 10:00 @Europe/Berlin > 2022-11-12 10:00 @!Europe/Berlin # "!" does nothing here, see below > 2022-11-12 10:00 @EST+5 # TZ syntax > 2022-11-12 10:00 @EST+5EDT,M3.2.0/2,M11.1.0/2 # manual time zone spec > allowed in TZ > > The "@" symbol is selected to disambiguate time zone specifier from > other auxiliary information in the timestamp. Like calendar name, > which might be added in future. Note that we cannot use [...] from > the standard draft. I selected "@" because it is read as "at" - > location specifier. > > The "!" symbol is adapted from > https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/ > > I use space before "@" to improve readability. We deviate from the > standard here so may as well. In contrast, no space before [+-]offset > is closer to the standard yet not cluttering the timestamp too much > (IMHO). > > 3. (1) and (2) can be combined > > 2022-11-12 12:00+08 @Asia/Singapore > > Org will unconditionally use +08 offset and ignore the time zone > name. We prefer absolute offset because it is non-ambiguous wrt > out-of-date tzdb on the computer. One may also not update the TZ > variable upon travelling - the system clock will again be more likely > accurate. > > This redundant time offset info can serve as human-readable > indication of absolute time, while the time zone name will indicate > the location. > > 2022-11-12 12:00+07 @!Asia/Singapore > > Org will calculate the internal time for both +07 offset and > Asia/Singapore time zone. If they do not match, Org will issue a > warning. The offset will still be preferred if we have to proceed. > > This can be useful when planning future meetings and sending Org file > with a timestamp to someone else, potentially with obsolete tzdb. > > |-----------------------------------| > | | > |-----------------------------------| > > Apart from the ideas mentioned above, > https://www.loc.gov/standards/datetime/ contains a number of other > interesting ideas that may or may not be adapted by Org in future. > I will outline the ideas I find noteworthy to keep them in mind when > considering changing (including current changes) in the timestamp > syntax: > > 1. Reduced timestamp precision: > 1985-04-12 (day precision, time omitted; available in Org) > 1985-04 (month precision, day and time omitted, not available in Org) > 1985 (year precision) > > Current timestamp syntax proposal should not interfere. > > 2. Using "T" as date/time delimiter > 1985-04-12T23:20:30 (not supported by Org) > > 3. Using "/" for time intervals > 2004-02-01/2005-02-08 (not supported and incompatible with Org) > > 4. Seasons > 2001-21 (Spring, 2001; not supported by Org) > > 5. Approximate dates > 1984? (year uncertain) > 2004-06~ (year-month approximate) > 2004-06-11% (entire date (year-month-day) uncertain and approximate) > 2004-06?-11 (year and month uncertain) > 2004-?06-11 (just month uncertain) > > 6. Unspecified digits > 1985-04-XX (day unspecified; might be an interesting idea for > defining repeater intervals) > > 7. Open time intervals > 1985-04-12/.. (from 1985-04-12 to infinite) > 1985-04-12/ (from 1985-04-12 to unknown) > > 8. Negative calendar year > -1985 (note: an alternative could be allowing AD/BC) > > 9. Set of dates > [1667,1668,1670..1672] (one of) > {1667,1668,1670..1672} (all) > [1760-01,1760-02,1760-12..] > (similar to regexp [...] groups; not compatible with Org syntax, but > the idea could be interesting for repeater intervals) > > -- > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at . > Support Org development at , > or support my work at > --000000000000dd151205f38e5bd2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dense poll. I had a question about this format which = is what I assume I'd be using if using org-mode with this on a day-to-d= ay basis if given the choice.
(from 2. Timestamp with time zone s= pecifier)

=C2=A02022-11-12 10:00 @EST+5=C2=A0 # TZ= syntax

Normally, when I'm communicating thing= s like standard and daylight savings time via mail or verbally, I'd use= this if writing emails or what have you.
ie. 2023-01-31 10:= 00 EST (or EDT)

Is the +5 offset in the example fr= om the poll here to disambiguate the EST from other ESTs (I realize from htt= ps://en.wikipedia.org/wiki/List_of_time_zone_abbreviations these are no= t always unique) or is the idea that someone would have to specify the time= zone offset each entry rather than saying EST or EDT?

<= div>thanks,
Daryl.




On Tue, Jan 31, 2023 at 6:48 PM Ihor Radchenko <yantar92@posteo.net> wrote:
Greg Minshall <minshall@umich.edu> writes:

> just a thought/reminder.=C2=A0 there are "semantics" and &qu= ot;encoding".=C2=A0 a spec
> like ISO-8601 specifies both.=C2=A0 the important thing for org-mode i= s to
> use an encoding that
>
> 1. is easily parsable/understandable by the mere mortal
>
> 2. allows expression of all the semantics of the underlying spec/specs=
>=C2=A0 =C2=A0 (be that ISO-8601, this new IETF spec, the Library of Con= gress spec,
>=C2=A0 =C2=A0 etc.)
>
> 3. and, importantly, is designed to *try* to follow updates to the
>=C2=A0 =C2=A0 underlying spec/specs (which will inevitably happen)

I agree with these three points.

Following the previous discussion and the various links provided, I have reviewed the main discussed timestamp standards and would like to
propose the new Org timestamp syntax that will allow specifying time
zone information.

I will not follow the standards fully because the available standards
are not designed to be easily understood by humans. I will also omit
the ideas from the standards that are unrelated to time stamps (but
still outline them below, and keep them in mind for
forward-compatibility). I will, however, try to use the syntax close to
the standards where possible.

1. https://datatracker.ietf.org= /doc/draft-ietf-sedate-datetime-extended/
=C2=A0 =C2=A0proposal is extending ISO8601/RFC3339 with time zone informati= on. In
=C2=A0 =C2=A0addition to UTC offset defined in ISO8601, it allows specifyin= g the
=C2=A0 =C2=A0time zone identifier and auxiliary information.

=C2=A0 =C2=A0Examples:

=C2=A0 =C2=A02022-07-08T02:14:07+02:00[Europe/Paris]
=C2=A0 =C2=A0(both offset, and time zone are specified)
=C2=A0 =C2=A0Note that we cannot use "[]" symbols because they ar= e incompatible
=C2=A0 =C2=A0with current timestamp syntax that must not contain closing &q= uot;]>"
=C2=A0 =C2=A0inside the timestamp.

=C2=A0 =C2=A01996-12-19T16:39:57-08:00[America/Los_Angeles][u-ca=3Dhebrew]<= br> =C2=A0 =C2=A0(preferred calendar is specified in addition to time zone)
=C2=A0 =C2=A0Note: calendar spec is out of scope of time zone discussion - = if we
=C2=A0 =C2=A0decide to add it in future, we can simply add new parts to
=C2=A0 =C2=A0timestamps, just like repeater interval and warning period.
=C2=A0 =C2=A0Further, the draft proposes an idea, which have also been disc= ussed
=C2=A0 =C2=A0in this thread: making use of redundant UTC offset + time zone=
=C2=A0 =C2=A0information to detect possible unexpected changes in time zone= rules:

=C2=A0 =C2=A02022-07-08T00:14:07+00:00[!Europe/London]
=C2=A0 =C2=A0("!" identifies that +00:00 offset, if not consisten= t with
=C2=A0 =C2=A0Europe/London at the timestamp time, must be signalled to user= or
=C2=A0 =C2=A0generally not ignored)

2. https://www.loc.gov/standards/datetime/ does not conta= in any new
=C2=A0 =C2=A0ideas relevant to time zones, although it has many other ideas= wrt
=C2=A0 =C2=A0approximate/incomplete timestamps. I will outline them later, = but
=C2=A0 =C2=A0they do not directly affect the proposed new Org timestamp syn= tax.

|-----------------------------------|
| The proposed new timestamp syntax |
|-----------------------------------|

I propose two forms of time zone information in Org timestamps

1. Timestamp with explicit UTC offset

=C2=A0 =C2=A0YYYY-MM-DD [optional day name] HH:MM[^ \]>]*?[+-=E2=88=92]H= H[MM]?
=C2=A0 =C2=A0YYYY-MM-DD [optional day name] HH:MM[^ \]>]*?Z[ \]>]

=C2=A0 =C2=A0"-" is latin "HYPHEN-MINUS" (code 0x2D) =C2=A0 =C2=A0"=E2=88=92" is unicode "MINUS SIGN" (code = 0x2212), as prescribed by ISO8601
=C2=A0 =C2=A0we will not actually use it when generating timestamps, but al= low it
=C2=A0 =C2=A0to keep some compatibility with ISO standard.

=C2=A0 =C2=A0"Z" in the second format refers to "Zulu" = time (another name for UTC)
=C2=A0 =C2=A0and must be either the last character in the timestamp or the<= br> =C2=A0 =C2=A0last character before space. Not sure if many users are famili= ar with
=C2=A0 =C2=A0"Z" convention, but it is (1) in ISO; (2) succinct f= or users who are
=C2=A0 =C2=A0familiar with it. We will prefer +00 number offset in auto-gen= erated
=C2=A0 =C2=A0timestamps.

=C2=A0 =C2=A0Examples:
=C2=A0 =C2=A02022-11-12 12:00+02 # 12:00 UTC+2
=C2=A0 =C2=A02022-11-12 14:00+0230 # 14:00 UTC+2:30
=C2=A0 =C2=A02022-11-12 14:00-0230 # 14:00 UTC-2:30
=C2=A0 =C2=A02022-11-12 14:00Z # 14:00 UTC

=C2=A0 =C2=A0The offset is a subset of what is defined by ISO8601.

=C2=A0 =C2=A0Note that unlike ISO8601, ":" is not allowed in the = offset specifier.
=C2=A0 =C2=A0This is to disambiguate with the time intervals in Org timesta= mps:
=C2=A0 =C2=A0[2022-11-12 8:00-9:00] in Org is a time range from 8am to 9am.=

=C2=A0 =C2=A0For time ranges, we will only allow a single offset and time z= one
=C2=A0 =C2=A0specifier for both start and end times:
=C2=A0 =C2=A0[2022-11-12 8:00-9:00+08]
=C2=A0 =C2=A0If different time zones are necessary to specify the start/end= times,
=C2=A0 =C2=A0users can still use full timestamp range syntax
=C2=A0 =C2=A0[2022-11-12 8:00+03]--[2022-11-12 22:00+08]

=C2=A0 =C2=A0The format is also forward-compatible with extending Org times= tamps
=C2=A0 =C2=A0for second/sub-second precision: 2022-11-12 14:00:05.0012+0230= will
=C2=A0 =C2=A0remain valid if we decide to adopt such format.

2. Timestamp with time zone specifier

=C2=A0 =C2=A0YYYY-MM-DD [optional day name] HH:MM[^ ]* @[!]?<[^ \]>]&= gt;

=C2=A0 =C2=A0For now, time zone name will only be processed when it follows= TZ
=C2=A0 =C2=A0POSIX format. If necessary, the proposed syntax will still all= ow
=C2=A0 =C2=A0extensions to TZ POSIX.

=C2=A0 =C2=A0Examples:
=C2=A0 =C2=A02022-11-12 12:00 @Asia/Singapore # tzdb syntax
=C2=A0 =C2=A02022-11-12 10:00 @Europe/Berlin
=C2=A0 =C2=A02022-11-12 10:00 @!Europe/Berlin # "!" does nothing = here, see below
=C2=A0 =C2=A02022-11-12 10:00 @EST+5 # TZ syntax
=C2=A0 =C2=A02022-11-12 10:00 @EST+5EDT,M3.2.0/2,M11.1.0/2 # manual time zo= ne spec allowed in TZ

=C2=A0 =C2=A0The "@" symbol is selected to disambiguate time zone= specifier from
=C2=A0 =C2=A0other auxiliary information in the timestamp. Like calendar na= me,
=C2=A0 =C2=A0which might be added in future. Note that we cannot use [...] = from
=C2=A0 =C2=A0the standard draft. I selected "@" because it is rea= d as "at" -
=C2=A0 =C2=A0location specifier.

=C2=A0 =C2=A0The "!" symbol is adapted from
=C2=A0 =C2=A0https://datatracke= r.ietf.org/doc/draft-ietf-sedate-datetime-extended/

=C2=A0 =C2=A0I use space before "@" to improve readability. We de= viate from the
=C2=A0 =C2=A0standard here so may as well. In contrast, no space before [+-= ]offset
=C2=A0 =C2=A0is closer to the standard yet not cluttering the timestamp too= much
=C2=A0 =C2=A0(IMHO).

3. (1) and (2) can be combined

=C2=A0 =C2=A02022-11-12 12:00+08 @Asia/Singapore

=C2=A0 =C2=A0Org will unconditionally use +08 offset and ignore the time zo= ne
=C2=A0 =C2=A0name. We prefer absolute offset because it is non-ambiguous wr= t
=C2=A0 =C2=A0out-of-date tzdb on the computer. One may also not update the = TZ
=C2=A0 =C2=A0variable upon travelling - the system clock will again be more= likely
=C2=A0 =C2=A0accurate.

=C2=A0 =C2=A0This redundant time offset info can serve as human-readable =C2=A0 =C2=A0indication of absolute time, while the time zone name will ind= icate
=C2=A0 =C2=A0the location.

=C2=A0 =C2=A02022-11-12 12:00+07 @!Asia/Singapore

=C2=A0 =C2=A0Org will calculate the internal time for both +07 offset and =C2=A0 =C2=A0Asia/Singapore time zone. If they do not match, Org will issue= a
=C2=A0 =C2=A0warning. The offset will still be preferred if we have to proc= eed.

=C2=A0 =C2=A0This can be useful when planning future meetings and sending O= rg file
=C2=A0 =C2=A0with a timestamp to someone else, potentially with obsolete tz= db.

|-----------------------------------|
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <end>=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
|-----------------------------------|

Apart from the ideas mentioned above,
https://www.loc.gov/standards/datetime/ contains a number= of other
interesting ideas that may or may not be adapted by Org in future.
I will outline the ideas I find noteworthy to keep them in mind when
considering changing (including current changes) in the timestamp
syntax:

1. Reduced timestamp precision:
=C2=A0 =C2=A01985-04-12 (day precision, time omitted; available in Org)
=C2=A0 =C2=A01985-04 (month precision, day and time omitted, not available = in Org)
=C2=A0 =C2=A01985 (year precision)

=C2=A0 =C2=A0Current timestamp syntax proposal should not interfere.

2. Using "T" as date/time delimiter
=C2=A0 =C2=A01985-04-12T23:20:30 (not supported by Org)

3. Using "/" for time intervals
=C2=A0 =C2=A02004-02-01/2005-02-08 (not supported and incompatible with Org= )

4. Seasons
=C2=A0 =C2=A02001-21 (Spring, 2001; not supported by Org)

5. Approximate dates
=C2=A0 =C2=A01984? (year uncertain)
=C2=A0 =C2=A02004-06~ (year-month approximate)
=C2=A0 =C2=A02004-06-11% (entire date (year-month-day) uncertain and approx= imate)
=C2=A0 =C2=A02004-06?-11 (year and month uncertain)
=C2=A0 =C2=A02004-?06-11 (just month uncertain)

6. Unspecified digits
=C2=A0 =C2=A01985-04-XX (day unspecified; might be an interesting idea for<= br> =C2=A0 =C2=A0defining repeater intervals)

7. Open time intervals
=C2=A0 =C2=A01985-04-12/.. (from 1985-04-12 to infinite)
=C2=A0 =C2=A01985-04-12/ (from 1985-04-12 to unknown)

8. Negative calendar year
=C2=A0 =C2=A0-1985 (note: an alternative could be allowing AD/BC)

9. Set of dates
=C2=A0 =C2=A0[1667,1668,1670..1672] (one of)
=C2=A0 =C2=A0{1667,1668,1670..1672} (all)
=C2=A0 =C2=A0[1760-01,1760-02,1760-12..]
=C2=A0 =C2=A0(similar to regexp [...] groups; not compatible with Org synta= x, but
=C2=A0 =C2=A0the idea could be interesting for repeater intervals)

--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,=
or support my work at <https://liberapay.com/yantar92>
--000000000000dd151205f38e5bd2--