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

* Max Nikulin <manikulin@gmail.com> [2023-02-14 14:45]:
> On 14/02/2023 16:45, tomas@tuxteam.de wrote:
> > On Tue, Feb 14, 2023 at 10:41:38AM +0100, Heinz Tuechler wrote:
> > > Jean Louis wrote/hat geschrieben on/am 14.02.2023 07:00:
> > > > Then just representation must be clear: @UTC is unclear in those
> > > > cases, but @RELTOUTC would be clear.
> > > 
> > > @RELTOUTC seems unfortunate, as it states only the obvious. If at all,
> > > it should be @AHEADUTC or @BEHINDUTC or some abbreviation of it, but as
> > > said above, it seems not necessary to me.
> > 
> > That's what the "+" and "-" do, anyway.
> 
> TZ=Etc/GMT-8 date '+%F %a %T %z %Z'
> 2023-02-14 Tue 19:37:01 +0800 +08
> 
> TZ=Etc/GMT+8 date '+%F %a %T %z %Z'
> 2023-02-14 Tue 03:38:24 -0800 -08
> 
> Notice sign in time zone identifier is opposite to time offset. However I am
> against RELTOUTC/AHEADUTC/BEHINDUTC. From my point of view +0800/-0800 is
> clear enough.
> 
> P.S. Last +08/-08 are really time zone abbreviations, not offset, however
> unlike "BST" & Co. they are acceptable to specify offset
> unambiguously.

That is different use case Max. 

For this use case I am in full agreement, that is what is used anyway
worldwide.

What Ihor proposed is time stamp like:

 2023-02-14 Tue 12:00:00 +0800 @UTC

Though I just say when we put "UTC" that means normally "UTC time
zone" and such has no prefix that is positive or negative, can be
zero.

-- 
Jean

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

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