From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id CJXZFUPECmR7bgAASxT56A (envelope-from ) for ; Fri, 10 Mar 2023 06:46:43 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id 6JrLFUPECmQhigAA9RJhRA (envelope-from ) for ; Fri, 10 Mar 2023 06:46:43 +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 C1042355A for ; Fri, 10 Mar 2023 06:46:42 +0100 (CET) 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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1678427203; 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=ET9bS+yIv66Cc3wzi03x+K4ZE2dohDNzq6gje8FIumM=; b=I08Gtg/QjbCV3W/hKDN5725cgo8a4Osn7jZm438K0AJCFLrnhQWNYDOPmCLRqD4hGXy9xm Lyw9rpbNblYHSqfkhQY79E24EXFF8vqIE3sB2j4RWQPcxxI5tY8TLPeZ1l+JgZ9eYWXbZ/ LDaVN2FV+YgW+maFI7/SlvFkHG6T3P/7JYlv1z5KmHA9R/Wz1geGXTQVZ1az2LGxhKP4HB uFp3gVB9nh6JvrGyB8BPsnmtW+ps2TbszswfFBIomFUnqBXuQ3O+mRqqe9gPWpX4C3vC+t 2VEU81IZ+R9+UIsjyNMZU04Ov1VqNQzpgr74HiuOqUey8raKEWfJq5wwdWWcaQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1678427203; a=rsa-sha256; cv=none; b=UrajLNlrMKgu87/jdvX0n5CS3WHwRjh6oRUO+dwUDcvKd4s7RhNov2ulLovDtSSwsq4ILu siA9aykTUPyOltFZdzbBClvXjGKjo9QjeuO/43sdN3lIuCPklyra9gdfGxXJ9xGHBs6KqY 92UKs4OVkqt6N/CH9y3ZDSfTWVLehUUUF9RpsM7hcF8oHDZDGNPyihAfVJDYd9+WHj4mzK 8C984b/3SWrEeP5OY0Dhusv3JdACFGTN9+j2Vm2BEjV9jhO/R8JBFh3Y3PIpolOoZrbNiO 7SNMZKAK/oI2JmQUAY6HQHMxqZfOW7vSQvBtV5lAjr+CJ3dkCPka+nrdcCinfw== 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 Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1paVZa-0001hU-A8; Fri, 10 Mar 2023 00:45:46 -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 1paVZV-0001hK-SM for emacs-orgmode@gnu.org; Fri, 10 Mar 2023 00:45:41 -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 1paVZT-0005hK-5l for emacs-orgmode@gnu.org; Fri, 10 Mar 2023 00:45:41 -0500 Received: from localhost ([::ffff:197.239.15.162]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 0000000000103A05.00000000640AC3E4.000053F3; Thu, 09 Mar 2023 22:45:07 -0700 Date: Fri, 10 Mar 2023 04:37:38 +0300 From: Jean Louis To: Ihor Radchenko 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) Message-ID: Mail-Followup-To: Ihor Radchenko , Ypo , Org-mode References: <87lelce6iu.fsf@localhost> <87357i9959.fsf@localhost> <877cwse95m.fsf@localhost> <878rh5eqz4.fsf@localhost> <87fsafe5g0.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87fsafe5g0.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: -2 X-Spam_score: -0.3 X-Spam_bar: / X-Spam_report: (-0.3 / 5.0 requ) BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, SPF_HELO_PASS=-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: X-Migadu-Scanner: scn0.migadu.com X-Migadu-Queue-Id: C1042355A X-Spam-Score: -3.79 X-Migadu-Spam-Score: -3.79 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 X-TUID: QV6JRhLGEKxj * Ihor Radchenko [2023-03-08 16:29]: > > 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. Yes, and that is what I was stating. What we were arguing about is rather notation. > I am referring to "fixed" offsets to be specified by users and will > never change. "Fixed" offset is IMHO wrong designation. What you want to say is "UTC time". Don't use any offsets with UTC time as not to confuse people. Use local time representation of UTC timestamps. For UTC timestamp there is no problem to be in future or in past. > These offsets are convenient to protect timestamp from regulatory > changes in time zones. UTC time is convenient. But if you intend to represent time with time stamps, fixing some "UTC offsets" to get "UTC time" representation, I do not see how it is convenient for anybody. > Effectively, they are simply another, sometimes convenient, way to > represent UTC time. Just use UTC time to tell what "fixed" time, and do not use "UTC offsets" as they are by convention changeable. > 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]. No matter in which time zone I am, one year from now depends on how year is calculated If current timestamp at UTC time is: 2023-03-10 01:08:07 then one year from now is: 2024-03-10 01:08:07 > 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. I understand and I do not agree to that notation for reason that it is confusing, but you please do how you wish. UTC offset is shown to user in many applications depending on user's time zone, while time that is fixed is static designation. I would agree to such notation only if UTC time is written in Org file, but you provide representation of UTC time showing the UTC offset. I see now use of providing "UTC time" with "UTC offset" as that is beyond conventions. Then we are speaking out of the reality of what people agreed on this planet, and people agreed not to use any offsets with UTC time. It is either UTC time without offset or offset zero, or no offset at all. But of course Org can be the playground to do what one wish and want. > > 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. While I cannot see the context of the above statement, I have never had any idea of letting user convert some timestamps manually, that is why computers are there to provide timestamps. I don't do that manually. > >> 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. Which indicates you did not do the homework. > >> > 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 in the time zone, meeting is at 12 o'clock. > >> > It would assume that UTC offset can change in future, but 12:00 clock would be authoritative time for future. > >> > >> 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: > > ┌──── > │ [2022-11-12 12:00 @+07,Asia/Singapore] # warn when mismatch > │ [2022-11-12 12:00 @+07,!Asia/Singapore] # use Asia/Singapore over +07 > │ [2022-11-12 12:00 @!+07,Asia/Singapore] # use +07 over Asia/Singapore > └──── In the above examples there is really nothing to be "warned". When you give wrong examples for other context, it means you did not understand it. You are showing time in past. For time in past, UTC offset is property of time zone, it is very good to show it, though computer program could derive it from time zone database, but there is nothing expected to change in future for such timestamps from past. There is nothing to be warned, and the time zone MUST match the UTC offset. Wrong example for the mentioned use case. We spoke of time designation in future. Not time in past. Here are comments on time in future: ┌──── │ [2032-11-12 12:00 @+07,Asia/Singapore] # warn when mismatch Mismatch what? UTC prefix can become +08 in Asia/Singapore zone, intended time of meeting is 12 o'clock, there is nothing to warn. For people in that time zone it will be, in case of UTC offset change, always same 12 o'clock. If you wish to use some UTC time, as fixed point of time in future, then use UTC time, do not use time zones. There is no need to use UTC offset from today in time designation in future. And it is not "timestamp" by main definition, as "timestamp" is used wrongly in Org for future, while timestamp in computing is used for log files, for past, and is much more definite than how we use it in present time. Author of Org was in his own world, without inspecting all these issues related to time, found somewhere the word "timestamp" and started using it for planning. See: https://en.wikipedia.org/wiki/Timestamp "A timestamp is a sequence of characters or encoded information identifying when a certain event occurred, usually giving date and time of day, sometimes accurate to a small fraction of a second." "Occurred" does not mean "to occure in future". │ [2032-11-12 12:00 @+07,!Asia/Singapore] # use Asia/Singapore over +07 If you wish to specify time with offset from UTC time, then do not use time zones. However, that is not common notation. If you use time zones, computer always need to verify that new, in new time in future UTC offset, as it could change from the time of writing it to the time of viewing it. │ [2032-11-12 12:00 @!+07,Asia/Singapore] # use +07 over Asia/Singapore └──── If you are to use +07 as offset in future, do not use time zone, as that is confusing, not common, capricious, and only you claim it is "convenient". It is hypothetical talk of no use. > The first timestamp is an error when time zone rules change. It is not, for reason that your timestamp examples were not relevant to discussion, as they are from past. Timestamps are in general always past. Remove wrong use of the word "timestamp" from Org manual. Timestamps as you have shown them here below would be perfectly valid, would you use the proper UTC offset for Asia/Singapore time zone, but you have not, you used wrong UTC offset of +07 while Asia/Singapore is +08 time zone. > ┌──── > │ [2022-11-12 12:00 @+07,Asia/Singapore] # warn when mismatch > │ [2022-11-12 12:00 @+07,!Asia/Singapore] # use Asia/Singapore over +07 > │ [2022-11-12 12:00 @!+07,Asia/Singapore] # use +07 over Asia/Singapore > └──── Correct timestamps would be: > ┌──── > │ [2022-11-12 12:00 @+08,Asia/Singapore] # warn when mismatch > │ [2022-11-12 12:00 @+08,!Asia/Singapore] # use Asia/Singapore over +08 > │ [2022-11-12 12:00 @!+08,Asia/Singapore] # use +08 over Asia/Singapore > └──── And for those timestamps, there is no warning when mismatch, because in future, you cannot change the UTC offset for past (rarely). We already know that +08 was UTC offset for 2022-11-12 and there is nothing in future to be warned about it, even if UTC offset for Asia/Singapore would change to +05, that is not relevant, as in the past UTC offset was +08 and there is nothing to warn about. And for following: > │ [2022-11-12 12:00 @+08,!Asia/Singapore] # use Asia/Singapore over +08 It is contradictory that one places "timestamp" which one would change in future depending of future time zone! That makes no sense, that is not timestamp anymore. Do your homework. If the UTC time was 04:00 because UTC offset was +08, then if user views the above perverted version of a "timestamp" with changed UTC offset e.g. +09, which could be designated in future in the new definition of the time zone, then if you use notion "use Asia/Singapore over +08", that would imply that timestamp in past changes. It would not be any more 04:00 UTC time, but it would be 03:00 UTC. And changing past timestamps is contradictory to the reason of using timestamps. And for following: > │ [2022-11-12 12:00 @!+08,Asia/Singapore] # use +08 over Asia/Singapore > └──── If UTC offset is there, then it is confusing to use "time zone", if you wish to designate UTC offset, do not use time zone. But using UTC offset is contradictory to conventions, so best is to use UTC time without any UTC offset. But for future time, if you wish to provide some time that differs from UTC time, then I would say most logical would be to use again UTC time, plus added markup to designate interval that has to be added or deducted from that UTC time. But not in the form of "UTC offset" as UTC time does not have UTC offset by conventions. I am referring to something like this: [2022-11-12 04:00 @Z] + '8 hours' > 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. I wish you good luck. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/