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

* Heinz Tuechler <tuechler@gmx.at> [2023-02-14 12:44]:
> Jean Louis wrote/hat geschrieben on/am 14.02.2023 07:00:
> > * tomas@tuxteam.de <tomas@tuxteam.de> [2023-02-12 16:50]:
> > > On Sun, Feb 12, 2023 at 12:33:40PM +0300, Jean Louis wrote:
> > > > * Ihor Radchenko <yantar92@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/