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.
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.
hth,
Tom
--
Thomas S. Dye
https://tsdye.online/tsdye
