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?
