Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Jean Louis]

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

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

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.

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

My time stamp here is <2023-01-19 Thu 17:12> now, what is yours?

Forcing users to write time stamps in UTC would cause havoc.

Thus time stamps already have their time zones, it is just not
recorded in Org file. 

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.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/