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 ms9.migadu.com with LMTPS id KA/dNumNCGQGSgAASxT56A (envelope-from ) for ; Wed, 08 Mar 2023 14:30:18 +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 iADONemNCGRZEgAAG6o9tA (envelope-from ) for ; Wed, 08 Mar 2023 14:30:17 +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 1A50641297 for ; Wed, 8 Mar 2023 14:30:16 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pZtqs-0001b7-Hb; Wed, 08 Mar 2023 08:29:06 -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 1pZtqr-0001ar-7v for emacs-orgmode@gnu.org; Wed, 08 Mar 2023 08:29:05 -0500 Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pZtqo-00061M-SZ for emacs-orgmode@gnu.org; Wed, 08 Mar 2023 08:29:04 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id BD134240210 for ; Wed, 8 Mar 2023 14:28:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1678282139; bh=6l2aPUqBSw3/Hf28A9zAECArKP18G9F0cp28uY4Yo18=; h=From:To:Cc:Subject:Date:From; b=SnTbcH2yW+SUj95YkU4+oz87XXNTVFnGWB7kyZ6Ndszc2jxAyVnXxwWASrgkt7v+Z hojAZfbVJBSWs/+110UXjvMtZelcffidP+qVD/JSHOjJvq4r3FYyioc6i+L8JxzJei YwPwLW+GjsaTdC4P9juff4kqn138JO8NLmef1kyrdbZ3rTfCaaCQj2xzAIKx31HUGG IBRrTpD2XgBlthZn2icE03JT5i80dXvQOGylAqVEysLBOT0MM1Ddeg0vX/v/HXq82R C5Ayks7ckc08vGxXybnpwCSh0bxAnPw+Wssavh/mATO0EX3EELmWqCUWE8Q1GoEO0k AcJoiKZHrsYkg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4PWtST6gT9z9rxV; Wed, 8 Mar 2023 14:28:57 +0100 (CET) From: Ihor Radchenko To: Jean Louis Cc: Ypo , Org-mode 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: References: <87lelce6iu.fsf@localhost> <87357i9959.fsf@localhost> <877cwse95m.fsf@localhost> <878rh5eqz4.fsf@localhost> Date: Wed, 08 Mar 2023 13:30:23 +0000 Message-ID: <87fsafe5g0.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.66; envelope-from=yantar92@posteo.net; helo=mout02.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, RCVD_IN_MSPIKE_H2=-0.001, 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-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1678282217; 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=8LL1fVR4YI7MC8+9BWjYT+uE8HRFgdUUCuksLzR9EeA=; b=lvugxsirFSDSg3cFUNDaqnjvHr+h0SBrIcxkjyRAQ14prGap7ASXtOLEnWsBfnSF3RP01q f5hh3trKES/7WvKsfL3R9ssvfC7PeoWXMV2QVfyKrBEPBRHi0oyV7i8aXY6T28Bkt5gfSx OF8u7wzsglCW0PvFAtbiiHN0V9NcXAGJdvsJm3YBwxbDVF3oYgfjMJy1YSJxk0x93e9RMX oBDln5VTeyMBSb317sQDLCtIt7NkCltbsDIeOr7Go5biQC7kWXrrQKolD6IZ9tI6OlT4wg /u9pp/hEl5sHx2VKN7XmPphwg8+TequgvSY2HGEsWLeIlDuROXy/8Kefyxpa4g== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=SnTbcH2y; 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=1678282217; a=rsa-sha256; cv=none; b=qkcemRJBXwpQXCh+MtPqgSnWjtjM7XJRJZ+sQ6+6yb0cUNnDsUaH422AFkKuu3BBj6ttHa 0Tw5pN/UFX6u6ElNMcbAlVPdYLOruX3zaoYB3iIGY2YldAXrfiJn5HlOCgLQCq5TSC1dI+ Yo4oSVmOKKo/Ai133b0ci96D7Wg5Z3QSiXMn1iMtSmW/84j/2tiGHSqcAiZJAGpEflWJgt T6EAudSg8ifBCGHDJDYCzanwai/FAKUSk1OEMHl2nJSFJdeWpt/s/RoAY2CBZTI4/AG6bP p8cJwUj28uCWwF0ZzEeGs1FtVxJXBlBCEIZ4tqWNRtyrnAByckbEoktb5eyRTQ== Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=SnTbcH2y; 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-Spam-Score: -6.20 X-Spam-Score: -6.20 X-Migadu-Queue-Id: 1A50641297 X-Migadu-Scanner: scn1.migadu.com X-TUID: 6bF7F+2thQsX Jean Louis writes: >> > Here is suggestion: >> > ------------------- >> > >> > 1. Convert local time timestamp to UTC >> > 2. Add 10024 hours >> > 3. Provide timestamp in UTC >>=20 >> This will involve converting time, which is prone to errors. I still >> think that sometimes it is more convenient for human to use familiar >> time zone and fix the offset for future. > > Your answer is not related any more to @UTC time you were mentioning > as now you are using "familiar time zone". I said, there is no offset > representation with UTC time but +00. But it can be with other time > zones. > > However, when you say "fix the offset for future" that does not > work. If you do specify time zone, you are fixing it by time zone, and > not by UTC offset, because it is less likely that the time zone > definition changes, but UTC offset can change easier. > > The UTC offset is property of the time zone. The future time zone > definition will know what is it's UTC offset. UTC offset is indeed a property of the time zone. However, UTC offset may be a subject of change in some time zones. I am referring to "fixed" offsets to be specified by users and will never change. These offsets are convenient to protect timestamp from regulatory changes in time zones. Effectively, they are simply another, sometimes convenient, way to represent UTC time. Consider that you need to put a timestamp exactly 1 year from now, even if time zone rules change. You are in +04 time zone at [2023-03-08 14:00 @Asia/Istanbul]. You can write [2024-03-08 11:00 @Z] or you can write [2024-03-08 14:00 @+03]. The latter is nothing but former, written without a need to mentally convert back to UTC from your current wall clock. > You can introduce something new in Org and say "This is fixed UTC > offset in time zone @ABC" but that way you are confusing yourself and > future programmer and users, as it does not comply to already accepted > international standards. > > iCalendar proposes different way of representation of time in future,haw > that is, it could be UTC time in future, or it could be date, time and > time zone. Using UTC offset for future is redundant, as in present > time when you are writing future time stamp, you cannot know the > future UTC offset. iCalendar provides just two options: time zone name and UTC. It is ok when the timestamps are written programmatically, but not ok when the format should be writable by humans manually. I do not see why we should force the users to convert to UTC manually in the above scenario. >> icalendar is _not_ the only time spec around. We can take it into >> account, but I do not see any reason to follow it blindly. > > How about finding reasons why iCalendar specifies it that way? > > And then deciding if those reasons, not specification literally, > should be followed? Feel free to share the underlying logic if you are aware about it. =20 >> Note that the idea with (optionally) providing two time zones/offsets is >> also coming from a time spec in >> https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/ > > ... > Conclusion is that your reference is only partially relevant, as you > may use it as guide for past timestamps, but not as guide for future > time representation. The cited document explicitly talks about timestamps in future. See 3.4. Inconsistent time-offset/Time-Zone Information > In my opinion people should be given the extended timestamp function > in Org where they may choose the time zone. > > - no C-u prefix, interactive selection: <2023-02-12 Sun> > > - with C-u prefix, interactive, with time: <2023-02-12 Sun 11:09> > > - with double, C-u C-u, prefix, non-interactive with time: <2023-02-12 Su= n 11:10> > > - but then I do not know what with 3 times C-u, some of those prefixes > could be used to let user choose the time zone Sure, though I had a slightly different interface in mind. In any case, it is too early to talk about interfaces. Let's finalize the syntax first. >> > 4. Hypothetical example of clear timestamp for future: >> > [2024-02-04 12:00! @-08,America/Vancouver] >> > where the time would be stamped with "!" and that would mean that i= n the time zone, meeting is at 12 o'clock. >> > It would assume that UTC offset can change in future, but 12:00 clo= ck would be authoritative time for future. >>=20 >> This is ambiguous. 12:00 which time zone? GTM+08? America/Vancouver? > > The sign "!" is telling "use time, not offset as authoritative". I do > not say you should implement it this way, but I am saying it is wrong > putting both the time and offset for future time, while you will not > know the future offset with certainty. Ok. I see the problem you referred to. We should then better stick to the TEC's proposal here: =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 [2022-11-12 12:00 @+07,Asia/Singapore] # warn when mismatch =E2=94=82 [2022-11-12 12:00 @+07,!Asia/Singapore] # use Asia/Singapore over= +07 =E2=94=82 [2022-11-12 12:00 @!+07,Asia/Singapore] # use +07 over Asia/Singa= pore =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 The first timestamp is an error when time zone rules change. In the two other timestamps, the complementary time zone is a redundant information that does not affect how the timestamp is interpreted and simply aids the human eye. Optionally, users could enable extra checking with Org warning about inconsistency for the two latter kinds of timestamps as well. > It is not good specifying something in Org program and not clearly > giving it to user what is authoritative. Sure. The first kind of timestamp is to be left to users to enter manually, when they need to. Automatic timestamps are of the other two kinds. --=20 Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at