Aloha Max,
Max Nikulin <maniku...@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
