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:

>> > 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.
>
> Your answer is not related any more to @UTC time you were mentioning
> as now you are using "familiar time zone". I said, there is no offset
> representation with UTC time but +00. But it can be with other time
> zones.
>
> However, when you say "fix the offset for future" that does not
> work. If you do specify time zone, you are fixing it by time zone, and
> not by UTC offset, because it is less likely that the time zone
> definition changes, but UTC offset can change easier.
>
> The UTC offset is property of the time zone. The future time zone
> definition will know what is it's UTC offset.

UTC offset is indeed a property of the time zone.
However, UTC offset may be a subject of change in some time zones.
I am referring to "fixed" offsets to be specified by users and will
never change. These offsets are convenient to protect timestamp from
regulatory changes in time zones. Effectively, they are simply another,
sometimes convenient, way to represent UTC time.

Consider that you need to put a timestamp exactly 1 year from now, even
if time zone rules change. You are in +04 time zone at
[2023-03-08 14:00 @Asia/Istanbul].

You can write [2024-03-08 11:00 @Z] or you can write
[2024-03-08 14:00 @+03]. The latter is nothing but former, written
without a need to mentally convert back to UTC from your current wall
clock.

> You can introduce something new in Org and say "This is fixed UTC
> offset in time zone @ABC" but that way you are confusing yourself and
> future programmer and users, as it does not comply to already accepted
> international standards.
>
> iCalendar proposes different way of representation of time in future,haw
> that is, it could be UTC time in future, or it could be date, time and
> time zone. Using UTC offset for future is redundant, as in present
> time when you are writing future time stamp, you cannot know the
> future UTC offset.

iCalendar provides just two options: time zone name and UTC. It is ok
when the timestamps are written programmatically, but not ok when the
format should be writable by humans manually. I do not see why we should
force the users to convert to UTC manually in the above scenario.

>> 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.
>
> How about finding reasons why iCalendar specifies it that way?
>
> And then deciding if those reasons, not specification literally,
> should be followed?

Feel free to share the underlying logic if you are aware about it.
 
>> 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/
>
> ...
> Conclusion is that your reference is only partially relevant, as you
> may use it as guide for past timestamps, but not as guide for future
> time representation.

The cited document explicitly talks about timestamps in future. See 3.4.
Inconsistent time-offset/Time-Zone Information

> In my opinion people should be given the extended timestamp function
> in Org where they may choose the time zone.
>
> - no C-u prefix, interactive selection: <2023-02-12 Sun>
>
> - with C-u prefix, interactive, with time: <2023-02-12 Sun 11:09>
>
> - with double, C-u C-u, prefix, non-interactive with time: <2023-02-12 Sun 11:10>
>
> - but then I do not know what with 3 times C-u, some of those prefixes
>   could be used to let user choose the time zone

Sure, though I had a slightly different interface in mind. In any case,
it is too early to talk about interfaces. Let's finalize the syntax
first.

>> > 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?
>
> The sign "!" is telling "use time, not offset as authoritative". I do
> not say you should implement it this way, but I am saying it is wrong
> putting both the time and offset for future time, while you will not
> know the future offset with certainty.

Ok. I see the problem you referred to. We should then better stick to
the TEC's proposal here:

┌────
│ [2022-11-12 12:00 @+07,Asia/Singapore]  # warn when mismatch
│ [2022-11-12 12:00 @+07,!Asia/Singapore] # use Asia/Singapore over +07
│ [2022-11-12 12:00 @!+07,Asia/Singapore] # use +07 over Asia/Singapore
└────

The first timestamp is an error when time zone rules change.
In the two other timestamps, the complementary time zone is a redundant
information that does not affect how the timestamp is interpreted and
simply aids the human eye. Optionally, users could enable extra checking
with Org warning about inconsistency for the two latter kinds of
timestamps as well.

> It is not good specifying something in Org program and not clearly
> giving it to user what is authoritative.

Sure. The first kind of timestamp is to be left to users to enter
manually, when they need to. Automatic timestamps are of the other two
kinds.

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