* Heinz Tuechler <tuech...@gmx.at> [2023-02-14 12:44]: > Jean Louis wrote/hat geschrieben on/am 14.02.2023 07:00: > > * to...@tuxteam.de <to...@tuxteam.de> [2023-02-12 16:50]: > > > On Sun, Feb 12, 2023 at 12:33:40PM +0300, Jean Louis wrote: > > > > * Ihor Radchenko <yanta...@posteo.net> [2023-02-10 13:48]: > > > > > Jean Louis <bugs@gnu.support> writes: > > > > > > > > > > > If you start adding in Org "fixed" time with UTC offset, that is a > > > > > > new > > > > > > type of timestamp, as it is not common in world. > > > > > > > > > > It is how ISO8601 defines offsets. > > > > > > > > - did you say you wish to represent time with UTC time zone by using > > > > UTC offset? > > > > > > > > - and I said, UTC time is always without offset, and if any is > > > > represented then it must be +00 > > > > > > > > - and now you say that ISO8601 defines offsets... sorry, you are > > > > confusing me and readers. > > > > > > It is not about "the offset OF UTC". It is about "the offset > > > RELATIVE TO UTC". > > > > Yes, surely is clear to me personally. > > If 2022-11-12 12:00+02 # 12:00 UTC+2 should mean that local time is > 2022-11-12 12:00 and that it is 2 hours _ahead_ of UTC, then it seems > intuitively clear to me. I would assume that holds for many others > as well.
Exactly that. Never said anything different. Discussion started from something like this: 2022-11-12 12:00+02 @UTC and that is different case, where Ihor was suggesting that: 2022-11-12 12:00 is UTC time, not local time, where by +02 is offset (I say not UTC offset) to be added or deducted on that time. > > That we got for sure. > > > > 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. As idea I understand Ihor and other person on Internet. But as implementation by using @UTC or by using date time representation as UTC time with offset (not UTC offset), I think it will be confusing for people, unless there is new tag invented to make sure of it. Any idea is fine: 2022-11-12 12:00+02 @UTC-SUM 2022-11-12 12:00+02 @UTC-TO 2022-11-12 12:00+02 @TO-UTC but not 2022-11-12 12:00+02 @UTC As that would be confusing. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/