Jean Louis <bugs@gnu.support> writes:
* Max Nikulin <maniku...@gmail.com> [2023-02-14 14:45]:
On 14/02/2023 16:45, to...@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.
Sigh. UTC is not a time zone.
All the best,
Tom
--
Thomas S. Dye
https://tsdye.online/tsdye
