Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Max Nikulin]

On 10/02/2023 10:29, Jean Louis wrote:

https://icalendar.org/iCalendar-RFC-5545/3-3-5-date-time.html

,
| The form of date and time with UTC offset MUST NOT be used. For
| example, the following is not valid for a DATE-TIME value:
|
|  19980119T23-0800   ;Invalid time format
`

As with the above format, author would maybe think it is alright, but
in general it is confusing. If author wish to specify UTC time, then
no offset shall be used.


RFC-5545 specifies a machine readable format. Org files are for humans 
even in raw text format. Decisions suitable for iCalendar are not always 
applicable for Org.


The timestamp in the examples follows ISO-8601 and I have no idea why it 
is confusing.


Offsets for RFC5545 means
- More code for parsing (negligible amount though)
- Due to wide spread confusions, an implementer may pretend that 
timezones are supported just because offsets are saved despite missed 
IANA TZ ID.


In respect to Org offsets and time zone identifiers are discussed in 
this thread in details. As a format for humans it should be more 
permissible and convenient for direct typing. There is no reason to 
insist on UTC where timestamps with fixed offsets are equally valid.

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Jean Louis  writes:

> Where you Ihor responded with this message:
> https://lists.gnu.org/archive/html/emacs-orgmode/2023-02/msg00018.html
>
>> [2022-11-12 14:00 @UTC+2]
>> [2022-11-12 14:00 @UTC-2:30]
>
>> are also fine within the proposed format.
>
> I am not sure what did you intend to show, did you intend to tell
> that:
>
> - 2022-11-12 14:00 @UTC+2 means 2022-11-12 12:00 @UTC ?
>
> In my understanding "@UTC" means "UTC time zone". From above first
> examples it is very confusing to use "UTC" as designation plus
> positive or negative prefix.
>
> It is not common to represent it that way. As if there is any
> designation for UTC, like "UTC" or "@UTC" or "Z", then there is no
> prefix shown, or if any, there will be zero.
>
> And I said, representing time that way by mixing word "UTC" with
> prefix would be confusing, as that practically creates new type of
> time representation that is not ordinarily used.

I mostly wanted to refer to TZ POSIX variable format, which allows
"ABBREVIATION+OFFSET" format. "UTC" is actually ignored there.

Further discussion revealed that UTC+2 is, in fact, even confusing. For
you and also because POSIX uses reversed symbol convention with +2 in TZ
referring to "time 2 hours __before__ UTC time".

@UTC+2 is not something we will recommend. It will be technically
POSIX-complaint, just as @BLAH-1 would be. Either one does not make
much sense.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Jean Louis  writes:

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

No, I did not mean that. It looks like the main reason why we
misunderstand each other.

I also do not recall providing such example.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Jean Louis]

* Ihor Radchenko  [2023-03-08 16:29]:
> > The UTC offset is property of the time zone. The future time zone
> > definition will know what is it's UTC offset.
> 
> UTC offset is indeed a property of the time zone.
> However, UTC offset may be a subject of change in some time zones.

Yes, and that is what I was stating. What we were arguing about is
rather notation.

> I am referring to "fixed" offsets to be specified by users and will
> never change. 

"Fixed" offset is IMHO wrong designation. What you want to say is "UTC
time". Don't use any offsets with UTC time as not to confuse
people. Use local time representation of UTC timestamps. For UTC
timestamp there is no problem to be in future or in past.

> These offsets are convenient to protect timestamp from regulatory
> changes in time zones.

UTC time is convenient.

But if you intend to represent time with time stamps, fixing some "UTC
offsets" to get "UTC time" representation, I do not see how it is
convenient for anybody.

> Effectively, they are simply another, sometimes convenient, way to
> represent UTC time.

Just use UTC time to tell what "fixed" time, and do not use "UTC
offsets" as they are by convention changeable.

> Consider that you need to put a timestamp exactly 1 year from now, even
> if time zone rules change. You are in +04 time zone at
> [2023-03-08 14:00 @Asia/Istanbul].

No matter in which time zone I am, one year from now depends on how
year is calculated

If current timestamp at UTC time is:
2023-03-10 01:08:07
then one year from now is:
2024-03-10 01:08:07

> You can write [2024-03-08 11:00 @Z] or you can write
> [2024-03-08 14:00 @+03]. The latter is nothing but former, written
> without a need to mentally convert back to UTC from your current wall
> clock.

I understand and I do not agree to that notation for reason that it is
confusing, but you please do how you wish.

UTC offset is shown to user in many applications depending on user's
time zone, while time that is fixed is static designation.

I would agree to such notation only if UTC time is written in Org
file, but you provide representation of UTC time showing the UTC
offset.

I see now use of providing "UTC time" with "UTC offset" as that is
beyond conventions.

Then we are speaking out of the reality of what people agreed on this
planet, and people agreed not to use any offsets with UTC time. It is
either UTC time without offset or offset zero, or no offset at all.

But of course Org can be the playground to do what one wish and want.

> > You can introduce something new in Org and say "This is fixed UTC
> > offset in time zone @ABC" but that way you are confusing yourself and
> > future programmer and users, as it does not comply to already accepted
> > international standards.
> >
> > iCalendar proposes different way of representation of time in future,haw
> > that is, it could be UTC time in future, or it could be date, time and
> > time zone. Using UTC offset for future is redundant, as in present
> > time when you are writing future time stamp, you cannot know the
> > future UTC offset.
> 
> iCalendar provides just two options: time zone name and UTC. It is ok
> when the timestamps are written programmatically, but not ok when the
> format should be writable by humans manually. I do not see why we should
> force the users to convert to UTC manually in the above scenario.

While I cannot see the context of the above statement, I have never
had any idea of letting user convert some timestamps manually, that is
why computers are there to provide timestamps. I don't do that manually.

> >> icalendar is _not_ the only time spec around. We can take it into
> >> account, but I do not see any reason to follow it blindly.
> >
> > How about finding reasons why iCalendar specifies it that way?
> >
> > And then deciding if those reasons, not specification literally,
> > should be followed?
> 
> Feel free to share the underlying logic if you are aware about it.

Which indicates you did not do the homework.

> >> > 4. Hypothetical example of clear timestamp for future:
> >> >[2024-02-04 12:00! @-08,America/Vancouver]
> >> >where the time would be stamped with "!" and that would mean that in 
> >> > the time zone, meeting is at 12 o'clock.
> >> >It would assume that UTC offset can change in future, but 12:00 clock 
> >> > would be authoritative time for future.
> >> 
> >> This is ambiguous. 12:00 which time zone? GTM+08? America/Vancouver?
> >
> > The sign "!" is telling "use time, not offset as authoritative". I do
> > not say you should implement it this way, but I am saying it is wrong
> > putting both the time and offset for future time, while you will not
> > know the future offset with certainty.
> 
> Ok. I see the problem you referred to. We should then better stick to
> the TEC's proposal here:
> 
> ┌
> │ [2022-11-12 12:00 @+07,Asia/Singapore]  # warn when mismatch
> │ [2022-11-12 12:00 @+07,!Asia/Singapore] # use Asia/Singapore over +07
> │ [2022-11-12 

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Jean Louis  writes:

>> > Here is suggestion:
>> > ---
>> >
>> > 1. Convert local time timestamp to UTC
>> > 2. Add 10024 hours
>> > 3. Provide timestamp in UTC
>> 
>> This will involve converting time, which is prone to errors. I still
>> think that sometimes it is more convenient for human to use familiar
>> time zone and fix the offset for future.
>
> Your answer is not related any more to @UTC time you were mentioning
> as now you are using "familiar time zone". I said, there is no offset
> representation with UTC time but +00. But it can be with other time
> zones.
>
> However, when you say "fix the offset for future" that does not
> work. If you do specify time zone, you are fixing it by time zone, and
> not by UTC offset, because it is less likely that the time zone
> definition changes, but UTC offset can change easier.
>
> The UTC offset is property of the time zone. The future time zone
> definition will know what is it's UTC offset.

UTC offset is indeed a property of the time zone.
However, UTC offset may be a subject of change in some time zones.
I am referring to "fixed" offsets to be specified by users and will
never change. These offsets are convenient to protect timestamp from
regulatory changes in time zones. Effectively, they are simply another,
sometimes convenient, way to represent UTC time.

Consider that you need to put a timestamp exactly 1 year from now, even
if time zone rules change. You are in +04 time zone at
[2023-03-08 14:00 @Asia/Istanbul].

You can write [2024-03-08 11:00 @Z] or you can write
[2024-03-08 14:00 @+03]. The latter is nothing but former, written
without a need to mentally convert back to UTC from your current wall
clock.

> You can introduce something new in Org and say "This is fixed UTC
> offset in time zone @ABC" but that way you are confusing yourself and
> future programmer and users, as it does not comply to already accepted
> international standards.
>
> iCalendar proposes different way of representation of time in future,haw
> that is, it could be UTC time in future, or it could be date, time and
> time zone. Using UTC offset for future is redundant, as in present
> time when you are writing future time stamp, you cannot know the
> future UTC offset.

iCalendar provides just two options: time zone name and UTC. It is ok
when the timestamps are written programmatically, but not ok when the
format should be writable by humans manually. I do not see why we should
force the users to convert to UTC manually in the above scenario.

>> icalendar is _not_ the only time spec around. We can take it into
>> account, but I do not see any reason to follow it blindly.
>
> How about finding reasons why iCalendar specifies it that way?
>
> And then deciding if those reasons, not specification literally,
> should be followed?

Feel free to share the underlying logic if you are aware about it.
 
>> Note that the idea with (optionally) providing two time zones/offsets is
>> also coming from a time spec in
>> https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/
>
> ...
> Conclusion is that your reference is only partially relevant, as you
> may use it as guide for past timestamps, but not as guide for future
> time representation.

The cited document explicitly talks about timestamps in future. See 3.4.
Inconsistent time-offset/Time-Zone Information

> In my opinion people should be given the extended timestamp function
> in Org where they may choose the time zone.
>
> - no C-u prefix, interactive selection: <2023-02-12 Sun>
>
> - with C-u prefix, interactive, with time: <2023-02-12 Sun 11:09>
>
> - with double, C-u C-u, prefix, non-interactive with time: <2023-02-12 Sun 
> 11:10>
>
> - but then I do not know what with 3 times C-u, some of those prefixes
>   could be used to let user choose the time zone

Sure, though I had a slightly different interface in mind. In any case,
it is too early to talk about interfaces. Let's finalize the syntax
first.

>> > 4. Hypothetical example of clear timestamp for future:
>> >[2024-02-04 12:00! @-08,America/Vancouver]
>> >where the time would be stamped with "!" and that would mean that in 
>> > the time zone, meeting is at 12 o'clock.
>> >It would assume that UTC offset can change in future, but 12:00 clock 
>> > would be authoritative time for future.
>> 
>> This is ambiguous. 12:00 which time zone? GTM+08? America/Vancouver?
>
> The sign "!" is telling "use time, not offset as authoritative". I do
> not say you should implement it this way, but I am saying it is wrong
> putting both the time and offset for future time, while you will not
> know the future offset with certainty.

Ok. I see the problem you referred to. We should then better stick to
the TEC's proposal here:

┌
│ [2022-11-12 12:00 @+07,Asia/Singapore]  # warn when mismatch
│ [2022-11-12 12:00 @+07,!Asia/Singapore] # use Asia/Singapore over +07
│ [2022-11-12 12:00 @!+07,Asia/Singapore] # use +07 over Asia/Singapore
└

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Jean Louis]

* Ihor Radchenko  [2023-02-15 18:17]:
> Jean Louis  writes:
> 
> > That is not same case as Ihor, when he designated it as 
> >
> > 2030-02-09 12:00 -0800 @UTC
> > because there are no offsets @UTC time zone.
> 
> I do not recall providing such example. May you point me to the message
> where you saw me writing -0800 @UTC?

Discussion on "@UTC" stated with this message by Christian:
https://lists.gnu.org/archive/html/emacs-orgmode/2023-02/msg00016.html

Theses were examples shown:

>Examples:
>2022-11-12 12:00+02 # 12:00 UTC+2
>2022-11-12 14:00+0230 # 14:00 UTC+2:30
>2022-11-12 14:00-0230 # 14:00 UTC-2:30
>2022-11-12 14:00Z # 14:00 UTC

Those examples are correct but there is comment "#" which was talking
about prefixes, only for understanding.

Examples without comments are:

>2022-11-12 12:00+02
>2022-11-12 14:00+0230 
>2022-11-12 14:00-0230 
>2022-11-12 14:00Z 

As you can see there is "Z" as designation for UTC time. When there is
designation for UTC time, no prefix is mentined.

You may observe that UTC prefixes in those examples are mentioned with
positive or negative prefixes, but there is no designation for "UTC",
as that would become confusing.

Which is what I was speaking about.

Where you Ihor responded with this message:
https://lists.gnu.org/archive/html/emacs-orgmode/2023-02/msg00018.html

> [2022-11-12 14:00 @UTC+2]
> [2022-11-12 14:00 @UTC-2:30]

> are also fine within the proposed format.

I am not sure what did you intend to show, did you intend to tell
that:

- 2022-11-12 14:00 @UTC+2 means 2022-11-12 12:00 @UTC ?

In my understanding "@UTC" means "UTC time zone". From above first
examples it is very confusing to use "UTC" as designation plus
positive or negative prefix.

It is not common to represent it that way. As if there is any
designation for UTC, like "UTC" or "@UTC" or "Z", then there is no
prefix shown, or if any, there will be zero.

And I said, representing time that way by mixing word "UTC" with
prefix would be confusing, as that practically creates new type of
time representation that is not ordinarily used.

-- 
Jean

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

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

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Jean Louis]

* Thomas S. Dye  [2023-02-14 19:50]:
> > 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.

I cannot know what you mean and in which context.

I can tell you to look here:
https://en.wikipedia.org/wiki/List_of_tz_database_time_zones

which is the context for computer time, or TZ database time zones,
where you may find Etc/UTC as time zone.

I can tell that in the context of the PostgreSQL database, "UTC" is
time zone, as following works well:

SELECT current_timestamp AT TIME ZONE 'UTC';

  timezone  

 2023-02-16 14:13:37.837977
(1 row)

SELECT CURRENT_TIMESTAMP;

   CURRENT_timestamp   
---
 2023-02-16 17:13:42.709239+03

There are differen time zones' categories:
https://en.wikipedia.org/wiki/Lists_of_time_zones

In military context:
https://en.wikipedia.org/wiki/List_of_military_time_zones

It is called "Zulu Time Zone" or "Z"

Then in this context:
https://en.wikipedia.org/wiki/List_of_time_zone_abbreviations

There is abbreviation "UTC" if you look there.

So, yes I do agree that UTC is "not time zone", but I do not know in
which context you mean. As in many common contexts the UTC is the time
zone.


-- 
Jean

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

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

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Jean Louis  writes:

> That is not same case as Ihor, when he designated it as 
>
> 2030-02-09 12:00 -0800 @UTC
> because there are no offsets @UTC time zone.

I do not recall providing such example. May you point me to the message
where you saw me writing -0800 @UTC?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Max Nikulin]

On 14/02/2023 22:59, Jean Louis wrote:

What Ihor proposed is time stamp like:

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


I am not sure that combination of +0800 and UTC was intentional. The 
following is redundant, but there is nothing wrong while offset and time 
zone identifier are in agreement:


2023-02-14 Tue 12:00:00 +0800 @Asia/Singapore

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Thomas S. Dye]

Jean Louis  writes:


* Max Nikulin  [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

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Jean Louis]

* Max Nikulin  [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/

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[tomas]

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.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Jean Louis]

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

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Max Nikulin]

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.

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Heinz Tuechler]

Jean Louis wrote/hat geschrieben on/am 14.02.2023 07:00:

* to...@tuxteam.de  [2023-02-12 16:50]:

On Sun, Feb 12, 2023 at 12:33:40PM +0300, Jean Louis wrote:

* Ihor Radchenko  [2023-02-10 13:48]:

Jean Louis  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.



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.

Heinz

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Jean Louis]

* to...@tuxteam.de  [2023-02-12 16:50]:
> On Sun, Feb 12, 2023 at 12:33:40PM +0300, Jean Louis wrote:
> > * Ihor Radchenko  [2023-02-10 13:48]:
> > > Jean Louis  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. 

That we got for sure.

Then just representation must be clear: @UTC is unclear in those
cases, but @RELTOUTC would be clear.

-- 
Jean

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

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

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[tomas]

On Sun, Feb 12, 2023 at 12:33:40PM +0300, Jean Louis wrote:
> * Ihor Radchenko  [2023-02-10 13:48]:
> > Jean Louis  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".

Sorry for raising my voice :-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ypo]

t; as that is time zone. You have to invent how to
represent it, that is unmistakable to other representations.

--
Jean

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

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


*From*: Jean Louis
*Subject*: 	Re: [POLL] Proposed syntax for timestamps with time zone 
info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps 
and org-agenda)

*Date*: Sun, 12 Feb 2023 13:32:21 +0300
*User-agent*:   Mutt/2.2.9+54 (af2080d) (2022-11-21)

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Jean Louis]

* Max Nikulin  [2023-02-11 07:47]:
> On 10/02/2023 10:29, Jean Louis wrote:
> > 2030-02-09 12:00 -08 @UTC -- this time CANNOT be said to be "fixed
> > UTC"
> 
> I do not see any reason why obviously invalid timestamp draws so much
> attention.
> 
> Resolution may be rather concise: behavior is *undefined* since field values
> are mutually inconsistent. Perhaps implementation may prefer to treat it as
> 2030-02-09T12:00:00-0800 discarding UTC as time zone specifier. `org-lint'
> should issue a warning requesting a user action.

Thank you!

I have demonstrated that Etar application from F-Droid would disregard
what is invalid and basically only enter valid time. Same for Google
calendar, it would disregard invalid timestamp (even though not
represented as above), and it would enter only valid one. PostgreSQL
will "silently" ignore what does not belong to it.

One can search for "silent" here:
https://www.postgresql.org/docs/current/datatype-datetime.html

> Could you explain what is wrong with the following (without timezone)?
> 
> 2030-02-09 12:00 -0800
> 
> I consider it as an unambiguous equivalent of 2030-02-09T20:00:00Z that is a
> UTC timestamp.

That is not same case as Ihor, when he designated it as 

2030-02-09 12:00 -0800 @UTC
because there are no offsets @UTC time zone.

In this different case you wish to say that it is:

time of 2030-02-09 12:00 -0800 whereby -0800 is UTC offset from floating time
2030-02-09 12:00, and one can derive UTC time.

That is totally alright as representation of time. That is how past
timestamps are represented in local time.

Why not -- you can use it for future.

I find it less useful for exchange purposes, almost useless, but you
can do. Because if you store time as UTC, you can always see local
time anywhere in the world. But if programmers wish to do that to Org,
okay fine.

It is different time type representation, that does not exist in ISO
8601, but why not, you can include it in Org.

You just be sure that you put a "tag" or such representation that
users will know what is it, even from plain text.

> The format with explicit offset may be convenient for a person
> living in an area that *likely* will have -08:00 offset and who
> would like to watch some astronomical event such as lunar eclipse
> and who had a plan to connect to some telescope on the opposite side
> of the globe. Event time will not change if local time changed. Both
> variants 2030-02-09T12:00:00-0800 and 2030-02-09T20:00:00Z may be
> presented as "2030-02-09 12:00" to users.

And now you speak of presentation. But then why store it with
2030-02-09T12:00:00-0800 when you can store it as 2030-02-09T20:00:00Z
and have representation be same "2030-02-09 12:00" to users.

So that is only addition to programmer.

Remember that not even databases store the time like that. It is
either UTC time, or date, time, and some time zone stored separately.

> If timezone offset is changed both variants will converted to
> "13:00" or "11:00" depending on sign of change.

Correct. I understand you want to say that representation of time for
that UTC time zone will be modified depnding of change, and that is
correct.

> So the format with offset is human friendly because it gives a hint
> concerning *probable* value of local time still remaining *precise*
> in respect to UTC.

This representation of time is human friendly:
2030-02-09 12:00 -0800 and that is the way how I daily see my
timestamps, like this: 2023-02-12 12:59:52.839773+03
which does not differ much from that one.

However, my timestamp is only represented with +03 UTC offset. It is
not stored with UTC offset.

Storing values is not equal to representing values.

- In other software values are not stored as "UTC time that has
  offset"

- It is stored as "UTC time"

- Offset is calculated from time zone and represented to user.

Of course you need not follow what other software does.

Though I think you need rather exact designation for users to
unmistakably can understand what you mean with it:

- Right now when I press C-c . I get: <2023-02-12 Sun>

- C-u C-c . and I get <2023-02-12 Sun 13:03>

- Then I can think you (developers) will invent something like:
  <2023-02-12 Sun 13:03 @Europe/Berlin> (whereby one has to avoid
  invalid time stamps), which is UTC time: 2023-02-12 12:03:00

- Then I can think you would invent time stamp which you proposed,
  something like: <2023-02-12 12:00 -08:00> which in this case cannot
  have day representation, as one cannot know which day is that,
  right?

  And in this case that timestamp would mean it is 20:00 o'clock UTC
  time.

  And which can be replaced with <2023-02-12 20:00 @UTC>

  I am just not sure if that will be enough human friendly to say:
  <2023-02-12 12:00 -08:00> to people, as there is no designation that
  it is UTC time, and one cannot use "@UTC" as that would be wrong.

  Maybe designation is not necessary?
  
When we consider how good calendars work, they will always ask user
for the 

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Jean Louis]

* Ihor Radchenko  [2023-02-10 13:48]:
> Jean Louis  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.

Please see here:
https://en.wikipedia.org/wiki/ISO_8601

on right side, there is representation of UTC time:
Date and time in UTC
2023-02-12T06:45:15+00:00
2023-02-12T06:45:15Z
20230212T064515Z

Do you see? There is no offset larger or smaller than zero.

We were discussing of a time stamp at @UTC time zone with offset!

That type of a timestamp does not exist.

What exists with positive or negative offset is timestamp with time
zone other but UTC.

But not with UTC.

If you do introduce positive or negative offsets at UTC time zone, you
are introducing something new in Org. It is not necessarily bad, but
IMHO you will create more confusion, for no good reason.

> > Here is suggestion:
> > ---
> >
> > 1. Convert local time timestamp to UTC
> > 2. Add 10024 hours
> > 3. Provide timestamp in UTC
> 
> This will involve converting time, which is prone to errors. I still
> think that sometimes it is more convenient for human to use familiar
> time zone and fix the offset for future.

Your answer is not related any more to @UTC time you were mentioning
as now you are using "familiar time zone". I said, there is no offset
representation with UTC time but +00. But it can be with other time
zones.

However, when you say "fix the offset for future" that does not
work. If you do specify time zone, you are fixing it by time zone, and
not by UTC offset, because it is less likely that the time zone
definition changes, but UTC offset can change easier.

The UTC offset is property of the time zone. The future time zone
definition will know what is it's UTC offset.

You can introduce something new in Org and say "This is fixed UTC
offset in time zone @ABC" but that way you are confusing yourself and
future programmer and users, as it does not comply to already accepted
international standards.

iCalendar proposes different way of representation of time in future,haw
that is, it could be UTC time in future, or it could be date, time and
time zone. Using UTC offset for future is redundant, as in present
time when you are writing future time stamp, you cannot know the
future UTC offset.

> > Also look at this reference:
> > https://icalendar.org/iCalendar-RFC-5545/3-3-5-date-time.html
> >i
> > ,
> > | The form of date and time with UTC offset MUST NOT be used. For
> > | example, the following is not valid for a DATE-TIME value:
> > | 
> > |  19980119T23-0800   ;Invalid time format
> > `
> 
> > As with the above format, author would maybe think it is alright, but
> > in general it is confusing. If author wish to specify UTC time, then
> > no offset shall be used.
> 
> icalendar is _not_ the only time spec around. We can take it into
> account, but I do not see any reason to follow it blindly.

How about finding reasons why iCalendar specifies it that way?

And then deciding if those reasons, not specification literally,
should be followed?

> Reading the linked RFC spec, I did note that the motivation for the time
> format used in calendar is mainly scheduling meetings for people
> residing in different time zones.

And I think that is what we are talking about, about conclusive time
representation in cases where Org users need it. If meeting or not,
that is something for users to decide.

Important is only to define the types of time stamps, and then let
users use it.

Goal is to improve Org timestamps so that Org get feature of
conclusive time representation.

That means to me, that inconclusive, like floating timestamps can be
left how they are, only new are added.

For past time representation is best using UTC timestamp, as such can
easily be converted to local time. But how? Using overlays? Or
updating time stamps in buffer? Or using updated local time timestamps
in exports?

There is that time stamp for future, if it should not be floating or
non-conclusive, then you use date, time and time zone.

You insist on "fixing UTC time offset for time zone", but I do not
understand that reasoning, as it is contradictory to time zone
database use per se.

> I can see how the icalendar format is reasonable within that
> specific purpose. I cannot see why Org timestamps should be limited
> to meetings.

"Meeting" is not for Org to specify, that is for user to specify what
it is.

It need not be meeting, any future representation is quite different
from past.

Past timestamps are more conclusive, than future.

Past time zone databases already exists, TZ database is rarely updated
with past time zones, 

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Max Nikulin]

On 10/02/2023 10:29, Jean Louis wrote:

2030-02-09 12:00 -08 @UTC -- this time CANNOT be said to be "fixed
UTC"


I do not see any reason why obviously invalid timestamp draws so much 
attention.


Resolution may be rather concise: behavior is *undefined* since field 
values are mutually inconsistent. Perhaps implementation may prefer to 
treat it as 2030-02-09T12:00:00-0800 discarding UTC as time zone 
specifier. `org-lint' should issue a warning requesting a user action.


Could you explain what is wrong with the following (without timezone)?

2030-02-09 12:00 -0800

I consider it as an unambiguous equivalent of 2030-02-09T20:00:00Z that 
is a UTC timestamp. The format with explicit offset may be convenient 
for a person living in an area that *likely* will have -08:00 offset and 
who would like to watch some astronomical event such as lunar eclipse 
and who had a plan to connect to some telescope on the opposite side of 
the globe. Event time will not change if local time changed. Both 
variants 2030-02-09T12:00:00-0800 and 2030-02-09T20:00:00Z may be 
presented as "2030-02-09 12:00" to users. If timezone offset is changed 
both variants will converted to "13:00" or "11:00" depending on sign of 
change. So the format with offset is human friendly because it gives a 
hint concerning *probable* value of local time still remaining *precise* 
in respect to UTC.


I find the following as acceptable, but confusing to some degree:

2030-02-09 12:00 -08

just because "-08" is currently used in TZ database as time zone 
abbreviation (a string similar to "BST"), not as offset that is 
represented in wide spread formats as -0800 or -08:00. Unfortunately the 
latter causes ambiguity in the context of Org.

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Jean Louis  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.

> Here is suggestion:
> ---
>
> 1. Convert local time timestamp to UTC
> 2. Add 10024 hours
> 3. Provide timestamp in UTC

This will involve converting time, which is prone to errors. I still
think that sometimes it is more convenient for human to use familiar
time zone and fix the offset for future.

> Also look at this reference:
> https://icalendar.org/iCalendar-RFC-5545/3-3-5-date-time.html
>
> ,
> | The form of date and time with UTC offset MUST NOT be used. For
> | example, the following is not valid for a DATE-TIME value:
> | 
> |  19980119T23-0800   ;Invalid time format
> `

> As with the above format, author would maybe think it is alright, but
> in general it is confusing. If author wish to specify UTC time, then
> no offset shall be used.

icalendar is _not_ the only time spec around. We can take it into
account, but I do not see any reason to follow it blindly.

Reading the linked RFC spec, I did note that the motivation for the time
format used in calendar is mainly scheduling meetings for people
residing in different time zones. I can see how the icalendar format is
reasonable within that specific purpose. I cannot see why Org timestamps
should be limited to meetings.

Note that the idea with (optionally) providing two time zones/offsets is
also coming from a time spec in
https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/

Considering that the idea with "!" has been independently proposed
within the current discussion, I assess that allowing two time zones can
be useful.

Please remember that this format is optional. If it is not useful for
your use cases, feel free to specify a single time zone.

>> I would like to remind you that timestamps are not necessarily used for
>> meetings. And not always shared with other people.
>
> Ok, and I have asked you to provide practical examples.

And I did, in one of the previous replies - scientific experiment.
Another example can be solar eclipse.

> Timestamps for past time, like for logs, I always store as UTC time in
> database, with time zone (which does not mean that time zone is
> stored, but displayed in local time zone).

For Org, the aim is not to rely solely on programmatically calculating
time in current time zone. It should be possible to create timestamps
readable in raw text. UTC may be readable for some people, but not for
others. Of course, you can put UTC timestamps in your files, if you
prefer. But more general timestamp format should permit different use
cases.

> 1. [2024-02-04 12:00 @-08,America/Vancouver] you define that @-08 has
>priority, OK fine, but how does user sees that? Only by reading
>documentation?

Yes. Either way, the timestamp should follow some format defined
in documentation.

> 2. You wish to say it will be future time of 20:00 o'clock, but time
>zone definition can change, so if it can change, why use time zone
>definition?

To get notified about the change.

> 3. UTC offset is displayed for past, as such time is accurate, but if
>you display it for future, be aware that it is wrong for reason
>that you cannot know the UTC offset in future without time
>zone. Just display UTC time. Offset is not relevant, it will be
>displayed to every user in their local time anyway, once they get
>UTC.

It may or may not be displayed. Because Org should be readable as plain
text.

> 4. Hypothetical example of clear timestamp for future:
>[2024-02-04 12:00! @-08,America/Vancouver]
>where the time would be stamped with "!" and that would mean that in the 
> time zone, meeting is at 12 o'clock.
>It would assume that UTC offset can change in future, but 12:00 clock 
> would be authoritative time for future.

This is ambiguous. 12:00 which time zone? GTM+08? America/Vancouver?

>> > Maybe this way (hypothetically):
>> >
>> > [2024-02-04 12:00 @-08, America/Vancouver/UTC-FIXED]
>> >
>> > as that way you would give signal to program that you want UTC fixed
>> > time in future, and not 12:00 o'clock necessary.
>> 
>> I am sorry, but I don't understand what you mean by UTC-FIXED.
>
> You mentioned it, you wish to have offset and to remain UTC fixed.
>
> And UTC is not fixed, it is either UTC without offset, or time zone
> with UTC offset.
>
> But if you do wish, you have to make "tag" somehow, for computer
> program to know what you mean, "UTC-FIXED" is only hypothetical tag.

Sorry but I still don't understand.
For me, -08 is GMT+08 nautical time zone. Short form.
America/Vancouver is a time zone.
What is America/Vancouver/UTC-FIXED?

>> It is sometimes easier to define UTC time +offset instead of doing an
>> extra conversion in your head.
>
> I hope you understood the difference.
>
> Providing UTC time plus some offset is inconclusive. It is idea that
> is 

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Jean Louis]

* Ihor Radchenko  [2023-02-08 13:36]:
> > Is it Org as program?
> >
> > Or is it human?
> 
> Both.
> 
> The idea is to ensure exact point of time relative to UTC.
> For example, when you want to schedule something exactly 10024 hours in
> future, regardless of time zone changes.

I got it, thank you.

iCalendar allows UTC time. If you have UTC time, you need not have UTC
offset, as that is NOT what other programs are doing.

My recommendation is follow what is successful. If you wish to use UTC
time, use it, but no need to add offset as it will be confusing.

Timestamp is either in UTC or in other time zones. UTC time has no
offset.

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.

Here is suggestion:
---

1. Convert local time timestamp to UTC
2. Add 10024 hours
3. Provide timestamp in UTC

Also look at this reference:
https://icalendar.org/iCalendar-RFC-5545/3-3-5-date-time.html

,
| The form of date and time with UTC offset MUST NOT be used. For
| example, the following is not valid for a DATE-TIME value:
| 
|  19980119T23-0800   ;Invalid time format
`

As with the above format, author would maybe think it is alright, but
in general it is confusing. If author wish to specify UTC time, then
no offset shall be used.

> The same can be done by specifying the timestamp in UTC directly.

That is simplest.

> > Another program in future, and human, must know did the organizer of
> > event, had in mind:
> 
> I would like to remind you that timestamps are not necessarily used for
> meetings. And not always shared with other people.

Ok, and I have asked you to provide practical examples.

Calculation of time shall not be made for sake of sole calculation,
but for human and by considering use application.

Timestamps for past time, like for logs, I always store as UTC time in
database, with time zone (which does not mean that time zone is
stored, but displayed in local time zone).

However, future time to be coordinated with people, anything human
related, it has to be stored with date, time, and time zone in
separate fields. That way program in future will understand it.

Timestamp is in general always considered past, not future. That is
where the word comes from, the "stamp", if you stamp something, it is
on paper, when it was done. It is not about "When it will be".

https://en.wikipedia.org/wiki/Timestamp

A timestamp is a sequence of characters or encoded information
identifying when a certain event occurred, usually giving date and
time of day, sometimes accurate to a small fraction of a second

We have to distinguish in Org what we are doing here, and meaning with
"timestamp", as in Org context, timestamp is more than just time when
something occured.

In Org context there is new type of "timestamp" which is meant for
future.

Timestamp for past -- should be as accurate as possible in general
applications.

Practical example of a timestamp: I enter person's contact details,
the moment I enter such details, the timestamp is created. It is not
100% accurate to the event that really has taken place, as computer
user need some time to write first name, last name of person, it is
"about". But for the sole entry of the data in database, that
timestamp is pretty accurate.

Timestamp for future is not really timestamp, it is intended time, in
many applications it cannot be accurate. 

The last example on the page:
https://icalendar.org/iCalendar-RFC-5545/3-3-5-date-time.html
gives good clues how to specify date and time in future.

> > I find such situations rather easy to solve with database:
> >
> > - I can have column like "timestamp" with UTC time or local time plus
> >   UTC offset, and if I did not enter any other information, that UTC
> >   offset is considered in future. Consider this column name
> >   "timestamp".
> >
> > - I can have column "time" and when such is entered, then date is
> >   extracted from "timestamp" column, and combined with time. In this
> >   case UTC is only calculated in new time point but not used as period
> >   from past to appointment time.
> >
> > - I can have time zone for the future, if I enter such in other
> >   column, the future calculation must use that proper time zone. 
> 
> Sorry, I do not understand what you are trying to explain here. Would
> you mind showing an example?

The above quote came from explaining that you should not use "time
offset" to designate UTC time, as such offset will be mistaken in
future for "UTC offset". 

By doing that you are creating new type of time representation that is
not used anywhere else (for future purposes).

Example
---

2023-02-01 12:00 -08 @SomeTimeZone would mean that UTC offset at that
time and date was -08. One can derive UTC time easily and it will be
accurate.

2033-02-01 12:00 -08 @SomeTimeZone, means that one should consider
that @SomeTimeZone in future to first derive the UTC offset, as -08
can only be taken 

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Jean Louis  writes:

>> It means "when I scheduled this item, I expected the UTC offset at the
>> time of the timestamp to be -08 and remain so. It was motivated by
>> America/Vancouver time zone, but if it changes in future, I do not care
>> - the scheduled time should remain at specific time point relative to
>> UTC".
>
> I read, though sorry, I do not understand who is expected to think
> that UTC offset is fixed?
>
> Is it Org as program?
>
> Or is it human?

Both.

The idea is to ensure exact point of time relative to UTC.
For example, when you want to schedule something exactly 10024 hours in
future, regardless of time zone changes.

The same can be done by specifying the timestamp in UTC directly.

> Another program in future, and human, must know did the organizer of
> event, had in mind:

I would like to remind you that timestamps are not necessarily used for
meetings. And not always shared with other people.

> I find such situations rather easy to solve with database:
>
> - I can have column like "timestamp" with UTC time or local time plus
>   UTC offset, and if I did not enter any other information, that UTC
>   offset is considered in future. Consider this column name
>   "timestamp".
>
> - I can have column "time" and when such is entered, then date is
>   extracted from "timestamp" column, and combined with time. In this
>   case UTC is only calculated in new time point but not used as period
>   from past to appointment time.
>
> - I can have time zone for the future, if I enter such in other
>   column, the future calculation must use that proper time zone. 

Sorry, I do not understand what you are trying to explain here. Would
you mind showing an example?

> You said "I do not care", that means you as human decide that 
> [2024-02-04 12:00 @-08,America/Vancouver] will use fixed -8 offset
>
> But from where in such timestamp does user or program understand that?

>From syntax we are now defining, XX takes priority in @XX,YY.

> Maybe this way (hypothetically):
>
> [2024-02-04 12:00 @-08, America/Vancouver/UTC-FIXED]
>
> as that way you would give signal to program that you want UTC fixed
> time in future, and not 12:00 o'clock necessary.

I am sorry, but I don't understand what you mean by UTC-FIXED.

>> > The UTC offset is the log what was the UTC offset at the time point
>> > when timestamp was created, as future UTC offset cannot be known.
>> 
>> Sure. -08 is expected offset.
>
> If you wish to specify UTC time in future, no need to specify even any
> offset, but you can. 
>
> Look here in first example how event is defined by using UTC time:
> https://icalendar.org/iCalendar-RFC-5545/4-icalendar-object-examples.html

It is sometimes easier to define UTC time +offset instead of doing an
extra conversion in your head.

>> > Making it "fixed" does not fix it in real time, you are then
>> > introducing something new than what other programs do with time.
>> 
>> I do not understand this statement.
>
> Well to understand that, you have to make practical examples and
> understand what would human think in periods of time A, B, C, D, from
> creation of appointment, through possible changes of DST, time zone,
> UTC offset, to final appointment.
>
> Look here the second example of group-scheduled meeting that begins at
> 8:30 AM EST on March 12, 1998 and ends at 9:30 AM EST on March 12,
> 1998
> https://icalendar.org/iCalendar-RFC-5545/4-icalendar-object-examples.html
>
> DTSTART;TZID=America/New_York:19980312T083000
> DTEND;TZID=America/New_York:19980312T093000
> LOCATION:1CP Conference Room 4350

> The stuff with iCalendar works for reason that it is structured. The
> timestamp such as: DTSTART:19960918T143000Z will clearly say that time
> is specified in UTC time. No need for confusion with time zone.

> But if DTSTART has this: TZID=America/New_York:19980312T083000
>
> Then it becomes clear that it will be the UTC offset in future with
> assumed mentiond time zone.
>
> But if you mix UTC offset, plus the time zone for future, that makes
> little sense, unless you introduce some tags that timestamp is
> recognizable as using UTC time, or that it uses date/time and time

The problem being addressed with @+08,!Asia/Singapore is possible future
change in time zone. Imagine a yearly meeting you attend at
[2024-01-02 19:00 @Asia/Singapore,!+08] while living in Europe/Athens
(UTC +2). Over the years, you are used to meeting being held 13:00
@Europe/Athens time, and you do not really follow Singapore government
politics on time zones. Then, one year Singapore government decides to
switch the time zone to UTC+7. Your TZDB will get updated, but you may
still miss the meeting even though Org agenda will display the correct
new local meeting time of 14:00 @Europe/Athens. It would be useful if
Org could notify the users about such changes.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at 

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Jean Louis]

* ypuntot  [2023-02-05 16:03]:
> For the Poll, the Jeans proposal would be to introduce manually:
> [2024-02-04 12:00 @America/Vancouver]

I never recommend or recommended to anybody, ever, to make timestamps
manually. That is for computer to make it right.

For human, that is to use calendar. Calendar must use time zone
databases in background as to avoid placing invalid timestamps.

> And org to convert it into:
> [2024-02-04 12:00 @-08,America/Vancouver]

If we speak of future planning, general recommendation I have already
referenced is:

- to say date, time and time zone,

- while knowing one cannot know if time zone will exist in future

- while knowing UTC offset may be changed in future, for future
  timestamps for human meetings is not necessary and not absolutely
  possible to know UTC offset

- future time zone database could tell that time zone does not exist
  any more. It could maybe try to derive new time zone, but it is
  vague, as cities and countries could change.

- future time zone database can have the new updated UTC offset.

- if offset is placed in future timestamps, again the future time zone
  database should be consulted. Change of UTC offset would not
  humanely change the time of meeting. If time of meeting is 12
  o'clock, then it would remain same, no matter offset. But other
  participants would need to consult time zone database to understand
  the time of meeting.

- for past timestamps local time plus UTC offset is good choice.

p-- 
Jean

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

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

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Jean Louis]

* Max Nikulin  [2023-02-05 20:06]:
> On 05/02/2023 01:59, ypuntot wrote:
> > Then, given the time zone and the local time, you can know UTC.
> > If orgmode gets the UTC there is not ambiguity.
> 
> Mapping from local time to UTC may be ambiguous, so mapping from local time
> to time zone offset may be ambiguous as well.

Okay, though explain practical case examples.

Local time to UTC is almost always used in computing for accurate log
purposes.

Using UTC time for future events is vague, for reason that other human
cannot know with certainty what the author intended to do. Maybe
author intended meeting at 10 o'clock, but UTC offset in author's or
participant's time zone changed, or even time zone entry is not any
more. Author maybe had UTC offset -5, but now is -7, it becomes vague
what time author really intended.

Local time to time with UTC offset for same reason could be
non-conclusive in future.

Past is alright, as local time with UTC offset is pretty certain as
time zones hardly change in past.

Org needs first use examples, and then implementation for use examples.

> Usual case is local time change due to daylight saving time. Notice that 2nd
> and 4th lines in the results table have the same input, but time offset
> differs by 1 hour in the output while local time is the same:

Which is good example to demonstrate to people that 2:30 o'clock alone
cannot be represented in such time zones without UTC offset. That
"02:30" appears twice, it does not mean it is ambigous, as UTC offset
or different name of time zone like CET, CEST, would indicat what time
is that exacctly.


-- 
Jean

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

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

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Jean Louis]

* Ihor Radchenko  [2023-02-06 17:11]:
> Jean Louis  writes:
> 
> > * Ihor Radchenko  [2023-02-05 13:45]:
> >> [2024-02-04 12:00 @-08,America/Vancouver] will use fixed -8 offset
> >
> > What does that mean practically? Provide example for better
> > understanding. 
> 
> It means "when I scheduled this item, I expected the UTC offset at the
> time of the timestamp to be -08 and remain so. It was motivated by
> America/Vancouver time zone, but if it changes in future, I do not care
> - the scheduled time should remain at specific time point relative to
> UTC".

I read, though sorry, I do not understand who is expected to think
that UTC offset is fixed?

Is it Org as program?

Or is it human?

Another program in future, and human, must know did the organizer of
event, had in mind:

- to rather keep appointment at 12:00 o'clock, no matter the UTC
  offset changes, or

- to keep appointment based on UTC definition?

I find such situations rather easy to solve with database:

- I can have column like "timestamp" with UTC time or local time plus
  UTC offset, and if I did not enter any other information, that UTC
  offset is considered in future. Consider this column name
  "timestamp".

- I can have column "time" and when such is entered, then date is
  extracted from "timestamp" column, and combined with time. In this
  case UTC is only calculated in new time point but not used as period
  from past to appointment time.

- I can have time zone for the future, if I enter such in other
  column, the future calculation must use that proper time zone. 

The above handling is for program to handle and for human to know that
it is handled that way.

You said "I do not care", that means you as human decide that 
[2024-02-04 12:00 @-08,America/Vancouver] will use fixed -8 offset

But from where in such timestamp does user or program understand that?

> > - The UTC offset is not certain to remain fixed in the future. 
> 
> Yes. But fixing UTC offset means that time point is fixed. Example: you
> need a timestamp exactly N hours from now. It must not be affected by
> time zone rule changes.

Not generally! As I said, your time stamp is not structured, I cannot
see how do you decide the appointment here: 
[2024-02-04 12:00 @-08,America/Vancouver]

1. Both time zone and UTC offset may be changed in future. 

2. You as organizer you were maybe meaning UTC time "fixed" with offet
   -8, but the UTC offset maybe changed in future, it became -07. It
   is confusing, and neither program neither human will know with
   certainty if you meant 1 hour more or less.

3. To solve that problem, appointments are better defined as
following, with the structured time stamp:

* Meeting, discussion of our plan beyond 2030
  :PROPERTIES:
  :TIME: 10:00
  :TIMEZONE: Europe/Berlin
  :END:

Or this way, but I do not find that practical, however, "UTC-TIME"
could mean to program that it is fixed.

* Meeting, discussion of our plan beyond 2030
  :PROPERTIES:
  :UTC-TIME: [2024-02-04 12:00 @-08, America/Vancouver]
  :END:

However, if you do not define UTC-TIME to mean fixed, how is program
to know that the timestamp:

[2024-02-04 12:00 @-08, America/Vancouver]

means that it is -08 UTC fixed offset?

Without putting some structure, it will not know it.

Maybe this way (hypothetically):

[2024-02-04 12:00 @-08, America/Vancouver/UTC-FIXED]

as that way you would give signal to program that you want UTC fixed
time in future, and not 12:00 o'clock necessary.

Without any tag, neither program, nor authors, cannot know which time
will it be in future, if there is DST change, time zone change or
replacement of it, or UTC offset change.

Structuring it, becomes clear DATE:, TIME:, TIME-ZONE: as future TZ
database can give information of UTC offset and various local times
for TIME:

> > - If you do not have the time of creation of the timestamp above, you
> >   cannot know with certainty what was the offset in past, to calculate
> >   new UTC offset in case it changed
> 
> America/Vancouver in the above timestamp is nothing but a reference
> comment. One may or may not use it.
> 
> > - As not even time zone is certain to remain in existence in future,
> >   you will need to use time zone, in order to derive that future UTC
> >   offset correctly. As it could change in mean time.
> 
> If timestamp must follow the future time zone rules, can just use 
>  [2024-02-04 12:00 @America/Vancouver]

Exactly. And that is human friendly versus UTC, which is not readable.

> >> [2024-02-04 12:00 @America/Vancouver] will use @America/Vancouver time
> >> zone, as it is be defined in you OS time zone database.
> >
> > If you do not keep UTC offset, you will miss changes in future and
> > generate errors.
> 
> Only if you care. Maybe it is not an error to follow the future changes.
> If you want to be notified, just use [2024-02-04 12:00
> @-08,!America/Vancouver] explicitly stating the offset you expect in
> future.

OK but expecting or not expecting makes again 

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

ypuntot  writes:

> For the Poll, the Jeans proposal would be to introduce manually:
> [2024-02-04 12:00 @America/Vancouver]
> And org to convert it into:
> [2024-02-04 12:00 @-08,America/Vancouver]
> ?

Depends on context. We are not really discussing what kind of format
will Org use by default. Just general syntax.

I can see situations where auto-inserting @-08,America/Vancouver makes
sense (like in clock items). There are also situations where it does not
makes sense and the user is to decide.

> Ihor's would add the option to get warnings, in case tzdata changes, when 
> that timestamp is generated?
> [2024-02-04 12:00 @-08,!America/Vancouver]
> ?

This is not Ihor's. All three timestamps are within the discussed format.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Jean Louis  writes:

> * Ihor Radchenko  [2023-02-05 13:45]:
>> [2024-02-04 12:00 @-08,America/Vancouver] will use fixed -8 offset
>
> What does that mean practically? Provide example for better
> understanding. 

It means "when I scheduled this item, I expected the UTC offset at the
time of the timestamp to be -08 and remain so. It was motivated by
America/Vancouver time zone, but if it changes in future, I do not care
- the scheduled time should remain at specific time point relative to
UTC".

> - The UTC offset is not certain to remain fixed in the future. 

Yes. But fixing UTC offset means that time point is fixed. Example: you
need a timestamp exactly N hours from now. It must not be affected by
time zone rule changes.

> - If you do not have the time of creation of the timestamp above, you
>   cannot know with certainty what was the offset in past, to calculate
>   new UTC offset in case it changed

America/Vancouver in the above timestamp is nothing but a reference
comment. One may or may not use it.

> - As not even time zone is certain to remain in existence in future,
>   you will need to use time zone, in order to derive that future UTC
>   offset correctly. As it could change in mean time.

If timestamp must follow the future time zone rules, can just use 
 [2024-02-04 12:00 @America/Vancouver]

>> [2024-02-04 12:00 @America/Vancouver] will use @America/Vancouver time
>> zone, as it is be defined in you OS time zone database.
>
> If you do not keep UTC offset, you will miss changes in future and
> generate errors.

Only if you care. Maybe it is not an error to follow the future changes.
If you want to be notified, just use [2024-02-04 12:00
@-08,!America/Vancouver] explicitly stating the offset you expect in
future.

>> [2024-02-04 12:00 @-08,!America/Vancouver] (note "!") will use fixed -8
>> offset, but also calculate America/Vancouver time from TZ database,
>> compare it with the time coming from -8 offset, and warn you if there is
>> inconsistency.
>
> The UTC offset is the log what was the UTC offset at the time point
> when timestamp was created, as future UTC offset cannot be known.

Sure. -08 is expected offset.

> Making it "fixed" does not fix it in real time, you are then
> introducing something new than what other programs do with time.

I do not understand this statement.

> I do not think that you need "!", you are creating work not necessary
> for users.

I hope that I clarified the need in the above examples. You may also
refer to the reference in the original proposal. The idea with "!" is
explained in more details.

> If users wish to get some warnings, let them customize single option.

This will be less fine-grained approach. For some timestamps, you don't
need warnings. Of course, default customization may be also provided to
enable warnings for timestamps without "!".

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Max Nikulin]

On 05/02/2023 01:59, ypuntot wrote:

Then, given the time zone and the local time, you can know UTC.
If orgmode gets the UTC there is not ambiguity.


Mapping from local time to UTC may be ambiguous, so mapping from local 
time to time zone offset may be ambiguous as well.


The extreme case is 1892-07-04 that happened twice in Pacific/Apia due 
to offset change by 24 hours to another side of International Date Line. 
Due to the opposite transition there was no 2011-12-30 in this time zone.


Usual case is local time change due to daylight saving time. Notice that 
2nd and 4th lines in the results table have the same input, but time 
offset differs by 1 hour in the output while local time is the same:


#+header: :var tz="Europe/Berlin"
#+header: :var t0='(:year 2023 :month 10 :day 29 :hour 2 :minute 30 
:second 0)

#+header: :var hours='(1 2 3 2)
#+begin_src elisp
  (mapcar
   (lambda (h)
 (let ((dt (apply #'make-decoded-time :zone tz :dst -1 t0)))
   (setf (decoded-time-hour dt) h)
   (list dt
 (format-time-string "%F %a %T @%z" (encode-time dt) tz
   hours)
#+end_src

#+RESULTS:
| (0 30 1 29 10 2023 nil -1 Europe/Berlin) | 2023-10-29 Sun 01:30:00 
@+0200 |
| (0 30 2 29 10 2023 nil -1 Europe/Berlin) | 2023-10-29 Sun 02:30:00 
@+0200 |
| (0 30 3 29 10 2023 nil -1 Europe/Berlin) | 2023-10-29 Sun 03:30:00 
@+0100 |
| (0 30 2 29 10 2023 nil -1 Europe/Berlin) | 2023-10-29 Sun 02:30:00 
@+0100 |


P.S.

https://zachholman.com/talk/utc-is-enough-for-everyone-right
https://www.youtube.com/watch?v=aEvB98CstOk
UTC is Enough for Everyone, Right?


Zach, whatever you do: just don't ever build a calendar

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[ypuntot]

For the Poll, the Jeans proposal would be to introduce manually:
[2024-02-04 12:00 @America/Vancouver]
And org to convert it into:
[2024-02-04 12:00 @-08,America/Vancouver]
?

Ihor's would add the option to get warnings, in case tzdata changes, when that 
timestamp is generated?
[2024-02-04 12:00 @-08,!America/Vancouver]
?

Feb 5, 2023 13:12:25 Jean Louis :

> * Ihor Radchenko  [2023-02-05 13:45]:
>> [2024-02-04 12:00 @-08,America/Vancouver] will use fixed -8 offset
> 
> What does that mean practically? Provide example for better
> understanding.
> 
> - The UTC offset is not certain to remain fixed in the future.
> 
> - If you do not have the time of creation of the timestamp above, you
>   cannot know with certainty what was the offset in past, to calculate
>   new UTC offset in case it changed
> 
> - As not even time zone is certain to remain in existence in future,
>   you will need to use time zone, in order to derive that future UTC
>   offset correctly. As it could change in mean time.
> 
> What is meaning of "fixed -8 offset"?
> 
>> [2024-02-04 12:00 @-08] will also use fixed -8 offset
> 
> That type of timestamp does not clearly show the time zone, that one
> may only be understood as timestamp with UTC offset. UTC time may be
> derived from such timestamp. That offset should remain fixed, as there
> is no time zone associated. It is UTC time represented with offset.
> 
>> [2024-02-04 12:00 @America/Vancouver] will use @America/Vancouver time
>> zone, as it is be defined in you OS time zone database.
> 
> If you do not keep UTC offset, you will miss changes in future and
> generate errors.
> 
>> [2024-02-04 12:00 @-08,!America/Vancouver] (note "!") will use fixed -8
>> offset, but also calculate America/Vancouver time from TZ database,
>> compare it with the time coming from -8 offset, and warn you if there is
>> inconsistency.
> 
> The UTC offset is the log what was the UTC offset at the time point
> when timestamp was created, as future UTC offset cannot be known.
> 
> Making it "fixed" does not fix it in real time, you are then
> introducing something new than what other programs do with time.
> 
> I do not think that you need "!", you are creating work not necessary
> for users.
> 
> If users wish to get some warnings, let them customize single option.
> 
> Not timestamp by timestamp.
> 
> --
> Jean
> 
> Take action in Free Software Foundation campaigns:
> https://www.fsf.org/campaigns
> 
> In support of Richard M. Stallman
> https://stallmansupport.org/

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Jean Louis]

* Ihor Radchenko  [2023-02-05 13:45]:
> [2024-02-04 12:00 @-08,America/Vancouver] will use fixed -8 offset

What does that mean practically? Provide example for better
understanding. 

- The UTC offset is not certain to remain fixed in the future. 

- If you do not have the time of creation of the timestamp above, you
  cannot know with certainty what was the offset in past, to calculate
  new UTC offset in case it changed

- As not even time zone is certain to remain in existence in future,
  you will need to use time zone, in order to derive that future UTC
  offset correctly. As it could change in mean time.

What is meaning of "fixed -8 offset"?

> [2024-02-04 12:00 @-08] will also use fixed -8 offset

That type of timestamp does not clearly show the time zone, that one
may only be understood as timestamp with UTC offset. UTC time may be
derived from such timestamp. That offset should remain fixed, as there
is no time zone associated. It is UTC time represented with offset.

> [2024-02-04 12:00 @America/Vancouver] will use @America/Vancouver time
> zone, as it is be defined in you OS time zone database.

If you do not keep UTC offset, you will miss changes in future and
generate errors.

> [2024-02-04 12:00 @-08,!America/Vancouver] (note "!") will use fixed -8
> offset, but also calculate America/Vancouver time from TZ database,
> compare it with the time coming from -8 offset, and warn you if there is
> inconsistency.

The UTC offset is the log what was the UTC offset at the time point
when timestamp was created, as future UTC offset cannot be known.

Making it "fixed" does not fix it in real time, you are then
introducing something new than what other programs do with time.

I do not think that you need "!", you are creating work not necessary
for users.

If users wish to get some warnings, let them customize single option.

Not timestamp by timestamp.

--
Jean

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

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

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Ypo  writes:

> 4. For the Poll: What would be the expected behavior if we used the UTC 
> offset?  [2024-02-04 12:00 @-08,America/Vancouver]
>      - We should know beforehand the DST of Vancouver, or there would be 
> warnings. It seems more difficult for the user: maybe the "-08," should 
> be optional?

In what I suggested,

[2024-02-04 12:00 @-08,America/Vancouver] will use fixed -8 offset
[2024-02-04 12:00 @-08] will also use fixed -8 offset
[2024-02-04 12:00 @America/Vancouver] will use @America/Vancouver time
zone, as it is be defined in you OS time zone database.
[2024-02-04 12:00 @-08,!America/Vancouver] (note "!") will use fixed -8
offset, but also calculate America/Vancouver time from TZ database,
compare it with the time coming from -8 offset, and warn you if there is
inconsistency.

>      - Case 3: After updating the tz database we would get warnings too. 
> To correct those warnings, should the UTC offset be changed manually in 
> the timestamp?. If there were 35 meetings in Vancouver throughout the 
> year, to change all the UTC offsets could be non trivial for a normal 
> user: UTC of the summer and winter would differ.
>    [2024-09-04 12:00 @-07,America/Vancouver] should be changed to 
> [2024-09-04 12:00 @-08,America/Vancouver]
>    [2024-02-04 12:00 @-08,America/Vancouver] should be changed to 
> [2024-02-04 12:00 @-09,America/Vancouver]

In what I suggested, you will need to mark "!" in order to get warnings.
There will be little point correcting, for example, clock entries - they
already represent the correct past time.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Samuel Wales  writes:

> On 2/1/23, Ihor Radchenko  wrote:
>> the best we can do is minimizing the breakage when designing the new syntax
>
> as a small nit [followup is not needed as i do not want to distract
> from the big boys talking about quantum dst on pluto for timestamps
> with [axial precession change :[]*, or follow up, as i have given up
> on the topic of tz for timestamps :]]:

That was a half-joke :) [ and, anyway, I do not see why TZDB will not
cover Moon TZ once a standard comes out ]

> it might be that i was not making a point for which it is entirely
> true that what you and everybody else is proposing, i.e. extending
> existing ts syntax for tz, is the best we can do, in principle.  :]
> what you said is true if you stick, for tz-using tses, with extending
> /existing/ ts syntax, as opposed to countenancing, for those tses, an
> extensible syntax that is also usable for ts-unrelated features and
> subfeatures so as to reduce proliferation of new, heterogenous, syntax
> as it will arise in future and has arisen for many years [i prefer
> less syntax], and other stuff like reusable infrastructure for
> semantics and parsing and display etc. and optional ability for users
> to extend syntax themselves readily without it being heterogenous but
> instead merely cl-style kw,

Your idea with universal custom object with cl-style properties is not
forgotten. But it is something should leave as the last resort for
users. Simply because its syntax will inevitably be verbose.

My vision is that Org syntax should be something intuitive for a person
not familiar with Org manual, simple enough to not distract reading the
Org files in plain text without fontification, yet machine-readable.

Too verbose syntax will violate the second point as it will move Org
constructs closer to html tags - too cluttered for reading the sources
directly.

That's why we need to provide _simple_ built-in syntax for common needs.
And time zone support is a common need as evident from the topic
surfacing again and again over the years.

> [*] i have read that global warming relates to earth axis precession
> change due to contemporary mass loss primarily in Greenland.  for all
> i know, also the origins of org coincidentally being due to an
> astrophysicist, this could affect tses.

I'd say that it could affect summer time :)

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Jean Louis]

* Ypo  [2023-02-05 00:41]:
> I have been thinking about how I would use this feature. So use cases
> appeared, which arose some doubts about how to use this feature, and an
> opinion for the Poll surged:
> 
> If I wanted to assist to a "Mastering Emacs book club" meeting in
> America/Vancouver, while living in Spain: Doubt: Should I use local time of
> America/Vancouver to schedule the meeting?. Like: [2024-02-04 12:00
> @America/Vancouver] (I don't like space before the @, for the Poll).

The above sounds as good idea! People are in Vancouver, so it is 12
o'clock on 4th February, by using time zone "America/Vancouver".

If that time zone changes before the future even, the time zone
database is going to hold change variables, and one will still be able
to figure out the time.

> 1. Doubt: I suppose my agenda timestamp would be: [2024-02-04 do. 21:00].
> (Spain local time). Correct?

Your agenda time stamp could be with Spanish time zone.

Your agenda is really this: [2024-02-04 12:00 @America/Vancouver]

And that would mean if you wish to represent it in Spanish time zone,
that computer program should:

- First read the [2024-02-04 12:00 @America/Vancouver] 

- read time zone database properties for America/Vancouver, this
  implies having latest time zone databas

- apply properties, such as possible UTC offsets, this implies
  possible changes of UTC offsets

- calculate the UTC time, at time point of reading that time

- understand local time zone, also calculate UTC time

- use above information to calculate Spanish time and representation
  in Spanish time zone

> 2. If I went on vacation to Brasília, my agenda timestamp should change to:
> [2024-02-04 do. 17:00]. (Brasília local time).

That is okay.

>    Doubt: How must the local time zone be updated to get that timestamp
> changed?

By similar formula as explained above.

> 3. Back to Spain, I see that, for political reasons, Vancouver's winter
> time-zone changed from UTC-8 to UTC-9.
>    Doubt: How would my tz database be updated?

By your system package manager and operating system maintainers. If
they do not update it, you would miss the time.

If there is any updated beyond international agreement like what is
now happening in Ukraine, I doubt you would have correct time
calculated by computer.

>    Doubt: After updating the tz database, my agenda timestamp would change
> automatically to  [2024-02-04 do. 22:00]. Correct?

Org will not know if you did update TZ database or not. That super Org
who knows how to calculate times should definitely use the TZ
database.

Time stamp would not change because you only come to some location.

But you also need to change the computer time settings (to be correct
time) and computer time zone.

If not computer time zone, then the settings for Org, as Org could
have in future settings of time zone

Once those settings are applied, your Org could show you local time.

> 4. For the Poll: What would be the expected behavior if we used the UTC
> offset?  [2024-02-04 12:00 @-08,America/Vancouver]

When time is not too far in future, it is less vague. 

When time is more far in future, it is more vague, as UTC offset could
be changed and time zone name could be changed, but TZ database would
have that information to re-calculate it in that future.

It means that UTC offset here: [2024-02-04 12:00 @-08,America/Vancouver]

is only something that is assumed, it could change, both with fact
that time zone could disappear, new time zone could appear.

TZ database would be handling those issues, that is the purpose of it.

Using UTC offset in future timestamps does not make sense as it is not
time that one can calculate in present time with certainty for reason
that future TZ database does not exist in present time.

Here is good recommendation for such case:

Time Zone Storage in Data Type "Timestamp With Time Zone" - ITCodar:
https://www.itcodar.com/sql/time-zone-storage-in-data-type-timestamp-with-time-zone.html

Booking future appointments where we want to keep the time-of-day even
if those pesky politicians change the offset of the time zone(s) in
their jurisdiction. These political changes happen surprisingly
often. So book an appointment using two columns: TIMESTAMP WITHOUT
TIME ZONE in one, and the name of the intended time zone in
another. Time zones are named with Continent/Region format such as
Africa/Tunis. At runtime, when you need a moment for calendaring,
apply the time zone to the date and time to dynamically determine a
moment according to the now-current time zone rules. In Noda Time, you
would retrieve a LocalDateTime and time zone, to produce a
ZonedDateTime for calendaring.

That means it would be better to use only date, time and time zone.

[2024-02-04 12:00 @America/Vancouver]

The TZ database is assumed to know any daylight saving time changes,
and can re-calculate it correctly in future.

There is difference with events which are not too far, and those which
are far in future.

>     - We 

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Jean Louis  writes:

>> It is a correct TZ value 路
>
> Time zone value?

TZ environment variable value

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Jean Louis]

* ypuntot  [2023-02-04 22:01]:
> Great link!
> https://spin.atomicobject.com/2016/07/06/time-zones-offsets/
> 
> "Given a local time and an offset, you can know UTC time, but you do
> not know which time zone you’re in (because multiple timezones have
> the same offset)."

Exactly.

> So, given a time zone you can know the offset (Google it, for
> example)..  Then, given the time zone and the local time, you can
> know UTC.  If orgmode gets the UTC there is not ambiguity.

Majority of people do not use UTC. Having time displayed in UTC would
and will confuse too many people, unless such time is only for logging
purposes. But Org timestamps like DEADLINE, SCHEDULE, are really meant
for a human.

Internally, in calculations, program shoulde find time time zone, UTC
offset, calculate, go to UTC, again to time zone, and again represent
proper time. And if not that way, in any case there is complexity
involved.

Here is also good reference telling people how to program and work
with time zones.

Working with Time Zones:
https://www.w3.org/TR/timezone/

> But, that would mean that the offset related to the different time
> zones must be downloaded and updated from some site.

For past timestamsp, one could store such as UTC time, and such time
may be easily represented in presen time, it may be viewable in local
time if computer program consults the time zone database. 

For timestamps we are making now, to record something, when it
happened, we could use UTC time, but only for logs and similar, not
so important time representations, which we will not revisit too often
in future.

But let us say for some future, timestamps in DEADLINE, SCHEDULED,
those timestamps related to human, the UTC offset in this case cannot
be so sure, because it is in the future, and it is vague as it could
change politically. So the future will know what will be the UTC
offset.

> As you said before, that offset can change. For example, peninsular
> Spain has the same time as Berlin, but as this doesn't make much
> sense, it could change, so updates would be necessary.

That is right.

Even the time zone designation (name) could change in future, but for that
reason, if we use today a time zone, the future time zone database
will know about time zone that (was) defined today, and computer
program will know how to calculate representation of the time in local
time in future, for the time of today.

Time zones are updated regularly, but we cannot be sure of it in case
of atomic war or other planetary commotions. ☹️ I wish people could
love each other more. ☮️

-- 
Jean

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

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

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Jean Louis]

* Ihor Radchenko  [2023-02-04 13:58]:
> I used "UTC+2" because it is how offsets are often represented.
> For example, https://time.is/London is displaying the following:
> 
> Time in London, United Kingdom now
> ...
> Time zone
> - Currently Greenwich Mean Time (GMT), UTC +0
> - Daylight saving time (British Summer Time (BST), UTC +1)
> starts March 26, 2023

The above examples are not good enough, for following reasons:

- in your example, you did not show other time zone but UTC time zone,
  plus the UTC prefix.

- in the above shown example, there are time zones shown, plus the UTC
  prefix, and that is how it should be

> Note UTC +0 and UTC +1.

Yes, but in your example, if I remember well, you used @ (now I cannot
be sure), so if you used @UTC+1 for me that would mean you are using
the time zone named "UTC" (I just assume it can be used as time zone
as it exists on my side in the database as well as one of time zones)
and then you added the UTC prefix too. That is not compatible with
each other.

If you use UTC time zone, prefix is always +0 or nothing.

If you use time zone other than UTC time zone, then prefix will be
there.

> I've seen such format in multiple time websites.

That is fine, sure, I have seen it too, though your representation and
those examples have difference.

> On the other hand, TZ POSIX is reverse from what is commonly meant when
> displaying UTC +1.

POSIX is for computers, that is how I understand it, time zones, UTC
offsets, they are rather for human.

> > I think it is incorrect time stamp. If you specify UTC, you do not
> > specify UTC offset. 
> 
> It is a correct TZ value 路

Time zone value?

That is what I meant, and that is how I understood it as "time zone
value" and it's label was "UTC", and then in that case UTC offset
can't be there, as it is contradictory to show UTC offset with UTC
time as UTC time has no UTC offset.

-- 
Jean

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

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

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Max Nikulin]

On 05/02/2023 04:38, Ypo wrote:


If I wanted to assist to a "Mastering Emacs book club" meeting in 
America/Vancouver, while living in Spain: Doubt: Should I use local time 
of America/Vancouver to schedule the meeting?. Like: [2024-02-04 12:00 
@America/Vancouver] (I don't like space before the @, for the Poll).


Below is my vision. Others may have their own opinions concerning 
particular details.


Depending of choice of persons in charge of this event you should add to 
your .org file either
- <2024-02-04 12:00 @America/Vancouver> if convenience of local 
participants is the most important point
- <2024-02-04 Sun 20:00:00 @Z> == <2024-02-04 Sun 12:00:00 @-0800> if 
enough online participants are expected, so the time is fixed for 
everybody independently of possible changes of the America/Vancouver 
time zone.


You may add <2024-02-04 do. 21:00>, but it will increase maintenance 
burden, see below.


1. Doubt: I suppose my agenda timestamp would be: [2024-02-04 do. 
21:00]. (Spain local time). Correct?


Agenda may display timestamps in your current time zone using overlays 
or just by formatting during generation of agenda.


2. If I went on vacation to Brasília, my agenda timestamp should change 
to: [2024-02-04 do. 17:00]. (Brasília local time).
    Doubt: How must the local time zone be updated to get that timestamp 
changed?


If you have in your file either <2024-02-04 12:00 @America/Vancouver> or 
<2024-02-04 Sun 20:00:00 @Z> then you do not need to update anything. 
You just set your current time zone to proper location in Brazil (and 
perhaps regenerate agenda)


3. Back to Spain, I see that, for political reasons, Vancouver's winter 
time-zone changed from UTC-8 to UTC-9.

    Doubt: How would my tz database be updated?


On Linux tzdata package is updated several times every year, this case 
you just need to keep your system up to date.


    Doubt: After updating the tz database, my agenda timestamp would 
change automatically to  [2024-02-04 do. 22:00]. Correct?


If you saved the event as <2024-02-04 do. 21:00> certainly it is up to 
you to find an update entries (and unsure that no timestamps is updated 
twice) to <2024-02-04 do. 22:00>. In the case of <2024-02-04 12:00 
@America/Vancouver> or <2024-02-04 Sun 20:00:00 @Z> just regenerate 
agenda after update of time zone database (perhaps emacs restart will be 
required).


4. For the Poll: What would be the expected behavior if we used the UTC 
offset?  [2024-02-04 12:00 @-08,America/Vancouver]

     - We should know beforehand the DST of Vancouver,


Obtaining offset from UTC is not a problem:

LANG=en_US.UTF-8 TZ=America/Vancouver date  -d '2024-02-04 12:00' '+<%F 
%a %T @%z>'

<2024-02-04 Sun 12:00:00 @-0800>

or there would be 
warnings. It seems more difficult for the user: maybe the "-08," should 
be optional?


I expect that both time zone identifier and offset are added either to 
resolve ambiguity of local time around change of time offset or to catch 
updates of timezone database. In the latter case it is optional, but it 
helps to notify you that event time is updated.


     - Case 3: After updating the tz database we would get warnings too. 
To correct those warnings, should the UTC offset be changed manually in 
the timestamp?. If there were 35 meetings in Vancouver throughout the 
year, to change all the UTC offsets could be non trivial for a normal 
user: UTC of the summer and winter would differ.


org-lint may present list of inconsistent timestamps. I am afraid, in 
some cases you will have to contact organizers to ensure that event was 
scheduled correctly (either in respect to local time or bound to UTC). 
Communications may require significantly more efforts than fixing 3 
dozens of timestamps.

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Samuel Wales]

tldr: carry on.  :]


On 2/4/23, Samuel Wales  wrote:
> On 2/1/23, Ihor Radchenko  wrote:
>> the best we can do is minimizing the breakage when designing the new
>> syntax
>
> as a small nit [followup is not needed as i do not want to distract
> from the big boys talking about quantum dst on pluto for timestamps
> with [axial precession change :[]*, or follow up, as i have given up
> on the topic of tz for timestamps :]]:
>
> it might be that i was not making a point for which it is entirely
> true that what you and everybody else is proposing, i.e. extending
> existing ts syntax for tz, is the best we can do, in principle.  :]
> what you said is true if you stick, for tz-using tses, with extending
> /existing/ ts syntax, as opposed to countenancing, for those tses, an
> extensible syntax that is also usable for ts-unrelated features and
> subfeatures so as to reduce proliferation of new, heterogenous, syntax
> as it will arise in future and has arisen for many years [i prefer
> less syntax], and other stuff like reusable infrastructure for
> semantics and parsing and display etc. and optional ability for users
> to extend syntax themselves readily without it being heterogenous but
> instead merely cl-style kw, and also if you don't take potential
> issues with compatibility with piles of regexps in 3rd party and
> personal code, including non-emacs, into account [not saying
> unreasonable].  etc.  never fear: i have given up on all of that
> completely.  at least for tz.  your syntax looks great and everybody
> seems delighted so i have no business butting in and cannot follow up
> for unrelated reasons in any case.  so just a nit.  this paragraph
> might be unreadable and in that case you can just ignore it.
>
> [*] i have read that global warming relates to earth axis precession
> change due to contemporary mass loss primarily in Greenland.  for all
> i know, also the origins of org coincidentally being due to an
> astrophysicist, this could affect tses.
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Samuel Wales]

On 2/1/23, Ihor Radchenko  wrote:
> the best we can do is minimizing the breakage when designing the new syntax

as a small nit [followup is not needed as i do not want to distract
from the big boys talking about quantum dst on pluto for timestamps
with [axial precession change :[]*, or follow up, as i have given up
on the topic of tz for timestamps :]]:

it might be that i was not making a point for which it is entirely
true that what you and everybody else is proposing, i.e. extending
existing ts syntax for tz, is the best we can do, in principle.  :]
what you said is true if you stick, for tz-using tses, with extending
/existing/ ts syntax, as opposed to countenancing, for those tses, an
extensible syntax that is also usable for ts-unrelated features and
subfeatures so as to reduce proliferation of new, heterogenous, syntax
as it will arise in future and has arisen for many years [i prefer
less syntax], and other stuff like reusable infrastructure for
semantics and parsing and display etc. and optional ability for users
to extend syntax themselves readily without it being heterogenous but
instead merely cl-style kw, and also if you don't take potential
issues with compatibility with piles of regexps in 3rd party and
personal code, including non-emacs, into account [not saying
unreasonable].  etc.  never fear: i have given up on all of that
completely.  at least for tz.  your syntax looks great and everybody
seems delighted so i have no business butting in and cannot follow up
for unrelated reasons in any case.  so just a nit.  this paragraph
might be unreadable and in that case you can just ignore it.

[*] i have read that global warming relates to earth axis precession
change due to contemporary mass loss primarily in Greenland.  for all
i know, also the origins of org coincidentally being due to an
astrophysicist, this could affect tses.

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ypo]

Great link!
https://spin.atomicobject.com/2016/07/06/time-zones-offsets/

"Given a local time and an offset, you can know UTC time, but you do 
not know which time zone you’re in (because multiple timezones have 
the same offset)."


So, given a time zone you can know the offset (Google it, for example)..
Then, given the time zone and the local time, you can know UTC.
If orgmode gets the UTC there is not ambiguity.

But, that would mean that the offset related to the different time 
zones must be downloaded and updated from some site.
As you said before, that offset can change. For example, peninsular 
Spain has the same time as Berlin, but as this doesn't make much 
sense, it could change, so updates would be necessary.
I have been thinking about how I would use this feature. So use cases 
appeared, which arose some doubts about how to use this feature, and an 
opinion for the Poll surged:


If I wanted to assist to a "Mastering Emacs book club" meeting in 
America/Vancouver, while living in Spain: Doubt: Should I use local time 
of America/Vancouver to schedule the meeting?. Like: [2024-02-04 12:00 
@America/Vancouver] (I don't like space before the @, for the Poll).
1. Doubt: I suppose my agenda timestamp would be: [2024-02-04 do. 
21:00]. (Spain local time). Correct?
2. If I went on vacation to Brasília, my agenda timestamp should change 
to: [2024-02-04 do. 17:00]. (Brasília local time).
   Doubt: How must the local time zone be updated to get that timestamp 
changed?
3. Back to Spain, I see that, for political reasons, Vancouver's winter 
time-zone changed from UTC-8 to UTC-9.

   Doubt: How would my tz database be updated?
   Doubt: After updating the tz database, my agenda timestamp would 
change automatically to  [2024-02-04 do. 22:00]. Correct?
4. For the Poll: What would be the expected behavior if we used the UTC 
offset?  [2024-02-04 12:00 @-08,America/Vancouver]
    - We should know beforehand the DST of Vancouver, or there would be 
warnings. It seems more difficult for the user: maybe the "-08," should 
be optional?
    - Case 3: After updating the tz database we would get warnings too. 
To correct those warnings, should the UTC offset be changed manually in 
the timestamp?. If there were 35 meetings in Vancouver throughout the 
year, to change all the UTC offsets could be non trivial for a normal 
user: UTC of the summer and winter would differ.
  [2024-09-04 12:00 @-07,America/Vancouver] should be changed to 
[2024-09-04 12:00 @-08,America/Vancouver]
  [2024-02-04 12:00 @-08,America/Vancouver] should be changed to 
[2024-02-04 12:00 @-09,America/Vancouver]

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[ypuntot]

Great link!
https://spin.atomicobject.com/2016/07/06/time-zones-offsets/

"Given a local time and an offset, you can know UTC time, but you do not know 
which time zone you’re in (because multiple timezones have the same offset)."

So, given a time zone you can know the offset (Google it, for example)..
Then, given the time zone and the local time, you can know UTC.
If orgmode gets the UTC there is not ambiguity.

But, that would mean that the offset related to the different time zones must 
be downloaded and updated from some site.
As you said before, that offset can change. For example, peninsular Spain has 
the same time as Berlin, but as this doesn't make much sense, it could change, 
so updates would be necessary.

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Jean Louis  writes:

>> >> [2022-11-12 14:00 @UTC+2]
>> >> [2022-11-12 14:00 @UTC-2:30]
>> >> 
>> >> are also fine within the proposed format.
>> >
>> > The above format is unclear to me. I look at timestamps every day, too
>> > many, often change them.
>> >
>> > I cannot understand what you mean.
>> 
>> See "std offset" format for TZ environment variable.
>> https://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html
>
> I understand that information on hyperlink.
>
> I do not understand how it is related to "UTC", a with "UTC" people do
> not put UTC offset.

Well. "UTC" there is rather arbitrary, but _some_ abbreviation is
required as per TZ spec. Could also be [2022-11-12 14:00 @BLAHBLAH+2]

I used "UTC+2" because it is how offsets are often represented.
For example, https://time.is/London is displaying the following:

Time in London, United Kingdom now
...
Time zone
- Currently Greenwich Mean Time (GMT), UTC +0
- Daylight saving time (British Summer Time (BST), UTC +1) starts March 26, 
2023

Note UTC +0 and UTC +1.
I've seen such format in multiple time websites.

On the other hand, TZ POSIX is reverse from what is commonly meant when
displaying UTC +1.

> It is either UTC as time zone and offset can be considered only ZERO,
> like +0, or it is NOT UTC as time zone, and there is offset to
> understand what was really the UTC. This latter is also explained in
> that hyperlink.

> So what do you really mean with such time stamp?
>

You are right. From the point of view of TZ POSIX spec, UTC+2 is not UTC
time zone and not a known time zone. Rather manual nautical time zone
with arbitrary name and fixed UTC offset (+2).

> I think it is incorrect time stamp. If you specify UTC, you do not
> specify UTC offset. 

It is a correct TZ value 路

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Jean Louis]

* Ihor Radchenko  [2023-02-01 14:12]:
> Let me try to explain better. Just specifying time zone is ambiguous
> once per year during daylight transition.

For reason to make it unambiguous, people (representatives of
countries in international associations) are creating the TZ database,
and maintaining it.

Specifying time zone is not ambiguous as long as you use the TZ
database for specifications!

> [2023-03-29 02:30 @Europe/Berlin] is special.

I may only guess you wanted to specify the last Sunday in March 2023,
where there is UTC offset shift.

Your time stamp above is very valid, but you probably wanted to point
out to the alleged problem with the daylight savings.

The time stamp you maybe wanted to demonstrate would be:

2023-03-26 02:30 @Europe/berlin

It is not special case!

It is INVALID time stamp. 

It does not exist in the context of internationally agreed time.

In the context of this e-mail, you may write what you want, but you
are arguing about something that does not exist.

Things that do not exist, do not make you a problem. 

The only thing that could be ambiguous is the hypothetical, imaginary,
lousy software that generates invalid time stamps like that.

You are bringing up the problem which in the human agreed reality does
not exist.

> According to https://www.timeanddate.com/time/zone/germany/berlin,
> 2023-03-29 is the time when the clock is shifted one hour back due to
> the daylight saving transition. The wall time goes like
> 
> 2023-03-29 02:30 -> ... -> 02:59 -> (CEST -> CET) 02:00 -> ... ->
> 2:30 (again!)

I got your point, even though you are showing invalid time stamp. 

And that is not a problem, because TZ database specifies exactly how
to calculat time.

If you however, use time zones but do not use time zone database,
well, that is case of bad program design, and your program, and
anything you do in that program will become ambigous as well.

> So, [2023-03-29 02:30 @Europe/Berlin] can mean two time points:
> before and after the transition.

1. Your timestamp is wrong for demonstration purposes, the time stamp
   you are displaying is not related to daylight savings shift.

2. The time stamp for demonstration should be: 
   2023-03-26 02:30 @Europe/berlin

3. The time stamp above, in the number (2) of this list, IS INVALID.

4. Recommendation is to stop using lousy programs generating invalid
   time stamps.

> Specifying explicit offset is thus necessary in this specific
> scenario to disambiguate the timestamp:

That specification of UTC offset is necessary is out of any doubt.

But you have formed your decision in invalid timestamp and lousy
programs, thus further conclusions based on such decisions cannot be
relevant, and people shall be cautious regarding conclusions that were
based on wrong and correct time stamp, where author wanted to point
out to daylight savings shift time stamp, whereby such time stamp is
invalid and as time representation does not exist.

It is because you do not need to worry how time zone is ambigous,
because it is not. Please read specification of the time zone
definition. It has been defined to solve this type of problems for
people.

> [2023-03-29 02:30+2 @Europe/Berlin] (before transition)
> [2023-03-29 02:30+1 @Europe/Berlin] (after transition)

Both of the above time stamps do not exist, both are valid.

If you meant daylight savings time stamps, then you maybe wanted to
say following:

> [2023-03-26 02:30+2 @Europe/Berlin] (before transition)
> [2023-03-26 02:30+1 @Europe/Berlin] (after transition)

However, above time stamps are INVALID. 

You deal with non-existent problem.

There is nothing to solve there.

Practical exercises for people to understand it:


Go in shell:

# Following will set your user's time zone to Europe/Berlin, that
# indicates that programs shall look for time zone specification, such
# as the one in /usr/share/zoneinfo/Europe/Berlin

$ export TZ=Europe/Berlin

# In the next step, setup the date:

$ sudo date -s '20230326 0159'
Sun Mar 26 01:59:00 AM CET 2023

# Ask for current time stamp from system

$ date
2023-03-26-01:59:22-Sunday

# Sorry that I have peculiar system time stamp personally, it is
# because I often use it to generate files

# Let us see it without my customization

$ /usr/bin/date
Sun Mar 26 01:59:06 AM CET 2023

# Let us repeat it, while we let time running:

$ /usr/bin/date
Sun Mar 26 01:59:32 AM CET 2023

# Observe what is happening:

$ /usr/bin/date
Sun Mar 26 01:59:58 AM CET 2023
~
$ /usr/bin/date
Sun Mar 26 01:59:58 AM CET 2023
~
$ /usr/bin/date
Sun Mar 26 01:59:59 AM CET 2023
~
$ /usr/bin/date
Sun Mar 26 03:00:00 AM CEST 2023

Did we arrive to 02:30? No. Why?

How about setting up the date to the imaginary "ambigous" and invalid
time stamp:

$ sudo date -s '20230326 0200'
date: invalid date ‘20230326 0200’

$ sudo date -s '20230326 0230'
date: invalid date ‘20230326 0230’

Hmm. Maybe the GNU `date' command simply does it's job 

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Jean Louis]

* Ihor Radchenko  [2023-02-02 11:38]:
> Jean Louis  writes:
> 
> > * Ihor Radchenko  [2023-02-01 15:23]:
> >> [2022-11-12 14:00 @UTC+2]
> >> [2022-11-12 14:00 @UTC-2:30]
> >> 
> >> are also fine within the proposed format.
> >
> > The above format is unclear to me. I look at timestamps every day, too
> > many, often change them.
> >
> > I cannot understand what you mean.
> 
> See "std offset" format for TZ environment variable.
> https://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html

I understand that information on hyperlink.

I do not understand how it is related to "UTC", a with "UTC" people do
not put UTC offset.

It is either UTC as time zone and offset can be considered only ZERO,
like +0, or it is NOT UTC as time zone, and there is offset to
understand what was really the UTC. This latter is also explained in
that hyperlink.

So what do you really mean with such time stamp?

I think it is incorrect time stamp. If you specify UTC, you do not
specify UTC offset. 

There is no UTC offset for UTC time.

-- 
Jean

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

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

Re: POSIX TS spec reverses the meaning of TZ offset compared to ISO (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Max Nikulin  writes:

>> Because `encode-time' accepts POSIX TZ as argument. So, may as well.
>> Note that Etc/GMT-8 is also accepted as POSIX TZ.
>
> "May" does not assume "should".

It will be easier to implement POSIX TZ compared to limiting it to TZDB.
We have no way to know if a given string is a valid TZDB entry to not.

> The disappointing issue with POSIX syntax is the case of decision of 
> authorities to change time zone offset. It is neither regular DST rule 
> nor constant offset. The result is incorrect mapping between UTC and 
> local time.

We cannot do much about it, AFAIU. Maximum is trying to do feature
request in glibc, but I assume that they know about this issue.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: POSIX TS spec reverses the meaning of TZ offset compared to ISO (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Max Nikulin]

On 02/02/2023 15:34, Ihor Radchenko wrote:

Max Nikulin writes:

Is there a strong reason to support POSIX TZ? Time zones with fixed
offsets are available as e.g. Etc/GMT-8 (unfortunately inverted sign as
well).


Because `encode-time' accepts POSIX TZ as argument. So, may as well.
Note that Etc/GMT-8 is also accepted as POSIX TZ.


"May" does not assume "should". I am leaving final decision to the 
person who will implement it though. I hope, there is no problem with 
such syntax on windows.


The disappointing issue with POSIX syntax is the case of decision of 
authorities to change time zone offset. It is neither regular DST rule 
nor constant offset. The result is incorrect mapping between UTC and 
local time.

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Timothy]

Hi Ihor,

>>>  with CST being ambiguous (and also not supported by `encode-time’).
>>
>> I imagine here one could ignore unrecognised but non-conflicting timestamps.
>
> There is no reliable way to detect if a time zone abbreviation is
> ambiguous or not. `encode-time’ will not signal anything and simply
> treat unrecognised time zone as UTC (currently; the actual behaviour is
> undefined AFAIK).

Ah, that makes my idea a bit harder to work with then. Hmmm.

All the best,
Timothy

-- 
Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
Learn more about Org mode at .
Support Org development at ,
or support my work at .

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Timothy  writes:

>>  with CST being ambiguous (and also not supported by `encode-time’).
>
> I imagine here one could ignore unrecognised but non-conflicting timestamps.

There is no reliable way to detect if a time zone abbreviation is
ambiguous or not. `encode-time' will not signal anything and simply
treat unrecognised time zone as UTC (currently; the actual behaviour is
undefined AFAIK).

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Timothy]

Hi Ihor,

>> It also occurs to me that this proposed behaviour might be easier with a 
>> single
>> `@TZINFO’ form as I mentioned earlier, e.g.
>>
>> ┌
>> │ [2022-11-12 Sat 12:00]# warn when mismatch
>> │ [2022-11-12 Sat 12:00]  # use Asia/Singapore over +07
>
>  Consider the requests about time zone abbreviations. Without “always
>  warn”, we can do
>
>  [2022-11-12 Sat 12:00]
>
>  with CST being ambiguous (and also not supported by `encode-time’).

I imagine here one could ignore unrecognised but non-conflicting timestamps.

All the best,
Timothy

-- 
Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
Learn more about Org mode at .
Support Org development at ,
or support my work at .

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Timothy  writes:

> This functions well, however I see a potential to be confusing at a glance 
> here.
> Consider the visual similarity of 10:30 to 11:00 in local time and 10:30 in
> UTC-11, and the combination of both.
>
> ┌
> │ [2022-11-12 10:30-11:00]
> │ [2022-11-12 10:30-1100]
> │ [2022-11-12 10:30-11:00-1100]
> └

Note that an alternative is 

 [2022-11-12 10:30-11:00]
 [2022-11-12 10:30-11]
 [2022-11-12 10:30-11:00-11]

which is much less confusing.

> I’d be inclined to put the UTC offset together with the time zone name if
> possible. Do you think something along the lines of `@-1100,America/Anchorage'
> could be viable? I’d think that would reduce the chance of confusion.
>
> ┌
> │ [2022-11-12 10:30-11:00]
> │ [2022-11-12 10:30 @-1100]
> │ [2022-11-12 10:30-11:00 @-1100]
> └

This might be an option.
A slight disadvantage is more verbose syntax for simple timestamps like

 [2022-11-12 10:30+02]
 [2022-11-12 10:30 @+02]

>>2022-11-12 12:00+07 @!Asia/Singapore
>>
>>Org will calculate the internal time for both +07 offset and
>>Asia/Singapore time zone. If they do not match, Org will issue a
>>warning. The offset will still be preferred if we have to proceed.
>>
>>This can be useful when planning future meetings and sending Org file
>>with a timestamp to someone else, potentially with obsolete tzdb.
>
> I like the way that combining these features works, but I do wonder if perhaps
> warning when these two bits of information don’t match should be the default
> behaviour, and the `!' used to specify which of them should be prioritised?

I am not sure if it is a good idea.

> It also occurs to me that this proposed behaviour might be easier with a 
> single
> `@TZINFO' form as I mentioned earlier, e.g.
>
> ┌
> │ [2022-11-12 12:00 @+07,Asia/Singapore]  # warn when mismatch
> │ [2022-11-12 12:00 @+07,!Asia/Singapore] # use Asia/Singapore over +07

 Consider the requests about time zone abbreviations. Without "always
 warn", we can do

 [2022-11-12 12:00 @+08,CST]

 with CST being ambiguous (and also not supported by `encode-time').


-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Max Nikulin  writes:

> On 01/02/2023 23:45, Ihor Radchenko wrote:
>> 
>> Note how `encode-time' TIME argument has both DST flag and the time zone
>> name:
>> 
>> (SECOND MINUTE HOUR DAY MONTH YEAR IGNORED DST ZONE)
>> 
>> DST is necessary exactly in the ambiguous situations like I described,
>> when we must know if day saving time is in effect or not __in addition__
>> to time zone name.
>
> Warning: just be aware that sometimes DST is not enough to resolve 
> ambiguity. E.g. in the following example attempt to pass non-nil DST 
> signals an error:
>
> zdump -v Africa/Juba | grep 2021
> Africa/Juba  Sun Jan 31 20:59:59 2021 UT = Sun Jan 31 23:59:59 2021 EAT 
> isdst=0 gmtoff=10800
> Africa/Juba  Sun Jan 31 21:00:00 2021 UT = Sun Jan 31 23:00:00 2021 CAT 
> isdst=0 gmtoff=7200

Providing UTC offset will resolve the ambiguity in this scenario. So, we
are good. Unfortunately, there seems to be no way to detect such
ambiguities programmatically. Not using glibc, at least.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Jean Louis  writes:

> * Ihor Radchenko  [2023-02-01 15:23]:
>> [2022-11-12 14:00 @UTC+2]
>> [2022-11-12 14:00 @UTC-2:30]
>> 
>> are also fine within the proposed format.
>
> The above format is unclear to me. I look at timestamps every day, too
> many, often change them.
>
> I cannot understand what you mean.

See "std offset" format for TZ environment variable.
https://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: POSIX TS spec reverses the meaning of TZ offset compared to ISO (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Max Nikulin  writes:

> On 01/02/2023 20:26, Ihor Radchenko wrote:
>> 
>> There is potential confusion coming from the different interpretations
>> of the time zone offsets used in ISO8601 and POSIX TZ specs:
>
> Ihor, I am sorry that I did not reply to your early question.
>
> Is there a strong reason to support POSIX TZ? Time zones with fixed 
> offsets are available as e.g. Etc/GMT-8 (unfortunately inverted sign as 
> well).

Because `encode-time' accepts POSIX TZ as argument. So, may as well.
Note that Etc/GMT-8 is also accepted as POSIX TZ.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Greg Minshall]

thanks, Tomas and Ihor,

> > [2022-11-12 12:00 @Asia/Singapore] vs. [2022-11-12 12:00 @ Asia/Singapore]
> > 
> > Either way is possible.
> > I am in favour of my variant though :)
> 
> Same with me. I read @ as a sigil [1]
...
> [1] https://en.wikipedia.org/wiki/Sigil_(computer_programming)

i'll try to get my head around the sigils (but appreciate that either
way is valid).

cheers, Greg

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Timothy]

Hi Ihor,

Thanks for the detailed proposal! The effort you’ve put into soliciting feedback
and working out an effective and concise proposal is most commendable .

> I propose two forms of time zone information in Org timestamps
>
> 1. Timestamp with explicit UTC offset
>
>-MM-DD [optional day name] HH:MM[^ \]>]*?[+-−]HH[MM]?
>-MM-DD [optional day name] HH:MM[^ \]>]*?Z[ \]>]
>
>“-” is latin “HYPHEN-MINUS” (code 0x2D)
>“−” is unicode “MINUS SIGN” (code 0x2212), as prescribed by ISO8601
>we will not actually use it when generating timestamps, but allow it
>to keep some compatibility with ISO standard.
>
>“Z” in the second format refers to “Zulu” time (another name for UTC)
>and must be either the last character in the timestamp or the
>last character before space. Not sure if many users are familiar with
>“Z” convention, but it is (1) in ISO; (2) succinct for users who are
>familiar with it. We will prefer +00 number offset in auto-generated
>timestamps.
>
>Examples:
>2022-11-12 12:00+02 # 12:00 UTC+2
>2022-11-12 14:00+0230 # 14:00 UTC+2:30
>2022-11-12 14:00-0230 # 14:00 UTC-2:30
>2022-11-12 14:00Z # 14:00 UTC
>
>The offset is a subset of what is defined by ISO8601.
>
>Note that unlike ISO8601, “:” is not allowed in the offset specifier.
>This is to disambiguate with the time intervals in Org timestamps:
>[2022-11-12 Sat 08:00]–[2022-11-12 Sat 09:00]  in Org is a time range from 
> 8am to 9am.
>
>For time ranges, we will only allow a single offset and time zone
>specifier for both start and end times:
>[2022-11-12 Sat 08:00]–[2022-11-12 Sat 09:00]
>If different time zones are necessary to specify the start/end times,
>users can still use full timestamp range syntax
>[2022-11-12 Sat 08:00]–[2022-11-12 Sat 22:00]
>
>The format is also forward-compatible with extending Org timestamps
>for second/sub-second precision: 2022-11-12 14:00:05.0012+0230 will
>remain valid if we decide to adopt such format.

This functions well, however I see a potential to be confusing at a glance here.
Consider the visual similarity of 10:30 to 11:00 in local time and 10:30 in
UTC-11, and the combination of both.

┌
│ [2022-11-12 10:30-11:00]
│ [2022-11-12 10:30-1100]
│ [2022-11-12 10:30-11:00-1100]
└

I’d be inclined to put the UTC offset together with the time zone name if
possible. Do you think something along the lines of `@-1100,America/Anchorage'
could be viable? I’d think that would reduce the chance of confusion.

┌
│ [2022-11-12 10:30-11:00]
│ [2022-11-12 10:30 @-1100]
│ [2022-11-12 10:30-11:00 @-1100]
└

Looking at this, I also personally rather like that it puts all the timezone
information together in a single `@TZINFO' token.

> 2. Timestamp with time zone specifier
>
>-MM-DD [optional day name] HH:MM[^ ]* @[!]?<[^ \]>]>
>
>For now, time zone name will only be processed when it follows TZ
>POSIX format. If necessary, the proposed syntax will still allow
>extensions to TZ POSIX.
>
>Examples:
>2022-11-12 12:00 @Asia/Singapore # tzdb syntax
>2022-11-12 10:00 @Europe/Berlin
>2022-11-12 10:00 @!Europe/Berlin # “!” does nothing here, see below
>2022-11-12 10:00 @EST+5 # TZ syntax
>2022-11-12 10:00 @EST+5EDT,M3.2.0/2,M11.1.0/2 # manual time zone spec 
> allowed in TZ
>
>The “@” symbol is selected to disambiguate time zone specifier from
>other auxiliary information in the timestamp. Like calendar name,
>which might be added in future. Note that we cannot use […] from
>the standard draft. I selected “@” because it is read as “at” -
>location specifier.
>
>The “!” symbol is adapted from
>
>
>I use space before “@” to improve readability. We deviate from the
>standard here so may as well. In contrast, no space before [+-]offset
>is closer to the standard yet not cluttering the timestamp too much
>(IMHO).

This looks like it works rather nicely to me.

> 3. (1) and (2) can be combined
>
>2022-11-12 12:00+08 @Asia/Singapore
>
>Org will unconditionally use +08 offset and ignore the time zone
>name. We prefer absolute offset because it is non-ambiguous wrt
>out-of-date tzdb on the computer. One may also not update the TZ
>variable upon travelling - the system clock will again be more likely
>accurate.
>
>This redundant time offset info can serve as human-readable
>indication of absolute time, while the time zone name will indicate
>the location.
>
>2022-11-12 12:00+07 @!Asia/Singapore
>
>Org will calculate the internal time for both +07 offset and
>Asia/Singapore time zone. If they do not match, Org will issue a
>warning. The offset will still be preferred if we have to proceed.
>
>This can be useful when planning future meetings and sending Org file
>with a timestamp to 

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Max Nikulin]

On 01/02/2023 23:45, Ihor Radchenko wrote:


Note how `encode-time' TIME argument has both DST flag and the time zone
name:

(SECOND MINUTE HOUR DAY MONTH YEAR IGNORED DST ZONE)

DST is necessary exactly in the ambiguous situations like I described,
when we must know if day saving time is in effect or not __in addition__
to time zone name.


Warning: just be aware that sometimes DST is not enough to resolve 
ambiguity. E.g. in the following example attempt to pass non-nil DST 
signals an error:


zdump -v Africa/Juba | grep 2021
Africa/Juba  Sun Jan 31 20:59:59 2021 UT = Sun Jan 31 23:59:59 2021 EAT 
isdst=0 gmtoff=10800
Africa/Juba  Sun Jan 31 21:00:00 2021 UT = Sun Jan 31 23:00:00 2021 CAT 
isdst=0 gmtoff=7200

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Jean Louis  writes:

>> [2023-03-29 02:30+2 @Europe/Berlin] (before transition)
>> [2023-03-29 02:30+1 @Europe/Berlin] (after transition)
>
> Both of the above time stamps do not exist, both are valid.
>
> If you meant daylight savings time stamps, then you maybe wanted to
> say following:
>
>> [2023-03-26 02:30+2 @Europe/Berlin] (before transition)
>> [2023-03-26 02:30+1 @Europe/Berlin] (after transition)

No. I meant 2023-10-29. When the clock moves backwards. Sorry for the
confusion.

   Sun, 29 Oct, 03:00   CEST → CET  -1 hour (DST end)   UTC+1h

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Jean Louis  writes:

>> The problems of daylight savings transition points is fairly well
>> understood and I think it is fairly well accepted that there is
>> ambiguity arising from the use of daylight savings.
>
> The only ambiguity is if you miss to understand that "time zone"
> definition already contains specification of daylight savings.
>
> If you do understand it, then there will be no ambiguity at all.

You are incorrect here. In such scenarios, time zone name must also be
accompanied by DST flag. Just supplying the time zone is not enough.

Note how `encode-time' TIME argument has both DST flag and the time zone
name:

   (SECOND MINUTE HOUR DAY MONTH YEAR IGNORED DST ZONE)

DST is necessary exactly in the ambiguous situations like I described,
when we must know if day saving time is in effect or not __in addition__
to time zone name.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Jean Louis  writes:

> Using UTC offset for future time stamps is IMHO possibly much more
> problematic for the same reason of possible changes in future.

Yes. But it is also an advantage when the purpose is creating timestamp
independent of possible changes in future.

>> Complex time zones in timestamps will not rely on user's computer having
>> the up-to-date time zone database: [1916-09-12 12:00+01 @Europe/London]
>> unambiguously specifies the UTC offset yet emphasizing that the
>> timestamp is related to specific location (Europe/London, but not
>> Europe/Paris). In fact, one may somewhat abuse this format and specify
>> [1916-09-12 12:00+01 @France/Marseille] emphasizing the location.
>
> Then if they are not to relay on time zone database, on what they can
> rely as alternative?

I suggest ignoring @... if +01 is specified (unless "@!..." is provided).
Then, the timestamp is considered in a nautical time zone with fixed (+01)
offset from UTC.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Jean Louis  writes:

> Are you going to implement the connection to time zone database?

It will be enough to use Emacs time API. `encode-time' accepts time zone
as an argument. The time zone in `encode-time' must follow the format
for TZ environment variable. Under the hook, `encode-time' uses glibc
system library that connects to zoneinfo (IANA Time Zone Database).

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Jean Louis]

* Ihor Radchenko  [2023-02-01 13:30]:
> Tim Cross  writes:
> 
> > The real question is, can the additional complexity associated with
> > including both a time zone name and an offset be justified in order to
> > handle the very small number of time stamps which will fall within the
> > daylight savings transition hour for those locations which have daylight
> > savings? Keep[ing in mind that the complexity is less to do with the
> > time stamp format and more to do with using that information in any
> > meaningful sense. This, combined with the reduced readability of such
> > time stamps and increased possibility of user confusion leads me to
> > question if allowing time stamps with both offset and time zone together
> > in the one time stamp is worthwhile. 
> 
> As I originally stated in the proposal, the real usefulness of combined
> offset+time zone is asking Org to double-check the consistency:

That is right, though that is not the fundamental reason for using UTC
offset and time zone.

Every good application should check if the time stamp is valid or
not. 

It should not allow user to specify invalid time stamps, and it should
not calculate and generate invalid time stamps.

The reason for UTC offset is future possible political changes of the
UTC offset.

It shall be assumed that time stamp from past was correct, that it was
generated by application that was using the time zone database, but
the UTC offset in present time could be changed, just as it was
mentioned for the Russian decision recently.

By using UTC offset and time zone from past, one can then use present
UTC offset definitions and calculate differences. However, there are
still rare changes with the past time zone definitions. 

Using UTC offset for future time stamps is IMHO possibly much more
problematic for the same reason of possible changes in future.

> Consider a time stamp far in future [2052-11-12 12:00+08 @!Asia/Singapore] 
> The time zone rules for Asia/Singapore may or may not remain the same
> due to political uncertainty. Today, we expect the offset to remain +08.
> If it changes in future, Org will warn the user.

Very right.

> In addition, I find specifying both the time zone and the offset
> useful for readability:

Thank you.

> Complex time zones in timestamps will not rely on user's computer having
> the up-to-date time zone database: [1916-09-12 12:00+01 @Europe/London]
> unambiguously specifies the UTC offset yet emphasizing that the
> timestamp is related to specific location (Europe/London, but not
> Europe/Paris). In fact, one may somewhat abuse this format and specify
> [1916-09-12 12:00+01 @France/Marseille] emphasizing the location.

Then if they are not to relay on time zone database, on what they can
rely as alternative?

--
Jean

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

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

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Jean Louis]

* Ihor Radchenko  [2023-02-01 15:23]:
> [2022-11-12 14:00 @UTC+2]
> [2022-11-12 14:00 @UTC-2:30]
> 
> are also fine within the proposed format.

The above format is unclear to me. I look at timestamps every day, too
many, often change them.

I cannot understand what you mean.

If there is considered UTC time zone, then the only prefix for such
time stamp is +00 and nothing else, or no prefix at all.

The time stamps that specify UTC offset are expressed in local time,
not in UTC time. 

Here are few examples of ordinary usage of UTC offset converted to UTC:

2023-01-07 09:21:11.019166+03 which means: 2023-01-07 06:21:11.019166 @UTC
2022-10-05 14:09:04.79737+03 which means: 2022-10-05 11:09:04.79737 @UTC

Due to that ordinary usage of time stamps, something like @UTC+2 where
you specify 14:00 o'clock, is unclear, if you mean UTC time plus 2,
like 16 o'clock, or you mean 12 o'clock.

Time stamps having UTC offset are in their representation such as in
calendar tied to the time zone, as they maybe are derived from system
time, where time zone need not be displayed in the time stamp, but it
is nevertheless there and used by program to derive the UTC offset.

And it is either UTC time, or local time plus UTC offset.

There is no UTC time plus UTC offset, why would anybody need that as
time stamp?

-- 
Jean

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

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

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Jean Louis]

* Ihor Radchenko  [2023-02-01 15:42]:
> Indeed. Org is used by a variety of users with different needs. What I
> just demonstrated is that specifying the time zone is not always
> necessary in timestamps.

Specifying time zone in time stamps is not necessary!

But using the time zone is necessary if developers wish to provide
accuracy of time calculations for users.

Using the time zone is built-in, it is just matter of representation
of time at export or exchanges.

And time zone could be changed from the default system time, inside of
the time stamp, if not there, inside of heading property, if not
there, inside of the file time stamp property.

That way majority of time stamps can remain how they are with addition
of specification of time zone property.

> Note that my proposal allows specifying the time zone when you need
> it.

Thank you!

That is good proposal.

> Or not specifying it and specifying the UTC offset only.

If you mean, specifying _local time_ plus UTC offset, then that is not
how you can exchange information with participants in meeting. That is
unsure.

But if you mean specifying _UTC time_ plus the UTC offset, that is
alright to derive local time from it.

Preceding condition is that such UTC time plus the UTC offset was
calculated correctly.

And there need not be the ultimate goal in Org that all kinds of time
stamps can be calculated for the future.

That shall be the job of the function to verify if the timestamp can
be re-calculated or not, and function may warn the user to update it
with missing time zone.

Read "Putting It All Together"
https://spin.atomicobject.com/2016/07/06/time-zones-offsets/

Are you going to implement the connection to time zone database?

-- 
Jean

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

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

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Jean Louis]

* Tim Cross  [2023-02-01 12:53]:
> > Let me try to explain better. Just specifying time zone is ambiguous
> > once per year during daylight transition.
> >
> > [2023-03-29 02:30 @Europe/Berlin] is special.
> >
> > According to https://www.timeanddate.com/time/zone/germany/berlin,
> > 2023-03-29 is the time when the clock is shifted one hour back due to
> > the daylight saving transition. The wall time goes like
> >
> > 2023-03-29 02:30 -> ... -> 02:59 -> (CEST -> CET) 02:00 -> ... -> 2:30 
> > (again!)
> >
> > So, [2023-03-29 02:30 @Europe/Berlin] can mean two time points: before
> > and after the transition. Specifying explicit offset is thus necessary
> > in this specific scenario to disambiguate the timestamp:
> >
> > [2023-03-29 02:30+2 @Europe/Berlin] (before transition)
> > [2023-03-29 02:30+1 @Europe/Berlin] (after transition)
> 
> OK, in that case, I think what we are in danger of here is letting
> the perfect be the enemy of good.
> 
> The problems of daylight savings transition points is fairly well
> understood and I think it is fairly well accepted that there is
> ambiguity arising from the use of daylight savings.

The only ambiguity is if you miss to understand that "time zone"
definition already contains specification of daylight savings.

If you do understand it, then there will be no ambiguity at all.

> The real question is, can the additional complexity associated with
> including both a time zone name and an offset be justified in order
> to handle the very small number of time stamps which will fall
> within the daylight savings transition hour for those locations
> which have daylight savings?

That additional complexity is important for future, as we cannot know
what will be the future UTC offset due to political changes!

> Keep[ing in mind that the complexity is less to do with the time
> stamp format and more to do with using that information in any
> meaningful sense.

That is very correct, that is why Org shall keep time stamps simple in
it's basic form and allow users to specify precision as they wish.

> This, combined with the reduced readability of such time stamps and
> increased possibility of user confusion leads me to question if
> allowing time stamps with both offset and time zone together in the
> one time stamp is worthwhile.

As we promote Org to be good for "reproducible research" then for
those people will be of value, and many other groups who need time
precision. 

https://html.duckduckgo.com/html/?q=org+mode+reproducible


--
Jean

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

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

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Samuel Wales  writes:

> amazing amount of work and good choices.  i won't object, although
> previous comments re syntax proliferation and 3rd party and personal
> code re stand, while acknowledging the replies.

There is no way around.
The feature has been demanded multiple times. It is _needed_ by users.
Since we clearly need the feature, the best we can do is minimizing the
breakage when designing the new syntax.

Note that the proposed syntax will even work with older versions of Org,
except that time zone information will be obviously ignored.

> bce and ce might be possibilities.  if negative numbers or somethigare
> not uniquely used for that.
>
> can any of this, or the semantics, be in emacs?  emacs has times all
> over the place.

`calendar-read-date' only supports AD, AFAIK. Also, glibc system library
may not work reliably on dates before 1970 (or 1900; I don't remember).

Calc appears to handle negative years though. But not
`parse-time-string'. On the other hand, directly specifying internal
time format works (but not sure if correctly):

(format-time-string "%Y-%m-%d %a %H:%M" (encode-time '(0 10 11 11 09 -1000)) 
"UTC-2:30")

> 1. Reduced timestamp precision:
>1985-04-12 (day precision, time omitted; available in Org)
>
> current agenda search query semantics seem /currently/ potentially
> confusing re in/equalities for today, now, day precision.  e.g. is
> today a specific minute or can = refer to any minute in the day?  is
> the manual clear?

The manual is not clear. I am not sure where it is important.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[tomas]

On Wed, Feb 01, 2023 at 12:48:12PM +, Ihor Radchenko wrote:
> Greg Minshall  writes:
> 
> >> 2022-11-12 12:00 @Asia/Singapore # tzdb syntax
> >
> > aesthetically, allowing a space after the "@" sign might be nice.  i
> > don't know what that would do to the parsing/BNF/whatever.
> 
> [2022-11-12 12:00 @Asia/Singapore] vs. [2022-11-12 12:00 @ Asia/Singapore]
> 
> Either way is possible.
> I am in favour of my variant though :)

Same with me. I read @ as a sigil [1]

Cheers

[1] https://en.wikipedia.org/wiki/Sigil_(computer_programming)
-- 
t


signature.asc
Description: PGP signature

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Greg Minshall  writes:

>> 2022-11-12 12:00 @Asia/Singapore # tzdb syntax
>
> aesthetically, allowing a space after the "@" sign might be nice.  i
> don't know what that would do to the parsing/BNF/whatever.

[2022-11-12 12:00 @Asia/Singapore] vs. [2022-11-12 12:00 @ Asia/Singapore]

Either way is possible.
I am in favour of my variant though :)
Mostly because I find it more neatly grouped in more complex timestamps
like
[2022-11-12 12:00 @Asia/Singapore +1w -1d]

[2022-11-12 12:00 @ Asia/Singapore +1w -1d]
feels a slightly wrong. And extra space to type manually.

Other opinions welcome though. We can decide according to the majority.
There is no technical limitation when choosing space vs. no space.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Jean Louis  writes:

>> Consider that you are running a scientific experiment around daylight
>> saving time change: [2022-10-29 2:15-5:15+02]. You don't care that the
>> government decided that the wall clock should go like 2:15 -> 2:59 ->
>> [CEST -> CET] 2:00 -> 2:15 -> 2:59. Physics does not care. You just need
>> to make sure that the experiment runs exactly 3 hours without trying to
>> consider the currently used TZ rules.
>
> Sorry, I cannot see how running the experiment three hours long is 
> related to exchange of for example, appointments, or calendar events
> that shall be represented in possibly different time zones. 

It is not related.

> It seems you have different personal purposes for time representation
> in Org.

Indeed. Org is used by a variety of users with different needs. What I
just demonstrated is that specifying the time zone is not always
necessary in timestamps.

Note that my proposal allows specifying the time zone when you need it.
Or not specifying it and specifying the UTC offset only. Your use-case
with appointments is covered. My example is also covered.

> Are you sure that telling not to care is good notion?

Maybe I used the words wrongly. I meant that physical phenomena do not
follow human conventions and wall time.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Christian Moe  writes:

> From this perspective I'd be happier with the less concise, but super
> explicit
>
>   2022-11-12 14:00 UTC+2
>   2022-11-12 14:00 UTC-2:30

[2022-11-12 14:00 @UTC+2]
[2022-11-12 14:00 @UTC-2:30]

are also fine within the proposed format.

Note, however, that because we are conforming to POSIX TZ, @UTC+2 is two
hours _behind_ the Greenwich.

https://www.di-mgt.com.au/wclock/help/wclo_tzexplain.html:

Explanation of TZ strings

General format of an entry in the file wclocktz.ini:
[continent/city]
TZ=posix-tz-string

Time zones that do not have daylight savings have a simple TZ string,
e.g.

[Pacific/Honolulu]
TZ=HST10

Where HST is the designation for the time zone (in this case Hawaii
Standard Time) and 10 is the offset in hours. The offset indicates the
value one must add to the local time to arrive at Coordinated
Universal Time (UTC, aka GMT), and so it is positive for west of the
meridian, e.g. America, and negative for east, e.g. China.

[Asia/Beijing]
TZ=CST-8

Minutes and seconds are optional, so CST-8 and CST-08:00:00 mean the
same thing. Note that the sign convention (+/-) used in a Posix TZ
string is the opposite to that used in Internet time offsets (RFC
3339) and in Arthur David Olson's TZ data files.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Christian Moe]

Hi,

I have only partly been able to follow the discussion, but this seems
like a very thoughtful proposal.

I'm just not super happy with the ISO format running clock time and
offset together, which I thinks makes clock times less readable when
you're just quickly glancing through notes.

>Examples:
>2022-11-12 12:00+02 # 12:00 UTC+2
>2022-11-12 14:00+0230 # 14:00 UTC+2:30
>2022-11-12 14:00-0230 # 14:00 UTC-2:30
>2022-11-12 14:00Z # 14:00 UTC

The '12:00+02' offset is not the 'dd:dd' shape I expect a clocktime
in. Also, since I don't think in UTC offsets, my brain goes '12:00 plus
2 hours' before 'the 12:00 that's 2 hours ahead of Greenwich'. The
extra cognitive load is admittedly small, and I'd probably probably get
used to it quickly if it were only the '+dd'. But I might still get
tripped up by an offset like '14:00-0230', which is unambiguous to a
computer, but synonymous with '14:00-02:30' to my brain.

>From this perspective I'd be happier with the less concise, but super
explicit

  2022-11-12 14:00 UTC+2
  2022-11-12 14:00 UTC-2:30

but I realize there are many considerations to balance here.

Yours,
Christian


>The offset is a subset of what is defined by ISO8601.
>
>Note that unlike ISO8601, ":" is not allowed in the offset specifier.
>This is to disambiguate with the time intervals in Org timestamps:
>[2022-11-12 8:00-9:00] in Org is a time range from 8am to 9am.
>
>For time ranges, we will only allow a single offset and time zone
>specifier for both start and end times:
>[2022-11-12 8:00-9:00+08]
>If different time zones are necessary to specify the start/end times,
>users can still use full timestamp range syntax
>[2022-11-12 8:00+03]--[2022-11-12 22:00+08]
>
>The format is also forward-compatible with extending Org timestamps
>for second/sub-second precision: 2022-11-12 14:00:05.0012+0230 will
>remain valid if we decide to adopt such format.
>
> 2. Timestamp with time zone specifier
>
>-MM-DD [optional day name] HH:MM[^ ]* @[!]?<[^ \]>]>
>
>For now, time zone name will only be processed when it follows TZ
>POSIX format. If necessary, the proposed syntax will still allow
>extensions to TZ POSIX.
>
>Examples:
>2022-11-12 12:00 @Asia/Singapore # tzdb syntax
>2022-11-12 10:00 @Europe/Berlin
>2022-11-12 10:00 @!Europe/Berlin # "!" does nothing here, see below
>2022-11-12 10:00 @EST+5 # TZ syntax
>2022-11-12 10:00 @EST+5EDT,M3.2.0/2,M11.1.0/2 # manual time zone spec 
> allowed in TZ
>
>The "@" symbol is selected to disambiguate time zone specifier from
>other auxiliary information in the timestamp. Like calendar name,
>which might be added in future. Note that we cannot use [...] from
>the standard draft. I selected "@" because it is read as "at" -
>location specifier.
>
>The "!" symbol is adapted from
>https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/
>
>I use space before "@" to improve readability. We deviate from the
>standard here so may as well. In contrast, no space before [+-]offset
>is closer to the standard yet not cluttering the timestamp too much
>(IMHO).
>
> 3. (1) and (2) can be combined
>
>2022-11-12 12:00+08 @Asia/Singapore
>
>Org will unconditionally use +08 offset and ignore the time zone
>name. We prefer absolute offset because it is non-ambiguous wrt
>out-of-date tzdb on the computer. One may also not update the TZ
>variable upon travelling - the system clock will again be more likely
>accurate.
>
>This redundant time offset info can serve as human-readable
>indication of absolute time, while the time zone name will indicate
>the location.
>
>2022-11-12 12:00+07 @!Asia/Singapore
>
>Org will calculate the internal time for both +07 offset and
>Asia/Singapore time zone. If they do not match, Org will issue a
>warning. The offset will still be preferred if we have to proceed.
>
>This can be useful when planning future meetings and sending Org file
>with a timestamp to someone else, potentially with obsolete tzdb.
>
> |---|
> |  |
> |---|
>
> Apart from the ideas mentioned above,
> https://www.loc.gov/standards/datetime/ contains a number of other
> interesting ideas that may or may not be adapted by Org in future.
> I will outline the ideas I find noteworthy to keep them in mind when
> considering changing (including current changes) in the timestamp
> syntax:
>
> 1. Reduced timestamp precision:
>1985-04-12 (day precision, time omitted; available in Org)
>1985-04 (month precision, day and time omitted, not available in Org)
>1985 (year precision)
>
>Current timestamp syntax proposal should not interfere.
>
> 2. Using "T" as date/time delimiter
>1985-04-12T23:20:30 (not supported by Org)
>
> 3. Using "/" for time intervals
>

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Max Nikulin]

On 01/02/2023 16:38, Tim Cross wrote:

This, combined with the reduced readability of such
time stamps and increased possibility of user confusion leads me to
question if allowing time stamps with both offset and time zone together
in the one time stamp is worthwhile.


Readability should not suffer if time offset is optional. It may be 
omitted for non-ambiguous local time. Time offset may even improve 
readability if you are looking at a timestamp with time zone unknown to you.


Sterling posted the following links (originating from the same group):
https://tc39.es/proposal-temporal/docs/ambiguity.html
https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/

What I do not like is that disambiguation is option of conversion, not 
of timestamp.



For instance, it does not address:

   *  Future time given as a local time in some specified time zone,
  where changes to the definition of that time zone (e.g., a
  political decision to enact or rescind daylight saving time)
  affect the instant in time corresponding with the timestamp.


In this sense I like Python's approach with fold=1 or fold=2 despite in 
general JavaScript Temporal proposal looks more flexible.

https://www.python.org/dev/peps/pep-0495/

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Tim Cross  writes:

> The real question is, can the additional complexity associated with
> including both a time zone name and an offset be justified in order to
> handle the very small number of time stamps which will fall within the
> daylight savings transition hour for those locations which have daylight
> savings? Keep[ing in mind that the complexity is less to do with the
> time stamp format and more to do with using that information in any
> meaningful sense. This, combined with the reduced readability of such
> time stamps and increased possibility of user confusion leads me to
> question if allowing time stamps with both offset and time zone together
> in the one time stamp is worthwhile. 

As I originally stated in the proposal, the real usefulness of combined
offset+time zone is asking Org to double-check the consistency:

Consider a time stamp far in future [2052-11-12 12:00+08 @!Asia/Singapore] 
The time zone rules for Asia/Singapore may or may not remain the same
due to political uncertainty. Today, we expect the offset to remain +08.
If it changes in future, Org will warn the user.

In addition, I find specifying both the time zone and the offset useful
for readability:

Complex time zones in timestamps will not rely on user's computer having
the up-to-date time zone database: [1916-09-12 12:00+01 @Europe/London]
unambiguously specifies the UTC offset yet emphasizing that the
timestamp is related to specific location (Europe/London, but not
Europe/Paris). In fact, one may somewhat abuse this format and specify
[1916-09-12 12:00+01 @France/Marseille] emphasizing the location.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Tim Cross]

Ihor Radchenko  writes:

> Tim Cross  writes:
>
>>> Either I understand you wrong, or you don't know what you are
>>> talking about. 2023-03-23 02:30 @Europe/Berlin refers to /two/
>>> points in time, thus it /is/ ambiguous. If you use disambiguating
>>> "time zones" (MEZ vs MESZ in this case) you can resolve that.
>>
>> I think the confusion relates to context interpretation. If you see
>> @Europe/Berlin in isolation, then it is ambiguous as it can refer to two
>> different time zone definitions (standard v daylight savings).  However,
>> if you consider it in conjunction with a date and time, as in 2023-03-23
>> 02:30 @Europe/Berlin, then it isn't ambiguous - in that case, it really
>> just says 'Lookup the time zone offset in the databse for Berlin as of
>> that date and time.
>>...
>> Personally, I cannot see the use case of including both a fully
>> qualitifed time zone (as in @Europe/Berlin) and an offset...
>
> Let me try to explain better. Just specifying time zone is ambiguous
> once per year during daylight transition.
>
> [2023-03-29 02:30 @Europe/Berlin] is special.
>
> According to https://www.timeanddate.com/time/zone/germany/berlin,
> 2023-03-29 is the time when the clock is shifted one hour back due to
> the daylight saving transition. The wall time goes like
>
> 2023-03-29 02:30 -> ... -> 02:59 -> (CEST -> CET) 02:00 -> ... -> 2:30 
> (again!)
>
> So, [2023-03-29 02:30 @Europe/Berlin] can mean two time points: before
> and after the transition. Specifying explicit offset is thus necessary
> in this specific scenario to disambiguate the timestamp:
>
> [2023-03-29 02:30+2 @Europe/Berlin] (before transition)
> [2023-03-29 02:30+1 @Europe/Berlin] (after transition)

OK, in that case, I think what we are in danger of here is letting
the perfect be the enemy of good.

The problems of daylight savings transition points is fairly well
understood and I think it is fairly well accepted that there is
ambiguity arising from the use of daylight savings.

The real question is, can the additional complexity associated with
including both a time zone name and an offset be justified in order to
handle the very small number of time stamps which will fall within the
daylight savings transition hour for those locations which have daylight
savings? Keep[ing in mind that the complexity is less to do with the
time stamp format and more to do with using that information in any
meaningful sense. This, combined with the reduced readability of such
time stamps and increased possibility of user confusion leads me to
question if allowing time stamps with both offset and time zone together
in the one time stamp is worthwhile. 

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Tim Cross  writes:

>> Either I understand you wrong, or you don't know what you are
>> talking about. 2023-03-23 02:30 @Europe/Berlin refers to /two/
>> points in time, thus it /is/ ambiguous. If you use disambiguating
>> "time zones" (MEZ vs MESZ in this case) you can resolve that.
>
> I think the confusion relates to context interpretation. If you see
> @Europe/Berlin in isolation, then it is ambiguous as it can refer to two
> different time zone definitions (standard v daylight savings).  However,
> if you consider it in conjunction with a date and time, as in 2023-03-23
> 02:30 @Europe/Berlin, then it isn't ambiguous - in that case, it really
> just says 'Lookup the time zone offset in the databse for Berlin as of
> that date and time.
>...
> Personally, I cannot see the use case of including both a fully
> qualitifed time zone (as in @Europe/Berlin) and an offset...

Let me try to explain better. Just specifying time zone is ambiguous
once per year during daylight transition.

[2023-03-29 02:30 @Europe/Berlin] is special.

According to https://www.timeanddate.com/time/zone/germany/berlin,
2023-03-29 is the time when the clock is shifted one hour back due to
the daylight saving transition. The wall time goes like

2023-03-29 02:30 -> ... -> 02:59 -> (CEST -> CET) 02:00 -> ... -> 2:30 (again!)

So, [2023-03-29 02:30 @Europe/Berlin] can mean two time points: before
and after the transition. Specifying explicit offset is thus necessary
in this specific scenario to disambiguate the timestamp:

[2023-03-29 02:30+2 @Europe/Berlin] (before transition)
[2023-03-29 02:30+1 @Europe/Berlin] (after transition)

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Jean Louis]

* Tim Cross  [2023-02-01 11:10]:
> I think the confusion relates to context interpretation. If you see
> @Europe/Berlin in isolation, then it is ambiguous as it can refer to
> two different time zone definitions (standard v daylight savings).

Of course, without the time stamp, the time zone alone cannot give
time.

> However, if you consider it in conjunction with a date and time, as
> in 2023-03-23 02:30 @Europe/Berlin, then it isn't ambiguous - in
> that case, it really just says 'Lookup the time zone offset in the
> databse for Berlin as of that date and time.

Exactly that.

> Now that could change - for example, the German government might
> make a temporary or permanent change that would change the offset
> from UTC for that date+time the day after I look at it (or export
> it).

It cannot change in past.

It will not change drastically or capriciously as Germany aligns with
other countries and ISO standard.

It is more likely that ISO non-members deviate from international
coordination of time related definitions:

ISO - Members:
https://www.iso.org/members.html

> Personally, I cannot see the use case of including both a fully
> qualitifed time zone (as in @Europe/Berlin) and an offset, but I
> also don't know all possible use cases - there could well be use
> cases where you want/need to record both the location time zone as
> well as the offset at the point when you recorded the timestamp.

Time Zones vs. Offsets – What's the Difference? Which Is Best?:
https://spin.atomicobject.com/2016/07/06/time-zones-offsets/

Quoting:


- Given a time zone and a UTC time, you can know the offset—and
  therefore the local time.

- Given a local time and an offset, you can know UTC time, but you do
  not know which time zone you’re in (because multiple timezones have
  the same offset).

- Given UTC and an offset, you can know the local time.

- Given a time zone and an offset, you don’t know much. 

- That’s why a calendar systems work with time zones, offsets, and
  UTC; 

- we need the offset to go from local time to UTC, and we need the
  time zone to go from UTC to local time.

-- 
Jean

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

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

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Jean Louis]

* to...@tuxteam.de  [2023-02-01 10:20]:
> Either I understand you wrong, or you don't know what you are
> talking about. 2023-03-23 02:30 @Europe/Berlin refers to /two/
> points in time, thus it /is/ ambiguous. If you use disambiguating
> "time zones" (MEZ vs MESZ in this case) you can resolve that.

Help me with understanding. Which two points in time does it refer?

When I use time zone Europe/Berlin, it only refers to following time
stamp:

2023-03-23 02:30:00+01

What is the other point in time that it refers to?

-- 
Jean

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

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

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Jean Louis]

* Thomas S. Dye  [2023-02-01 10:05]:
> Aloha Jean Louis,
> 
> Jean Louis  writes:
> 
> > * Ihor Radchenko  [2023-01-31 16:46]:
> > > Specifying just @Europe/Berlin is ambiguous around the daylight
> > > savings
> > > transition.
> > 
> > Sorry, I cannot see practical example why is it ambiguous. Unless
> > programmer does not take all information in account, it is not
> > ambigous. People on this planet agree on time zones in advance, so
> > there are few changes that people cannot plan in advance.
> 
> Please see Russia's plan to put Eastern Ukraine on Moscow time, and then
> come back and argue that people on this planet agree on time zones in
> advance:
> 
> https://www.nytimes.com/2023/01/27/world/europe/russia-ukraine-time-zones.html?smid=url-share

Then I have not expressed me enough specific. 

When I said "people", I definitely did not think "all people", as
that is impossible.

The agreement of "people" is summarized by standards of International
Organization for Standardization (ISO) with ISO 8601 that includes
specification and representation of time and time zones.

There may be many disagreements on the world in relation to time
zones, and if they do not align it for international standard, we do
not need to consider it. 

While it may be specific disalignment problem in some country, their
citizen must anyway resort to ISO again for calculations.

We all rely on ISO standard. Not capricious decisions going behind that.

-- 
Jean

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

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

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Tim Cross]

 writes:

> [[PGP Signed Part:Undecided]]
> On Tue, Jan 31, 2023 at 11:12:00PM +0300, Jean Louis wrote:
>> * Ihor Radchenko  [2023-01-31 16:46]:
>> > Specifying just @Europe/Berlin is ambiguous around the daylight savings
>> > transition.
>> 
>> Sorry, I cannot see practical example why is it ambiguous. Unless
>> programmer does not take all information in account, it is not
>> ambigous. People on this planet agree on time zones in advance, so
>> there are few changes that people cannot plan in advance.
>
> (snipped the huge CC list)
>
> Either I understand you wrong, or you don't know what you are
> talking about. 2023-03-23 02:30 @Europe/Berlin refers to /two/
> points in time, thus it /is/ ambiguous. If you use disambiguating
> "time zones" (MEZ vs MESZ in this case) you can resolve that.
>

I think the confusion relates to context interpretation. If you see
@Europe/Berlin in isolation, then it is ambiguous as it can refer to two
different time zone definitions (standard v daylight savings).  However,
if you consider it in conjunction with a date and time, as in 2023-03-23
02:30 @Europe/Berlin, then it isn't ambiguous - in that case, it really
just says 'Lookup the time zone offset in the databse for Berlin as of
that date and time. Now that could change - for example, the German
government might make a temporary or permanent change that would change
the offset from UTC for that date+time the day after I look at it (or
export it). 

Personally, I cannot see the use case of including both a fully
qualitifed time zone (as in @Europe/Berlin) and an offset, but I also
don't know all possible use cases - there could well be use cases where
you want/need to record both the location time zone as well as the
offset at the point when you recorded the timestamp. This is why I'm in
favor of a flexible and extensible syntax and strongly disagree with any
argument which says we don't need UTC or we don't need abbreviated TZ
names or .

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[tomas]

On Tue, Jan 31, 2023 at 11:12:00PM +0300, Jean Louis wrote:
> * Ihor Radchenko  [2023-01-31 16:46]:
> > Specifying just @Europe/Berlin is ambiguous around the daylight savings
> > transition.
> 
> Sorry, I cannot see practical example why is it ambiguous. Unless
> programmer does not take all information in account, it is not
> ambigous. People on this planet agree on time zones in advance, so
> there are few changes that people cannot plan in advance.

(snipped the huge CC list)

Either I understand you wrong, or you don't know what you are
talking about. 2023-03-23 02:30 @Europe/Berlin refers to /two/
points in time, thus it /is/ ambiguous. If you use disambiguating
"time zones" (MEZ vs MESZ in this case) you can resolve that.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Thomas S. Dye]

Aloha Jean Louis,

Jean Louis  writes:


* Ihor Radchenko  [2023-01-31 16:46]:
Specifying just @Europe/Berlin is ambiguous around the daylight 
savings

transition.


Sorry, I cannot see practical example why is it ambiguous. 
Unless

programmer does not take all information in account, it is not
ambigous. People on this planet agree on time zones in advance, 
so

there are few changes that people cannot plan in advance.


Please see Russia's plan to put Eastern Ukraine on Moscow time, 
and then come back and argue that people on this planet agree on 
time zones in advance:


https://www.nytimes.com/2023/01/27/world/europe/russia-ukraine-time-zones.html?smid=url-share

All the best,
Tom
--
Thomas S. Dye
https://tsdye.online/tsdye

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Jean Louis]

* Ihor Radchenko  [2023-01-31 16:46]:
> Specifying just @Europe/Berlin is ambiguous around the daylight savings
> transition.

Sorry, I cannot see practical example why is it ambiguous. Unless
programmer does not take all information in account, it is not
ambigous. People on this planet agree on time zones in advance, so
there are few changes that people cannot plan in advance.

Those changes are recorded in time zone databases.

Unless you consider programming without using time zone databases,
then I can surely understand that it will be ambiguous. 

> To resolve the ambiguous, we should either introduce DST flag

DST is property of time zone. You do not introduce it, you read it
from time zone database.

But maybe you wish to implement time zones in Org.

In that case I can only say "Good luck" to accuracy.

> or simply allow specifying the UTC offset directly.

UTC offset is not reliable, and is also derived from time zone
database. 

Try it out, make tests, create experiments, compare if that approach
will be usable, publish it and put in for testing.

> Since DST is not guaranteed to be +-1 hour (it may be more, up to 1
> full day), DST flag is more problematic than UTC offset.

Is not if you always pull the latest tz database. Political changes
are pretty careful to people and decisions are announced ahead of the
change.

So do you think that you cannot use tz database in Emacs Lisp?

Maybe it will be necessary to make new Lisp functions defined in C
language, accessing the time zone database.

But it is not for Org to implement new tz database in Emacs Lisp, that
will become unmaintainable work. But why not, if you wish, but
accuracy of time will be questionable.

Researching following pages will give you idea with what you are
trying to deal with on Org level:

How to Read the tz Database:
https://data.iana.org/time-zones/tz-how-to.html

List of tz database time zones - Wikipedia:
https://en.wikipedia.org/wiki/List_of_tz_database_time_zones

tz database - Wikipedia:
https://en.wikipedia.org/wiki/Tz_database

-- 
Jean

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

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

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Jean Louis]

* Ihor Radchenko  [2023-01-31 16:46]:
> >>For time ranges, we will only allow a single offset and time zone
> >>specifier for both start and end times:
> >>[2022-11-12 8:00-9:00+08]
> >>If different time zones are necessary to specify the start/end times,
> >>users can still use full timestamp range syntax
> >>[2022-11-12 8:00+03]--[2022-11-12 22:00+08]
> >
> > I have already explained today that above calculation cannot be
> > unambigous. Please verify my references and practical examples. When
> > user thinks that span is X hours, the real span could be X-1 or X+1
> 
> This has been discussed in the previous emails.
> Consider that you are running a scientific experiment around daylight
> saving time change: [2022-10-29 2:15-5:15+02]. You don't care that the
> government decided that the wall clock should go like 2:15 -> 2:59 ->
> [CEST -> CET] 2:00 -> 2:15 -> 2:59. Physics does not care. You just need
> to make sure that the experiment runs exactly 3 hours without trying to
> consider the currently used TZ rules.

Sorry, I cannot see how running the experiment three hours long is 
related to exchange of for example, appointments, or calendar events
that shall be represented in possibly different time zones. 

It seems you have different personal purposes for time representation
in Org.

How about making a list, why at all are you doing it? Is it for
scientific experiment that you run in your place 3 hours? Or for
people travelling or exchanging times.

Are you sure that telling not to care is good notion?

Why not simply give up on setting up times correctly?

> In contrast, writing [2022-10-29 2:15-5:15 @Europe/Berlin] is
> ambiguous as it may imply both 2:15CEST-5:15CET (4 hours) or
> 2:15CET-5:15CET (3 hours).

Why don't you make the experiment and show how it is ambiguous?

Where is the error in this comparison of Europe/Berlin time and CET
time?

Is daylight savings change what you expect? I am not sure and I am
asking you about this.

Here is practical example, is there anything wrong?

How is it ambigious?

 2022-10-29 02:15:00+02 | 2022-10-29 01:15:00
 2022-10-29 02:20:00+02 | 2022-10-29 01:20:00
 2022-10-29 02:25:00+02 | 2022-10-29 01:25:00
 2022-10-29 02:30:00+02 | 2022-10-29 01:30:00
 2022-10-29 02:35:00+02 | 2022-10-29 01:35:00
 2022-10-29 02:40:00+02 | 2022-10-29 01:40:00
 2022-10-29 02:45:00+02 | 2022-10-29 01:45:00
 2022-10-29 02:50:00+02 | 2022-10-29 01:50:00
 2022-10-29 02:55:00+02 | 2022-10-29 01:55:00
 2022-10-29 03:00:00+02 | 2022-10-29 02:00:00
 2022-10-29 03:05:00+02 | 2022-10-29 02:05:00
 2022-10-29 03:10:00+02 | 2022-10-29 02:10:00
 2022-10-29 03:15:00+02 | 2022-10-29 02:15:00
 2022-10-29 03:20:00+02 | 2022-10-29 02:20:00
 2022-10-29 03:25:00+02 | 2022-10-29 02:25:00
 2022-10-29 03:30:00+02 | 2022-10-29 02:30:00
 2022-10-29 03:35:00+02 | 2022-10-29 02:35:00
 2022-10-29 03:40:00+02 | 2022-10-29 02:40:00
 2022-10-29 03:45:00+02 | 2022-10-29 02:45:00
 2022-10-29 03:50:00+02 | 2022-10-29 02:50:00
 2022-10-29 03:55:00+02 | 2022-10-29 02:55:00
 2022-10-29 04:00:00+02 | 2022-10-29 03:00:00
 2022-10-29 04:05:00+02 | 2022-10-29 03:05:00
 2022-10-29 04:10:00+02 | 2022-10-29 03:10:00
 2022-10-29 04:15:00+02 | 2022-10-29 03:15:00
 2022-10-29 04:20:00+02 | 2022-10-29 03:20:00
 2022-10-29 04:25:00+02 | 2022-10-29 03:25:00
 2022-10-29 04:30:00+02 | 2022-10-29 03:30:00
 2022-10-29 04:35:00+02 | 2022-10-29 03:35:00
 2022-10-29 04:40:00+02 | 2022-10-29 03:40:00
 2022-10-29 04:45:00+02 | 2022-10-29 03:45:00
 2022-10-29 04:50:00+02 | 2022-10-29 03:50:00
 2022-10-29 04:55:00+02 | 2022-10-29 03:55:00
 2022-10-29 05:00:00+02 | 2022-10-29 04:00:00
 2022-10-29 05:05:00+02 | 2022-10-29 04:05:00
 2022-10-29 05:10:00+02 | 2022-10-29 04:10:00
 2022-10-29 05:15:00+02 | 2022-10-29 04:15:00

-- 
Jean

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

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

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Samuel Wales]

amazing amount of work and good choices.  i won't object, although
previous comments re syntax proliferation and 3rd party and personal
code re stand, while acknowledging the replies.  i cannot take a close
look.

just a few tiny nits tht shouldn't realy affect much or quite possibly
reflect ignorance:

bce and ce might be possibilities.  if negative numbers or somethigare
not uniquely used for that.

can any of this, or the semantics, be in emacs?  emacs has times all
over the place.

1. Reduced timestamp precision:
   1985-04-12 (day precision, time omitted; available in Org)

current agenda search query semantics seem /currently/ potentially
confusing re in/equalities for today, now, day precision.  e.g. is
today a specific minute or can = refer to any minute in the day?  is
the manual clear?


On 1/31/23, Ihor Radchenko  wrote:
> Greg Minshall  writes:
>
>> just a thought/reminder.  there are "semantics" and "encoding".  a spec
>> like ISO-8601 specifies both.  the important thing for org-mode is to
>> use an encoding that
>>
>> 1. is easily parsable/understandable by the mere mortal
>>
>> 2. allows expression of all the semantics of the underlying spec/specs
>>(be that ISO-8601, this new IETF spec, the Library of Congress spec,
>>etc.)
>>
>> 3. and, importantly, is designed to *try* to follow updates to the
>>underlying spec/specs (which will inevitably happen)
>
> I agree with these three points.
>
> Following the previous discussion and the various links provided, I have
> reviewed the main discussed timestamp standards and would like to
> propose the new Org timestamp syntax that will allow specifying time
> zone information.
>
> I will not follow the standards fully because the available standards
> are not designed to be easily understood by humans. I will also omit
> the ideas from the standards that are unrelated to time stamps (but
> still outline them below, and keep them in mind for
> forward-compatibility). I will, however, try to use the syntax close to
> the standards where possible.
>
> 1. https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/
>proposal is extending ISO8601/RFC3339 with time zone information. In
>addition to UTC offset defined in ISO8601, it allows specifying the
>time zone identifier and auxiliary information.
>
>Examples:
>
>2022-07-08T02:14:07+02:00[Europe/Paris]
>(both offset, and time zone are specified)
>Note that we cannot use "[]" symbols because they are incompatible
>with current timestamp syntax that must not contain closing "]>"
>inside the timestamp.
>
>1996-12-19T16:39:57-08:00[America/Los_Angeles][u-ca=hebrew]
>(preferred calendar is specified in addition to time zone)
>Note: calendar spec is out of scope of time zone discussion - if we
>decide to add it in future, we can simply add new parts to
>timestamps, just like repeater interval and warning period.
>
>Further, the draft proposes an idea, which have also been discussed
>in this thread: making use of redundant UTC offset + time zone
>information to detect possible unexpected changes in time zone rules:
>
>2022-07-08T00:14:07+00:00[!Europe/London]
>("!" identifies that +00:00 offset, if not consistent with
>Europe/London at the timestamp time, must be signalled to user or
>generally not ignored)
>
> 2. https://www.loc.gov/standards/datetime/ does not contain any new
>ideas relevant to time zones, although it has many other ideas wrt
>approximate/incomplete timestamps. I will outline them later, but
>they do not directly affect the proposed new Org timestamp syntax.
>
> |---|
> | The proposed new timestamp syntax |
> |---|
>
> I propose two forms of time zone information in Org timestamps
>
> 1. Timestamp with explicit UTC offset
>
>-MM-DD [optional day name] HH:MM[^ \]>]*?[+-−]HH[MM]?
>-MM-DD [optional day name] HH:MM[^ \]>]*?Z[ \]>]
>
>"-" is latin "HYPHEN-MINUS" (code 0x2D)
>"−" is unicode "MINUS SIGN" (code 0x2212), as prescribed by ISO8601
>we will not actually use it when generating timestamps, but allow it
>to keep some compatibility with ISO standard.
>
>"Z" in the second format refers to "Zulu" time (another name for UTC)
>and must be either the last character in the timestamp or the
>last character before space. Not sure if many users are familiar with
>"Z" convention, but it is (1) in ISO; (2) succinct for users who are
>familiar with it. We will prefer +00 number offset in auto-generated
>timestamps.
>
>Examples:
>2022-11-12 12:00+02 # 12:00 UTC+2
>2022-11-12 14:00+0230 # 14:00 UTC+2:30
>2022-11-12 14:00-0230 # 14:00 UTC-2:30
>2022-11-12 14:00Z # 14:00 UTC
>
>The offset is a subset of what is defined by ISO8601.
>
>Note that unlike ISO8601, ":" is not allowed in the offset specifier.
>This is to disambiguate with the 

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Tim Cross]

Ihor Radchenko  writes:

> Greg Minshall  writes:
>
>> just a thought/reminder.  there are "semantics" and "encoding".  a spec
>> like ISO-8601 specifies both.  the important thing for org-mode is to
>> use an encoding that
>>
>> 1. is easily parsable/understandable by the mere mortal
>>
>> 2. allows expression of all the semantics of the underlying spec/specs
>>(be that ISO-8601, this new IETF spec, the Library of Congress spec,
>>etc.)
>>
>> 3. and, importantly, is designed to *try* to follow updates to the
>>underlying spec/specs (which will inevitably happen)
>
> I agree with these three points.
>
> Following the previous discussion and the various links provided, I have
> reviewed the main discussed timestamp standards and would like to
> propose the new Org timestamp syntax that will allow specifying time
> zone information.
>
> I will not follow the standards fully because the available standards
> are not designed to be easily understood by humans. I will also omit
> the ideas from the standards that are unrelated to time stamps (but
> still outline them below, and keep them in mind for
> forward-compatibility). I will, however, try to use the syntax close to
> the standards where possible.
>
> 1. https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/
>proposal is extending ISO8601/RFC3339 with time zone information. In
>addition to UTC offset defined in ISO8601, it allows specifying the
>time zone identifier and auxiliary information.
>
>Examples:
>
>2022-07-08T02:14:07+02:00[Europe/Paris]
>(both offset, and time zone are specified)
>Note that we cannot use "[]" symbols because they are incompatible
>with current timestamp syntax that must not contain closing "]>"
>inside the timestamp.
>
>1996-12-19T16:39:57-08:00[America/Los_Angeles][u-ca=hebrew]
>(preferred calendar is specified in addition to time zone)
>Note: calendar spec is out of scope of time zone discussion - if we
>decide to add it in future, we can simply add new parts to
>timestamps, just like repeater interval and warning period.
>
>Further, the draft proposes an idea, which have also been discussed
>in this thread: making use of redundant UTC offset + time zone
>information to detect possible unexpected changes in time zone rules:
>
>2022-07-08T00:14:07+00:00[!Europe/London]
>("!" identifies that +00:00 offset, if not consistent with
>Europe/London at the timestamp time, must be signalled to user or
>generally not ignored)
>
> 2. https://www.loc.gov/standards/datetime/ does not contain any new
>ideas relevant to time zones, although it has many other ideas wrt
>approximate/incomplete timestamps. I will outline them later, but
>they do not directly affect the proposed new Org timestamp syntax.
>
> |---|
> | The proposed new timestamp syntax |
> |---|
>
> I propose two forms of time zone information in Org timestamps
>
> 1. Timestamp with explicit UTC offset
>
>-MM-DD [optional day name] HH:MM[^ \]>]*?[+-−]HH[MM]?
>-MM-DD [optional day name] HH:MM[^ \]>]*?Z[ \]>]
>
>"-" is latin "HYPHEN-MINUS" (code 0x2D)
>"−" is unicode "MINUS SIGN" (code 0x2212), as prescribed by ISO8601
>we will not actually use it when generating timestamps, but allow it
>to keep some compatibility with ISO standard.
>
>"Z" in the second format refers to "Zulu" time (another name for UTC)
>and must be either the last character in the timestamp or the
>last character before space. Not sure if many users are familiar with
>"Z" convention, but it is (1) in ISO; (2) succinct for users who are
>familiar with it. We will prefer +00 number offset in auto-generated
>timestamps.
>
>Examples:
>2022-11-12 12:00+02 # 12:00 UTC+2
>2022-11-12 14:00+0230 # 14:00 UTC+2:30
>2022-11-12 14:00-0230 # 14:00 UTC-2:30
>2022-11-12 14:00Z # 14:00 UTC
>
>The offset is a subset of what is defined by ISO8601.
>
>Note that unlike ISO8601, ":" is not allowed in the offset specifier.
>This is to disambiguate with the time intervals in Org timestamps:
>[2022-11-12 8:00-9:00] in Org is a time range from 8am to 9am.
>
>For time ranges, we will only allow a single offset and time zone
>specifier for both start and end times:
>[2022-11-12 8:00-9:00+08]
>If different time zones are necessary to specify the start/end times,
>users can still use full timestamp range syntax
>[2022-11-12 8:00+03]--[2022-11-12 22:00+08]
>
>The format is also forward-compatible with extending Org timestamps
>for second/sub-second precision: 2022-11-12 14:00:05.0012+0230 will
>remain valid if we decide to adopt such format.
>
> 2. Timestamp with time zone specifier
>
>-MM-DD [optional day name] HH:MM[^ ]* @[!]?<[^ \]>]>
>
>For now, time zone name will only be processed when it follows TZ

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Greg Minshall]

Ihor,

thanks for all the information.

> 2022-11-12 12:00 @Asia/Singapore # tzdb syntax

aesthetically, allowing a space after the "@" sign might be nice.  i
don't know what that would do to the parsing/BNF/whatever.

cheers, Greg

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Jean Louis]

* Ihor Radchenko  [2023-01-31 14:48]:
> I will not follow the standards fully because the available standards
> are not designed to be easily understood by humans.

Very right, thank you.

> 1. https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/
>2022-07-08T02:14:07+02:00[Europe/Paris]

The above looks nice, though not as clear from human view point as
compared to standard Org time stamps, which are very readable.

> 2. https://www.loc.gov/standards/datetime/ does not contain any new

I would disregard above, as that is US government, not international
document. Reason why they use UTC offset alone is that they decided
they do not need more than that.

Org is international and should not be bound to US only.

>-MM-DD [optional day name] HH:MM[^ \]>]*?[+-−]HH[MM]?
>-MM-DD [optional day name] HH:MM[^ \]>]*?Z[ \]>]

>Examples:
>2022-11-12 12:00+02 # 12:00 UTC+2
>2022-11-12 14:00+0230 # 14:00 UTC+2:30
>2022-11-12 14:00-0230 # 14:00 UTC-2:30
>2022-11-12 14:00Z # 14:00 UTC

It looks nice, but I have demonstrated that calculations by using UTC
offset can't be accurate.

Please disprove and rectify me, by using practical examples, you could
disprove my practical example offered previously.

>For time ranges, we will only allow a single offset and time zone
>specifier for both start and end times:
>[2022-11-12 8:00-9:00+08]
>If different time zones are necessary to specify the start/end times,
>users can still use full timestamp range syntax
>[2022-11-12 8:00+03]--[2022-11-12 22:00+08]

I have already explained today that above calculation cannot be
unambigous. Please verify my references and practical examples. When
user thinks that span is X hours, the real span could be X-1 or X+1

> 3. (1) and (2) can be combined
> 
>2022-11-12 12:00+08 @Asia/Singapore

That is how it should be, the UTC offset combined, with the time zone. 

And I suggest avoiding such timestamps by default, rather using time
stamps as usual, and having heading time zone property, file time zone
property and Org using system time zone in absence of any of them.

Providing practical example or functions on how to calculate it should
give better feeling which way will be better.

This is very simple timestamp, readable, with weekday:

<2023-01-31 Tue 16:13>

I propose to remain that way, how it is, with addition:

1. If user wish, could add time zone, including UTC offset. Adding
   only UTC offset makes no sense, and adding time zone without UTC
   offset will cause difficulties in future. Thus:

<2023-01-31 Tue 16:13+03 @Africa/Nairobi>

2. Otherwise heading could have time stamp when necessary to
   distinguish it from other headings:

* My heading
  :PROPERTIES:
  :TIMEZONE: +03 @Africa/Nairobi
  :END:

Then this time stamp <2023-01-31 Tue 16:13> would 

3. Otherwise file could have time stamp, if necessary to distinguish
   it from other files on the same system:

#+TIMEZONE: +03 @Africa/Nairobi

4. Otherwise system time zone

That way you only upgrade time stamps with UTC offset and time zone,
only when necessary, leaving everything else how it is, with addition
of better calculations and related functions.

All of the timestamps, including those simple existing one like
<2023-01-31 Tue 16:21> in Org can be made unambigous in their
representation or exchange by using UTC offset, plus the time zone, by
using those properties.

And very good reference on that link:
https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/

Although serialization with offset time zones is supported in this
document for backwards compatibility with java.time.ZonedDateTime
[JAVAZDT], use of offset time zones is strongly discouraged.  In
particular, programs MUST NOT copy the UTC offset from a timestamp
into an offset time zone in order to satisfy another program which
requires a time zone annotation in its input.  Doing this will
improperly assert that the UTC offset of timestamps in that location
will never change, which can result in incorrect calculations in
programs that add, subtract, or otherwise derive new timestamps from
the one provided.  For example, 2020-01- 01T00:00+01:00[Europe/Paris]
will let programs add six months to the timestamp while adjusting for
Summer Time (Daylight Saving Time).  But the same calculation applied
to 2020-01-01T00:00+01:00[+01:00] will produce an incorrect result
that will be off by one hour in the timezone Europe/Paris.


-- 
Jean

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

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

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

[ adding Org ML back to CC ]

Daryl Manning  writes:

> OMG it would be amazing if (simply) going <2023-01-31 10:00 @EST> or when
> daylight savings time hits <2023-01-31 10:00 @EDT> worked.
>
> would be *super* happy with that as a user who spends a lot of time dealing
> with other time zones. =]

You can play around with the following

(format-time-string "%Y-%m-%d %a %H:%M" (current-time) "EST")
(format-time-string "%Y-%m-%d %a %H:%M" (current-time) "Asia/Singapore")

(format-time-string "%Y-%m-%d %a %H:%M" (current-time) "EDT") ; => not correct
(format-time-string "%Y-%m-%d %a %H:%M" (current-time) "EDT5") ;=> correct, 
because daylight saving is not active now

"EDT" is not supported (at least, on my system). AFAIK, the correct TZ
format is
(format-time-string "%Y-%m-%d %a %H:%M" (current-time) "EST5EDT")

(Side note: we should probably detect unsupported time zone names and
issue a warning)

Note that Emacs provides `timezone-zone-to-minute', but, as you see in
the docstring below, EST must not be used because it may be ambiguous
outside USA. (That's why POSIX TZ format demands the offset part in
addition to time zone abbreviation)

`current-time-zone' is also not helpful here:
(current-time-zone nil "EDT") ;=> (0 "EDT") == UTC??
(current-time-zone nil "EST") ;=> (-18000 "EST")
(current-time-zone nil "EST5EDT") ;=> (-18000 "EST")

(defvar timezone-world-timezones
  '(("PST" .  -800)
("PDT" .  -700)
("MST" .  -700)
("MDT" .  -600)
("CST" .  -600)
("CDT" .  -500)
("EST" .  -500)
("EDT" .  -400)
("AST" .  -400) ;by 
("NST" .  -330) ;by 
("UT"  .  +000)
("GMT" .  +000)
("BST" .  +100)
("MET" .  +100)
("EET" .  +200)
("JST" .  +900)
("GMT+1"  .  +100) ("GMT+2"  .  +200) ("GMT+3"  .  +300)
("GMT+4"  .  +400) ("GMT+5"  .  +500) ("GMT+6"  .  +600)
("GMT+7"  .  +700) ("GMT+8"  .  +800) ("GMT+9"  .  +900)
("GMT+10" . +1000) ("GMT+11" . +1100) ("GMT+12" . +1200) ("GMT+13" . +1300)
("GMT-1"  .  -100) ("GMT-2"  .  -200) ("GMT-3"  .  -300)
("GMT-4"  .  -400) ("GMT-5"  .  -500) ("GMT-6"  .  -600)
("GMT-7"  .  -700) ("GMT-8"  .  -800) ("GMT-9"  .  -900)
("GMT-10" . -1000) ("GMT-11" . -1100) ("GMT-12" . -1200))
  "Time differentials of timezone from GMT in +-HHMM form.
This list is obsolescent, and is present only for backwards compatibility,
because time zone names are ambiguous in practice.
Use `current-time-zone' instead.")

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Jean Louis]

* Max Nikulin  [2023-01-31 11:16]:
> On 31/01/2023 14:04, Jean Louis wrote:
> > I have given facts, and references with the sole intention to help in
> > understanding so that Org programmers do not start relying on UTC
> > offset alone, as that is not how other programs work.
> 
> From my point of view at the beginning you were promoting that Org must use
> purely UTC timestamps just because PostgreSQL recommends timestamptz
> type.

I am not promoter of "UTC timestamps", you have mixed me maybe with
some other person. Last time you misquoted me.

That PostgreSQL recommends time stamp with time zone is only in so far
related to Org as for program design decisions.

There is plethore of other programs using time, just look in any
calendar and underground.

I do not promote anything, I give suggestions to developers to make
decisions that will not impact people. 

My proposal is not that what you describe, but I will repeat it here
for clarity:

- Timestamps may be left how they are now with small addition

- Time stamp could get time zone (I never said UTC, neither UTC
  offset) -- I would myself never suggest to people to place
  timestamps in time zone, but to simply use the local system time
  zone. Case to use time stamps with time zone would be then when such
  time stamp is isolated in the whole Org file and as such, the task
  has to be sent to other people, shared, or published. This is finely
  grained.

- Heading could have time zone property, then all time stamps in that
  heading would easily be calculated for sharing purposes.

- If not heading, then user could set up file #+TIMEZONE property, if
  such is or should be different to system time zone

- Without any settings in Org, Org may use system time zone to
  calculate future time difference.

And I said that is in Emacs Lisp similar to logical OR:

timestamp-time-zone OR heading-time-zone OR file-time-zone OR system-time-ZONE

So please do not misinterpret and reiterate what I never proposed or suggested.

> Now you are insisting that every timestamp must have timezone with
> rules describing DST and other transitions.

Absolutely not, I cannot find myself in your description.

> In both cases you are doing it with excessive passion.

You are free to describe it as you wish. And?

> Currently you are arguing with people who have already agreed that
> location-based timezones are important, e.g. Tim and Thomas. I am in
> doubts if it is helpful to someone.

I do not argue with people nothing as because of their name or
position, as people are not object of discussion.

Neither my last writing was related to "location based time zone" but
to UTC offset.

All my writing is directed to Org developers to get access to
references before making any decisions how to calculate times.

-- 
Jean

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

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

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Daryl Manning  writes:

> Dense poll. I had a question about this format which is what I assume I'd
> be using if using org-mode with this on a day-to-day basis if given the
> choice.
> (from 2. Timestamp with time zone specifier)
>
>  2022-11-12 10:00 @EST+5  # TZ syntax
>
> Normally, when I'm communicating things like standard and daylight savings
> time via mail or verbally, I'd use this if writing emails or what have you.
> ie. 2023-01-31 10:00 EST (or EDT)

AFAIK, 2023-01-31 10:00 @EST will work.
We need "@" because otherwise we may run into trouble if we need to
add more information fields to timestamp syntax.

> Is the +5 offset in the example from the poll here to disambiguate the EST
> from other ESTs (I realize from
> https://en.wikipedia.org/wiki/List_of_time_zone_abbreviations these are not
> always unique) or is the idea that someone would have to specify the
> timezone offset each entry rather than saying EST or EDT?

The aim is to pass the @ transparently to glibc. Anything you can
put into TZ environment variable should do. AFAIK, "EST" is allowed via
TZDB (see https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)

Note that we will eventually adapt the interactive commands to simplify
entering the time zones. Adding time zone completion is one of the
obvious useful features.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Jean Louis  writes:

>>For time ranges, we will only allow a single offset and time zone
>>specifier for both start and end times:
>>[2022-11-12 8:00-9:00+08]
>>If different time zones are necessary to specify the start/end times,
>>users can still use full timestamp range syntax
>>[2022-11-12 8:00+03]--[2022-11-12 22:00+08]
>
> I have already explained today that above calculation cannot be
> unambigous. Please verify my references and practical examples. When
> user thinks that span is X hours, the real span could be X-1 or X+1

This has been discussed in the previous emails.
Consider that you are running a scientific experiment around daylight
saving time change: [2022-10-29 2:15-5:15+02]. You don't care that the
government decided that the wall clock should go like 2:15 -> 2:59 ->
[CEST -> CET] 2:00 -> 2:15 -> 2:59. Physics does not care. You just need
to make sure that the experiment runs exactly 3 hours without trying to
consider the currently used TZ rules. In contrast, writing [2022-10-29
2:15-5:15 @Europe/Berlin] is ambiguous as it may imply both
2:15CEST-5:15CET (4 hours) or 2:15CET-5:15CET (3 hours).

Specifying just @Europe/Berlin is ambiguous around the daylight savings
transition. To resolve the ambiguous, we should either introduce DST
flag or simply allow specifying the UTC offset directly. Since DST is
not guaranteed to be +-1 hour (it may be more, up to 1 full day), DST
flag is more problematic than UTC offset.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Daryl Manning]

Dense poll. I had a question about this format which is what I assume I'd
be using if using org-mode with this on a day-to-day basis if given the
choice.
(from 2. Timestamp with time zone specifier)

 2022-11-12 10:00 @EST+5  # TZ syntax

Normally, when I'm communicating things like standard and daylight savings
time via mail or verbally, I'd use this if writing emails or what have you.
ie. 2023-01-31 10:00 EST (or EDT)

Is the +5 offset in the example from the poll here to disambiguate the EST
from other ESTs (I realize from
https://en.wikipedia.org/wiki/List_of_time_zone_abbreviations these are not
always unique) or is the idea that someone would have to specify the
timezone offset each entry rather than saying EST or EDT?

thanks,
Daryl.




On Tue, Jan 31, 2023 at 6:48 PM Ihor Radchenko  wrote:

> Greg Minshall  writes:
>
> > just a thought/reminder.  there are "semantics" and "encoding".  a spec
> > like ISO-8601 specifies both.  the important thing for org-mode is to
> > use an encoding that
> >
> > 1. is easily parsable/understandable by the mere mortal
> >
> > 2. allows expression of all the semantics of the underlying spec/specs
> >(be that ISO-8601, this new IETF spec, the Library of Congress spec,
> >etc.)
> >
> > 3. and, importantly, is designed to *try* to follow updates to the
> >underlying spec/specs (which will inevitably happen)
>
> I agree with these three points.
>
> Following the previous discussion and the various links provided, I have
> reviewed the main discussed timestamp standards and would like to
> propose the new Org timestamp syntax that will allow specifying time
> zone information.
>
> I will not follow the standards fully because the available standards
> are not designed to be easily understood by humans. I will also omit
> the ideas from the standards that are unrelated to time stamps (but
> still outline them below, and keep them in mind for
> forward-compatibility). I will, however, try to use the syntax close to
> the standards where possible.
>
> 1. https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/
>proposal is extending ISO8601/RFC3339 with time zone information. In
>addition to UTC offset defined in ISO8601, it allows specifying the
>time zone identifier and auxiliary information.
>
>Examples:
>
>2022-07-08T02:14:07+02:00[Europe/Paris]
>(both offset, and time zone are specified)
>Note that we cannot use "[]" symbols because they are incompatible
>with current timestamp syntax that must not contain closing "]>"
>inside the timestamp.
>
>1996-12-19T16:39:57-08:00[America/Los_Angeles][u-ca=hebrew]
>(preferred calendar is specified in addition to time zone)
>Note: calendar spec is out of scope of time zone discussion - if we
>decide to add it in future, we can simply add new parts to
>timestamps, just like repeater interval and warning period.
>
>Further, the draft proposes an idea, which have also been discussed
>in this thread: making use of redundant UTC offset + time zone
>information to detect possible unexpected changes in time zone rules:
>
>2022-07-08T00:14:07+00:00[!Europe/London]
>("!" identifies that +00:00 offset, if not consistent with
>Europe/London at the timestamp time, must be signalled to user or
>generally not ignored)
>
> 2. https://www.loc.gov/standards/datetime/ does not contain any new
>ideas relevant to time zones, although it has many other ideas wrt
>approximate/incomplete timestamps. I will outline them later, but
>they do not directly affect the proposed new Org timestamp syntax.
>
> |---|
> | The proposed new timestamp syntax |
> |---|
>
> I propose two forms of time zone information in Org timestamps
>
> 1. Timestamp with explicit UTC offset
>
>-MM-DD [optional day name] HH:MM[^ \]>]*?[+-−]HH[MM]?
>-MM-DD [optional day name] HH:MM[^ \]>]*?Z[ \]>]
>
>"-" is latin "HYPHEN-MINUS" (code 0x2D)
>"−" is unicode "MINUS SIGN" (code 0x2212), as prescribed by ISO8601
>we will not actually use it when generating timestamps, but allow it
>to keep some compatibility with ISO standard.
>
>"Z" in the second format refers to "Zulu" time (another name for UTC)
>and must be either the last character in the timestamp or the
>last character before space. Not sure if many users are familiar with
>"Z" convention, but it is (1) in ISO; (2) succinct for users who are
>familiar with it. We will prefer +00 number offset in auto-generated
>timestamps.
>
>Examples:
>2022-11-12 12:00+02 # 12:00 UTC+2
>2022-11-12 14:00+0230 # 14:00 UTC+2:30
>2022-11-12 14:00-0230 # 14:00 UTC-2:30
>2022-11-12 14:00Z # 14:00 UTC
>
>The offset is a subset of what is defined by ISO8601.
>
>Note that unlike ISO8601, ":" is not allowed in the offset specifier.
>This is to disambiguate with the time intervals in Org 

[POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Greg Minshall  writes:

> just a thought/reminder.  there are "semantics" and "encoding".  a spec
> like ISO-8601 specifies both.  the important thing for org-mode is to
> use an encoding that
>
> 1. is easily parsable/understandable by the mere mortal
>
> 2. allows expression of all the semantics of the underlying spec/specs
>(be that ISO-8601, this new IETF spec, the Library of Congress spec,
>etc.)
>
> 3. and, importantly, is designed to *try* to follow updates to the
>underlying spec/specs (which will inevitably happen)

I agree with these three points.

Following the previous discussion and the various links provided, I have
reviewed the main discussed timestamp standards and would like to
propose the new Org timestamp syntax that will allow specifying time
zone information.

I will not follow the standards fully because the available standards
are not designed to be easily understood by humans. I will also omit
the ideas from the standards that are unrelated to time stamps (but
still outline them below, and keep them in mind for
forward-compatibility). I will, however, try to use the syntax close to
the standards where possible.

1. https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/
   proposal is extending ISO8601/RFC3339 with time zone information. In
   addition to UTC offset defined in ISO8601, it allows specifying the
   time zone identifier and auxiliary information.

   Examples:

   2022-07-08T02:14:07+02:00[Europe/Paris]
   (both offset, and time zone are specified)
   Note that we cannot use "[]" symbols because they are incompatible
   with current timestamp syntax that must not contain closing "]>"
   inside the timestamp.

   1996-12-19T16:39:57-08:00[America/Los_Angeles][u-ca=hebrew]
   (preferred calendar is specified in addition to time zone)
   Note: calendar spec is out of scope of time zone discussion - if we
   decide to add it in future, we can simply add new parts to
   timestamps, just like repeater interval and warning period.

   Further, the draft proposes an idea, which have also been discussed
   in this thread: making use of redundant UTC offset + time zone
   information to detect possible unexpected changes in time zone rules:

   2022-07-08T00:14:07+00:00[!Europe/London]
   ("!" identifies that +00:00 offset, if not consistent with
   Europe/London at the timestamp time, must be signalled to user or
   generally not ignored)

2. https://www.loc.gov/standards/datetime/ does not contain any new
   ideas relevant to time zones, although it has many other ideas wrt
   approximate/incomplete timestamps. I will outline them later, but
   they do not directly affect the proposed new Org timestamp syntax.
   
|---|
| The proposed new timestamp syntax |
|---|

I propose two forms of time zone information in Org timestamps

1. Timestamp with explicit UTC offset

   -MM-DD [optional day name] HH:MM[^ \]>]*?[+-−]HH[MM]?
   -MM-DD [optional day name] HH:MM[^ \]>]*?Z[ \]>]
   
   "-" is latin "HYPHEN-MINUS" (code 0x2D)
   "−" is unicode "MINUS SIGN" (code 0x2212), as prescribed by ISO8601
   we will not actually use it when generating timestamps, but allow it
   to keep some compatibility with ISO standard.

   "Z" in the second format refers to "Zulu" time (another name for UTC)
   and must be either the last character in the timestamp or the
   last character before space. Not sure if many users are familiar with
   "Z" convention, but it is (1) in ISO; (2) succinct for users who are
   familiar with it. We will prefer +00 number offset in auto-generated
   timestamps.

   Examples:
   2022-11-12 12:00+02 # 12:00 UTC+2
   2022-11-12 14:00+0230 # 14:00 UTC+2:30
   2022-11-12 14:00-0230 # 14:00 UTC-2:30
   2022-11-12 14:00Z # 14:00 UTC

   The offset is a subset of what is defined by ISO8601.
   
   Note that unlike ISO8601, ":" is not allowed in the offset specifier.
   This is to disambiguate with the time intervals in Org timestamps:
   [2022-11-12 8:00-9:00] in Org is a time range from 8am to 9am.

   For time ranges, we will only allow a single offset and time zone
   specifier for both start and end times:
   [2022-11-12 8:00-9:00+08]
   If different time zones are necessary to specify the start/end times,
   users can still use full timestamp range syntax
   [2022-11-12 8:00+03]--[2022-11-12 22:00+08]

   The format is also forward-compatible with extending Org timestamps
   for second/sub-second precision: 2022-11-12 14:00:05.0012+0230 will
   remain valid if we decide to adopt such format.

2. Timestamp with time zone specifier

   -MM-DD [optional day name] HH:MM[^ ]* @[!]?<[^ \]>]>

   For now, time zone name will only be processed when it follows TZ
   POSIX format. If necessary, the proposed syntax will still allow
   extensions to TZ POSIX.

   Examples:
   2022-11-12 12:00 @Asia/Singapore # tzdb syntax
   2022-11-12 10:00 @Europe/Berlin
   2022-11-12 10:00 

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Max Nikulin]

On 31/01/2023 14:04, Jean Louis wrote:

I have given facts, and references with the sole intention to help in
understanding so that Org programmers do not start relying on UTC
offset alone, as that is not how other programs work.


From my point of view at the beginning you were promoting that Org must 
use purely UTC timestamps just because PostgreSQL recommends timestamptz 
type. Now you are insisting that every timestamp must have timezone with 
rules describing DST and other transitions. In both cases you are doing 
it with excessive passion. Currently you are arguing with people who 
have already agreed that location-based timezones are important, e.g. 
Tim and Thomas. I am in doubts if it is helpful to someone.


P.S.
- There are cases when local time + time zone must be stored.
- There are cases when UTC or UTC + fixed offset must be stored.
- There are cases when UTC or UTC + fixed offset is enough, however time 
zone can be added.

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Jean Louis]

Dear Heinz,

Thanks, let me see.

* Heinz Tuechler  [2023-01-31 01:02]:
> Dear Jean Louis,
> 
> it appears to me that you mix two aspects. I agree with you that a time
> zone needs an offset from UTC to be defined. Consequently the definition
> of a time zone requires an offset.

Yes, that is good our mutual understanding.

> But an offset does not need a time zone to define a time.

I am trying to understand what you wanted to say with the
above. 

Before representing time with the UTC offset:
-

To derive the representation of time with the UTC offset, one needs
time zone, as UTC offset is defined in the time zone. That is what you
also said above.

After representing time with the UTC offset:


That time is defined, and at that time point does not need time zone. 

I am not concerned of time representation after UTC offset has been
derived, but of programming calculations to users' local time, as for
example in Org Agenda.

> For example, true mean local solar time of a specific longitude can
> be described by UTC plus offset.

Solar time - Wikipedia:
https://en.wikipedia.org/wiki/Solar_time

By meaning that solar time should be related to longitude, I am
totally with you Heinz. It is also true that one could disregard the
definition of UTC offset from the political reality, and calculate it
absolutely.

That condition I have already mentioned, when I said, that means we
are making "new type of time" in Org, if we start calculating it that
way. 

The meaning of "UTC offset" is however, political. Please see the UTC
offsets here:
https://upload.wikimedia.org/wikipedia/commons/8/88/World_Time_Zones_Map.png

Look at the map, find Kazakhstan with UTC offset +6 on the same
longitude with Russian Federation with UTC offset +5.

Observe Kazakhstan with UTC offset +6 on the same longitude with China
with the UTC offset +8.

That alone should tell you that solar time is not really related to
UTC offset, but we could say it is "approximate" with few hours more
or less.

Of course you can describe solar time with UTC offset, but do not
assume it will be accurate.

> I agree with your criticism of "They refer to local *solar time* at a
> particular place." This is written in
> https://en.wikipedia.org/wiki/UTC_offset , but not even there the
> description is consistent.

We can say it is approximate what they mean.

> Of course, for every finite offset, we can find a corresponding
> particular place (a longitude).

I wish it would be so, but it is not so. It is approximate, just look
at the map.

And please tell me if after this you still think there is something
wrong?

-- 
Jean

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

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

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Jean Louis]

* Tim Cross  [2023-01-31 01:05]:
> Jean,
> 
> you have a very irritating habit of changing the topic of the discussion
> in order to push whatever you feel you want to argue about. My response
> to you had nothing to do with all the irrelevant points you insist on
> repeating despite numerous attempts by many to explain why what you are
> sending is adding little value.
> 
> I was simply responding to your response to Sterling's glossary of
> definitions where you argue against defining offset (the term) as a
> fixed value.
> 
> I will not be engaging with you further.

UTC offsets have been assigned by authorities, that they are
political, change due to daylight savings -- and for that reason
cannot alone as such be used for calculations of time, for example in
Org Agenda.

I fully understand that representation of time with UTC offset alone
is as such fine and good, never said anything opposite.

Adding some hours, days, as absolute time to it, or deducting, it is
of course always possible.

I have given facts, and references with the sole intention to help in
understanding so that Org programmers do not start relying on UTC
offset alone, as that is not how other programs work.

My intention is of course not what you stated. 

I have not get bad intentions. Please do not assume it.

You got references showing that it is politically related, that UTC
offset does change suddenly, and for that reason one cannot just use
it for calculations in program.

I am fully aware and never stated different, that once you place UTC
offset as representation somewhere in text, that it is offset from UTC
time and that time point is fine and remains fixed.

What I am saying is that calculating that time point to local time is
tricky, as using UTC offset alone is not going to give accurate local
time unambiguously. Sometimes it will give, but sometimes not if
programmer uses direct calculation.

"fixed" is thus only fixed in context of representation.

I was thinking we speak here of using time objects for calculating
times in future, not only of representation, as I did not argue about
it.

UTC offset is representation as it has to be derived from time zone to
be represented as such. Provided that program knew how to derive
correct UTC offset, that is "fixed" as representation.

Programmer can now add some time or deduct some time and directly
added or deducted time will also represent some point in time.

But will it be that time that user was thinking for another user in
different time zone?

Unambiguously is not possible to use only UTC offset for such
calculation, due to reason that UTC offset changes how authorities
decide on it.

Let me try to make exercise example both for me and other people, and
feel free to correct me:

From:
https://www.timeanddate.com/news/time/europe-starts-dst-2022.html

,
| Daylight Saving in Europe
| 
| Time changes in Europe are synchronized. According to the current EU
| law, DST starts on the last Sunday of March and ends on the last
| Sunday of October. Participating countries are:
| 
| The European Union (EU), including Bulgaria, France, Germany,
| Italy, Poland, and Spain. 
`

- Last Sunday of March in 2022 was 27th March 2022, or 2022-03-27

- the clock forward had to be done at 1 hour UTC time on March 27th
  2022, because Berlin before 27th March 2022, was with UTC offset +1,
  that time should be 2022-03-27 01:00 UTC time, which is also same as
  Berlin time. 

- Let us say one second after 2022-03-27 01:00 UTC time or UTC +1, the
  clock will not be 2022-03-27 01:00 UTC, but 2022-03-27 02:00 UTC,
  loosing one hour, as clock moved forward. UTC offset changed
  suddenly.

- person in Berlin plans meeting for on 26th March with somebody in
  China, for 27th March 2022 at 10 o'clock, how is he going to
  represent this? Let us see, maybe as
  following. <2022-03-27 Sun 10:00>

- on 26th March 2022, the UTC offset in Berlin was +1

- on 26th March 2022, when user exports that appointment, the time was
  for example 16 o'clock, something like 2022-03-27 16:00+01 because
  UTC offset was +1 at that time.

- If Org programmer decides to use UTC offset only for calculations,
  then the program will know that UTC offset in China is +8 hours.

- What will program do? By using UTC offset only, program will know
  that now is 2022-03-27 16:00+01 and that timestamp like
  <2022-03-27 Sun 10:00> is also with UTC offset +1 (which is not
  true). But program would think it is 2022-03-27 10:00+01 if program
  uses UTC offset only.

- Program may wish to provide new UTC offset for Chinese user, by
  knowing that in China on 26th March 2022, at 16 o'clock is +8 and
  not +1, the difference of 7 hours will be added on the time stamp of
  appointment, which is 2022-03-27 17:00+01

- However the time of 27th March 2022 at 10 o'clock Berlin time the
  time in Shanghai was 16 o'clock.

- While Chinese user was in restaurant at 16 o'clock and waiting for
  appointment at 17 o'clock, because he 

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Thomas S. Dye]

Aloha Jean Louis,

Jean Louis  writes:


Dear Thomas,

I give my best to find references for you and explain you the 
possible
problem in calculation of time stamps. That problems exist is 
clear.


To solve problem it is important to first define it. And when 
there
are developers reading it, I wish to provide best possible 
references

for the sake of people using Org mode.

So let me gently try explaining it with different words.


At this point, we appear to be talking past one another.

All the best,
Tom
--
Thomas S. Dye
https://tsdye.online/tsdye

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Tim Cross]

Jean Louis  writes:

> * Tim Cross  [2023-01-29 23:38]:
>> Saying that an offset is a fixed value is very different from saying
>> that a time zone has a fixed offset. I think this is where your
>> confusion is coming from. 
>
> I said neither of those. I never said that UTC offset is fixed. I am
> trying to give you references that you understand what people agreed
> on this planet.
>
> I never said that time zone has fixed offset, some time zones have it
> fixed, some not, as UTC offset changes for daylight savings and
> political reasons.

Jean,

you have a very irritating habit of changing the topic of the discussion
in order to push whatever you feel you want to argue about. My response
to you had nothing to do with all the irrelevant points you insist on
repeating despite numerous attempts by many to explain why what you are
sending is adding little value.

I was simply responding to your response to Sterling's glossary of
definitions where you argue against defining offset (the term) as a
fixed value.

I will not be engaging with you further.

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Jean Louis]

* Tim Cross  [2023-01-29 23:38]:
> Yes, a timezone is defined by the offset it has from UTC

Other way around Tim, the UTC offset is defined for the time zone.

Time zone is not derived fro UTC offset, that does not work. UTC
offset is derived from time zone.

> Yes, a location time zone may change due to various reasons, such as
> daylight savings time, which also means the offset for that timezone
> changes.

Including that offset for that time zone can be changed for political
reasons, and did change in past, and some time zones may multiple UTC
offsets.

> However, it is the time zone definition which has changed.

Yes, and that change is about UTC offset. As time zone represents
location but UTC offset must be tied to it, otherwise how would you
know what time has the time zone?

> When you specify a date+time wiht an explicit offset, that offset is
> fixed.

It is fixed for that time moment. I have not said anything
different. 

I am only worried that if calculation go straight from UTC offset to
UTC offset without observig time zones, one will get proper UTC time,
but not proper representation in users' time zone.

I do believe that Org developers will make right decisions.

> That date+time is fixed. It will not change when daylight davings
> comes in or goes out because it isn't a time zone. It is only an
> offset and has no location reference and therefore no time zone.

For the above, I have already sent a map, by only observing the map,
one can see that time offset is directly related to time zone, it is
property of time zone, and it will change depending of political
changes, and it does change with daylight savings time. I have given
enough references, feel free to read it.

What does not change is the fact that UTC offset representation will
accurately provide UTC time.

>From UTC time, by using user's time zone and various embedded
parameters one could arrive to user's local time, including users UTC
offset.

Excercise:

When there is daylight savings time (clock goes forward or backward),
it shall be clear that UTC offset changes as well. That means one hour
more or less must be accounted for in every calculations of Org
Agenda.

But by using UTC offset alone, one cannot even include daylight
savings time changes! As for that one needs time zone.

Here is another good reference:
https://spin.atomicobject.com/2016/07/06/time-zones-offsets/

,
| Our Example
| 
| America/Coral_Harbour is a time zone (for simplicity, I will focus
| only on IANA* time zones). America/Detroit is a time zone. With laws
| as they are now, the America/Coral_Harbour time zone has an unchanging
| offset of -0500, or five hours “behind” GMT, which for our purposes
| here matches UTC. America/Detroit changes during the year from an
| -0400 offset to an -0500 offset. So sometimes, the good people of
| Coral Harbour and the good people of Detroit have the same
| offset. Sometimes, they don’t.
`

What do you think, is that information true?

Does UTC offset "change" or "remain fixed"?

Is it possible for programmer to convert UTC offset by using direct
calculations?

Or programmer needs to know information about time zones?

This makes calculations of Org Agenda or future time stamps difficult
when using solely UTC time offset.

Time offset is best expressed as representation of time at that time
point, and is always derived from the time zone.

> Saying that an offset is a fixed value is very different from saying
> that a time zone has a fixed offset. I think this is where your
> confusion is coming from. 

I said neither of those. I never said that UTC offset is fixed. I am
trying to give you references that you understand what people agreed
on this planet.

I never said that time zone has fixed offset, some time zones have it
fixed, some not, as UTC offset changes for daylight savings and
political reasons.

-- 
Jean

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

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