* 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. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
