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-01-31 14:48]:
> I will not follow the standards fully because the available standards
> are not designed to be easily understood by humans.

Very right, thank you.

> 1. https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/
>    2022-07-08T02:14:07+02:00[Europe/Paris]

The above looks nice, though not as clear from human view point as
compared to standard Org time stamps, which are very readable.

> 2. https://www.loc.gov/standards/datetime/ does not contain any new

I would disregard above, as that is US government, not international
document. Reason why they use UTC offset alone is that they decided
they do not need more than that.

Org is international and should not be bound to US only.

>    YYYY-MM-DD [optional day name] HH:MM[^ \]>]*?[+-−]HH[MM]?
>    YYYY-MM-DD [optional day name] HH:MM[^ \]>]*?Z[ \]>]

>    Examples:
>    2022-11-12 12:00+02 # 12:00 UTC+2
>    2022-11-12 14:00+0230 # 14:00 UTC+2:30
>    2022-11-12 14:00-0230 # 14:00 UTC-2:30
>    2022-11-12 14:00Z # 14:00 UTC

It looks nice, but I have demonstrated that calculations by using UTC
offset can't be accurate.

Please disprove and rectify me, by using practical examples, you could
disprove my practical example offered previously.

>    For time ranges, we will only allow a single offset and time zone
>    specifier for both start and end times:
>    [2022-11-12 8:00-9:00+08]
>    If different time zones are necessary to specify the start/end times,
>    users can still use full timestamp range syntax
>    [2022-11-12 8:00+03]--[2022-11-12 22:00+08]

I have already explained today that above calculation cannot be
unambigous. Please verify my references and practical examples. When
user thinks that span is X hours, the real span could be X-1 or X+1

> 3. (1) and (2) can be combined
> 
>    2022-11-12 12:00+08 @Asia/Singapore

That is how it should be, the UTC offset combined, with the time zone. 

And I suggest avoiding such timestamps by default, rather using time
stamps as usual, and having heading time zone property, file time zone
property and Org using system time zone in absence of any of them.

Providing practical example or functions on how to calculate it should
give better feeling which way will be better.

This is very simple timestamp, readable, with weekday:

<2023-01-31 Tue 16:13>

I propose to remain that way, how it is, with addition:

1. If user wish, could add time zone, including UTC offset. Adding
   only UTC offset makes no sense, and adding time zone without UTC
   offset will cause difficulties in future. Thus:

<2023-01-31 Tue 16:13+03 @Africa/Nairobi>

2. Otherwise heading could have time stamp when necessary to
   distinguish it from other headings:

* My heading
  :PROPERTIES:
  :TIMEZONE: +03 @Africa/Nairobi
  :END:

Then this time stamp <2023-01-31 Tue 16:13> would 

3. Otherwise file could have time stamp, if necessary to distinguish
   it from other files on the same system:

#+TIMEZONE: +03 @Africa/Nairobi

4. Otherwise system time zone

That way you only upgrade time stamps with UTC offset and time zone,
only when necessary, leaving everything else how it is, with addition
of better calculations and related functions.

All of the timestamps, including those simple existing one like
<2023-01-31 Tue 16:21> in Org can be made unambigous in their
representation or exchange by using UTC offset, plus the time zone, by
using those properties.

And very good reference on that link:
https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/

Although serialization with offset time zones is supported in this
document for backwards compatibility with java.time.ZonedDateTime
[JAVAZDT], use of offset time zones is strongly discouraged.  In
particular, programs MUST NOT copy the UTC offset from a timestamp
into an offset time zone in order to satisfy another program which
requires a time zone annotation in its input.  Doing this will
improperly assert that the UTC offset of timestamps in that location
will never change, which can result in incorrect calculations in
programs that add, subtract, or otherwise derive new timestamps from
the one provided.  For example, 2020-01- 01T00:00+01:00[Europe/Paris]
will let programs add six months to the timestamp while adjusting for
Summer Time (Daylight Saving Time).  But the same calculation applied
to 2020-01-01T00:00+01:00[+01:00] will produce an incorrect result
that will be off by one hour in the timezone Europe/Paris.


-- 
Jean

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

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