From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id KMvvEoHN02Pw4AAAbAwnHQ (envelope-from ) for ; Fri, 27 Jan 2023 14:11:29 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id 4GDZEoHN02OtvwAA9RJhRA (envelope-from ) for ; Fri, 27 Jan 2023 14:11:29 +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 E9E8E20940 for ; Fri, 27 Jan 2023 14:11:28 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pLOVI-0007yh-Nf; Fri, 27 Jan 2023 08:10:52 -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 1pLOVH-0007y9-Tv for emacs-orgmode@gnu.org; Fri, 27 Jan 2023 08:10:51 -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 1pLOVF-0002f8-Q8 for emacs-orgmode@gnu.org; Fri, 27 Jan 2023 08:10:51 -0500 Received: from localhost ([::ffff:102.85.186.8]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 000000000010394C.0000000063D3CD5B.00007DB3; Fri, 27 Jan 2023 06:10:50 -0700 Date: Fri, 27 Jan 2023 12:54:02 +0300 From: Jean Louis To: Sterling Hooten Cc: "Thomas S. Dye" , 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: Sterling Hooten , "Thomas S. Dye" , Tim Cross , Ihor Radchenko , Daryl Manning , rjhorn@alum.mit.edu, emacs-orgmode@gnu.org References: <63c8f5a6.170a0220.ea8cf.7f96@mx.google.com> <63c9b654.170a0220.d82d2.4254@mx.google.com> <87mt6e86sr.fsf@tsdye.online> <63c9d976.620a0220.a7d40.113b@mx.google.com> <87tu0mjb24.fsf@tsdye.online> <63ca1283.170a0220.5bc81.0fdd@mx.google.com> <87pmb9k8oi.fsf@tsdye.online> <3035CDD5-41DD-4516-9E4E-9E0DF16BE2E0@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3035CDD5-41DD-4516-9E4E-9E0DF16BE2E0@gmail.com> 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: 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-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1674825089; 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=KNExnuYIYg6DlLSi6tBGYIgXbTZBKyr4fjJsMp3h8L8=; b=rLp6AkpDjzqz6qJwoYkyAc1xAJFve8Guo9l2ZQN27fznWDlBElSU8lT2/wfIjBchV6+JP6 HIDMios9pLdEqc9xnOqECEoUu9T4GnnVWmAAoRxoluaJ18ou74mRJKQ0tmLu8p4UvXPYzf 9yGOv/oI32Knrj+CIgdWL+FPZsxNCKDbze22Nb7Ozuo/1JM4o7+IP90L1Ayt1YwfP/b7dd 5i/jXAHrl6ntRXHuuplSlSVN6O9k6ZqTKS6uXlfWxgbLA9Wq7RpPezIWAtFV16JCmFLrQt MtFglt7s5jCDQ1gAq+MUWgO99PvQtDhvC1GyW8GAHf9I+gipQrH3cYVEs7Dfzg== 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=1674825089; a=rsa-sha256; cv=none; b=sRSyYKcdJQpns1T0M7+Xfc/7dqCWpfyrPi44LEaGBhTKUjmiziXqQGZWG9scXYo+PsBJJ/ oqkwUnqiR06urhnGoRuve9GLvGJMjbhIU6JKX4e5kZMzxDRW0y5LoVxbJFH1ZqTpjJpk06 uaq/tTAVic0c8hpX53SsyUXQ05mkBp0Bn401T7oXGYmpO7Rs/1S6pDdff6XV5Ao1tHkidY COKn3/F09NIOQTMpxxW9Sv7L3QBYjnxuwIW3KJLKFrxKl+yY03EKTIijAevEGVN9hcAGc4 zvoF2JLir4SkDhyZuAWzsKG223ldgbSnztsno9QJp98yeEHeImlPWrTnl4qFRg== 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.87 X-Spam-Score: -1.87 X-Migadu-Queue-Id: E9E8E20940 X-TUID: k+noxkTTwKo5 * Sterling Hooten [2023-01-27 09:06]: > Offset > Constant duration difference between times of two time scales > (ISO). i.e., a quantity to combine with a time scale to produce > a wall time. e.g., Nepal uses a +5:45 offset from the UTC time > scale. I would be careful calling it constant as time offset is changing depending of daylight saving time. It is not constant. Time offset time stamp may be derived from time zone time. I am sure about this. Time zone time stamp cannot be unambiguously derived from time offset. I am mostly sure about this. > What kinds of representations would a calendar system capable of > handling timezones require? > > • Instant (fixed) > • This is referring to an unambiguous moment in time > • e.g., 2007-02-03T05:00:00.000Z > • Offset (fixed) > • This captures the idea of "when did it happen for the person who > made the observation" > • e.g., 2007-02-03T04:00:00.000+01:00 Offset is not that fixed, maybe from viewpoint of storage as maybe it is considered fixed in it's representation, but you have to keep in mind that time offset by it's definition is changing itself, suddenly, depending of daylight saving and time zone. I am trying to find well described reference to read, try here: Time Zones vs. Offsets – What's the Difference? Which Is Best?: https://spin.atomicobject.com/2016/07/06/time-zones-offsets/ ,---- | Putting It All Together | | Given a time zone and a UTC time, you can know the offset—and | therefore the local time. Given a local time and an offset, you can | know UTC time, but you do not know which time zone you’re in (because | multiple timezones have the same offset). Given UTC and an offset, you | can know the local time. Given a time zone and an offset, you don’t | know much. That’s why a calendar systems work with time zones, | offsets, and UTC; we need the offset to go from local time to UTC, and | we need the time zone to go from UTC to local time. `---- > • Instant with explicit offset and zone (fixed) > • e.g., 2007-01-01T02:00:00.000+01:00[America/Chicago] > • Zoned local date time (floating) > • Tricky, requires decisions about how to interpret timestamps after > political changes. > • e.g., 2007-01-01T01:00:00.000[America/Chicago] For calendars it is good to follow recommendation Internet Calendaring and Schedulingn Core Object Specification (iCalendar) iCalendar - Date and time format: https://en.wikipedia.org/wiki/ICalendar#Date_and_time_format In other words it is good to follow what other successful applications are already doing. For example, if you open Evolution calendar in Gnome: evolution -c calendar and make task, and save that task as iCalendar, then you can see what time stamp format is used there for exchange purposes. Representation for user using Org file is different from representation for sharing purposes, as user already (mostly) have specified local time zone on this computer, while sharing object such as iCalendar file must take that information of local time zone and store it unambiguously. > I claim that before dealing with the nuances of calendar appointments, > repeating events, agenda displays etc, that Org must first support > fixed/absolute time instead of just floating time. Parameters needed to make it fixed are already in computer, only disconnected. changing this time stamp for Org: <2023-01-27 Fri 10:18> to something "fixed" would break Org compatibility for past Org files. While new unambigious time stamp formats may be introduced, the way to go is with past time stamps is to understand the time stamp for representation and calculation purposes by using OR logical function: timestamp-time-zone OR heading-time-zone OR file-time-zone OR system-time-zone as by using those, for now still disconnected parameters, one can get the fixed time for representation purposes (Org export or sharing) or calculation purposes (on local computer and by using some shared Org objects). > Without some basis time scale the conversions from time zones and > offsets to some incremental time point is impossible. Resolving this > prerequisite will also simplify the timezone discussion because we > won't be mixing calendar issues with time issues. I guess that OR consideration above may remedy it and keep past compatibility while expanding more specific time stamp as option. > What would a roadmap be? > > • Design and implement an absolute and offset timestamp system > • Decide on a time scale > • Decide on a format and syntax > • Implement instant timestamps > • Implement offeset timestamps > • Design and implement the time zone aware calendar system This is a > separate project. Sounds complex to me and over board for program that tries to define data type by using simple text written ambiguously by many people. > What format and syntax should Org use? > > A heretical suggestion: We should abandon the day of week abbreviation > and use a new format. Day of week abbreviation is useful. Full day is even more useful. Removing what is useful is not useful. There is no calendar application that I know that does not specify days of week. > The current format generates a three leter abbreviation of the day of > the week [2023-01-25 Wed 12:12]. I suggest supporting this as a > legacy/simple format but switch to a format/encoding like > [2023-01-25T15:13:42Z] for the new system. Which format is more useful for people? I find [2023-01-25 Wed 12:12] more useful, rather than the other one, for reason that it has clear date, day of week and time. And I always consider that Emacs packages like Org shall be designed to be useful to majority of people, rather than to few who may have the idea very right, but not comforting the majority of people. There is no calendar application that I know that by default uses UTC format, which representation is of course contradictory to large majority of time zones and to people got used to, to display their time in their time zone. > Specifically I'm advocating for an extended ISO 8601 format, > compatible with expanded dates and Level 2 of the EDTF, with some > (bracket?) notation surrounding it such that Org can parse the > syntax as a timestamp. I advocate further for the use of durations > and repeating intervals to follow the same standard format. Thus > instead of a range being formatted as: > > [2023-01-25 Wed 13:57]–[2023-01-26 Thu 13:57] > > it would be: > > [2023-01-25T16:57:42Z/2023-01-26T16:57:42Z]. Such representations should not become default to users, but used in representation, or sharing, or re-writing of time stamps by user option. Using such time stamps by default in Org file is confusing for people and showing time which is not their time to majority of people. I am surprised and in same time disappointed, that your analysis leads to conclusion that users should represent their time in UTC. > What are the problems with the day of the week in existing format? > > • The day of the week is redundant information and can be rebuilt from > an ISO date Any user who wishes to display a format with the day of > the week can do so. It is redundant or who? Is it redundant for majority of Org users? Maybe it is reundant for you? For some people? Do you know for who? I never even heard some user here complaining for day of week representation. Let me add one big fricking LOL here. Any user who wishes to do anything could be left to program it alone and do what they wish. But programming should be useful to people by majority of demands and wants. > • It's a nonstandard format The statement above miss the context. Non-standard where? How? In which context? In context of Org file is prime standard. In context of Evolution calendar it is not standard, but neither the graphical representation of a task in such calendar is standard. Program's representation of time is NOT REQUIRED to be standard, rather it shall be useful to user using the program to understand the information. In other words, representation shall be simple and readable, understandable! > Although the Org documentation says that the timestamps are > "inspired by the standard ISO 8601 date/time format" the use of a > day name is not contained in the ISO specification. Being inspired does not mean "conforming to ISO 8601" There is distinction, different context, of using time stamps inside of Org file, and different context of "worldwide exchange and communication of date and time related data", see ISO 8601 purposes. I fully agree that in exchange or sharing of date/time information, Org program should sometims use ISO 8601, but not in all exports. For example in HTML export it is enough to say time and time zone. But some people like to export it in ISO 8601. Such considerations could be user option. Right now HTML export is ambiguous as it does not have time zone. The usage of ISO 8601 should rather depend on method exchange or exporting. But it should not be user's representation, as user is not a robot, or program that is supposed to read computer-meant time stamps. And you forgot to list disadvantages of making Org for robots, not for human. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/