From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.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 uCtALFIA2WMevAAAbAwnHQ (envelope-from ) for ; Tue, 31 Jan 2023 12:49:38 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id oK8BLFIA2WN2dAEAauVa8A (envelope-from ) for ; Tue, 31 Jan 2023 12:49:38 +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 60E39172B2 for ; Tue, 31 Jan 2023 12:49:37 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pMp84-0004CB-4T; Tue, 31 Jan 2023 06:48:48 -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 1pMp7W-00048i-EY for emacs-orgmode@gnu.org; Tue, 31 Jan 2023 06:48:14 -0500 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pMp7T-0000u6-Cy for emacs-orgmode@gnu.org; Tue, 31 Jan 2023 06:48:14 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 2C3AE240545 for ; Tue, 31 Jan 2023 12:48:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1675165688; bh=CIP29UB2uuhplbWGB0XQI+a7v0ijO7Ae0+4+UbmhsTI=; h=From:To:Cc:Subject:Date:From; b=CerKf6s+oGtKKbKMGDPlXQgkbIu0n8tM0ALnJPvnElZ6DjJdJzWr8BcKMBYzL9VlC v/2iD1RESqFJJR2/+ner8vRZD8DbF0X5KjWVhV7yfmALNORuJvZ1w0RiR6cUOMcOvN 2Qzs6G35G23cKLshrJXfbx/CyE99A6bHIQ0L607YC/cGHCNPQov+sW5qfLzYBQcdrV C2KaYN3VPdfksObHWGJIWepNjzAMYM2REZVOtY+wxIU1M9qcaqBPF3QimgoDpeGsH7 JAni4l8s3wQ8i5LutKnBMWS/HPm3RziJ7wYIfqx+hytKxBpLyWRSXWPE7NlXWBUPGD 3ujyGObIXgsQA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4P5jwk3P82z9rxG; Tue, 31 Jan 2023 12:48:06 +0100 (CET) From: Ihor Radchenko To: Greg Minshall Cc: Sterling Hooten , "Thomas S. Dye" , Tim Cross , Jean Louis , Daryl Manning , rjhorn@alum.mit.edu, emacs-orgmode@gnu.org Subject: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda) In-Reply-To: <2150768.1675077958@archlinux> 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> Date: Tue, 31 Jan 2023 11:48:41 +0000 Message-ID: <87tu063ox2.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, 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-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1675165777; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=l4yt6Seg6ETzNz0q7KhztVKtAaQ4DpPozY9J5/qtz9E=; b=Yd4563IjxxztcU+IPnDq0UylYjEzm004psihLGuwwUJYfguVT/2jXkSy6wqVgN9idJwrHR 0QaqmBIEloOImmgnSRLI2gOT8MZAXn9AaI6id7heMwKU3WR3tv/HDEZDTnKqlYtuQxiRw5 BYulAM4TTEBpJF7aV9/6G69OSvtZRbmzQhPEsv4wipheAYLj6ju46JDJbYFr+Ehh2Xgy/z 6o6GfPh7jo2XSF0L3qhAX1U08WJpmkUbbiPOl43yAbD+z4ssdZF7d8PLOy9be5Qd2GNwO4 e3jtRsYfgoJm31Cjk9qFMHqK1XPnj2zpUeklxKPW5MWqTfKfG8FYcRTC/s3Ubg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=CerKf6s+; 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=posteo.net ARC-Seal: i=1; s=key1; d=yhetil.org; t=1675165777; a=rsa-sha256; cv=none; b=tOHr/aX+FwfZ0LuZ9yVjEdLKfCTw7UsGnT6iWsPCD80hnmrQdhDbxQkBYxCW9qDoAJhHFr 9Y1lTdbSWXPVBjPiThWmhMuXPq/L7hFfv+0k9JKKKfAphhjuaA/+DOPpd59VGzIH7FbvbO GDsycNAbxbJesC5hexYsqB2cp4MStfAda3bWjABzFOXCtGcxs5X0osBV15xoCjiqm4/GFQ dOLVEbmPQ3AY5W4m+mNVOm1WyAxh3lJSd1u5oVK6SuaTs4uidKcEc4iL0JL7jDfZvFUjFc Nl9bGDn4GyLT24m3gqlStm1MG6wje6imt5HQxzvKsFJX4gZujCB2dVC4pYTC/w== Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=CerKf6s+; 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=posteo.net X-Migadu-Scanner: scn0.migadu.com X-Spam-Score: -6.14 X-Migadu-Queue-Id: 60E39172B2 X-Migadu-Spam-Score: -6.14 X-TUID: yqJ6hzFSIhy0 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. =20=20=20 |-----------------------------------| | 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[ \]>] =20=20=20 "-" is latin "HYPHEN-MINUS" (code 0x2D) "=E2=88=92" is unicode "MINUS SIGN" (code 0x2212), as prescribed by ISO8= 601 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. =20=20=20 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 al= lowed 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) --=20 Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at