* Ihor Radchenko <yanta...@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/
