Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode)

[Max Nikulin <manikulin@gmail.com>]

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