From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 kOmIOdtT2mMAXgEAbAwnHQ (envelope-from ) for ; Wed, 01 Feb 2023 12:58:20 +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 UGSfONtT2mN9KwAAG6o9tA (envelope-from ) for ; Wed, 01 Feb 2023 12:58:19 +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 82B843CFDD for ; Wed, 1 Feb 2023 12:58:18 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pNBjk-0006UD-Ro; Wed, 01 Feb 2023 06:57:13 -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 1pNBjW-0006TG-HN for emacs-orgmode@gnu.org; Wed, 01 Feb 2023 06:56:58 -0500 Received: from mailer-211-145.hitrost.net ([91.185.211.145]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pNBjR-00063r-Rl for emacs-orgmode@gnu.org; Wed, 01 Feb 2023 06:56:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=christianmoe.com; s=x; h=Content-Type:MIME-Version:Message-ID:Date: In-reply-to:Subject:To:From:References:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=CHNGqIqwtVXRC1N33PP215NalmzRh99CPWxNcD1ozL4=; b=GmE8wCSS15kyTtAURWatCxlkOt DK0GZ/i6dUvAcJDwp4P8Ng/FnhJenvMvAMZmvB/4HMxLVdzbzQpbitGp8Qvh7OSdvVO4iHRiyTYBW mFVev71KkimHqpLx0fLKaNKPm0p4lVN7owoLG9KlMnSj0EuIzjkYFYx/VKZuM3cxYOJXbvhELEoK/ zh8eJpeWW9slg2m3po+EKMPiBgoonBHd76tvZj47VXvGj4u73T3Y7q9Ez7Sw2gtLHCZOslzNF7bDx MGeJ5v7dlISaVsrFT16TiAiNTGKmUGHhcsWFODFesgMbeoOJnrJijgzsEeAzaaAs9DmSVwK732/I1 e0Su0yag==; Received: from 92-63-21-56.dynamic.telemach.net ([92.63.21.56] helo=Tauriel) by b1.hitrost.net with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1pNBjL-00BKZV-0e; Wed, 01 Feb 2023 12:56:47 +0100 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> User-agent: mu4e 1.2.0; emacs 27.2 From: Christian Moe To: emacs-orgmode@gnu.org Subject: Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda) In-reply-to: <87tu063ox2.fsf@localhost> Date: Wed, 01 Feb 2023 12:56:46 +0100 Message-ID: <87r0v9sio1.fsf@christianmoe.com> MIME-Version: 1.0 Content-Type: text/plain X-GeoIP: Country [IP], SI [92.63.21.56] X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-Authenticated-Id: mail@christianmoe.com Received-SPF: pass client-ip=91.185.211.145; envelope-from=mail@christianmoe.com; helo=mailer-211-145.hitrost.net X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 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." 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=1675252698; 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=CHNGqIqwtVXRC1N33PP215NalmzRh99CPWxNcD1ozL4=; b=SUk54EW/lHVrUuiQFd4Yzd8sFnKDHsTnKvu+Wi3gcArWOe4yDqj59telnRfvN2IJ9Ay89Y 3Zw6V1kkr2ccSv4oFqfif2RinQvG8x6xOp1SD2jsxU7H36yVmB/mFxv21g7aUOxWLRfNd6 wNiBQGHCJONkQ2dnedsRm1oGd9aCDMdA2YRNvyX3NjKBQl1PRBETPY/phCaMZZ/F0M8lHY yU080nhLr3ngbvEt0DUQyUp9hoZKVySz2RLoDS5GCCxqdgN3U6qJREP+52PKddoW4hBuKr hA+xzHVbFNAzfKIPsmbMNpZ7IAtaVJRrTFYkgROVSIiXQAs+CYdo4ycLB6BDdg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none ("invalid DKIM record") header.d=christianmoe.com header.s=x header.b=GmE8wCSS; 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-Seal: i=1; s=key1; d=yhetil.org; t=1675252698; a=rsa-sha256; cv=none; b=J94SGloDnPvyyiiNKPqd/Sph0cHEFuLddIoZ2vDMYMYmNY49qRfMojw5AmsIlSonjBBZ4p z4F0RFg3D7pywe1ouJEtj1RSLolBOHthBaaw7ZogyzlUG/uMMoMjzUy2iPNWJdNHl1MVIQ soNyf5QSLEmz5nM9Gj4O9O4Cjo9GNSo+p8sZn8ORFws9VCzsXTcGl2tSk2Gvfemg9snQ1b 2c7JoZraUfS41JpA47I/vtrB6PDFHfk/BD0TpAdbzb7ymw1S8hmG9l/WUGyF5NzUmuNPk1 KRWakmJhW6SkGma43rB9KQ/ixPG6KVkuPeM0sw48byOnJJRWkgmyRDt5GKszjw== Authentication-Results: aspmx1.migadu.com; dkim=none ("invalid DKIM record") header.d=christianmoe.com header.s=x header.b=GmE8wCSS; 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: scn0.migadu.com X-Spam-Score: -1.88 X-Migadu-Queue-Id: 82B843CFDD X-Migadu-Spam-Score: -1.88 X-TUID: DRo4CBreUugw Hi, I have only partly been able to follow the discussion, but this seems like a very thoughtful proposal. I'm just not super happy with the ISO format running clock time and offset together, which I thinks makes clock times less readable when you're just quickly glancing through notes. > 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 '12:00+02' offset is not the 'dd:dd' shape I expect a clocktime in. Also, since I don't think in UTC offsets, my brain goes '12:00 plus 2 hours' before 'the 12:00 that's 2 hours ahead of Greenwich'. The extra cognitive load is admittedly small, and I'd probably probably get used to it quickly if it were only the '+dd'. But I might still get tripped up by an offset like '14:00-0230', which is unambiguous to a computer, but synonymous with '14:00-02:30' to my brain. >From this perspective I'd be happier with the less concise, but super explicit 2022-11-12 14:00 UTC+2 2022-11-12 14:00 UTC-2:30 but I realize there are many considerations to balance here. Yours, Christian > 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)