emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezon


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
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2

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].



reply via email to

[Prev in Thread] Current Thread [Next in Thread]