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

[Thomas S. Dye]

Aloha Max,

Max Nikulin <manikulin@gmail.com> writes:

> Let's consider the following timestamp
>
> [2023-01-22 Sun 08:29@+1100]
>
> "@" is unimportant here, I take it from Ihor's examples. This 
> timestamp is from
> the "Date:" header of your message. It is not UTC, but in my 
> opinion it is
> equally precise (disregarding seconds) to a UTC timestamp.
>
> Would you prefer to have timestamps in your files in such form 
> or as
>
> [2023-01-21 Sat 21:29Z] ([2023-01-21 Sat 21:29@UTC], [2023-01-21 
> Sat
> 21:29@+00:00], etc)?
>
> Maybe [@1674336588] (seconds since epoch)?
>
> I consider storage format as a part of Org UI, so I believe that 
> [2023-01-22 Sun
> 08:29@+1100] with offset of the usual time zone is more 
> convenient than
> [2023-01-21 Sat 21:29@+0000]. Overlays may present your local 
> time in both
> cases, but raw value with usual offset is easier to comprehend.
>
> When a file is shared by a group of people spread across the 
> globe, they are
> free to use UTC or another fixed timezone or do not care at all 
> concerning
> particular offset, it just should present.

UTC is not a timezone.  It is absolute time.

> Postgres has a reason to insist on UTC since timestamps are 
> stored in binary
> format as microseconds since epoch. It is important for 
> performance and there is
> no room to specify offset. Org has to parse timestamps from 
> strings anyway, so
> it is better to use format more convenient for humans.

Agreed.

> 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.  If I'm correct that 
occurrences, events relative to user, and events not relative to 
user exhaustively classify the possibilities, then Org should 
insist that timestamps conform to one of these three 
possibilities.  If the classification is complete, then there is 
no need for a catch-all default.

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

All the best,
Tom

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