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

["Thomas S. Dye" <tsd@tsdye.online>]

Aloha Max,

Max Nikulin <manikulin@gmail.com> writes:

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

Agreed, offset relative to UTC is 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.
>
It is independent of the legislative tampering (DST, etc.) that 
makes timezones difficult to work with.

> 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?

No, not if +1100 is relative to UTC.

> 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.
>
This confuses me.  Calculating offset relative to a timezone, such 
as HST, refers to space/time and yields an event.  Calculating 
offset relative to UTC does not refer to space/time and yields 
absolute time.  IMO, using "time zone", which typically refers to 
a region of space/time, to refer to a set of rules that might 
yield absolute time invites the confusion Ramsey was hoping to 
avoid.

>>> 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.
>
Is there some way for Org to identify when it is likely that user 
has not specified time zone?  If so, a query might be useful.

>>> 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.
>
Yes, if +1100 is relative to UTC.  If not, then it assumes a 
timezone library that correctly includes the past time.

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

I'm not sure to follow this.  IIUC, the timestamp with offset 
refers to absolute time, whereas the timestamp with the 
Australia/Sydney timezone refers to a region of space/time whose 
relation to absolute time is fixed for any moment, but potentially 
variable over time.

All the best,
Tom

-- 
Thomas S. Dye
https://tsdye.online/tsdye