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

[Ihor Radchenko <yantar92@posteo.net>]

Jean Louis <bugs@gnu.support> writes:

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

It is how ISO8601 defines offsets.

> Here is suggestion:
> -------------------
>
> 1. Convert local time timestamp to UTC
> 2. Add 10024 hours
> 3. Provide timestamp in UTC

This will involve converting time, which is prone to errors. I still
think that sometimes it is more convenient for human to use familiar
time zone and fix the offset for future.

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

icalendar is _not_ the only time spec around. We can take it into
account, but I do not see any reason to follow it blindly.

Reading the linked RFC spec, I did note that the motivation for the time
format used in calendar is mainly scheduling meetings for people
residing in different time zones. I can see how the icalendar format is
reasonable within that specific purpose. I cannot see why Org timestamps
should be limited to meetings.

Note that the idea with (optionally) providing two time zones/offsets is
also coming from a time spec in
https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/

Considering that the idea with "!" has been independently proposed
within the current discussion, I assess that allowing two time zones can
be useful.

Please remember that this format is optional. If it is not useful for
your use cases, feel free to specify a single time zone.

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

And I did, in one of the previous replies - scientific experiment.
Another example can be solar eclipse.

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

For Org, the aim is not to rely solely on programmatically calculating
time in current time zone. It should be possible to create timestamps
readable in raw text. UTC may be readable for some people, but not for
others. Of course, you can put UTC timestamps in your files, if you
prefer. But more general timestamp format should permit different use
cases.

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

Yes. Either way, the timestamp should follow some format defined
in 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?

To get notified about the change.

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

It may or may not be displayed. Because Org should be readable as plain
text.

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

This is ambiguous. 12:00 which time zone? GTM+08? America/Vancouver?

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

Sorry but I still don't understand.
For me, -08 is GMT+08 nautical time zone. Short form.
America/Vancouver is a time zone.
What is America/Vancouver/UTC-FIXED?

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

iCalendar is not the only source of truth. The suggested offsets are
what ISO8601 defines. iCalendar explicitly disregards the fixed offsets
for some iCalendar-specific reasons. It is iCalendar that is not being
aligned with more common standard.

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

Your statement is true only when TZ database is guaranteed to be
up-to-date. It is not always the case. Consider opening an Org document
on machine with out-of-date TZ database.

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

You will not. But I can see myself missing the meeting and assuming the
time "as usual".

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

The second link illustrates exactly UTC offset + also time zone name.
Similar to what I proposed.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>