From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.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 0IIuKdm65WOawwAAbAwnHQ (envelope-from ) for ; Fri, 10 Feb 2023 04:32:41 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id SEwfKdm65WO7bAAAauVa8A (envelope-from ) for ; Fri, 10 Feb 2023 04:32:41 +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 ACEAD353FE for ; Fri, 10 Feb 2023 04:32:40 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pQK8P-00014D-Rv; Thu, 09 Feb 2023 22:31:37 -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 1pQK8N-00013y-VL for emacs-orgmode@gnu.org; Thu, 09 Feb 2023 22:31:36 -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 1pQK8L-0000Cu-60 for emacs-orgmode@gnu.org; Thu, 09 Feb 2023 22:31:35 -0500 Received: from localhost ([::ffff:197.239.15.119]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 0000000000103955.0000000063E5BA76.000027AE; Thu, 09 Feb 2023 20:31:01 -0700 Date: Fri, 10 Feb 2023 06:29:13 +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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <877cwse95m.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-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=1675999961; a=rsa-sha256; cv=none; b=RbMlE69/HvJUNPIZBQgB1E5V7CD4Duv2om89xKZ+LYmUBXQNPRM4y2MAcKavygHx/l8dO1 PM8fA92wrjY3ilyC4YalbWrUlYk0XSL2dkIFsy9rh5CpG7aAfIyk2Z0wDapkHmd+uoGtGk Bd7J/LAxeZ+UcMgeccHylEvnDG3pCSLN7c8cto4s/+ogP3O47LMIeV+HCZbVCjLTmHKIwy QANfVGM3Qqd/5MSdvrUPWk6DOVir0QtkgwchxvDYmGQz24CSkk0BOmYSr6WisoUzmlTIRR 60nIsLSw2G/vSpdtblgJyc6tRi0hr7nDbU0GkNffgiu7460aYaMP4Z2WtWLW4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1675999961; 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=VpLp+u4UcsLrh40nArDnRK+kWFBWLdWhoXkusU8m1zA=; b=jf8Op4bTwvoomwjyzL+UgqaBUwgz44nSxHZ8UZvcxlksmVnOqg+pOFZyhpgDFipLdIS/+p AIE7WlTUemWSWJUsM9a/1ep221ImuGYOGTOGigij31AxeMSHi3122HNQHbxyMCEyexAyib 3NwTwiNGL1dUXNPuqP7Dg3I/RF3FiVrIperd+Szf2EZPCDW7fR+X5szcHA1ClhnaLqQVyl u7kedvQkxRZB5a9VfFwT8Aty8NSvKxwy5IuZYCs7M2Cg9SCjJQkh214x7UOeHGkV9pm9ao vsiLh6tPpv31c/mpzd0w3W03YPOo4j+OQ0L8r/bK636uyP1DoVZrI8MvAxXYCQ== 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: scn0.migadu.com X-Migadu-Spam-Score: -2.40 X-Spam-Score: -2.40 X-Migadu-Queue-Id: ACEAD353FE X-TUID: KJCwOgatZqdm * Ihor Radchenko [2023-02-08 13:36]: > > Is it Org as program? > > > > Or is it human? > > Both. > > The idea is to ensure exact point of time relative to UTC. > For example, when you want to schedule something exactly 10024 hours in > future, regardless of time zone changes. I got it, thank you. iCalendar allows UTC time. If you have UTC time, you need not have UTC offset, as that is NOT what other programs are doing. My recommendation is follow what is successful. If you wish to use UTC time, use it, but no need to add offset as it will be confusing. Timestamp is either in UTC or in other time zones. UTC time has no offset. If you start adding in Org "fixed" time with UTC offset, that is a new type of timestamp, as it is not common in world. Here is suggestion: ------------------- 1. Convert local time timestamp to UTC 2. Add 10024 hours 3. Provide timestamp in UTC Also look at this reference: https://icalendar.org/iCalendar-RFC-5545/3-3-5-date-time.html ,---- | The form of date and time with UTC offset MUST NOT be used. For | example, the following is not valid for a DATE-TIME value: | | 19980119T230000-0800 ;Invalid time format `---- As with the above format, author would maybe think it is alright, but in general it is confusing. If author wish to specify UTC time, then no offset shall be used. > The same can be done by specifying the timestamp in UTC directly. That is simplest. > > Another program in future, and human, must know did the organizer of > > event, had in mind: > > I would like to remind you that timestamps are not necessarily used for > meetings. And not always shared with other people. Ok, and I have asked you to provide practical examples. Calculation of time shall not be made for sake of sole calculation, but for human and by considering use application. Timestamps for past time, like for logs, I always store as UTC time in database, with time zone (which does not mean that time zone is stored, but displayed in local time zone). However, future time to be coordinated with people, anything human related, it has to be stored with date, time, and time zone in separate fields. That way program in future will understand it. Timestamp is in general always considered past, not future. That is where the word comes from, the "stamp", if you stamp something, it is on paper, when it was done. It is not about "When it will be". 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 We have to distinguish in Org what we are doing here, and meaning with "timestamp", as in Org context, timestamp is more than just time when something occured. In Org context there is new type of "timestamp" which is meant for future. Timestamp for past -- should be as accurate as possible in general applications. Practical example of a timestamp: I enter person's contact details, the moment I enter such details, the timestamp is created. It is not 100% accurate to the event that really has taken place, as computer user need some time to write first name, last name of person, it is "about". But for the sole entry of the data in database, that timestamp is pretty accurate. Timestamp for future is not really timestamp, it is intended time, in many applications it cannot be accurate. The last example on the page: https://icalendar.org/iCalendar-RFC-5545/3-3-5-date-time.html gives good clues how to specify date and time in future. > > 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. > > Sorry, I do not understand what you are trying to explain here. Would > you mind showing an example? The above quote came from explaining that you should not use "time offset" to designate UTC time, as such offset will be mistaken in future for "UTC offset". By doing that you are creating new type of time representation that is not used anywhere else (for future purposes). Example ------- 2023-02-01 12:00 -08 @SomeTimeZone would mean that UTC offset at that time and date was -08. One can derive UTC time easily and it will be accurate. 2033-02-01 12:00 -08 @SomeTimeZone, means that one should consider that @SomeTimeZone in future to first derive the UTC offset, as -08 can only be taken vaguely, you cannot know if it will remain same in future. I would assume that author wants us to meet at 12:00 o'clock of that @SomeTimeZone, no matter the UTC offset, as that one will be calculated in future time. If time zone changes, the TZ database would tell what is the new time zone, and calculation is still expected to be good for future. Time stamp like this 2008-04-29 02:53:24.796564+03 is past time, with +03 UTC offset. Past UTC offset does not change, it is accurate. It was how it was. 2030-02-09 12:00 is future time. I need no offset, but time is floating as it is not bound to time zone. 2030-02-09 12:00 -08 @UTC -- this time CANNOT be said to be "fixed UTC" time for reason that UTC time is not represented with UTC offset. It is either UTC time or time zone time with UTC offset. Cannot be this and that. 2030-02-09 12:00 -08 @SomeTimeZone -- this is alright 2030-02-09 12:00 -08 @UTC -- not alright, as other programs do not represent time with UTC time zone with offset. That offset is offset, does not make it "UTC offset" as such is not used with UTC time zone. Only with other time zones. For future designation, in database is better, and also confirmed by references, to enter designation in separate fields, like this: TIME-DATE: 2023-02-09 12:00 TIME: NIL TIME-ZONE: @SomeTimeZone It becomes clear what is intended time zone, and what is date, time intended. The above representation is not enough clear, as what if it is only date intended? Maybe this would be more clear: DATE: 2023-02-09 TIME: NIL TIME-ZONE: @SomeTimeZone And this: DATE: 2023-02-09 TIME: 12:00 TIME-ZONE: @SomeTimeZone The UTC offset matters not for future as it may change, and it has to be calculated from @SomeTimeZone definition in future. Because fields are separated, it can become clear what is intended. 2023-02-09 12:00 -08 @UTC -- is not clear as fields are not separated, when you say that such timestamp should be UTC fixed time stamp with offset, because offset is not used with UTC, it is confusing, and you are showing 12 o'clock, which is contradictory to using offset. You mean UTC offset, but definition of UTC offset is not that it will remain fixed in future. Follow example of iCalendar which says that such designation of UTC time plus offset would be invalid. > > 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? > > From syntax we are now defining, XX takes priority in @XX,YY. That is wrong, for the above mentioned reasons, references. People who designed iCalendar, had some reasons to tell you why is such timestamp in future invalid. If you intend to say UTC time in future, do not use offsets and time zone. It is contradictory. It is either UTC time in future, or it is time with time zone in future. While person could tell about UTC offset in future, such is vague as it can change. And if you are defining anything, for reasons that fields are not separated and not marked, user cannot know what you mean: 1. [2024-02-04 12:00 @-08,America/Vancouver] you define that @-08 has priority, OK fine, but how does user sees that? Only by reading documentation? 2. You wish to say it will be future time of 20:00 o'clock, but time zone definition can change, so if it can change, why use time zone definition? 3. UTC offset is displayed for past, as such time is accurate, but if you display it for future, be aware that it is wrong for reason that you cannot know the UTC offset in future without time zone. Just display UTC time. Offset is not relevant, it will be displayed to every user in their local time anyway, once they get UTC. 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. 5. Hypothetical example of timestamp for future, with "tag" to tell what you mean, maybe with "!": [2024-02-04 12:00 @-08!,America/Vancouver] where the time would be stamped with "!" and that would mean that time "12:00" would be disregarded, but offset of -8 hours from UTC would be used. However, it remains confusing by using offset. > > 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. > > I am sorry, but I don't understand what you mean by UTC-FIXED. You mentioned it, you wish to have offset and to remain UTC fixed. And UTC is not fixed, it is either UTC without offset, or time zone with UTC offset. But if you do wish, you have to make "tag" somehow, for computer program to know what you mean, "UTC-FIXED" is only hypothetical tag. > >> > 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 > > It is sometimes easier to define UTC time +offset instead of doing an > extra conversion in your head. I hope you understood the difference. Providing UTC time plus some offset is inconclusive. It is idea that is not aligned with what international community is doing. Provide UTC time. Or provide time zone plus UTC offset. Your idea as such is alright, but is individual, and it has to be coordinated with what other programs are doing. Otherwise it become confusing. Remember the reference on iCalendar, "not do do that". iCalendar provides either UTC time, or date, time and time zone. > > 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 > > The problem being addressed with @+08,!Asia/Singapore is possible future > change in time zone. That problem is solved, if you use TZ database: - in case of change of time zone, the TZ database will provide future adjustment, there may be new name of new time zone. - in case of change of UTC offset, the TZ database in future will know it. > Imagine a yearly meeting you attend at [2024-01-02 19:00 > @Asia/Singapore,!+08] while living in Europe/Athens (UTC +2). Over > the years, you are used to meeting being held 13:00 @Europe/Athens > time, and you do not really follow Singapore government politics on > time zones. Then, one year Singapore government decides to switch > the time zone to UTC+7. Your TZDB will get updated, but you may > still miss the meeting even though Org agenda will display the > correct new local meeting time of 14:00 @Europe/Athens. It would be > useful if Org could notify the users about such changes. You are explaining situation with 2 timestamps. It is either the timestamp: [2024-01-02 19:00 > @Asia/Singapore] or Europe/Athens timestamp. Once you have the timestamp [2024-01-02 19:00 > @Asia/Singapore] I expect that such may be seen in future Org program, in local time. To see it in local time program would know the future UTC offset, and convert it to local time. I will never miss the meeting provided program consults TZ database. But if I have 2 timestamps, that is different situation. You need no UTC offset for future time representation. Also good to read: https://engineering.q42.nl/why-always-use-utc-is-bad-advice/ Also good to read: https://swizec.com/blog/saving-time-in-utc-doesnt-work-and-offsets-arent-enough/ where it says: The correct way to send "Wednesday at 3pm in San Francisco" looks like this: { ... timestamp: { time: '2022-03-16T15:00:00` tz: 'America/Los_Angeles' } } They also do not provide UTC offset. And none provides UTC time with offset. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/