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

[Jean Louis <bugs@gnu.support>]

* Sterling Hooten <hooten@gmail.com> [2023-01-27 09:06]:
>   Offset
>         Constant duration difference between times of two time scales
>         (ISO). i.e., a quantity to combine with a time scale to produce
>         a wall time. e.g., Nepal uses a +5:45 offset from the UTC time
>         scale.

I would be careful calling it constant as time offset is changing
depending of daylight saving time. It is not constant.

Time offset time stamp may be derived from time zone time. I am sure
about this.

Time zone time stamp cannot be unambiguously derived from time
offset. I am mostly sure about this.

> What kinds of representations would a calendar system capable of
> handling timezones require?
> 
> • Instant (fixed)
>   • This is referring to an unambiguous moment in time
>   • e.g., 2007-02-03T05:00:00.000Z
> • Offset (fixed)
>   • This captures the idea of "when did it happen for the person who
>     made the observation"
>   • e.g., 2007-02-03T04:00:00.000+01:00

Offset is not that fixed, maybe from viewpoint of storage as maybe it
is considered fixed in it's representation, but you have to keep in
mind that time offset by it's definition is changing itself, suddenly,
depending of daylight saving and time zone.

I am trying to find well described reference to read, try here:

Time Zones vs. Offsets – What's the Difference? Which Is Best?:
https://spin.atomicobject.com/2016/07/06/time-zones-offsets/

,----
| Putting It All Together
| 
| Given a time zone and a UTC time, you can know the offset—and
| therefore the local time. Given a local time and an offset, you can
| know UTC time, but you do not know which time zone you’re in (because
| multiple timezones have the same offset). Given UTC and an offset, you
| can know the local time. Given a time zone and an offset, you don’t
| know much. That’s why a calendar systems work with time zones,
| offsets, and UTC; we need the offset to go from local time to UTC, and
| we need the time zone to go from UTC to local time.
`----

> • Instant with explicit offset and zone (fixed)
>   • e.g., 2007-01-01T02:00:00.000+01:00[America/Chicago]
> • Zoned local date time (floating)
>   • Tricky, requires decisions about how to interpret timestamps after
>     political changes.
>   • e.g., 2007-01-01T01:00:00.000[America/Chicago]

For calendars it is good to follow recommendation Internet Calendaring
and Schedulingn Core Object Specification (iCalendar)

iCalendar - Date and time format:
https://en.wikipedia.org/wiki/ICalendar#Date_and_time_format

In other words it is good to follow what other successful applications
are already doing. 

For example, if you open Evolution calendar in Gnome:

evolution -c calendar

and make task, and save that task as iCalendar, then you can see what
time stamp format is used there for exchange purposes.

Representation for user using Org file is different from
representation for sharing purposes, as user already (mostly) have
specified local time zone on this computer, while sharing object such
as iCalendar file must take that information of local time zone and
store it unambiguously.

> I claim that before dealing with the nuances of calendar appointments,
> repeating events, agenda displays etc, that Org must first support
> fixed/absolute time instead of just floating time. 

Parameters needed to make it fixed are already in computer, only
disconnected. 

changing this time stamp for Org:
<2023-01-27 Fri 10:18>
to something "fixed" would break Org compatibility for past Org files.

While new unambigious time stamp formats may be introduced, the way to
go is with past time stamps is to understand the time stamp for
representation and calculation purposes by using OR logical function:

timestamp-time-zone OR heading-time-zone OR file-time-zone OR system-time-zone

as by using those, for now still disconnected parameters, one can get
the fixed time for representation purposes (Org export or sharing) or
calculation purposes (on local computer and by using some shared Org
objects).

> Without some basis time scale the conversions from time zones and
> offsets to some incremental time point is impossible. Resolving this
> prerequisite will also simplify the timezone discussion because we
> won't be mixing calendar issues with time issues.

I guess that OR consideration above may remedy it and keep past
compatibility while expanding more specific time stamp as option.

> What would a roadmap be?
> 
> • Design and implement an absolute and offset timestamp system
>   • Decide on a time scale
>   • Decide on a format and syntax
>   • Implement instant timestamps
>   • Implement offeset timestamps
> • Design and implement the time zone aware calendar system This is a
>   separate project.

Sounds complex to me and over board for program that tries to define
data type by using simple text written ambiguously by many people.

> What format and syntax should Org use?
> 
> A heretical suggestion: We should abandon the day of week abbreviation
> and use a new format.

Day of week abbreviation is useful. Full day is even more
useful. Removing what is useful is not useful.

There is no calendar application that I know that does not specify
days of week.

> The current format generates a three leter abbreviation of the day of
> the week [2023-01-25 Wed 12:12]. I suggest supporting this as a
> legacy/simple format but switch to a format/encoding like
> [2023-01-25T15:13:42Z] for the new system.

Which format is more useful for people?

I find [2023-01-25 Wed 12:12] more useful, rather than the other one,
for reason that it has clear date, day of week and time.

And I always consider that Emacs packages like Org shall be designed
to be useful to majority of people, rather than to few who may have
the idea very right, but not comforting the majority of people.

There is no calendar application that I know that by default uses UTC
format, which representation is of course contradictory to large
majority of time zones and to people got used to, to display their
time in their time zone. 

> Specifically I'm advocating for an extended ISO 8601 format,
> compatible with expanded dates and Level 2 of the EDTF, with some
> (bracket?) notation surrounding it such that Org can parse the
> syntax as a timestamp. I advocate further for the use of durations
> and repeating intervals to follow the same standard format. Thus
> instead of a range being formatted as:
> 
> [2023-01-25 Wed 13:57]–[2023-01-26 Thu 13:57]
> 
> it would be:
> 
> [2023-01-25T16:57:42Z/2023-01-26T16:57:42Z].

Such representations should not become default to users, but used in
representation, or sharing, or re-writing of time stamps by user
option. 

Using such time stamps by default in Org file is confusing for people
and showing time which is not their time to majority of people.

I am surprised and in same time disappointed, that your analysis leads
to conclusion that users should represent their time in UTC.

> What are the problems with the day of the week in existing format?
> 
> • The day of the week is redundant information and can be rebuilt from
>   an ISO date Any user who wishes to display a format with the day of
>   the week can do so.

It is redundant or who? 

Is it redundant for majority of Org users?

Maybe it is reundant for you?

For some people?

Do you know for who?

I never even heard some user here complaining for day of week
representation. Let me add one big fricking LOL here.

Any user who wishes to do anything could be left to program it alone
and do what they wish.

But programming should be useful to people by majority of demands and
wants.

> • It's a nonstandard format

The statement above miss the context. Non-standard where? How? In
which context?

In context of Org file is prime standard.

In context of Evolution calendar it is not standard, but neither the
graphical representation of a task in such calendar is standard.

Program's representation of time is NOT REQUIRED to be standard,
rather it shall be useful to user using the program to understand the
information. 

In other words, representation shall be simple and readable,
understandable!

> Although the Org documentation says that the timestamps are
> "inspired by the standard ISO 8601 date/time format" the use of a
> day name is not contained in the ISO specification.

Being inspired does not mean "conforming to ISO 8601"

There is distinction, different context, of using time stamps inside
of Org file, and different context of "worldwide exchange and
communication of date and time related data", see ISO 8601 purposes.

I fully agree that in exchange or sharing of date/time information,
Org program should sometims use ISO 8601, but not in all exports.

For example in HTML export it is enough to say time and time zone. But
some people like to export it in ISO 8601. Such considerations could
be user option.

Right now HTML export is ambiguous as it does not have time zone.

The usage of ISO 8601 should rather depend on method exchange or
exporting.

But it should not be user's representation, as user is not a robot, or
program that is supposed to read computer-meant time stamps.

And you forgot to list disadvantages of making Org for robots, not for
human.

-- 
Jean

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

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