From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.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 UMqzHYf1zGOaAwEAbAwnHQ (envelope-from ) for ; Sun, 22 Jan 2023 09:36:23 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id 8D64HYf1zGOHBAAA9RJhRA (envelope-from ) for ; Sun, 22 Jan 2023 09:36:23 +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 38725F9E8 for ; Sun, 22 Jan 2023 09:36:23 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pJVpS-0006bp-HY; Sun, 22 Jan 2023 03:35:54 -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 1pJVpQ-0006bc-BP for emacs-orgmode@gnu.org; Sun, 22 Jan 2023 03:35:52 -0500 Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pJVpO-0008Gx-LQ for emacs-orgmode@gnu.org; Sun, 22 Jan 2023 03:35:52 -0500 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1pJVpL-00058a-LT for emacs-orgmode@gnu.org; Sun, 22 Jan 2023 09:35:47 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org From: Max Nikulin Subject: Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode) Date: Sun, 22 Jan 2023 15:35:42 +0700 Message-ID: References: <63c66048.630a0220.427bf.a5f6@mx.google.com> <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> <63c8f5a6.170a0220.ea8cf.7f96@mx.google.com> <63c9b654.170a0220.d82d2.4254@mx.google.com> <87lelxk87a.fsf@tsdye.online> <63ca5101.630a0220.b2298.3363@mx.google.com> <63cb2d0b.630a0220.f919a.6174@mx.google.com> <63cc5983.620a0220.a7d40.68f6@mx.google.com> <87r0vnhxj6.fsf@tsdye.online> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Content-Language: en-US In-Reply-To: <87r0vnhxj6.fsf@tsdye.online> Received-SPF: pass client-ip=116.202.254.214; envelope-from=geo-emacs-orgmode@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 27 X-Spam_score: 2.7 X-Spam_bar: ++ X-Spam_report: (2.7 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-0.092, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=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=1674376583; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=bnkf0NvWyWpJIWvLLDhS543srvfqCApwQfxpZflcJpo=; b=TFY6M+y1y+dWUgDAzB+PQfzARcjwxqew5mb4kpJBHcvBTCm+15vx1+vlf0voRuLT4405z3 0UsXyParrgYmOn+Qcp3TrLrWTWgffIF7aL/X8R2jMAf/6ECt9SyJC4IX/tlqAE+xiQQ66p JPM8TYJ2Z+NWiFQlOW5MygFJasaRyLcfrvyW/dxmSTwRqLUBxiT797ziOtTq8k+JkonvmX qzadrTX9j22iTjKKzkqnCS+YyBnYcG96hfLrYu6IzMjHQhhGhyhSh6g3Af+ttI0MboL3Me zu5kF0ZB0XQ4BZ5F+Z5o22hy51HDV4ugvxKaIUktcjSzmu1uhaMlPsrsNmqASA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=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=1674376583; a=rsa-sha256; cv=none; b=iT6jUmz2D5lpxN9rLyZcJYVBJQm+Bi0IyqFL68r7k7VdHKW0LiGUitH78pe7RM+iUYJZwJ WH72ALDiA77nEfc0GkG1ImOtM8+akh4QCuXHMUytC3HPjQOb0sh/SQQ+F7p5Oo1o070s2T KpGqw15UXbLxojaaV3u43d0CZakQv+ILlB95yOimWbI0Q9vWBVBMT4FO1vVQjjWkqoBsbd qbd3pMAh70dkbR+umd6xAz5Pcp53fI5l5Udku7T4vzLd6mMZPJ8mvnrqTj6sXvR//WdUVD vUexuOnTDT5QJjNjkH5evHzOtp3z3NzyLB7EHjpIgEshrfxlocpsRQ1PIF323Q== X-Migadu-Scanner: scn1.migadu.com X-Migadu-Spam-Score: 4.11 X-Spam-Score: 4.11 X-Migadu-Queue-Id: 38725F9E8 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=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-TUID: QjzB7yIcKhTT Thomas, notice that I resumed a postponed earlier part of discussion related to timestamps in the past. Offset from UTC is almost always well defined this case. My perception is that discussing timestamps in future, we came to agreement with Tom that timestamps can be specified with timezone <2024-02-22 08:29@Australia/Sydney>, in UTC <2024-02-21 21:29@UTC>, or in local timezone <2024-02-22 08:29> Now I had a hope to convince at least some participants that explicit time offset may be used interchangeably with UTC. It is applicable to timestamps in the past and to future timestamps when the person who created appointment respects remote participants, so decided to rule out DST and fix absolute time. On 22/01/2023 13:17, Thomas S. Dye wrote: > > UTC is not a timezone.  It is absolute time. I do not see any point to consider UTC too special. Both timestamps [2023-01-21 Sat 21:29@UTC] and [2023-01-22 Sun 08:29@+1100] specify absolute time. "+1100" means 11 hours, not particular location. Do you have an example of a case where I am wrong? I use the term "time zone" as a set of rules how to calculate offset at particular time moment. UTC is a degenerate case of fixed zero offset. In this sense "+11:00" is not a timezone, it is time offset. Several time zones (as set of rules) may have such offset at some specific time moments including "Etc/GMT-11" that is a timezone. >> A side note. In my opinion, *by default* timestamps should be created >> in local >> time with no offset or timezone. There are should be some preferences >> to enable >> absolute timestamps and a function to fix offsets or timezone >> identifiers for >> existing timestamp when the user realizes that they become necessary >> (e.g. >> before a trip). > > I don't think there should be a default. Unfortunately hard choice of default value or behavior is unavoidable during development of software. Consider a user who just have installed Org. Till it is explicitly configured, perhaps it is better to add e.g. clocking entries without offset or timezone assuming local time. It should be possible to change it later. >> So I do not see any advantages of UTC in comparison to time offset >> specific to >> particular time zone, usually user's local one. My vote is [2023-01-22 >> Sun >> 08:29@+1100] and not [2023-01-21 Sat 21:29@UTC] (of course, only in >> cases when >> identifiers like Australia/Sydney do not matter) with a configuration >> option >> with timezone used fix offsets in stored timestamps. > > The disadvantage of time offset specific to a particular timezone is > that the timezone offset wrt UTC can change arbitrarily. This is a > potential problem if the arbitrary change takes place between the > creation of the timestamp and the happening it identifies.  In contrast, > UTC is guaranteed not to change.  It is not a timezone, it is absolute > time, a pure continuum.  It is a requirement of occurrences. I consider the case when offset is already known because it is a time moment in the past. Besides rare corner cases offset can be considered as a part of authoritative data. Timestamps like [2023-01-22 Sun 08:29@+1100] can be unambiguously mapped to UTC. > I'm not sure offset is necessary for events, given that offset can > change arbitrarily.  WDYT?  It seems to me that once an event has been > tied to a particular time in a particular time zone that Org's job is to > take into account changes to that timezone, such as DST and arbitrary > legislation.  These changes in the event's timezone need to be > propagated through the schedule for each user, so it is possible to > synchronize local timestamps around the globe. For timestamp in the past offsets simplifies calculation of duration. Offsets may be used to fix absolute time before changing location when time zone was omitted. Perhaps I will add more in another part of this thread. After all, for a person in Berlin [2023-01-22 Sun 08:29@+1100] may tell more than [2023-01-22 Sun 08:29@Australia/Sydney].