Aloha Tim,
Tim Cross <theophil...@gmail.com> writes:
"Thomas S. Dye" <tsd@tsdye.online> writes:
Aloha Max,
Max Nikulin <maniku...@gmail.com> writes:
On 20/01/2023 23:09, Thomas S. Dye wrote:
Max Nikulin writes:
Now, if Amsterdam's timezone arbitrarily changes its relation
to UTC before the
conference takes place,
then everyone who participates in the conference must notice
this (or miss the
start of the conference).
My point is that if timestamp is stored in UTC than it becomes
incorrect in the
case of time offset change. If such timestamp is stored as
local time + time
zone identifier then application presenting the timestamp to
users will show
correct time as soon as zoneinfo data is updated.
A virtual conference is organized by someone in Amsterdam,
who sets a start
time corresponding to 9AM in Amsterdam at a date some years
in the future and
invites participants from all over the world. Now, if
Amsterdam's timezone
arbitrarily changes its relation to UTC before the conference
takes place,
then must everyone notice this? Or, should Org, from the
time the arbitrary change is
made public, simply adjust the conference time for all the
participants in the Amsterdam timezone?
Both variants are possible and a planning application should
support them. It is
matter of negotiation between the committee and the
participants. Timestamp
should be stored in UTC only in one case.
Agreed. So, IIUC, there are three cases:
1) Occurrence, where the timestamp includes UTC;
2) Event relative to user, where the timestamp does not include
UTC or a time zone; and 3)
Event not relative to user, where the timestamp includes the
relevant time zone.
I would argue case 2 is really just a specialisation of case 3
i.e. it
has an implicit time zone which is the user's local time zone.
Case 2 covers things the user wants to do at a particular time,
regardless of where they are and the time zone they are in. For a
repeating task the time zone might change from one instance to the
next. It needs to follow the user around and can presumably rely
on software to keep track of that.
For completeness, Case 3 might benefit from a procedure to
change the relevant time zone.
For instance, when the boss has scheduled time for you at 9:00
AM her time, but doesn't
know where she will be on that day.
If it is to be a fact-to-face meeting (event), implying it
therefore has
a location, you would assume your local time zone. If not
face-to-face
(occurrence), it needs a UTC offset in order to ensure same
point in
time for all participants. The boss either needs to specify the
time
zone they are referencing the 9am to or the user will need to
make a
guess, which may or may not be correct.
Or, it might be a recurring virtual meeting that the boss wants to
initiate at 9:00 AM her time, regardless of the time zone she
happens to inhabit, as might happen on a business trip. Here, the
virtual meeting is an event because the boss relates it to her own
space/time. Inconvenient for employees, but some bosses are like
that. Here, the time zone needs to follow the boss around.
My current hypothesis is that the three cases are exhaustive.
All the best,
Tom
--
Thomas S. Dye
https://tsdye.online/tsdye
