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