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 KBrZJTPuy2NN3AAAbAwnHQ (envelope-from ) for ; Sat, 21 Jan 2023 14:52:51 +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 OIWkJTPuy2OOUwEAauVa8A (envelope-from ) for ; Sat, 21 Jan 2023 14:52:51 +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 146B813E55 for ; Sat, 21 Jan 2023 14:52:50 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pJEHn-00024u-FK; Sat, 21 Jan 2023 08:51:59 -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 1pJEHj-00024H-BD for emacs-orgmode@gnu.org; Sat, 21 Jan 2023 08:51:58 -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 1pJEHg-00061v-EI for emacs-orgmode@gnu.org; Sat, 21 Jan 2023 08:51:54 -0500 Received: from localhost ([::ffff:197.239.14.92]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 0000000000103951.0000000063CBEDFA.00004F9F; Sat, 21 Jan 2023 06:51:53 -0700 Date: Sat, 21 Jan 2023 16:50:37 +0300 From: Jean Louis To: "Thomas S. Dye" Cc: Tim Cross , Ihor Radchenko , Daryl Manning , rjhorn@alum.mit.edu, emacs-orgmode@gnu.org Subject: Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda Message-ID: Mail-Followup-To: "Thomas S. Dye" , Tim Cross , Ihor Radchenko , Daryl Manning , rjhorn@alum.mit.edu, emacs-orgmode@gnu.org References: <87r0vtiks0.fsf@localhost> <63c671c0.a70a0220.61aa5.56b8@mx.google.com> <87fsc88aq9.fsf@localhost> <63c7dd3d.170a0220.6b4d6.f84f@mx.google.com> <877cxk6oeu.fsf@localhost> <63c86454.170a0220.80970.652d@mx.google.com> <87wn5jf2to.fsf@tsdye.online> <87sfg6fq8u.fsf@tsdye.online> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <87sfg6fq8u.fsf@tsdye.online> 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-Seal: i=1; s=key1; d=yhetil.org; t=1674309171; a=rsa-sha256; cv=none; b=mBQwrRrZckiIfkoT1C1GLfQ9n3vWP189g6tNHZzDUZq2IwE/F9UFoTWYNHGBtsVbY/kq3n UJHH8HIMMNIGTLF23wjbt/R4qvRssKMmQr2LHtmbvk3U3vL0i9MgWYoD/11coYxo9rnOfR LHVAaFJKNeIx4AsMrMsbKre79Dnodp5Uqku/FdUWXPVZNQz8E1eBJBW1OupCMZ8VjG7IDF T8crU1M5sLV2aJXkq25K/5kjL9mlhJrsvkTHW2w4qruOw1/oIzMhLAa4PpmLwY8jvl6Bu7 od+P0TOHoyRdvwJfmLSITIricfulnqOesfK9TPR9NR0ny5Bmo3gkYgrqnivvEA== 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-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1674309171; 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=pXAHmxwLZSJXgWXx5jOW6LoMYbq2gt3r+46Ij3iZgEk=; b=mPeHGp/Tt6c0IEmLKxMBTi+Bg5Pht9KQ6BlcIq7IEV6ojLa2o+1/6eXXX8jJFCpKCcdvM5 y1HgrXtCPenkBDOYM2lCLRambw30vOSJNYUmHgfSDlQKq3VxiitMEyMWvwLt+haHnOO3Xa dJx8z1KyAQiZ6ORxlWlnfXZ4X2ok4XQJ2nWSXvTbxbxJA2HKA2TiC2PZO6MxkR9A2qYAP8 kumz6Al6hhQzKaD1oAmJaqI91Lu9c2+ZxfDEo1nkyxqIBwQPkp4nzmj17N1DulHtsXSmfY xrouygViqGXN7L1vtaxg3MWRe3pvC94XQ3sLBpvFHAAvL5BAx7AALEBfkIE6TQ== X-Spam-Score: -1.91 X-Migadu-Queue-Id: 146B813E55 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-Scanner: scn0.migadu.com X-Migadu-Spam-Score: -1.91 X-TUID: ak6PVZQtKxSf * Thomas S. Dye [2023-01-19 19:23]: > Only occurrences require absolute time, UTC. Events do not. They follow > the user's space/time. > > > > > Org in this state can't handle such things. > > > > > > Org can do the useful thing: translate the UTC timestamp into local > > > time and > > > report both UTC and local time. User will be able quickly to > > > determine if > > > local time is incorrect for some reason, such as DST or travel. > > > > Other way around, it has to translate time stamp into UTC time in the > > first place. > > Yes, to store the time stamp, Org must take it from the event time of the > user and translate it to UTC. When reporting an occurrence to the user, > then Org must translate from UTC to the user's space/time. User might have > a toggle, like pretty entities, that either shows UTC or translation to > user's space/time. That is right. I have stated same. How do you want Org to know that user's time is in X time zone? It means, that new settings, variables, functions, must be introduced to handle it properly. Timestamp like this one: <2023-01-21 Sat 09:55> at HTML export will be from 95% and upwards incorrect. To be correct, time zone designation shall be placed in HTML export. User could be in South America, not in London, that exports it. Time zone UTC does not apply for South America. Representation is wrong. When you say that Org must take it from the event time of the user, that means that Org must take some parameter to understand what time zone user was. That means involving functions for export, or sharing of Org files. In general, we speak about representation. You may start making distinctions between "events" and "occurences", but technically we speak of time stamps which lack relation to time zone in Org. Whatever you "time stamp" without time zone, representation of it in other time zone becomes difficult, as it lacks the fundamental designation of time zone where it was recorded. And it does not matter if user records time zones in UTC, or other time zones. What matters is designation of time zone. Parameter must exist, something like "#+TIMEZONE: PST" As that property is then used by programs to understand time zone of the file, or task. In general computers store things in UTC. We are repeatedly discussing what is already agreed before decades. What we need in Org is representation in time zones. All programs work by storing in UTC time zone: ---------------------------------------------- Observe file system: $ touch MY-FILE ~ $ ls -l |grep MY-FILE -rw-r--r-- 1 admin input 0 Jan 21 16:21 MY-FILE ~ $ TZ=UTC ls -l |grep MY-FILE -rw-r--r-- 1 admin input 0 Jan 21 13:21 MY-FILE UTC is basis for time. There are time zone libraries and calculations. All that one has to think for Org is representation in familiar local time zone. > > Expecting that all user among so many various time zones write their > > time stamps in UTC is not reasonable. Org users are advanced, I know, > > but majority of note takers with other applications will not even > > think of different time zones, it is surprise they get when dealing > > internationally. People are not ready for calculating or even viewing > > their own time in UTC time zone, unless they are English or Icelandic, > > Portuguese, or Africans in parts of the West Africa. > > > Org should translate from the user's space/time to absolute time, UTC. That is right. So far I am telling same, maybe we think is not. > The user has to tell Org what is the space/time relationship to > absolute time. That is right. I said that long ago. The way to "tell it to Org" is at export, for Org to recognize it in terms of Lisp (or time-stamp-zone heading-time-zone file-time-zone system-time-zone) whatever comes first, then at any sharing of Org directly to people in other time zones, and in other uses cases. Such sharing and export must have variables that help to interpolate time properly in other zones, and Org shall recognize that time stamp displayed is not in local time zone and ask user if to show or translate time stamps. Many options exist. Best is when it is automatic, as that is usual in many other software. > Org might use the timezone machinery to suggest a space/time > relationship to absolute time, and it might warn the user when the > user's suggested relationship differs from the value reported by the > timezone machinery. That is right. > > > Storing timestamps in UTC solves the interval problem Ihor > > > raised. Intervals always make sense in absolute time. Moving them > > > to event time leads to the insanity Ihor mentioned. > > > > The other way around. Assuming that time stamps are UTC raises > > problems for all other people: > > https://upload.wikimedia.org/wikipedia/commons/8/88/World_Time_Zones_Map.png > > > > Org now does not support time stamps, right? > > > > So people write timestamps in their own time zone! Is it right? > > IIUC, Org currently stores events, which are relative to the user's > space/time. This works for events, but breaks for occurrences, which > require absolute time, UTC. You have got that theory from a book, it is different philosophical concept that somebody finds useful. Though it is not directly related to the problem that Org does not have time zone representation. To solve the problem first one has to define it. You can call time stamps as you wish. How you call them it does not matter. You can call it "event" or "completed" or "deadline" or "scheduled" or "occurence", those are types useful for user. Whatever they are called, local user shall get any time displayed in local time or with proper time zone designation, so that time may be displayed or converted to local time. Nothing will break what designation get introduced in Org. I mean to introduce variables analogous to following logic: (or time-stamp-zone heading-time-zone file-time-zone system-time-zone) > > Thus time stamps already have their time zones, it is just not > > recorded in Org file. > > Events don't need a time zone, only occurrences need absolute time. When you introduce words that have different meaning in different context in your book, you can't expect that it will be generally expected. No matter how you "name" the time zone, all time you write in your computer beyond Org is already written in your local time zone. Any time user designates in notes, calendars, etc. is already in local time zone. Any time displayed to user is in his local time zone. Follow the steps! It is that simple. If event need time zone or not, because you think it does not need, many others may disagree. Why argue how you call that time? Just follow the steps to display it in local time zone, and any time to accept as UTC, written in local time zone. Any time always is related to UTC in computers, there is nothing unsolved. Finally users who do not want to fiddle with time zone shall also be left to do so. Org could also give to user to designate how time stamp should look like, by using format that user may specify: %Y/%m/%d - %H:%M %Z Which could display: 2023/01/21 - 16:40 EAT by using: https://linux.die.net/man/3/strftime instead of trying to satisfy every possible way of formats of time stamps (congratulation for that). 1. System time is always in local time 2. Org may introduce TIMEZONE property as already discussed 2. Org may introduce property "#+TIMEZONE_FORMAT" like "%Y/%m/%d - %H:%M %Z" 3. Any time stamp would use that format Translation of timestamps to other time zones by using that format are easier, than trying to satisfy every person on planet. For Org, which is not even demanded apart from us here. > > :TIMEZONE: EET > > :END: > > > > or inside of the time zone. > > > > When such heading is read in Seattle, Washington, Org will tell to > > user or ask to translate it to PST time. > > > > In such translations, EET time is first converted to UTC, for reason > > of using system libraries, and not complicating Org, and then > > converted to PST time zone. > > The Org user in Seattle would either see UTC or toggle to see UTC translated > to Seattle space/time, assuming user set space/time relationship to UTC > correctly. If not, then Org should warn user that the specified > relationship differs from the one suggested by the timezone > machinery. Why would you see UTC if you are not in UTC time zone? It is not useful. But yes, user could or should be able to see it in any time zone, but without much focus on that. Users can change local time zone, so let them do that if they want, but displaying local time zone is decades long standard in computin. I have various software here, none of it asks me to look at UTC time. UTC is for computer to calculat, not for human to see, it is not useful for human unless to those who happen to be in that time zone. All computer software calculates to and from UTC when showing local time zone. We basically speak of "calendar" applications where users need to share various times. Then why not follow what is already successful elsewhere? 3.2.19. Time Zone Identifier | iCalendar (RFC 5545) | RFC Specifications: https://icalendar.org/iCalendar-RFC-5545/3-2-19-time-zone-identifier.html This parameter MUST be specified on the "DTSTART", "DTEND", "DUE", "EXDATE", and "RDATE" properties when either a DATE-TIME or TIME value type is specified and when the value is neither a UTC or a "floating" time. Refer to the DATE-TIME or TIME value type definition for a description of UTC and "floating time" formats. This property parameter specifies a text value that uniquely identifies the "VTIMEZONE" calendar component to be used when evaluating the time portion of the property. The value of the "TZID" property parameter will be equal to the value of the "TZID" property for the matching time zone definition. An individual "VTIMEZONE" calendar component MUST be specified for each unique "TZID" parameter value specified in the iCalendar object. The parameter MUST be specified on properties with a DATE-TIME value if the DATE-TIME is not either a UTC or a "floating" time. Failure to include and follow VTIMEZONE definitions in iCalendar objects may lead to inconsistent understanding of the local time at any given location. Thus in Org, we want to avoid also: "inconsistent understanding" at any given location. That is why only iCalendar export supports the conversion. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/