Aloha Jean Louis,
Jean Louis <bugs@gnu.support> writes:
* Thomas S. Dye <tsd@tsdye.online> [2023-01-19 09:37]:
Meetings are occurrences, which require absolute time, which
has no
timezones. Org should record occurrences with timestamps in
UTC,
possibly translating from the user's local time.
User in Grece needs appointment at 9 o'clock, and writes it as:
<2023-01-20 Fri 09:00> He also has TIMEZONE (either system or
Org file
based) set to "EET". That way the time has been recorded in UTC
for
Org purposes, and UTC has been solved. For Greek user it is
completely
solved. Org calculates UTC based on configured time zone. But
when it
is 16:00 o'clock in Greece, it is 06:00 in Seattle.
Online appointment is sent to user in Seattle, with the time
zone
PST. He receives the Org file from Greece, at 8:00 o'clock,
which has
settings inside TIMEZONE="EET". At first user thinks that
appointment
is in just 1 hour, because he can see "08:00", but Org
gracefully
notifies user that appointment is (probably) in a different time
zone,
and asks user if user would like to have it displayed in PST
time
zone. User answers with "Yes" and on his screen appears that
meeting
is actually at <2023-01-20 Fri 23:00>, he prepares himself for
longer
evening, and waits for his Greek partner on Jitsi Meet:
https://meet.jit.si/ to get online.
It confirms your hypothesis, yes, all times are calculated as
UTC, but
all time stamps at export, sharing, or change of time zone,
shall be
displayable in understandable manner to human user.
Only occurrences require absolute time, UTC. Events do not. They
follow the user's space/time.
> Org in this state can't handle such things.
Org can do the useful thing: translate the UTC timestamp into
local time and
report both UTC and local time. User will be able quickly to
determine if
local time is incorrect for some reason, such as DST or travel.
Other way around, it has to translate time stamp into UTC time
in the first place.
Yes, to store the time stamp, Org must take it from the event time
of the user and translate it to UTC. When reporting an occurrence
to the user, then Org must translate from UTC to the user's
space/time. User might have a toggle, like pretty entities, that
either shows UTC or translation to user's space/time.
Expecting that all user among so many various time zones write
their
time stamps in UTC is not reasonable. Org users are advanced, I
know,
but majority of note takers with other applications will not
even
think of different time zones, it is surprise they get when
dealing
internationally. People are not ready for calculating or even
viewing
their own time in UTC time zone, unless they are English or
Icelandic,
Portuguese, or Africans in parts of the West Africa.
Org should translate from the user's space/time to absolute time,
UTC. The user has to tell Org what is the space/time relationship
to absolute time. Org might use the timezone machinery to suggest
a space/time relationship to absolute time, and it might warn the
user when the user's suggested relationship differs from the value
reported by the timezone machinery.
Storing timestamps in UTC solves the interval problem Ihor
raised. Intervals always make sense in absolute time. Moving
them
to event time leads to the insanity Ihor mentioned.
The other way around. Assuming that time stamps are UTC raises
problems for all other people:
https://upload.wikimedia.org/wikipedia/commons/8/88/World_Time_Zones_Map.png
Org now does not support time stamps, right?
So people write timestamps in their own time zone! Is it right?
IIUC, Org currently stores events, which are relative to the
user's space/time. This works for events, but breaks for
occurrences, which require absolute time, UTC.
My time stamp here is <2023-01-19 Thu 17:12> now, what is yours?
<2023-01-19 Thu 06:08> This is an event, specified relative to my
space/time.
Forcing users to write time stamps in UTC would cause havoc.
Agreed, Org should help.
Thus time stamps already have their time zones, it is just not
recorded in Org file.
Events don't need a time zone, only occurrences need absolute
time.
Options can be created so that:
- user always and automatically record time zone in Org file,
for
example from system time zone, so that when first time
property is
invoked that it stays there:
#+TIMEZONE: EET
Or like this
* TODO Appointment on Jitsy Meet with Greek investor
DEADLINE: <2023-01-20 Fri 09:00>
:PROPERTIES:
:TIMEZONE: EET
:END:
or inside of the time zone.
When such heading is read in Seattle, Washington, Org will tell
to
user or ask to translate it to PST time.
In such translations, EET time is first converted to UTC, for
reason
of using system libraries, and not complicating Org, and then
converted to PST time zone.
The Org user in Seattle would either see UTC or toggle to see UTC
translated to Seattle space/time, assuming user set space/time
relationship to UTC correctly. If not, then Org should warn user
that the specified relationship differs from the one suggested by
the timezone machinery.
hth,
Tom
--
Thomas S. Dye
https://tsdye.online/tsdye
