Aloha Tim,
Tim Cross <theophil...@gmail.com> writes:
"Thomas S. Dye" <tsd@tsdye.online> writes:
Aloha Tim,
Tim Cross <theophil...@gmail.com> writes:
"Thomas S. Dye" <tsd@tsdye.online> writes:
Aloha Tim,
UTC is a time zone - just one where offset is +0000
UTC is absolute time. It lacks the spatial component that
defines a time zone.
Really? I would have thought the prime meridian was the
spacial
component for UTC? I thought the full long time zone name was
Etc/UTC
and UTC as the abbreviation.
Regardless, in all the libraries I've used, you can use
Etc/UTC or UTC
in exactly the same way you would use something like
Australia/Sydney or
AEST. So perhaps, from a pedantic standpoint, it is not a time
zone, but
for all intent and purpose in this discussion, I feel that
point is
irrelevant.
Agreed. It does seem irrelevant for time zone libraries.
Nevertheless, from the Org perspective it might not be. An
occurrence, which marks
changes in the nature or relations of things at a time,
requires absolute time. Meetings,
which involve a change in relation among participants, are
occurrences. IMO, this
indicates Org should give occurrences a UTC timestamp, then
translate that for each of the
participants using their local time zone. The insane interval
problems that Ihor brought
up are moot in absolute time. A single timestamp serves a
meeting regardless of whether
the participants are all in one time zone or spread around the
globe.
An occurrence contrasts with an event, which is tied to the
user's space/time. Time here
is relative to the user. IMO, this means that Org should give
events a timestamp without
reference to either absolute time or a particular time zone,
like the one it uses now.
Just checking if I understand. I think we are coming from the
same
position and with the same conclusion.
Thanks!
In the situation where the meeting involves people from
different time
zones, the time of the meeting as reported by org needs to be
adjusted
after a daylight savings transition so that the time maintains
the same
relative to UTC. i.e. meeting time reported in local time goes
forward/backward 1 hour depending on the daylight savings
transition
(in/out). I guess this is what you call an occurrence?
When all participants in a meeting are in the same time zone,
you do not
want the time changed as the result of the daylight savings
transition.
This is what you call an event?
Every meeting is an occurrence because it involves changes in
relations of things at time; in this case meeting participants
relate to one another via Jitsi, regardless of whether they are
all in one time zone or spread over the globe.
An event's time is relative to the user's location, or space/time.
So, the example I gave earlier "Brush teeth before bed" set to
10:00 PM, which works whether I am home in Honolulu or enjoying
the hustle and bustle of Manhattan, is a simple event. It happens
at that time in the timezone I happen to inhabit at the moment,
because I intend to go to sleep shortly after 10:00 PM regardless
of where I am.
So, using your terminology, what we now need is convenience
functions
for setting an occurrence timestamp and an event timestamp. I'm
not sure
if occurrence/event are the best terms, but I cannot think of
better
ones. Just slightly concerned people will have trouble grasping
the
difference and undersanding why some meetings are an occurrence
while
others are an event. FOr the user, they are just meetings.
Yes, both meetings are occurrences.
I agree that the terms take some getting used to. I got them from
Frank Ramsey, who seemed to be happy with event, but not so happy
with occurrence.
The difference is this: Will the happening being scheduled involve
other people, who will share the Org timestamp, or will it take
place at the same absolute time, regardless of where you are when
it happens? If so, then the timestamp should be stored as UTC (it
is an occurrence that requires absolute time).
Or, is it something you want to do at a time, regardless of where
you are. If so, then the usual Org timestamp without UTC is what
should be stored (it is an event that requires time local to the
user).
In the case of a meeting, where the one who calls the meeting
sends an Org file with a meeting agenda and a UTC timestamp to
each of the participants, Org will translate the UTC timestamp
into local time for each participant. Similarly, when you are
traveling, Org will translate the UTC timestamp to the timezone
you happen to inhabit. Here, I'm assuming that the timezone
machinery is capable of determining local time relative to UTC.
hth,
Tom
--
Thomas S. Dye
https://tsdye.online/tsdye
