Aloha Max,
Max Nikulin <maniku...@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
