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 ms5.migadu.com with LMTPS id ONG1Jy3P4mOkPQEAbAwnHQ (envelope-from ) for ; Tue, 07 Feb 2023 23:22:37 +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 YO3LJy3P4mPBlQAA9RJhRA (envelope-from ) for ; Tue, 07 Feb 2023 23:22:37 +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 410A83FF35 for ; Tue, 7 Feb 2023 23:22:37 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pPWLk-0001Re-KC; Tue, 07 Feb 2023 17:22:04 -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 1pPWLj-0001RW-P1 for emacs-orgmode@gnu.org; Tue, 07 Feb 2023 17:22:03 -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 1pPWLh-0005mA-KE for emacs-orgmode@gnu.org; Tue, 07 Feb 2023 17:22:03 -0500 Received: from localhost ([::ffff:197.239.15.228]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 0000000000103840.0000000063E2CF0C.00004A96; Tue, 07 Feb 2023 15:22:03 -0700 Date: Wed, 8 Feb 2023 01:19:24 +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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <87357i9959.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: 14 X-Spam_score: 1.4 X-Spam_bar: + X-Spam_report: (1.4 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, 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: 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-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-Seal: i=1; s=key1; d=yhetil.org; t=1675808557; a=rsa-sha256; cv=none; b=LCIa/2vAvJsggCo0IrtRNMX4X1NrizlurCsKw0UII6T+CBL2L3zTdcPpU0JwwevgqiPzQz gcw9GyaH5WOcGWkTIjKB4lDNXa3ab84sWaUyo1oRZJYshtifFLTNIJxVPRiMTCitcopgq7 T2+7YuAyXoCytgsWgpDAJiGf3pMXZEWGrYc+G+hm+1cF9VWgMn3r7gMK/lOgNKnoG2aefW py/R2tOwaddov/zXAmcgJRyVmnl+5ljRo0DlyGYVAtAadu/In4UUK2wwWacOnNgykS6wYE sPv6igzzOi5JpYpAsaqIZx4I9BIOdVevtBragX3AEbOWKt/sM3qZkw7rycGG7w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1675808557; 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=EpNybE0e0XaEDYHPMtQ4Bg0HSzt8r4dfSiGUl1LecR4=; b=imT+dO/lVwGxB/mJQXZ2cFQ1pBuQW2IwP75Hh3KVcyTyOx3cZKcoN4y3MWLTdYHbomSEDg 3eDcK72Erqx+OidiYgXkPx6Ph9lvt9fj2sk0ubETLkBHwDCVPtlDGX0mI2EcnIIihya2gn vX0eCnEvBt+QlNOLpr2hFCpfCT1QrU868RqVAdCU8t83PH6qz3A8RHKevJFkXl9o7Mg3FF JbYKMPb/zhRFSl3uZiymJks8NIy3esjiiV+h6NdooMNTOHP4bt8UHrKVWGf4e8PP7vnG1n ASgouimY+DxRCJ6Zgcd0LIDmhB6SS2xF8Iccju7Yyfvi4AfRw/l8h+3LiXdk2w== X-Migadu-Spam-Score: 0.41 X-Spam-Score: 0.41 X-Migadu-Queue-Id: 410A83FF35 X-Migadu-Scanner: scn1.migadu.com 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-TUID: b7JnGJ7YmYJy * Ihor Radchenko [2023-02-06 17:11]: > Jean Louis writes: > > > * Ihor Radchenko [2023-02-05 13:45]: > >> [2024-02-04 12:00 @-08,America/Vancouver] will use fixed -8 offset > > > > What does that mean practically? Provide example for better > > understanding. > > It means "when I scheduled this item, I expected the UTC offset at the > time of the timestamp to be -08 and remain so. It was motivated by > America/Vancouver time zone, but if it changes in future, I do not care > - the scheduled time should remain at specific time point relative to > UTC". I read, though sorry, I do not understand who is expected to think that UTC offset is fixed? Is it Org as program? Or is it human? Another program in future, and human, must know did the organizer of event, had in mind: - to rather keep appointment at 12:00 o'clock, no matter the UTC offset changes, or - to keep appointment based on UTC definition? I find such situations rather easy to solve with database: - I can have column like "timestamp" with UTC time or local time plus UTC offset, and if I did not enter any other information, that UTC offset is considered in future. Consider this column name "timestamp". - I can have column "time" and when such is entered, then date is extracted from "timestamp" column, and combined with time. In this case UTC is only calculated in new time point but not used as period from past to appointment time. - I can have time zone for the future, if I enter such in other column, the future calculation must use that proper time zone. The above handling is for program to handle and for human to know that it is handled that way. You said "I do not care", that means you as human decide that [2024-02-04 12:00 @-08,America/Vancouver] will use fixed -8 offset But from where in such timestamp does user or program understand that? > > - The UTC offset is not certain to remain fixed in the future. > > Yes. But fixing UTC offset means that time point is fixed. Example: you > need a timestamp exactly N hours from now. It must not be affected by > time zone rule changes. Not generally! As I said, your time stamp is not structured, I cannot see how do you decide the appointment here: [2024-02-04 12:00 @-08,America/Vancouver] 1. Both time zone and UTC offset may be changed in future. 2. You as organizer you were maybe meaning UTC time "fixed" with offet -8, but the UTC offset maybe changed in future, it became -07. It is confusing, and neither program neither human will know with certainty if you meant 1 hour more or less. 3. To solve that problem, appointments are better defined as following, with the structured time stamp: * Meeting, discussion of our plan beyond 2030 :PROPERTIES: :TIME: 10:00 :TIMEZONE: Europe/Berlin :END: Or this way, but I do not find that practical, however, "UTC-TIME" could mean to program that it is fixed. * Meeting, discussion of our plan beyond 2030 :PROPERTIES: :UTC-TIME: [2024-02-04 12:00 @-08, America/Vancouver] :END: However, if you do not define UTC-TIME to mean fixed, how is program to know that the timestamp: [2024-02-04 12:00 @-08, America/Vancouver] means that it is -08 UTC fixed offset? Without putting some structure, it will not know it. Maybe this way (hypothetically): [2024-02-04 12:00 @-08, America/Vancouver/UTC-FIXED] as that way you would give signal to program that you want UTC fixed time in future, and not 12:00 o'clock necessary. Without any tag, neither program, nor authors, cannot know which time will it be in future, if there is DST change, time zone change or replacement of it, or UTC offset change. Structuring it, becomes clear DATE:, TIME:, TIME-ZONE: as future TZ database can give information of UTC offset and various local times for TIME: > > - If you do not have the time of creation of the timestamp above, you > > cannot know with certainty what was the offset in past, to calculate > > new UTC offset in case it changed > > America/Vancouver in the above timestamp is nothing but a reference > comment. One may or may not use it. > > > - As not even time zone is certain to remain in existence in future, > > you will need to use time zone, in order to derive that future UTC > > offset correctly. As it could change in mean time. > > If timestamp must follow the future time zone rules, can just use > [2024-02-04 12:00 @America/Vancouver] Exactly. And that is human friendly versus UTC, which is not readable. > >> [2024-02-04 12:00 @America/Vancouver] will use @America/Vancouver time > >> zone, as it is be defined in you OS time zone database. > > > > If you do not keep UTC offset, you will miss changes in future and > > generate errors. > > Only if you care. Maybe it is not an error to follow the future changes. > If you want to be notified, just use [2024-02-04 12:00 > @-08,!America/Vancouver] explicitly stating the offset you expect in > future. OK but expecting or not expecting makes again not much sense, it leads to confusions, including for organizer. If I am expecting -8 UTC offset, I cannot know if UTC offset will change in future. And when it changes, maybe my expectation also changes. It is useless and creates problems. And why not follow what other programs do? Specify date, time, not UTC in future. > >> [2024-02-04 12:00 @-08,!America/Vancouver] (note "!") will use fixed -8 > >> offset, but also calculate America/Vancouver time from TZ database, > >> compare it with the time coming from -8 offset, and warn you if there is > >> inconsistency. > > > > The UTC offset is the log what was the UTC offset at the time point > > when timestamp was created, as future UTC offset cannot be known. > > Sure. -08 is expected offset. If you wish to specify UTC time in future, no need to specify even any offset, but you can. Look here in first example how event is defined by using UTC time: https://icalendar.org/iCalendar-RFC-5545/4-icalendar-object-examples.html > > Making it "fixed" does not fix it in real time, you are then > > introducing something new than what other programs do with time. > > I do not understand this statement. Well to understand that, you have to make practical examples and understand what would human think in periods of time A, B, C, D, from creation of appointment, through possible changes of DST, time zone, UTC offset, to final appointment. Look here the second example of group-scheduled meeting that begins at 8:30 AM EST on March 12, 1998 and ends at 9:30 AM EST on March 12, 1998 https://icalendar.org/iCalendar-RFC-5545/4-icalendar-object-examples.html DTSTART;TZID=America/New_York:19980312T083000 DTEND;TZID=America/New_York:19980312T093000 LOCATION:1CP Conference Room 4350 The stuff with iCalendar works for reason that it is structured. The timestamp such as: DTSTART:19960918T143000Z will clearly say that time is specified in UTC time. No need for confusion with time zone. But if DTSTART has this: TZID=America/New_York:19980312T083000 Then it becomes clear that it will be the UTC offset in future with assumed mentiond time zone. But if you mix UTC offset, plus the time zone for future, that makes little sense, unless you introduce some tags that timestamp is recognizable as using UTC time, or that it uses date/time and time -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/