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

[Thomas S. Dye]

Aloha Max,

Max Nikulin <manikulin@gmail.com> writes:

> 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.
Agreed.  Another idea for the mobile event is "variably situated 
event".  I don't doubt that better terms might be proposed.

> 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.

I was trying to capture this in the timestamp, where an explicit 
time zone is indicated and an implicit time zone is simply a date 
and time.
> 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.

An alternative would be to have headlines for each stop on the 
trip, each of which has a #+TIMEZONE property.  Under each 
headline would be subheads for events, each with a timestamp for a 
"mobile event".  Org would let me toggle the times of these events 
relative to my current location, the event location, and UTC.

> 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.

In the first case, "Open Christmas presents at 8:00 AM", the event 
would be variably situated because I want to do this on the years 
I celebrate at home and also the years when I celebrate with 
friends and family in other parts of the world.  A timestamp for a 
variably situated event shares well--the recipient user needs to 
ensure that the event is stored within user's local time zone 
scope.

In the second case, "Send Christmas greetings to Max when he opens 
presents at 8:00 AM" would be an event situated at the place Max 
is celebrating--it is separate from the first case.  If I know 
where Max will celebrate Christmas, then I could use a timestamp 
for a situated event.  Otherwise, I would use a timestamp for a 
mobile event and make certain to ensure that the time zone scope 
for the event tracks Max's whereabouts.
> 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.

Yes, UTC is the sign we've widely agreed to interpret as absolute 
time.  A key property is that UTC is a continuum, absent the 
potential discontinuities that characterize space/time units like 
time zones.

> 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.
Well, you know where I stand on this---UTC is not a time zone and 
no good comes from confusing it with one.  Nevertheless, the UI 
issue need not require the user to grasp the distinction between 
event and occurrence.  My idea was to use "no host event" to refer 
to an occurrence.  To my mind, "no host" gets to the point of "not 
associated with a particular region of space/time", so that 
calling it an event, a fundamental space/time unit, is less likely 
to cause confusion.

> 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.
The discussion around this point confuses me.  One the one hand, a 
timestamp for absolute time (UTC or offset from UTC) should be 
stored in the format that minimizes computations that will 
subsequently involve it.  On the other hand, the user can toggle 
or otherwise see (Ihor's eldoc solution) the timestamp in the 
format that makes the most sense, so the readability of the 
storage format is not really at issue.

> 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?

No, I don't think you've missed anything significant.  Thanks very 
much for your patience during a discussion that was interesting 
for me.  I learned quite a bit from you and the other contributors 
to the thread and look forward now to learning how Org mode 
evolves to handle events and occurrences.

Let me know if you have questions.

All the best,
Tom

--
Thomas S. Dye
https://tsdye.online/tsdye