Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Jean Louis <bugs@gnu.support>]

* Ihor Radchenko <yantar92@posteo.net> [2023-02-06 17:11]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > * Ihor Radchenko <yantar92@posteo.net> [2023-02-05 13:45]:
> >> [2024-02-04 12:00 @-08,America/Vancouver] will use fixed -8 offset
> >
> > What does that mean practically? Provide example for better
> > understanding. 
> 
> It means "when I scheduled this item, I expected the UTC offset at the
> time of the timestamp to be -08 and remain so. It was motivated by
> America/Vancouver time zone, but if it changes in future, I do not care
> - the scheduled time should remain at specific time point relative to
> UTC".

I read, though sorry, I do not understand who is expected to think
that UTC offset is fixed?

Is it Org as program?

Or is it human?

Another program in future, and human, must know did the organizer of
event, had in mind:

- to rather keep appointment at 12:00 o'clock, no matter the UTC
  offset changes, or

- to keep appointment based on UTC definition?

I find such situations rather easy to solve with database:

- I can have column like "timestamp" with UTC time or local time plus
  UTC offset, and if I did not enter any other information, that UTC
  offset is considered in future. Consider this column name
  "timestamp".

- I can have column "time" and when such is entered, then date is
  extracted from "timestamp" column, and combined with time. In this
  case UTC is only calculated in new time point but not used as period
  from past to appointment time.

- I can have time zone for the future, if I enter such in other
  column, the future calculation must use that proper time zone. 

The above handling is for program to handle and for human to know that
it is handled that way.

You said "I do not care", that means you as human decide that 
[2024-02-04 12:00 @-08,America/Vancouver] will use fixed -8 offset

But from where in such timestamp does user or program understand that?

> > - The UTC offset is not certain to remain fixed in the future. 
> 
> Yes. But fixing UTC offset means that time point is fixed. Example: you
> need a timestamp exactly N hours from now. It must not be affected by
> time zone rule changes.

Not generally! As I said, your time stamp is not structured, I cannot
see how do you decide the appointment here: 
[2024-02-04 12:00 @-08,America/Vancouver]

1. Both time zone and UTC offset may be changed in future. 

2. You as organizer you were maybe meaning UTC time "fixed" with offet
   -8, but the UTC offset maybe changed in future, it became -07. It
   is confusing, and neither program neither human will know with
   certainty if you meant 1 hour more or less.

3. To solve that problem, appointments are better defined as
following, with the structured time stamp:

* Meeting, discussion of our plan beyond 2030
  :PROPERTIES:
  :TIME:     10:00
  :TIMEZONE: Europe/Berlin
  :END:

Or this way, but I do not find that practical, however, "UTC-TIME"
could mean to program that it is fixed.

* Meeting, discussion of our plan beyond 2030
  :PROPERTIES:
  :UTC-TIME: [2024-02-04 12:00 @-08, America/Vancouver]
  :END:

However, if you do not define UTC-TIME to mean fixed, how is program
to know that the timestamp:

[2024-02-04 12:00 @-08, America/Vancouver]

means that it is -08 UTC fixed offset?

Without putting some structure, it will not know it.

Maybe this way (hypothetically):

[2024-02-04 12:00 @-08, America/Vancouver/UTC-FIXED]

as that way you would give signal to program that you want UTC fixed
time in future, and not 12:00 o'clock necessary.

Without any tag, neither program, nor authors, cannot know which time
will it be in future, if there is DST change, time zone change or
replacement of it, or UTC offset change.

Structuring it, becomes clear DATE:, TIME:, TIME-ZONE: as future TZ
database can give information of UTC offset and various local times
for TIME:

> > - If you do not have the time of creation of the timestamp above, you
> >   cannot know with certainty what was the offset in past, to calculate
> >   new UTC offset in case it changed
> 
> America/Vancouver in the above timestamp is nothing but a reference
> comment. One may or may not use it.
> 
> > - As not even time zone is certain to remain in existence in future,
> >   you will need to use time zone, in order to derive that future UTC
> >   offset correctly. As it could change in mean time.
> 
> If timestamp must follow the future time zone rules, can just use 
>  [2024-02-04 12:00 @America/Vancouver]

Exactly. And that is human friendly versus UTC, which is not readable.

> >> [2024-02-04 12:00 @America/Vancouver] will use @America/Vancouver time
> >> zone, as it is be defined in you OS time zone database.
> >
> > If you do not keep UTC offset, you will miss changes in future and
> > generate errors.
> 
> Only if you care. Maybe it is not an error to follow the future changes.
> If you want to be notified, just use [2024-02-04 12:00
> @-08,!America/Vancouver] explicitly stating the offset you expect in
> future.

OK but expecting or not expecting makes again not much sense, it leads
to confusions, including for organizer.

If I am expecting -8 UTC offset, I cannot know if UTC offset will
change in future. And when it changes, maybe my expectation also
changes.

It is useless and creates problems.

And why not follow what other programs do? Specify date, time, not UTC
in future.

> >> [2024-02-04 12:00 @-08,!America/Vancouver] (note "!") will use fixed -8
> >> offset, but also calculate America/Vancouver time from TZ database,
> >> compare it with the time coming from -8 offset, and warn you if there is
> >> inconsistency.
> >
> > The UTC offset is the log what was the UTC offset at the time point
> > when timestamp was created, as future UTC offset cannot be known.
> 
> Sure. -08 is expected offset.

If you wish to specify UTC time in future, no need to specify even any
offset, but you can. 

Look here in first example how event is defined by using UTC time:
https://icalendar.org/iCalendar-RFC-5545/4-icalendar-object-examples.html

> > Making it "fixed" does not fix it in real time, you are then
> > introducing something new than what other programs do with time.
> 
> I do not understand this statement.

Well to understand that, you have to make practical examples and
understand what would human think in periods of time A, B, C, D, from
creation of appointment, through possible changes of DST, time zone,
UTC offset, to final appointment.

Look here the second example of group-scheduled meeting that begins at
8:30 AM EST on March 12, 1998 and ends at 9:30 AM EST on March 12,
1998
https://icalendar.org/iCalendar-RFC-5545/4-icalendar-object-examples.html

DTSTART;TZID=America/New_York:19980312T083000
DTEND;TZID=America/New_York:19980312T093000
LOCATION:1CP Conference Room 4350

The stuff with iCalendar works for reason that it is structured. The
timestamp such as: DTSTART:19960918T143000Z will clearly say that time
is specified in UTC time. No need for confusion with time zone.

But if DTSTART has this: TZID=America/New_York:19980312T083000

Then it becomes clear that it will be the UTC offset in future with
assumed mentiond time zone.

But if you mix UTC offset, plus the time zone for future, that makes
little sense, unless you introduce some tags that timestamp is
recognizable as using UTC time, or that it uses date/time and time

-- 
Jean

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

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