From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.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 KAN1Hnp432NibAAAbAwnHQ (envelope-from ) for ; Sun, 05 Feb 2023 10:35:54 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id GONeHnp432OvLAAAauVa8A (envelope-from ) for ; Sun, 05 Feb 2023 10:35:54 +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 CB12D1109F for ; Sun, 5 Feb 2023 10:35:53 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pObQM-0000Aa-TL; Sun, 05 Feb 2023 04:35:03 -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 1pObQK-00009x-SO for emacs-orgmode@gnu.org; Sun, 05 Feb 2023 04:35:00 -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 1pObQI-0007o7-Lq for emacs-orgmode@gnu.org; Sun, 05 Feb 2023 04:35:00 -0500 Received: from localhost ([::ffff:102.83.69.138]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 000000000010B846.0000000063DF7845.000016B7; Sun, 05 Feb 2023 02:35:00 -0700 Date: Sun, 5 Feb 2023 12:31:45 +0300 From: Jean Louis To: Ypo Cc: 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: Ypo , Org-mode References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1675589754; 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=7PUXK1fFVE5GktIa1MdhInXNE3gy5YKoEQOhVnDY0is=; b=SgwD3Bj6WPaRf1IzNvcgCvOKXl5MxL8FPqMLvPamzMpRjjdP4hHa1RQw+9mqR7OjHyo3Rs sRCQDbamHlb5mueIdaBiJooQg0+Dm2u0AhohRA2089p81H/lJoj/ra+OCsl/xywcdrfCFM j706m5r2P2HRrLOLqUUMuQ54j60x0r0yyTVtqP+0e3Bka0YvM4cUyOVxZ9rKGHy3SQm+wX 4/bTvV6LLB+CyorgR/HG0o5EKglLYfRGNVH6N1XBA9z+NgqHJmgxJgnC8WSfFjob1NwrWO /lAmF2ZeB8Vb9igmJxI74u97DLns8cuZARdka5ALN4W+vBEePI0VYjKgVh65pw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=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" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1675589754; a=rsa-sha256; cv=none; b=fZPSXHwT6mpGCqTtVCIWbSFrC+lt9yIxYP+8o+Nb15K00svUs7xypxtuj4V0ab+R2xLgLN gHnKpVtqmMJ9WDDlHf6Vn32yARF+cPzxfVeWL+Nxfp4foSojlsuf2PhC8yYH4QFFuKRjvr Z81KkEeRH41Ogr4qB9uEKt217dKwjFdoSXAA3zhpojsP4QIcEEh9mCi4/FQczZvQg84Xt2 fNLUVtZrwwthzrg2ospHNNLScM9T6mt1Ozz2mnYIniHmWvYuJDQo6QeV+zUEAnEMipXIh5 9AVw8wLQEkAEgCc2Vf97Ddshk7zou7XVK5hbW31MexUMEXtV3gZl51wMbyH2jQ== X-Migadu-Queue-Id: CB12D1109F X-Migadu-Scanner: scn0.migadu.com Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=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" X-Migadu-Spam-Score: -2.89 X-Spam-Score: -2.89 X-TUID: 9iCJ0v4uBPz8 * Ypo [2023-02-05 00:41]: > I have been thinking about how I would use this feature. So use cases > appeared, which arose some doubts about how to use this feature, and an > opinion for the Poll surged: > > If I wanted to assist to a "Mastering Emacs book club" meeting in > America/Vancouver, while living in Spain: Doubt: Should I use local time of > America/Vancouver to schedule the meeting?. Like: [2024-02-04 12:00 > @America/Vancouver] (I don't like space before the @, for the Poll). The above sounds as good idea! People are in Vancouver, so it is 12 o'clock on 4th February, by using time zone "America/Vancouver". If that time zone changes before the future even, the time zone database is going to hold change variables, and one will still be able to figure out the time. > 1. Doubt: I suppose my agenda timestamp would be: [2024-02-04 do. 21:00]. > (Spain local time). Correct? Your agenda time stamp could be with Spanish time zone. Your agenda is really this: [2024-02-04 12:00 @America/Vancouver] And that would mean if you wish to represent it in Spanish time zone, that computer program should: - First read the [2024-02-04 12:00 @America/Vancouver] - read time zone database properties for America/Vancouver, this implies having latest time zone databas - apply properties, such as possible UTC offsets, this implies possible changes of UTC offsets - calculate the UTC time, at time point of reading that time - understand local time zone, also calculate UTC time - use above information to calculate Spanish time and representation in Spanish time zone > 2. If I went on vacation to Brasília, my agenda timestamp should change to: > [2024-02-04 do. 17:00]. (Brasília local time). That is okay. >    Doubt: How must the local time zone be updated to get that timestamp > changed? By similar formula as explained above. > 3. Back to Spain, I see that, for political reasons, Vancouver's winter > time-zone changed from UTC-8 to UTC-9. >    Doubt: How would my tz database be updated? By your system package manager and operating system maintainers. If they do not update it, you would miss the time. If there is any updated beyond international agreement like what is now happening in Ukraine, I doubt you would have correct time calculated by computer. >    Doubt: After updating the tz database, my agenda timestamp would change > automatically to  [2024-02-04 do. 22:00]. Correct? Org will not know if you did update TZ database or not. That super Org who knows how to calculate times should definitely use the TZ database. Time stamp would not change because you only come to some location. But you also need to change the computer time settings (to be correct time) and computer time zone. If not computer time zone, then the settings for Org, as Org could have in future settings of time zone Once those settings are applied, your Org could show you local time. > 4. For the Poll: What would be the expected behavior if we used the UTC > offset?  [2024-02-04 12:00 @-08,America/Vancouver] When time is not too far in future, it is less vague. When time is more far in future, it is more vague, as UTC offset could be changed and time zone name could be changed, but TZ database would have that information to re-calculate it in that future. It means that UTC offset here: [2024-02-04 12:00 @-08,America/Vancouver] is only something that is assumed, it could change, both with fact that time zone could disappear, new time zone could appear. TZ database would be handling those issues, that is the purpose of it. Using UTC offset in future timestamps does not make sense as it is not time that one can calculate in present time with certainty for reason that future TZ database does not exist in present time. Here is good recommendation for such case: Time Zone Storage in Data Type "Timestamp With Time Zone" - ITCodar: https://www.itcodar.com/sql/time-zone-storage-in-data-type-timestamp-with-time-zone.html Booking future appointments where we want to keep the time-of-day even if those pesky politicians change the offset of the time zone(s) in their jurisdiction. These political changes happen surprisingly often. So book an appointment using two columns: TIMESTAMP WITHOUT TIME ZONE in one, and the name of the intended time zone in another. Time zones are named with Continent/Region format such as Africa/Tunis. At runtime, when you need a moment for calendaring, apply the time zone to the date and time to dynamically determine a moment according to the now-current time zone rules. In Noda Time, you would retrieve a LocalDateTime and time zone, to produce a ZonedDateTime for calendaring. That means it would be better to use only date, time and time zone. [2024-02-04 12:00 @America/Vancouver] The TZ database is assumed to know any daylight saving time changes, and can re-calculate it correctly in future. There is difference with events which are not too far, and those which are far in future. >     - We should know beforehand the DST of Vancouver, or there would be > warnings. It seems more difficult for the user: maybe the "-08," should be > optional? You cannot know it "beforehand" for future, for present time, yes, and for some foreseeable period, it is close to certain, though depends of the country. In some countries by knowing their political stability, it may be very certain. >     - Case 3: After updating the tz database we would get warnings > too. There need not be any warnings as smart program could figure it out all. Condition is only that timestamps were generated with program which knows it well and not manually. > To correct those warnings, should the UTC offset be changed manually > in the timestamp? I do not think so, and that should not be work of human. > If there were 35 meetings in Vancouver throughout the year, to > change all the UTC offsets could be non trivial for a normal user: > UTC of the summer and winter would differ. >       [2024-09-04 12:00 @-07,America/Vancouver] should be changed to > [2024-09-04 12:00 @-08,America/Vancouver] >       [2024-02-04 12:00 @-08,America/Vancouver] should be changed to > [2024-02-04 12:00 @-09,America/Vancouver] As TZ database would know that UTC offset change preceded the date and time of 2023-02-04 12:00, that would be work of program, not human. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/