From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.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 aGbJHL0r2WPfCwEAbAwnHQ (envelope-from ) for ; Tue, 31 Jan 2023 15:54:53 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id WEvHHL0r2WMODAAA9RJhRA (envelope-from ) for ; Tue, 31 Jan 2023 15:54:53 +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 0312536E86 for ; Tue, 31 Jan 2023 15:54:52 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pMqng-0002dO-2P; Tue, 31 Jan 2023 08:35: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 ) id 1pMqne-0002dC-2Y for emacs-orgmode@gnu.org; Tue, 31 Jan 2023 08:35:50 -0500 Received: from stw1.rcdrun.com ([217.170.207.13]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pMqnb-0004UT-O6 for emacs-orgmode@gnu.org; Tue, 31 Jan 2023 08:35:49 -0500 Received: from localhost ([::ffff:102.85.240.173]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 000000000010B84B.0000000063D917FC.00003E37; Tue, 31 Jan 2023 06:30:36 -0700 Date: Tue, 31 Jan 2023 16:22:26 +0300 From: Jean Louis To: Ihor Radchenko Cc: Greg Minshall , Sterling Hooten , "Thomas S. Dye" , Tim Cross , Daryl Manning , rjhorn@alum.mit.edu, 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) Message-ID: Mail-Followup-To: Ihor Radchenko , Greg Minshall , Sterling Hooten , "Thomas S. Dye" , Tim Cross , Daryl Manning , rjhorn@alum.mit.edu, emacs-orgmode@gnu.org References: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87tu063ox2.fsf@localhost> User-Agent: Mutt/2.2.9+54 (af2080d) (2022-11-21) Received-SPF: pass client-ip=217.170.207.13; envelope-from=bugs@gnu.support; helo=stw1.rcdrun.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-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=1675176893; a=rsa-sha256; cv=none; b=sp0l1j1aQ/51zc5GkXVsutmp1KUTn2KOIix6Gh7vkIoilWXTgcThKi9A9St//L4BUXFVqE b4lsKe68fVvBPBcWLSxbzx1uMO23Ab7rydaHlPX1pYGgi0xhxByU41Mk3RkbQ4O/KifZc2 dq06cn0ARI/o8xWpqaWQrDbTu7atJdnHQI8Q+o+JxUct6WIZABiIs66RO7cA+Ws8DRkFVy gFdxpSdXUy2zxp0JxbPTtlnDWTux0Bddm3nENo2Y4JNaE300bm5TnpzYNPVZPPyPdkz8Vn 2svbN42nS0GZgUqPlFimt2X4gGGAe28ZyKk9sNitB7pcAYMUgW7oXS/6tJBVIw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; 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=1675176893; 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; bh=ktKEOZ2ejX4DnhCfFKPUsc8DTycttSF5OyvCgcnKXKY=; b=YXpuk04HdfxF0R0jsZANZVgiAJo4EFzc+pmOqxhcbir6bl1pc7rUSJCU0Ogl6/k9fz8Yzp f8FsHgX/CXI7F7XwxfjCVBu7MQAOl0ftq5MoGJqeOl0l6tSoGdaepLt0k/BMc5R/Lwl1He z6H2N1wxVQiFeb8Df+R55j8AdpTdtRhsNTXCjtya0nnzrUDsbAceZ3DcetVU6VGk5c6NLg TraAxnwZiphJ26YYZon2T1vc1LjsbEEAN6V4hP28PdcxA8wm5ZRuU9cMmIAD8n65FdQc0I TRTUeb46ZGL6nlVo6GEnOpUX+wsiChoazDH24hefGXFKd+ORr7oowtOQ/tXZpg== Authentication-Results: aspmx1.migadu.com; dkim=none; 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: -1.38 X-Spam-Score: -1.38 X-Migadu-Queue-Id: 0312536E86 X-TUID: pwBLuwxWqCOM * Ihor Radchenko [2023-01-31 14:48]: > I will not follow the standards fully because the available standards > are not designed to be easily understood by humans. Very right, thank you. > 1. https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/ > 2022-07-08T02:14:07+02:00[Europe/Paris] The above looks nice, though not as clear from human view point as compared to standard Org time stamps, which are very readable. > 2. https://www.loc.gov/standards/datetime/ does not contain any new I would disregard above, as that is US government, not international document. Reason why they use UTC offset alone is that they decided they do not need more than that. Org is international and should not be bound to US only. > YYYY-MM-DD [optional day name] HH:MM[^ \]>]*?[+-−]HH[MM]? > YYYY-MM-DD [optional day name] HH:MM[^ \]>]*?Z[ \]>] > 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 It looks nice, but I have demonstrated that calculations by using UTC offset can't be accurate. Please disprove and rectify me, by using practical examples, you could disprove my practical example offered previously. > 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] I have already explained today that above calculation cannot be unambigous. Please verify my references and practical examples. When user thinks that span is X hours, the real span could be X-1 or X+1 > 3. (1) and (2) can be combined > > 2022-11-12 12:00+08 @Asia/Singapore That is how it should be, the UTC offset combined, with the time zone. And I suggest avoiding such timestamps by default, rather using time stamps as usual, and having heading time zone property, file time zone property and Org using system time zone in absence of any of them. Providing practical example or functions on how to calculate it should give better feeling which way will be better. This is very simple timestamp, readable, with weekday: <2023-01-31 Tue 16:13> I propose to remain that way, how it is, with addition: 1. If user wish, could add time zone, including UTC offset. Adding only UTC offset makes no sense, and adding time zone without UTC offset will cause difficulties in future. Thus: <2023-01-31 Tue 16:13+03 @Africa/Nairobi> 2. Otherwise heading could have time stamp when necessary to distinguish it from other headings: * My heading :PROPERTIES: :TIMEZONE: +03 @Africa/Nairobi :END: Then this time stamp <2023-01-31 Tue 16:13> would 3. Otherwise file could have time stamp, if necessary to distinguish it from other files on the same system: #+TIMEZONE: +03 @Africa/Nairobi 4. Otherwise system time zone That way you only upgrade time stamps with UTC offset and time zone, only when necessary, leaving everything else how it is, with addition of better calculations and related functions. All of the timestamps, including those simple existing one like <2023-01-31 Tue 16:21> in Org can be made unambigous in their representation or exchange by using UTC offset, plus the time zone, by using those properties. And very good reference on that link: https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/ Although serialization with offset time zones is supported in this document for backwards compatibility with java.time.ZonedDateTime [JAVAZDT], use of offset time zones is strongly discouraged. In particular, programs MUST NOT copy the UTC offset from a timestamp into an offset time zone in order to satisfy another program which requires a time zone annotation in its input. Doing this will improperly assert that the UTC offset of timestamps in that location will never change, which can result in incorrect calculations in programs that add, subtract, or otherwise derive new timestamps from the one provided. For example, 2020-01- 01T00:00+01:00[Europe/Paris] will let programs add six months to the timestamp while adjusting for Summer Time (Daylight Saving Time). But the same calculation applied to 2020-01-01T00:00+01:00[+01:00] will produce an incorrect result that will be off by one hour in the timezone Europe/Paris. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/