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

[Max Nikulin <manikulin@gmail.com>]

On 23/01/2023 23:04, Thomas S. Dye wrote:
> * Kinds of event
> - No-host event :: An event that takes place at an absolute time. 
> Participants must know their local timezone offset from UTC. Example 
> [2023-01-23 06:00@UTC].
> - Situated event :: An event that takes place at a time local to the 
> event site.  Participants must know their local timezone offset from UTC 
> and the event site timezone offset from UTC at the time of the event.  
> Example [2023-01-22 Sun 08:29@Australia/Sydney].
> - [Itinerant | Traveling | Mobile] event :: An event that takes place at 
> a time local to the event site, which might change after the event has 
> been scheduled.  Participants must know their local timezone offset from 
> UTC and the event site timezone offset from UTC at the time of the 
> event.  Examples might be a regular staff meeting that takes place at 
> 9:00 AM wherever the boss happens to be, or a proposal to meet with a 
> traveler when it is noon on Sunday for the traveler. Example [2023-01-23 
> 06:00].  In this case timezone is set according to user timezone 
> preference in scope.

Thomas, I mostly agree with the set of event kinds your suggested. 
Perhaps names should be justified to have precise and concise terms in 
UI. From my point of view their value is association with appropriate 
storage format for particular timestamp.

An additional parameter (or sometimes first one to choose) is if 
explicit or implicit time zone should be used in the file. In the latter 
case the same kinds of events are possible, particular one is determined 
from a parent scope. User should be just aware what is actual time zone 
if it is implicit one.

The following concept is aside from event kinds, but might (or might 
not) be useful to present agenda, to schedule events, to implement the 
feature. Perhaps a trip may be considered as an ad hoc timezone that 
follows offsets of time in locations to visit. (Several such ad hoc time 
zones may allow to track schedule of several people, but it may be too 
complex to use.) It may be considered close to "mobile" event, but the 
purpose is not to ensure correct time of particular event. It may 
facilitate presentation of timeline during the trip.

Perhaps it is more correct to talk about how events are scheduled, not 
of event kinds. Consider Christmas and similar events. It is personal 
and local for each user. If you share your .org file (with specified 
file-local time zone) with other persons they celebrate accordingly to 
their local time. In addition they may decide that it should be pleasant 
for you to receive a greeting close to your local time.

It seems during discussion we use terms in slightly different meaning, 
so I will try to clarify my point of view.

I had a course on general relativity theory, so "absolute time" does 
make much sense for me. UTC is just a widely accepted agreement. I was 
bound to Earth rotation and accumulated some offset from more precise 
atomic clocks. UTC however currently is easiest way to perform time 
related calculations.

My perception is still that UTC is one of timezones that may be used to 
specify event time. It is a bit special since it is used as a reference 
for other time zones, so it may be preferable for global events. If UTC 
considered as an ordinary time zone then the whole set of time zones may 
be divided into 2 classes: with fixed time offset (including UTC, 
Etc/GMT+3 that may be specified as -03:00, etc) and with time zones 
associated to specific locations. Second class is affected by DST, 
changes of offsets that may be source of uncertainty. The role of UI is 
to help user to choose a timezone that is suited best for particular 
event. For events in the future often it is necessary to use a 
location-based time zone, in other cases it is UTC or anyone with fixed 
offset. When you recording current time, explicit offset may be better. 
I am still unsure what is better to use: kinds of events or kinds of 
time zones.

I agree that offset as a part of timestamp may be confusing, but I am 
afraid that significant part of affected users are unaware of UTC as 
well. That is why proper UI may be a challenging task.

Thomas, for me event kinds are less important than understanding that 
UTC timestamps are not enough achieve properly working schedule. 
Currently you see that timezones associated with locations in some cases 
must be used in stored timestamps. Have you noticed that I missed 
anything significant in your messages?