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

[Max Nikulin]

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.