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

[Jean Louis <bugs@gnu.support>]

* Thomas S. Dye <tsd@tsdye.online> [2023-01-19 19:23]:
> 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.

That is right. I have stated same.

How do you want Org to know that user's time is in X time zone? 

It means, that new settings, variables, functions, must be introduced
to handle it properly. Timestamp like this one: <2023-01-21 Sat 09:55>
at HTML export will be from 95% and upwards incorrect. To be correct,
time zone designation shall be placed in HTML export. User could be in
South America, not in London, that exports it. Time zone UTC does not
apply for South America. Representation is wrong.

When you say that Org must take it from the event time of the user,
that means that Org must take some parameter to understand what time
zone user was.

That means involving functions for export, or sharing of Org files.

In general, we speak about representation.

You may start making distinctions between "events" and "occurences",
but technically we speak of time stamps which lack relation to time
zone in Org. Whatever you "time stamp" without time zone,
representation of it in other time zone becomes difficult, as it lacks
the fundamental designation of time zone where it was recorded. 

And it does not matter if user records time zones in UTC, or other
time zones.

What matters is designation of time zone.

Parameter must exist, something like "#+TIMEZONE: PST"

As that property is then used by programs to understand time zone of
the file, or task.

In general computers store things in UTC. We are repeatedly discussing
what is already agreed before decades.

What we need in Org is representation in time zones.

All programs work by storing in UTC time zone:
----------------------------------------------

Observe file system:

$ touch MY-FILE
~
$  ls -l |grep MY-FILE 
-rw-r--r--     1 admin input       0 Jan 21 16:21 MY-FILE
~
$ TZ=UTC ls -l |grep MY-FILE 
-rw-r--r--     1 admin input       0 Jan 21 13:21 MY-FILE


UTC is basis for time. There are time zone libraries and calculations.

All that one has to think for Org is representation in familiar local time zone.

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

That is right. So far I am telling same, maybe we think is not.

> The user has to tell Org what is the space/time relationship to
> absolute time.

That is right. I said that long ago. The way to "tell it to Org" is at
export, for Org to recognize it in terms of Lisp 
(or time-stamp-zone heading-time-zone file-time-zone system-time-zone)
whatever comes first, then at any sharing of Org directly to people in
other time zones, and in other uses cases. Such sharing and export
must have variables that help to interpolate time properly in other
zones, and Org shall recognize that time stamp displayed is not in
local time zone and ask user if to show or translate time stamps. Many
options exist.

Best is when it is automatic, as that is usual in many other software.

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

That is right.

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

You have got that theory from a book, it is different philosophical
concept that somebody finds useful. 

Though it is not directly related to the problem that Org does not
have time zone representation.

To solve the problem first one has to define it. 

You can call time stamps as you wish. How you call them it does not
matter. 

You can call it "event" or "completed" or "deadline" or "scheduled" or
"occurence", those are types useful for user.

Whatever they are called, local user shall get any time displayed in
local time or with proper time zone designation, so that time may be
displayed or converted to local time.

Nothing will break what designation get introduced in Org.

I mean to introduce variables analogous to following logic:

(or time-stamp-zone heading-time-zone file-time-zone system-time-zone)

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

When you introduce words that have different meaning in different
context in your book, you can't expect that it will be generally
expected.

No matter how you "name" the time zone, all time you write in your
computer beyond Org is already written in your local time zone.

Any time user designates in notes, calendars, etc. is already in local
time zone.

Any time displayed to user is in his local time zone.

Follow the steps!

It is that simple.

If event need time zone or not, because you think it does not need,
many others may disagree.

Why argue how you call that time? 

Just follow the steps to display it in local time zone, and any time
to accept as UTC, written in local time zone. Any time always is
related to UTC in computers, there is nothing unsolved.

Finally users who do not want to fiddle with time zone shall also be
left to do so.

Org could also give to user to designate how time stamp should look
like, by using format that user may specify:

%Y/%m/%d - %H:%M %Z

Which could display:

2023/01/21 - 16:40 EAT

by using:
https://linux.die.net/man/3/strftime

instead of trying to satisfy every possible way of formats of time
stamps (congratulation for that).

1. System time is always in local time
2. Org may introduce TIMEZONE property as already discussed
2. Org may introduce property "#+TIMEZONE_FORMAT" like "%Y/%m/%d - %H:%M %Z"
3. Any time stamp would use that format

Translation of timestamps to other time zones by using that format are
easier, than trying to satisfy every person on planet. For Org, which
is not even demanded apart from us here.

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

Why would you see UTC if you are not in UTC time zone? It is not
useful. 

But yes, user could or should be able to see it in any time zone, but
without much focus on that. Users can change local time zone, so let
them do that if they want, but displaying local time zone is decades
long standard in computin.

I have various software here, none of it asks me to look at UTC
time. UTC is for computer to calculat, not for human to see, it is not
useful for human unless to those who happen to be in that time zone.

All computer software calculates to and from UTC when showing local
time zone.

We basically speak of "calendar" applications where users need to
share various times. 

Then why not follow what is already successful elsewhere?

3.2.19. Time Zone Identifier | iCalendar (RFC 5545) | RFC Specifications:
https://icalendar.org/iCalendar-RFC-5545/3-2-19-time-zone-identifier.html

This parameter MUST be specified on the "DTSTART", "DTEND", "DUE",
"EXDATE", and "RDATE" properties when either a DATE-TIME or TIME value
type is specified and when the value is neither a UTC or a "floating"
time. Refer to the DATE-TIME or TIME value type definition for a
description of UTC and "floating time" formats. This property
parameter specifies a text value that uniquely identifies the
"VTIMEZONE" calendar component to be used when evaluating the time
portion of the property. The value of the "TZID" property parameter
will be equal to the value of the "TZID" property for the matching
time zone definition. An individual "VTIMEZONE" calendar component
MUST be specified for each unique "TZID" parameter value specified in
the iCalendar object.

The parameter MUST be specified on properties with a DATE-TIME value
if the DATE-TIME is not either a UTC or a "floating" time. Failure to
include and follow VTIMEZONE definitions in iCalendar objects may lead
to inconsistent understanding of the local time at any given location.

Thus in Org, we want to avoid also: "inconsistent understanding" at
any given location. That is why only iCalendar export supports the
conversion. 

-- 
Jean

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

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