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

["Thomas S. Dye" <tsd@tsdye.online>]

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