On 10/02/2023 10:29, Jean Louis wrote:
2030-02-09 12:00 -08 @UTC -- this time CANNOT be said to be "fixed
UTC"
I do not see any reason why obviously invalid timestamp draws so much
attention.
Resolution may be rather concise: behavior is *undefined* since field
values are mutually inconsistent. Perhaps implementation may prefer to
treat it as 2030-02-09T12:00:00-0800 discarding UTC as time zone
specifier. `org-lint' should issue a warning requesting a user action.
Could you explain what is wrong with the following (without timezone)?
2030-02-09 12:00 -0800
I consider it as an unambiguous equivalent of 2030-02-09T20:00:00Z that
is a UTC timestamp. The format with explicit offset may be convenient
for a person living in an area that *likely* will have -08:00 offset and
who would like to watch some astronomical event such as lunar eclipse
and who had a plan to connect to some telescope on the opposite side of
the globe. Event time will not change if local time changed. Both
variants 2030-02-09T12:00:00-0800 and 2030-02-09T20:00:00Z may be
presented as "2030-02-09 12:00" to users. If timezone offset is changed
both variants will converted to "13:00" or "11:00" depending on sign of
change. So the format with offset is human friendly because it gives a
hint concerning *probable* value of local time still remaining *precise*
in respect to UTC.
I find the following as acceptable, but confusing to some degree:
2030-02-09 12:00 -08
just because "-08" is currently used in TZ database as time zone
abbreviation (a string similar to "BST"), not as offset that is
represented in wide spread formats as -0800 or -08:00. Unfortunately the
latter causes ambiguity in the context of Org.