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-08 13:36]:
> > Is it Org as program?
> >
> > Or is it human?
> 
> Both.
> 
> The idea is to ensure exact point of time relative to UTC.
> For example, when you want to schedule something exactly 10024 hours in
> future, regardless of time zone changes.

I got it, thank you.

iCalendar allows UTC time. If you have UTC time, you need not have UTC
offset, as that is NOT what other programs are doing.

My recommendation is follow what is successful. If you wish to use UTC
time, use it, but no need to add offset as it will be confusing.

Timestamp is either in UTC or in other time zones. UTC time has no
offset.

If you start adding in Org "fixed" time with UTC offset, that is a new
type of timestamp, as it is not common in world.

Here is suggestion:
-------------------

1. Convert local time timestamp to UTC
2. Add 10024 hours
3. Provide timestamp in UTC

Also look at this reference:
https://icalendar.org/iCalendar-RFC-5545/3-3-5-date-time.html

,----
| The form of date and time with UTC offset MUST NOT be used. For
| example, the following is not valid for a DATE-TIME value:
| 
|  19980119T230000-0800       ;Invalid time format
`----

As with the above format, author would maybe think it is alright, but
in general it is confusing. If author wish to specify UTC time, then
no offset shall be used.

> The same can be done by specifying the timestamp in UTC directly.

That is simplest.

> > Another program in future, and human, must know did the organizer of
> > event, had in mind:
> 
> I would like to remind you that timestamps are not necessarily used for
> meetings. And not always shared with other people.

Ok, and I have asked you to provide practical examples.

Calculation of time shall not be made for sake of sole calculation,
but for human and by considering use application.

Timestamps for past time, like for logs, I always store as UTC time in
database, with time zone (which does not mean that time zone is
stored, but displayed in local time zone).

However, future time to be coordinated with people, anything human
related, it has to be stored with date, time, and time zone in
separate fields. That way program in future will understand it.

Timestamp is in general always considered past, not future. That is
where the word comes from, the "stamp", if you stamp something, it is
on paper, when it was done. It is not about "When it will be".

https://en.wikipedia.org/wiki/Timestamp

A timestamp is a sequence of characters or encoded information
identifying when a certain event occurred, usually giving date and
time of day, sometimes accurate to a small fraction of a second

We have to distinguish in Org what we are doing here, and meaning with
"timestamp", as in Org context, timestamp is more than just time when
something occured.

In Org context there is new type of "timestamp" which is meant for
future.

Timestamp for past -- should be as accurate as possible in general
applications.

Practical example of a timestamp: I enter person's contact details,
the moment I enter such details, the timestamp is created. It is not
100% accurate to the event that really has taken place, as computer
user need some time to write first name, last name of person, it is
"about". But for the sole entry of the data in database, that
timestamp is pretty accurate.

Timestamp for future is not really timestamp, it is intended time, in
many applications it cannot be accurate. 

The last example on the page:
https://icalendar.org/iCalendar-RFC-5545/3-3-5-date-time.html
gives good clues how to specify date and time in future.

> > 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. 
> 
> Sorry, I do not understand what you are trying to explain here. Would
> you mind showing an example?

The above quote came from explaining that you should not use "time
offset" to designate UTC time, as such offset will be mistaken in
future for "UTC offset". 

By doing that you are creating new type of time representation that is
not used anywhere else (for future purposes).

Example
-------

2023-02-01 12:00 -08 @SomeTimeZone would mean that UTC offset at that
time and date was -08. One can derive UTC time easily and it will be
accurate.

2033-02-01 12:00 -08 @SomeTimeZone, means that one should consider
that @SomeTimeZone in future to first derive the UTC offset, as -08
can only be taken vaguely, you cannot know if it will remain same in
future. I would assume that author wants us to meet at 12:00 o'clock
of that @SomeTimeZone, no matter the UTC offset, as that one will be
calculated in future time. If time zone changes, the TZ database would
tell what is the new time zone, and calculation is still expected to
be good for future.

Time stamp like this 2008-04-29 02:53:24.796564+03 is past time, with
+03 UTC offset. Past UTC offset does not change, it is accurate. It
was how it was.

2030-02-09 12:00 is future time. I need no offset, but time is
floating as it is not bound to time zone.

2030-02-09 12:00 -08 @UTC -- this time CANNOT be said to be "fixed
UTC" time for reason that UTC time is not represented with UTC
offset. It is either UTC time or time zone time with UTC
offset. Cannot be this and that.

2030-02-09 12:00 -08 @SomeTimeZone -- this is alright

2030-02-09 12:00 -08 @UTC -- not alright, as other programs do not represent time with UTC time zone with offset.

That offset is offset, does not make it "UTC offset" as such is not
used with UTC time zone. Only with other time zones.

For future designation, in database is better, and also confirmed by
references, to enter designation in separate fields, like this:

TIME-DATE: 2023-02-09 12:00
TIME: NIL
TIME-ZONE: @SomeTimeZone

It becomes clear what is intended time zone, and what is date, time intended.

The above representation is not enough clear, as what if it is only date intended?

Maybe this would be more clear:

DATE: 2023-02-09
TIME: NIL
TIME-ZONE: @SomeTimeZone

And this:

DATE: 2023-02-09
TIME: 12:00
TIME-ZONE: @SomeTimeZone

The UTC offset matters not for future as it may change, and it has to
be calculated from @SomeTimeZone definition in future.

Because fields are separated, it can become clear what is intended.

2023-02-09 12:00 -08 @UTC -- is not clear as fields are not separated,
when you say that such timestamp should be UTC fixed time stamp with
offset, because offset is not used with UTC, it is confusing, and you
are showing 12 o'clock, which is contradictory to using offset. You
mean UTC offset, but definition of UTC offset is not that it will
remain fixed in future.

Follow example of iCalendar which says that such designation of UTC
time plus offset would be invalid.

> > 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?
> 
> From syntax we are now defining, XX takes priority in @XX,YY.

That is wrong, for the above mentioned reasons, references. People who
designed iCalendar, had some reasons to tell you why is such timestamp
in future invalid.

If you intend to say UTC time in future, do not use offsets and time
zone. It is contradictory. 

It is either UTC time in future, or it is time with time zone in
future.

While person could tell about UTC offset in future, such is vague as
it can change.

And if you are defining anything, for reasons that fields are not
separated and not marked, user cannot know what you mean:

1. [2024-02-04 12:00 @-08,America/Vancouver] you define that @-08 has
   priority, OK fine, but how does user sees that? Only by reading
   documentation?

2. You wish to say it will be future time of 20:00 o'clock, but time
   zone definition can change, so if it can change, why use time zone
   definition?

3. UTC offset is displayed for past, as such time is accurate, but if
   you display it for future, be aware that it is wrong for reason
   that you cannot know the UTC offset in future without time
   zone. Just display UTC time. Offset is not relevant, it will be
   displayed to every user in their local time anyway, once they get
   UTC.

4. Hypothetical example of clear timestamp for future:
   [2024-02-04 12:00! @-08,America/Vancouver]
   where the time would be stamped with "!" and that would mean that in the time zone, meeting is at 12 o'clock.
   It would assume that UTC offset can change in future, but 12:00 clock would be authoritative time for future.

5. Hypothetical example of timestamp for future, with "tag" to tell
   what you mean, maybe with "!":

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

   where the time would be stamped with "!" and that would mean that
   time "12:00" would be disregarded, but offset of -8 hours from UTC
   would be used.  However, it remains confusing by using offset.

> > 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.
> 
> I am sorry, but I don't understand what you mean by UTC-FIXED.

You mentioned it, you wish to have offset and to remain UTC fixed.

And UTC is not fixed, it is either UTC without offset, or time zone
with UTC offset.

But if you do wish, you have to make "tag" somehow, for computer
program to know what you mean, "UTC-FIXED" is only hypothetical tag.

> >> > 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
> 
> It is sometimes easier to define UTC time +offset instead of doing an
> extra conversion in your head.

I hope you understood the difference.

Providing UTC time plus some offset is inconclusive. It is idea that
is not aligned with what international community is doing.

Provide UTC time.

Or provide time zone plus UTC offset.

Your idea as such is alright, but is individual, and it has to be
coordinated with what other programs are doing. Otherwise it become
confusing.

Remember the reference on iCalendar, "not do do that". 

iCalendar provides either UTC time, or date, time and time zone.

> > 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
> 
> The problem being addressed with @+08,!Asia/Singapore is possible future
> change in time zone.

That problem is solved, if you use TZ database:

- in case of change of time zone, the TZ database will provide future
  adjustment, there may be new name of new time zone. 

- in case of change of UTC offset, the TZ database in future will know
  it. 

> Imagine a yearly meeting you attend at [2024-01-02 19:00
> @Asia/Singapore,!+08] while living in Europe/Athens (UTC +2). Over
> the years, you are used to meeting being held 13:00 @Europe/Athens
> time, and you do not really follow Singapore government politics on
> time zones. Then, one year Singapore government decides to switch
> the time zone to UTC+7. Your TZDB will get updated, but you may
> still miss the meeting even though Org agenda will display the
> correct new local meeting time of 14:00 @Europe/Athens. It would be
> useful if Org could notify the users about such changes.

You are explaining situation with 2 timestamps. 

It is either the timestamp: [2024-01-02 19:00 > @Asia/Singapore]
or Europe/Athens timestamp.

Once you have the timestamp [2024-01-02 19:00 > @Asia/Singapore]
I expect that such may be seen in future Org program, in local time.

To see it in local time program would know the future UTC offset, and
convert it to local time.

I will never miss the meeting provided program consults TZ database.

But if I have 2 timestamps, that is different situation.

You need no UTC offset for future time representation.

Also good to read:
https://engineering.q42.nl/why-always-use-utc-is-bad-advice/

Also good to read:
https://swizec.com/blog/saving-time-in-utc-doesnt-work-and-offsets-arent-enough/

where it says:

The correct way to send "Wednesday at 3pm in San Francisco" looks like this:

{ ...
    timestamp: {
        time: '2022-03-16T15:00:00`
        tz: 'America/Los_Angeles'
    }
}

They also do not provide UTC offset. And none provides UTC time with offset.

-- 
Jean

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

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