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

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

[Ypo]

[-- Attachment #1: Type: text/plain, Size: 2692 bytes --]

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



[-- Attachment #2: Type: text/html, Size: 4279 bytes --]

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)

[Jean Louis]

* Ypo <ypuntot@gmail.com> [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 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?

You cannot know it "beforehand" for future, for present time, yes, and
for some foreseeable period, it is close to certain, though depends of
the country. In some countries by knowing their political stability,
it may be very certain.

>     - Case 3: After updating the tz database we would get warnings
> too.

There need not be any warnings as smart program could figure it out
all.

Condition is only that timestamps were generated with program which
knows it well and not manually.

> To correct those warnings, should the UTC offset be changed manually
> in the timestamp?

I do not think so, and that should not be work of human.

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

As TZ database would know that UTC offset change preceded the date and
time of 2023-02-04 12:00, that would be work of program, not human.

-- 
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 <ypuntot@gmail.com> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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 <yantar92@posteo.net> [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)

[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 <bugs@gnu.support>:

> * Ihor Radchenko <yantar92@posteo.net> [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]

ypuntot <ypuntot@gmail.com> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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 <ypuntot@gmail.com> [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)

[Ihor Radchenko]

Jean Louis <bugs@gnu.support> writes:

> * Ihor Radchenko <yantar92@posteo.net> [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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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 <yantar92@posteo.net> [2023-02-06 17:11]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > * Ihor Radchenko <yantar92@posteo.net> [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 not much sense, it leads
to confusions, including for organizer.

If I am expecting -8 UTC offset, I cannot know if UTC offset will
change in future. And when it changes, maybe my expectation also
changes.

It is useless and creates problems.

And why not follow what other programs do? Specify date, time, not UTC
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.

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

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

-- 
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 <bugs@gnu.support> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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 <yantar92@posteo.net> [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:
| 
|  19980119T230000-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 vaguely, you cannot know if it will remain same in
future. I would assume that author wants us to meet at 12:00 o'clock
of that @SomeTimeZone, no matter the UTC offset, as that one will be
calculated in future time. If time zone changes, the TZ database would
tell what is the new time zone, and calculation is still expected to
be good for future.

Time stamp like this 2008-04-29 02:53:24.796564+03 is past time, with
+03 UTC offset. Past UTC offset does not change, it is accurate. It
was how it was.

2030-02-09 12:00 is future time. I need no offset, but time is
floating as it is not bound to time zone.

2030-02-09 12:00 -08 @UTC -- this time CANNOT be said to be "fixed
UTC" time for reason that UTC time is not represented with UTC
offset. It is either UTC time or time zone time with UTC
offset. Cannot be this and that.

2030-02-09 12:00 -08 @SomeTimeZone -- this is alright

2030-02-09 12:00 -08 @UTC -- not alright, as other programs do not represent time with UTC time zone with offset.

That offset is offset, does not make it "UTC offset" as such is not
used with UTC time zone. Only with other time zones.

For future designation, in database is better, and also confirmed by
references, to enter designation in separate fields, like this:

TIME-DATE: 2023-02-09 12:00
TIME: NIL
TIME-ZONE: @SomeTimeZone

It becomes clear what is intended time zone, and what is date, time intended.

The above representation is not enough clear, as what if it is only date intended?

Maybe this would be more clear:

DATE: 2023-02-09
TIME: NIL
TIME-ZONE: @SomeTimeZone

And this:

DATE: 2023-02-09
TIME: 12:00
TIME-ZONE: @SomeTimeZone

The UTC offset matters not for future as it may change, and it has to
be calculated from @SomeTimeZone definition in future.

Because fields are separated, it can become clear what is intended.

2023-02-09 12:00 -08 @UTC -- is not clear as fields are not separated,
when you say that such timestamp should be UTC fixed time stamp with
offset, because offset is not used with UTC, it is confusing, and you
are showing 12 o'clock, which is contradictory to using offset. You
mean UTC offset, but definition of UTC offset is not that it will
remain fixed in future.

Follow example of iCalendar which says that such designation of UTC
time plus offset would be invalid.

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

That is wrong, for the above mentioned reasons, references. People who
designed iCalendar, had some reasons to tell you why is such timestamp
in future invalid.

If you intend to say UTC time in future, do not use offsets and time
zone. It is contradictory. 

It is either UTC time in future, or it is time with time zone in
future.

While person could tell about UTC offset in future, such is vague as
it can change.

And if you are defining anything, for reasons that fields are not
separated and not marked, user cannot know what you mean:

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?

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?

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.

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.

5. Hypothetical example of timestamp for future, with "tag" to tell
   what you mean, maybe with "!":

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

   where the time would be stamped with "!" and that would mean that
   time "12:00" would be disregarded, but offset of -8 hours from UTC
   would be used.  However, it remains confusing by using offset.

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

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

I hope you understood the difference.

Providing UTC time plus some offset is inconclusive. It is idea that
is not aligned with what international community is doing.

Provide UTC time.

Or provide time zone plus UTC offset.

Your idea as such is alright, but is individual, and it has to be
coordinated with what other programs are doing. Otherwise it become
confusing.

Remember the reference on iCalendar, "not do do that". 

iCalendar provides either UTC time, or date, time and time zone.

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

That problem is solved, if you use TZ database:

- in case of change of time zone, the TZ database will provide future
  adjustment, there may be new name of new time zone. 

- in case of change of UTC offset, the TZ database in future will know
  it. 

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

You are explaining situation with 2 timestamps. 

It is either the timestamp: [2024-01-02 19:00 > @Asia/Singapore]
or Europe/Athens timestamp.

Once you have the timestamp [2024-01-02 19:00 > @Asia/Singapore]
I expect that such may be seen in future Org program, in local time.

To see it in local time program would know the future UTC offset, and
convert it to local time.

I will never miss the meeting provided program consults TZ database.

But if I have 2 timestamps, that is different situation.

You need no UTC offset for future time representation.

Also good to read:
https://engineering.q42.nl/why-always-use-utc-is-bad-advice/

Also good to read:
https://swizec.com/blog/saving-time-in-utc-doesnt-work-and-offsets-arent-enough/

where it says:

The correct way to send "Wednesday at 3pm in San Francisco" looks like this:

{ ...
    timestamp: {
        time: '2022-03-16T15:00:00`
        tz: 'America/Los_Angeles'
    }
}

They also do not provide UTC offset. And none provides UTC time with 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)

[Ihor Radchenko]

Jean Louis <bugs@gnu.support> writes:

> If you start adding in Org "fixed" time with UTC offset, that is a new
> type of timestamp, as it is not common in world.

It is how ISO8601 defines offsets.

> 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:
> | 
> |  19980119T230000-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 not aligned with what international community is doing.
>
> Provide UTC time.
>
> Or provide time zone plus UTC offset.
>
> Your idea as such is alright, but is individual, and it has to be
> coordinated with what other programs are doing. Otherwise it become
> confusing.
>
> Remember the reference on iCalendar, "not do do that". 
>
> iCalendar provides either UTC time, or date, time and time zone.

iCalendar is not the only source of truth. The suggested offsets are
what ISO8601 defines. iCalendar explicitly disregards the fixed offsets
for some iCalendar-specific reasons. It is iCalendar that is not being
aligned with more common standard.

>> > 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.
>
> That problem is solved, if you use TZ database:
>
> - in case of change of time zone, the TZ database will provide future
>   adjustment, there may be new name of new time zone. 
>
> - in case of change of UTC offset, the TZ database in future will know
>   it. 

Your statement is true only when TZ database is guaranteed to be
up-to-date. It is not always the case. Consider opening an Org document
on machine with out-of-date TZ database.

> I will never miss the meeting provided program consults TZ database.

You will not. But I can see myself missing the meeting and assuming the
time "as usual".

> But if I have 2 timestamps, that is different situation.
>
> You need no UTC offset for future time representation.
>
> Also good to read:
> https://engineering.q42.nl/why-always-use-utc-is-bad-advice/
>
> Also good to read:
> https://swizec.com/blog/saving-time-in-utc-doesnt-work-and-offsets-arent-enough/

The second link illustrates exactly UTC offset + also time zone name.
Similar to what I proposed.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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 <yantar92@posteo.net> [2023-02-10 13:48]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > If you start adding in Org "fixed" time with UTC offset, that is a new
> > type of timestamp, as it is not common in world.
> 
> It is how ISO8601 defines offsets.

- did you say you wish to represent time with UTC time zone by using
  UTC offset?

- and I said, UTC time is always without offset, and if any is
  represented then it must be +00

- and now you say that ISO8601 defines offsets... sorry, you are
  confusing me and readers.

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:
> > | 
> > |  19980119T230000-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, they are already there. Only for historical
purposes past time zones may be updated. But very rarely.

You have got past, and future.

Any non-floating "present" timestamp is already past in the moment it
is created.

"Meeting" is not time type of a timestamp. It is action to take place. 

That action can be anything, leave that to users.

I am using various actions, like "call", "marketing campaign",
"directory action", "case", "action", "follow-up", "task", "plan",
"meeting", and various others. 

And not forget, "timestamp" is by computing definition always past.

In Org we are trying to inject future timestamps by thinking it is
"timestamp" while in other computing subjects timestamps is by rule
always past and not future.

References show that future shall be sheduled by using date, time and
time zone or by using UTC plainly.

Problem is how to represent or diferrentiate future from past in Org
type of a timestamp.

This would be alright for me:
<2023-03-10 Fri 10:24 @Europe/Berlin>

One would need to provide algorithm to Org as to avoid placing invalid
timestamps in future, and in future, Org would know how to ask TZ
database to derive the UTC offset.

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

Please note:

- that document speaks of timestamps in it's definition, that means
  "timestamp is represntation of past time".

- It references: https://www.rfc-editor.org/rfc/rfc3339 if you read
  introduction, it says "when representing and using date and time in
  Internet protocols" (Org is not Internet protocol), and then "There
  are many ways in which date and time values might appear in Internet
  protocols: this document focuses on just one common usage,
  viz. timestamps for Internet protocol events" (Org is not Internet
  protocol event)

- then your referenced document says "This document defines an
  extension syntax for timestamps as specified in [RFC3339] that has
  the following properties"

- then your above referenced document further says "This document does
  not address extensions to the format where the semantic result is no
  longer a fixed timestamp that is referenced to a (past or future)
  UTC time.  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."

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.

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

After I told you above, maybe you should re-consider how did you draw
those conclusions. I do not see how your idea is analogous to what
documents speak about.

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

For myself is less important, I can create timestamps in Org how I
wish and want. In general for future, I am using structured time
representation, same thing what is recommended internationally.

                      Time zone   nil
            Start Date and Time   "2023-02-10 06:31:57.919956+03"
              End Date and Time   nil

- begin timestamp is with time zone representation, +03, it is only
  represented that way, but that is UTC time.

- only if there is time zone defined, then the UTC offset will be
  disregarded, and new time calculated by using the time zone's
  definition and it's UTC offset.

That is same thing as iCalendar, or any other software that knows how
to deal with time, I just coupled it together and made conditional.

My Org use is very structured. I use Org or any markup with
properties. And I mix markups like Org, LaTeX, Asciidoc, all in one
document. In same way my timestamps are separated from Org objects.

Thus for this representation:

                      Time zone   nil
            Start Date and Time   "2023-02-10 06:31:57.919956+03"
              End Date and Time   nil

That is UTC time and it will be displayed in my local time zone as:

2023-02-10 06:31:57.919956+03

but if I would be in Europe/Berlin time zone, it would be displayed as:

2023-02-10 04:31:57.919956+01

How is Org going to display a timestamp in local time when it is
stored in UTC time?

It needs either re-writing of a buffer, or temporary preview, or
conversions during export.

And when my time representation has any time zone, then it is
displayed in that time zone:

                      Time zone   "Asia/Kuching"
            Start Date and Time   "2023-02-10 06:31:57.919956+03"
              End Date and Time   nil

In this case, it will be represented in my local time, but this way:

2023-02-10 11:31:57.919956+03

In my case where I keep timestamps as properties separate from Org
objects, it is very easy to get such representations:

SELECT 
  CASE WHEN hyobjects_timezones IS NULL 
  THEN hyobjects_date
       ELSE hyobjects_date AT TIME ZONE hyobjects_timezones 
       END 
  FROM hyobjects WHERE hyobjects_id = 79134;

As I rely on PostgreSQL database and their authors, and it spares me
programming efforts tremendously.

There are many use cases where past representation should NOT be
represented with UTC time. 

Let me remind you that those documents were referring mostly to
Internet time protocols, not to human representation of time.

When person is born, that person knows the date, but the date is tied
to location. 

Thus representing birth date and birth tim with UTC time is of no
use. Hospital will tell it was date of 2023-02-12 and 06:00
o'clock. The time zone is forgotten in such representations, only
local people could derive the time zone. Practically UTC time in such
representation is only confusing. It may be represented in UTC time,
but what really matters is not the UTC time but local time. So local
time must be seen with eyes, even if stored with UTC time.

For this specific birth date case, I always write time with time
zone. That means that UTC time is not to be seen or calculated, but
only the date, time and time zone information.

There are other cases where past time is practically better
represented with the time zone.

For future time, it is alright for me personally to specify it with
the UTC time if such future moments are not really too far in future,
as it is unlikely really that my work.

Though if there are multiple people involved, then I have to represent
it better, and have to say about the time zone.

I am choosing the time zone by using completion. If you need this way
of completing, let me know, I can provide the list of time zones for
purposes of completion in Org.

Here is video of how I select time zones:
https://gnu.support/images/2023/02/2023-02-12/2023-02-12-11:05:15.ogv

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

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

Thank you, that is good.

I have provided examples myself too in this email.

As you say, solar eclipse is future time event that in my opinion
could be represented with the UTC time and displayed to users in their
local time.

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

I totally agree and that is reason why I am writing, I agree it is
good for human to have it readable.

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

It is not good specifying something in Org program and not clearly
giving it to user what is authoritative.

It is either the UTC time, or date, time plus time zone. 

It is not ambigious, it is example that remedies your ambigious
example.

You said: [2024-02-04 12:00 @-08,America/Vancouver] -- would be
counted with fixed UTC offset. So fixed from what? Fixed from time
zone America/Vancouver? Fixed form time represented 2023-02-04 12:00?

When those parts are separate fields, picture becomes clear:

                      Time zone   "America/Vancouver"
            Start Date and Time   "2023-02-04 12:00:00+03"
              End Date and Time   nil

From this time stamp, user seeing it in plain text, cannot know if Org
program means that time 12 o'clock is authoritative or that some
"fixed offset" is used:

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

- you said, you wish to use "fixed offset" from UTC, but than if it is
  fixed, you better use UTC straight, and not wrong representation. It
  is wrong because it is not ordinary. It is either time zone which
  will tell what is offset in future, or it is UTC time which has no
  offset. 

- it is not visible in the time representation that you mean "fixed
  offset", because traditionally offsets are calculated from time zone
  database, and not from past representation!

- traditionally UTC offset is used with local time in order to
  calculate what is UTC. 12:00 -08, means 04:00 UTC time.

- you have introduced confusion, telling that you wish to represent
  time also with @UTC time zone but with offset, that is
  contradictory. 

- OK fine, if I assume that you wish to use "fixed UTC offset in
  future", that means you contradict to time zone definitions, you do
  not even need the time zones! [2024-02-04 12:00 @-08] would mean
  that UTC time is 20:00 o'clock, and that is UTC time. Why do you
  need time zone if you wish to say that it is fixed UTC offset? Time
  zone is used for reason that UTC offsets are not fixed and we have
  to derive it from their definitions.

In general I see you have got it messed up with introduction of:

1. Timestamps @UTC time zone with UTC offsets as they are
   contradictory to international standards and agreements of time
   representation.

2. Timestamps with "fixed UTC offset" where you specify time zone, it
   is contradictory. 

Sure you need not follow international recommendations for future
events, but that will not make Org more useful in that regard of time
representation.

The GMT-08 time zone you mentioned is not authoriative, I could say it
is supplementary.

Can you choose GMT-08 by using `tzselect' command? Wonder why...

[2024-02-04 12:00! @-08,America/Vancouver] is not ambigous, because it
says "America/Vancouver" and has "!" to indicate that 12 o'clock is
authoritative time. I made this only hypothetically for you to
understand that people will not understand the difference by looking
into text like this: [2024-02-04 12:00 @-08,America/Vancouver] where
you said that "this is fixed UTC offset", as one cannot derive from
text alone what you mean!

But this way it can be derived eventually:

[2024-02-04 12:00! @-08,America/Vancouver] -- it means 12 o'clock at
America/Vancouver time zone in future, UTC offset at time point of
planning was -08, but is disregarded as America/Vancouver time zone in
future must be consulted and UTC offset how it will defined in future
must be used as authoritative.

[2024-02-04 12:00 @-08!,America/Vancouver] -- it means it MUST be -08
offset from time 2024-02-04 12:00, but that would indicate UTC time,
so it is useless and confusing to mention "America/Vancouver" as:
[2024-02-04 12:00 @-08!] would be enough as that would be UTC time,
but nowhere is written it is UTC time, it becomes consuing because
ordinary time representation is not represented with UTC offset
without time zone. Then it would be better: [2024-02-04 04:00 @UTC]
as that becomes clear.

The time zone database defines everything. Dwell inside of it. Resarch
it. Do not create new types of time representation.

In case of political changes, the time zone database will again
re-define it, so that local time of that representation can be
displayed with accuracy.

> >> > 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 my attempt to help you understand that time representation type
is not visibl from the timestamp, for the reason that you introduced 2
different time representation types, you introduced:

- timestamp @UTC time zone with UTC offset, this does not exist
  anywhere, only in your idea so far, and I hope it will never be
  implemented, and if it does get implemented I have to file bugs on
  it

- timestamp with time zone other but UTC where you are talking about
  "fixed UTC offset" which is known that it is not fixed, whereby time
  zones are used to derive that future UTC time offset. You can fix it
  for past, not for future.

- thus "UTC-FIXED" is only a different "tag" on the timestamp, to make
  it hypothetically clear in plain text what you really mean

- you forgot that user cannot see your intention from 
  [2024-02-04 12:00 @-08, America/Vancouver]
  in case where you say "UTC offset is fixed"

- what if I as user think that is 12 o'clock in America/Vancouver
  time? 

- and you think as programmer "This is UTC fixed offset", but where is
  designation in that text that it is so?

- I provided examples how to designate it:

  1. [2024-02-04 12:00 @-08!, America/Vancouver] -- means your
     imaginary UTC fixed one (I hope you will understand and drop it),
     this is same as 20 o'clock UTC time, why do you show
     America/Vancouver? Show UTC only.

  2. [2024-02-04 12:00! @-08, America/Vancouver] -- means 12 o'clock
     at America/Vancouver time, no matter the offset. Original offset
     was -08, but new offset in future could be something else and
     must be derived from America/Vancouver time zone.

  3. [2024-02-04 12:00 @-08, America/Vancouver/UTC-FIXED] is same as
     example number 1, just with different tag. 

  4. Do not do that in 1 or 3, that is not what software does. It is
     new type you are trying to implement because you think with best
     intentions, but to me is obvious that you have to research it
     more.

> >> 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 not aligned with what international community is doing.
> >
> > Provide UTC time.
> >
> > Or provide time zone plus UTC offset.
> >
> > Your idea as such is alright, but is individual, and it has to be
> > coordinated with what other programs are doing. Otherwise it become
> > confusing.
> >
> > Remember the reference on iCalendar, "not do do that". 
> >
> > iCalendar provides either UTC time, or date, time and time zone.
> 
> iCalendar is not the only source of truth. The suggested offsets are
> what ISO8601 defines. 

Just that you did not use ISO 8601 principles. You mixed something up.

Where does ISO 8601 advises using date, time, with time zone being UTC
by using UTC offset other but zero? 

Show me one example. I have shown you on Wikipedia example of ISO 8601
timestamp by using UTC time. There is no offset.

Timestamp stored in computers is mostly stored in UTC time. 

Then UTC offset is shown only to user looking at it in local time or
different time zones.

Read here:
https://en.wikipedia.org/wiki/ISO_8601#Coordinated_Universal_Time_(UTC)

,----
| If the time is in UTC, add a Z directly after the time without a
| space. Z is the zone designator for the zero UTC offset. "09:30 UTC"
| is therefore represented as "09:30Z" or "T0930Z". "14:45:15 UTC" would
| be "14:45:15Z" or "T144515Z".
`----

Thus when representing UTC time, do not use UTC offset. That will
confuse people and is what I am talking about "the new Org time type
representation".

Read here:
https://en.wikipedia.org/wiki/ISO_8601#Time_offsets_from_UTC

,----
| The UTC offset is appended to the time in the same way that 'Z' was
| above, in the form ±[hh]:[mm], ±[hh][mm], or ±[hh].
| 
| Negative UTC offsets describe a time zone west of UTC±00:00, where the
| civil time is behind (or earlier) than UTC so the zone designator will
| look like "−03:00","−0300", or "−03".
`----

It EITHER -- OR condition. It is either UTC time, OR time with UTC
offset, because UTC time could only be represented with zero
offset. For that reason I believe "Z" is used for UTC time.

Then read examples of UTC offsets:

,----
| The following times all refer to the same moment: "18:30Z",
| "22:30+04", "1130−0700", and "15:00−03:30". Nautical time zone letters
| are not used with the exception of Z. To calculate UTC time one has to
| subtract the offset from the local time, e.g. for "15:00−03:30" do
| 15:00 − (−03:30) to get 18:30 UTC. 
`----

You mentioned ISO 8601, and I also wish to put your attention on it,
so we agree both that the time representation should be aligned with
what is commonly used in ISO 8601. Right?

Only that I do not agree that you are interpreting it right, for
reason that you use date, time, UTC negativ/positive offset at UTC
time zone.

UTC offset at UTC time zone is zero. Nothing else, never.

> iCalendar explicitly disregards the fixed offsets for some
> iCalendar-specific reasons. It is iCalendar that is not being
> aligned with more common standard.

It is.

Your interpretation is not.

> >> > 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.
> >
> > That problem is solved, if you use TZ database:
> >
> > - in case of change of time zone, the TZ database will provide future
> >   adjustment, there may be new name of new time zone. 
> >
> > - in case of change of UTC offset, the TZ database in future will know
> >   it. 
> 
> Your statement is true only when TZ database is guaranteed to be
> up-to-date. It is not always the case. Consider opening an Org document
> on machine with out-of-date TZ database.

Of course.

And you are not making it compatible to outdated TZ databases!

You are making it compatible to present and future TZ databases!

In general, you can also leave org with floating timestamps, as very
few people will get affected, if at all.

Most of professiona people cannot use Org for meeting and
appointments, and collaborative time management!

Org is single user application.

What we are talking here about is trivial when MySQL or MariaDB or
PostgreSQL is used. 

Majority of ERP software runs on such databases, they use functions
that matter.

Org is not for that, and will never be without some serious and
striking integration efforts.

It means, do not strive for absolute accuracy.

Strive for simplicity.

> > I will never miss the meeting provided program consults TZ database.
> 
> You will not. But I can see myself missing the meeting and assuming the
> time "as usual".

Of course everything in our life is conditional.

Maybe the planet will stop moving, it must stop and disintegrate at
one point of time in future.

We speak of reality that is in present time, TZ database is being
updated, and is our current reality.

Time Zone Database:
https://www.iana.org/time-zones

I also do not consider it "authoritative" as it is in hands of United
States.

In case of international war, they can corrupt it, and corrupt other
countries time.

It is not something "universally" accessible, it relies on consensus,
and is not under our people' control. It has to be updated with
political statuses.

Too many conditions! It is constantly updated work and effort.

> > But if I have 2 timestamps, that is different situation.
> >
> > You need no UTC offset for future time representation.
> >
> > Also good to read:
> > https://engineering.q42.nl/why-always-use-utc-is-bad-advice/
> >
> > Also good to read:
> > https://swizec.com/blog/saving-time-in-utc-doesnt-work-and-offsets-arent-enough/
> 
> The second link illustrates exactly UTC offset + also time zone name.
> Similar to what I proposed.

Remember, you started by showing UTC offset with UTC time zone, and
only for that specific case I told you that is not how it works and
how time should be represented.

I think you are referring to following, do you?
-----------------------------------------------

From:
https://swizec.com/blog/saving-time-in-utc-doesnt-work-and-offsets-arent-enough/

,----
| "You have an appointment today at 3pm" is tricky. Your server runs in
| UTC (usually), the user is who knows where. Their 3pm is not your
| server's 3pm 💩
| 
| One solution is to save time with a UTC offset.
| 
| Like this:
| 
| 2022-03-09T15:00:00-08:00
| 
| Instead of Z for zulu time, we have an offset that says this time is 8 hours behind UTC. At 3pm.
| 
| Now your server understands the user's intention of 3pm and the exact
| point in time for UTC. Fantastic.
`----

That is his idea! But that idea is incorrect, I am sorry as I did not
refer to that idea, but other parts on article.

That guy never implemented that idea for reason that it simply does
not work!

There is no such type of time types in the PostgreSQL or MySQL
database.

You can only get the representation by program.

Example:

#+BEGIN_SRC sql :engine postgresql :exports results :host localhost :cmdline :database admin
CREATE TABLE example (time TIMESTAMP WITH TIME ZONE);
#+END_SRC

#+RESULTS:
| CREATE TABLE |
|--------------|

#+BEGIN_SRC sql :engine postgresql :exports results :host localhost :cmdline :database admin
INSERT INTO example (time) VALUES ('2023-02-12 12:00-03:00');
#+END_SRC

#+RESULTS:
| INSERT 0 1 |
|------------|

#+BEGIN_SRC sql :engine postgresql :exports results :host localhost :cmdline :database admin
SELECT * FROM example ORDER BY time DESC;
#+END_SRC

#+RESULTS:
| time                   |
|------------------------|
| 2023-02-12 18:00:00+03 |
| 2023-02-12 18:00:00+03 |

Or we try without time zone?

#+BEGIN_SRC sql :engine postgresql :exports results :host localhost :cmdline :database admin
CREATE TABLE example_without (time TIMESTAMP WITHOUT TIME ZONE);
#+END_SRC

#+RESULTS:
| CREATE TABLE |
|--------------|


#+BEGIN_SRC sql :engine postgresql :exports results :host localhost :cmdline :database admin
INSERT INTO example_without (time) VALUES ('2023-02-12 12:00-03:00');
#+END_SRC

#+RESULTS:
| INSERT 0 1 |
|------------|

#+BEGIN_SRC sql :engine postgresql :exports results :host localhost :cmdline :database admin
SELECT * FROM example_without ORDER BY time DESC;
#+END_SRC

#+RESULTS:
| time                |
|---------------------|
| 2023-02-12 12:00:00 |

As you can see, you and that guy, you got similar idea, but that does
not exist in software.

What can be done is to record time with offset as text.

Or it can be recorded as date, time without time zone, without offset, but with offset being separate.

However, I repeat, that is totally out of what other software and other programmers do.


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

[-- Attachment #1: Type: text/plain, Size: 790 bytes --]

On Sun, Feb 12, 2023 at 12:33:40PM +0300, Jean Louis wrote:
> * Ihor Radchenko <yantar92@posteo.net> [2023-02-10 13:48]:
> > Jean Louis <bugs@gnu.support> writes:
> > 
> > > If you start adding in Org "fixed" time with UTC offset, that is a new
> > > type of timestamp, as it is not common in world.
> > 
> > It is how ISO8601 defines offsets.
> 
> - did you say you wish to represent time with UTC time zone by using
>   UTC offset?
> 
> - and I said, UTC time is always without offset, and if any is
>   represented then it must be +00
> 
> - and now you say that ISO8601 defines offsets... sorry, you are
>   confusing me and readers.

It is not about "the offset OF UTC". It is about "the offset
RELATIVE TO UTC".

Sorry for raising my voice :-)

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Jean Louis]

* tomas@tuxteam.de <tomas@tuxteam.de> [2023-02-12 16:50]:
> On Sun, Feb 12, 2023 at 12:33:40PM +0300, Jean Louis wrote:
> > * Ihor Radchenko <yantar92@posteo.net> [2023-02-10 13:48]:
> > > Jean Louis <bugs@gnu.support> writes:
> > > 
> > > > If you start adding in Org "fixed" time with UTC offset, that is a new
> > > > type of timestamp, as it is not common in world.
> > > 
> > > It is how ISO8601 defines offsets.
> > 
> > - did you say you wish to represent time with UTC time zone by using
> >   UTC offset?
> > 
> > - and I said, UTC time is always without offset, and if any is
> >   represented then it must be +00
> > 
> > - and now you say that ISO8601 defines offsets... sorry, you are
> >   confusing me and readers.
> 
> It is not about "the offset OF UTC". It is about "the offset
> RELATIVE TO UTC".

Yes, surely is clear to me personally. 

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)

[Heinz Tuechler]

Jean Louis wrote/hat geschrieben on/am 14.02.2023 07:00:
> * tomas@tuxteam.de <tomas@tuxteam.de> [2023-02-12 16:50]:
>> On Sun, Feb 12, 2023 at 12:33:40PM +0300, Jean Louis wrote:
>>> * Ihor Radchenko <yantar92@posteo.net> [2023-02-10 13:48]:
>>>> Jean Louis <bugs@gnu.support> writes:
>>>>
>>>>> If you start adding in Org "fixed" time with UTC offset, that is a new
>>>>> type of timestamp, as it is not common in world.
>>>>
>>>> It is how ISO8601 defines offsets.
>>>
>>> - did you say you wish to represent time with UTC time zone by using
>>>   UTC offset?
>>>
>>> - and I said, UTC time is always without offset, and if any is
>>>   represented then it must be +00
>>>
>>> - and now you say that ISO8601 defines offsets... sorry, you are
>>>   confusing me and readers.
>>
>> It is not about "the offset OF UTC". It is about "the offset
>> RELATIVE TO UTC".
>
> Yes, surely is clear to me personally.

If 2022-11-12 12:00+02 # 12:00 UTC+2 should mean that local time is
2022-11-12 12:00 and that it is 2 hours _ahead_ of UTC, then it seems
intuitively clear to me. I would assume that holds for many others as well.

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

[tomas]

[-- Attachment #1: Type: text/plain, Size: 513 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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, tomas@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)

[Jean Louis]

* Max Nikulin <manikulin@gmail.com> [2023-02-14 14:45]:
> On 14/02/2023 16:45, tomas@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)

[Thomas S. Dye]

Jean Louis <bugs@gnu.support> writes:

> * Max Nikulin <manikulin@gmail.com> [2023-02-14 14:45]:
>> On 14/02/2023 16:45, tomas@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]

* Thomas S. Dye <tsd@tsdye.online> [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)

[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)

[Jean Louis]

* Heinz Tuechler <tuechler@gmx.at> [2023-02-14 12:44]:
> Jean Louis wrote/hat geschrieben on/am 14.02.2023 07:00:
> > * tomas@tuxteam.de <tomas@tuxteam.de> [2023-02-12 16:50]:
> > > On Sun, Feb 12, 2023 at 12:33:40PM +0300, Jean Louis wrote:
> > > > * Ihor Radchenko <yantar92@posteo.net> [2023-02-10 13:48]:
> > > > > Jean Louis <bugs@gnu.support> writes:
> > > > > 
> > > > > > If you start adding in Org "fixed" time with UTC offset, that is a new
> > > > > > type of timestamp, as it is not common in world.
> > > > > 
> > > > > It is how ISO8601 defines offsets.
> > > > 
> > > > - did you say you wish to represent time with UTC time zone by using
> > > >   UTC offset?
> > > > 
> > > > - and I said, UTC time is always without offset, and if any is
> > > >   represented then it must be +00
> > > > 
> > > > - and now you say that ISO8601 defines offsets... sorry, you are
> > > >   confusing me and readers.
> > > 
> > > It is not about "the offset OF UTC". It is about "the offset
> > > RELATIVE TO UTC".
> > 
> > Yes, surely is clear to me personally.
> 
> If 2022-11-12 12:00+02 # 12:00 UTC+2 should mean that local time is
> 2022-11-12 12:00 and that it is 2 hours _ahead_ of UTC, then it seems
> intuitively clear to me. I would assume that holds for many others
> as well.

Exactly that. Never said anything different.

Discussion started from something like this:

2022-11-12 12:00+02 @UTC

and that is different case, where Ihor was suggesting that: 2022-11-12
12:00 is UTC time, not local time, where by +02 is offset (I say not
UTC offset) to be added or deducted on that time.

> > That we got for sure.
> > 
> > Then just representation must be clear: @UTC is unclear in those
> > cases, but @RELTOUTC would be clear.
> > 
> 
> @RELTOUTC seems unfortunate, as it states only the obvious. If at all,
> it should be @AHEADUTC or @BEHINDUTC or some abbreviation of it, but as
> said above, it seems not necessary to me.

As idea I understand Ihor and other person on Internet.

But as implementation by using @UTC or by using date time
representation as UTC time with offset (not UTC offset), I think it
will be confusing for people, unless there is new tag invented to make
sure of it.

Any idea is fine:

2022-11-12 12:00+02 @UTC-SUM
2022-11-12 12:00+02 @UTC-TO
2022-11-12 12:00+02 @TO-UTC

but not

2022-11-12 12:00+02 @UTC

As that would be confusing.

-- 
Jean

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

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

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 <bugs@gnu.support> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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 <bugs@gnu.support> 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
└────

The first timestamp is an error when time zone rules change.
In the two other timestamps, the complementary time zone is a redundant
information that does not affect how the timestamp is interpreted and
simply aids the human eye. Optionally, users could enable extra checking
with Org warning about inconsistency for the two latter kinds of
timestamps as well.

> It is not good specifying something in Org program and not clearly
> giving it to user what is authoritative.

Sure. The first kind of timestamp is to be left to users to enter
manually, when they need to. Automatic timestamps are of the other two
kinds.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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 <yantar92@posteo.net> [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 12:00 @!+07,Asia/Singapore] # use +07 over Asia/Singapore
> └────

In the above examples there is really nothing to be "warned". When you
give wrong examples for other context, it means you did not understand
it.

You are showing time in past. For time in past, UTC offset is property
of time zone, it is very good to show it, though computer program
could derive it from time zone database, but there is nothing expected
to change in future for such timestamps from past. There is nothing to
be warned, and the time zone MUST match the UTC offset.

Wrong example for the mentioned use case.

We spoke of time designation in future. Not time in past.

Here are comments on time in future:

 ┌────
 │ [2032-11-12 12:00 @+07,Asia/Singapore]  # warn when mismatch

Mismatch what? UTC prefix can become +08 in Asia/Singapore zone,
intended time of meeting is 12 o'clock, there is nothing to warn. For
people in that time zone it will be, in case of UTC offset change,
always same 12 o'clock.

If you wish to use some UTC time, as fixed point of time in future,
then use UTC time, do not use time zones.

There is no need to use UTC offset from today in time designation in
future. 

And it is not "timestamp" by main definition, as "timestamp" is used
wrongly in Org for future, while timestamp in computing is used for
log files, for past, and is much more definite than how we use it in
present time. 

Author of Org was in his own world, without inspecting all these
issues related to time, found somewhere the word "timestamp" and
started using it for planning.

See: 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."

"Occurred" does not mean "to occure in future".
 
 │ [2032-11-12 12:00 @+07,!Asia/Singapore] # use Asia/Singapore over +07

If you wish to specify time with offset from UTC time, then do not use
time zones. However, that is not common notation.

If you use time zones, computer always need to verify that new, in new
time in future UTC offset, as it could change from the time of writing
it to the time of viewing it.

 │ [2032-11-12 12:00 @!+07,Asia/Singapore] # use +07 over Asia/Singapore
 └────

If you are to use +07 as offset in future, do not use time zone, as
that is confusing, not common, capricious, and only you claim it is
"convenient". It is hypothetical talk of no use.

> The first timestamp is an error when time zone rules change.

It is not, for reason that your timestamp examples were not relevant
to discussion, as they are from past. Timestamps are in general always
past. 

Remove wrong use of the word "timestamp" from Org manual.

Timestamps as you have shown them here below would be perfectly valid,
would you use the proper UTC offset for Asia/Singapore time zone, but
you have not, you used wrong UTC offset of +07 while Asia/Singapore is
+08 time zone.

> ┌────
> │ [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
> └────

Correct timestamps would be:

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

And for those timestamps, there is no warning when mismatch, because
in future, you cannot change the UTC offset for past (rarely). We
already know that +08 was UTC offset for 2022-11-12 and there is
nothing in future to be warned about it, even if UTC offset for
Asia/Singapore would change to +05, that is not relevant, as in the
past UTC offset was +08 and there is nothing to warn about.

And for following:

> │ [2022-11-12 12:00 @+08,!Asia/Singapore] # use Asia/Singapore over +08

It is contradictory that one places "timestamp" which one would change
in future depending of future time zone! That makes no sense, that is
not timestamp anymore. Do your homework.

If the UTC time was 04:00 because UTC offset was +08, then if user
views the above perverted version of a "timestamp" with changed UTC
offset e.g. +09, which could be designated in future in the new
definition of the time zone, then if you use notion "use
Asia/Singapore over +08", that would imply that timestamp in past
changes. It would not be any more 04:00 UTC time, but it would be
03:00 UTC.

And changing past timestamps is contradictory to the reason of using
timestamps. 

And for following:

> │ [2022-11-12 12:00 @!+08,Asia/Singapore] # use +08 over Asia/Singapore
> └────

If UTC offset is there, then it is confusing to use "time zone", if
you wish to designate UTC offset, do not use time zone. But using UTC
offset is contradictory to conventions, so best is to use UTC time
without any UTC offset.

But for future time, if you wish to provide some time that differs
from UTC time, then I would say most logical would be to use again UTC
time, plus added markup to designate interval that has to be added or
deducted from that UTC time. But not in the form of "UTC offset" as
UTC time does not have UTC offset by conventions.

I am referring to something like this:

[2022-11-12 04:00 @Z] + '8 hours'

> In the two other timestamps, the complementary time zone is a redundant
> information that does not affect how the timestamp is interpreted and
> simply aids the human eye. Optionally, users could enable extra checking
> with Org warning about inconsistency for the two latter kinds of
> timestamps as well.

I wish you good luck.

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

[Jean Louis]

* Max Nikulin <manikulin@gmail.com> [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 time zone. There is settings.

And then if you write that event is on Sunday 20 o'clock, it will be
considered 20 o'clock at that time zone.

When you send it, it will be maybe converted to UTC time, but maybe
not, maybe with time zone designation.

In any case remote user will either get UTC time or date, time with
time zone.

Getting time representation with offset, to calculate UTC time seem
redundant.

But why not, it is possible.

Will you do it, practically implement it?

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

That is why is better not to use TZ time zone abbreviation for future times!

For past times, is somehow okay. For future no.

Let me consult the database.

#+BEGIN_SRC sql :engine postgresql :exports results :host localhost :cmdline :database rcdbusiness :dbuser maddox
SELECT name, abbrev,  utc_offset, is_dst
FROM pg_timezone_names where abbrev = '-08';
#+END_SRC

#+RESULTS:
| name                   | abbrev | utc_offset | is_dst |
|------------------------+--------+------------+--------|
| Etc/GMT+8              |    -08 |  -08:00:00 | f      |
| Pacific/Pitcairn       |    -08 |  -08:00:00 | f      |
| posix/Etc/GMT+8        |    -08 |  -08:00:00 | f      |
| posix/Pacific/Pitcairn |    -08 |  -08:00:00 | f      |

In your example, you should not use time zone abbreviations to say
that it is UTC time with offset.

Better use accurate offset (which is not UTC offset, as that is changeable).

This is better if you really wish to designate the time with offset
which represents UTC time:

2030-02-09 12:00 -08:00

Because you are rounding for no good reason! You have introduced new
type of time storage, which is time with offset representing UTC time. 

While UTC offsets are mostly rounded, you are introducing not the UTC
offset, but "offset".

That means that following is also just fine:

2030-02-09 11:47 -08:12

Which is not common. But you insist on using time with offset, that
represents UTC time, however, then you should not be using "UTC
offsets" for such representations, but leave to users what "offset" to
add or deduce, for UTC calculation.

I am against such storage, and representation, but either:

- as UTC time, without offset

- or as date, time, time zone, as UTC offset can be calculated in future time points

But we can see that Org is different case, it is textual, not database. 

However, this time: <2023-02-12 13:29> was always considered floating,
and then by changing anything it can become [2023-02-13 Mon 13:29],
the day is "added" automatically.

So one needs some "tag" for time represented as UTC time but with
offset, like [2023-02-13 13:29 @TO-UTC -08:00]

it cannot be "@UTC" 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/

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 <bugs@gnu.support> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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 <yantar92@posteo.net> [2023-02-15 18:17]:
> Jean Louis <bugs@gnu.support> 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)

[Ihor Radchenko]

Jean Louis <bugs@gnu.support> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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:
> |
> |  19980119T230000-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)

[Ypo]

[-- Attachment #1: Type: text/plain, Size: 10816 bytes --]

Could it be reasonable to collect the hypothetical cases where relative 
timestamps would be used?
So, alternatives and solutions could be evaluated more easily.
For example:


| External Input                                          | User's 
input                     | Org output                             | 
Agenda output (local time) | Org time storing     |

|---------------------------------------------------------+----------------------------------+----------------------------------------+----------------------------+----------------------|
| Meeting at 09:37:54, 28 February 2023, in Foz do Iguaçu | [2023-02-28 
ma. 09:37 @UTC-3]    | [2023-02-28 ma. 09:37 @UTC-3]          | 
[2023-02-28 ma. 13:37]     | 20230228T12:37:54,68 |
| Same case as above                                      | [2023-02-28 
ma. 09:37 @timezone] | [2023-02-28 ma. 09:37 @UTC-3,timezone] | 
[2023-02-28 ma. 13:37]     | 20230228T12:37:54,68 |
| Party at my home, tomorrow                              | [2023-02-13 
lu. 14:15]           | [2023-02-13 lu. 14:15 @UTC+1,timezone] | 
[2023-02-13 lu. 14:15]     | 20230213T13:15:54,68 |


- I didn't expect this: it is more difficult for me to find the 
timezone, and to write it in the correct format, than to find the UTC 
offset.

- Maybe org output should always show the time zone, since for calculations

- Should convert show every timestamp timezone, so we know local 
timezone is correct?

- Sorry for the table format, I don't know how to export it from orgmode 
to thunderbird's mail editor.




> ------------------------------------------------------------------------
> * Max Nikulin<manikulin@gmail.com>  [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 time zone. There is settings.
>
> And then if you write that event is on Sunday 20 o'clock, it will be
> considered 20 o'clock at that time zone.
>
> When you send it, it will be maybe converted to UTC time, but maybe
> not, maybe with time zone designation.
>
> In any case remote user will either get UTC time or date, time with
> time zone.
>
> Getting time representation with offset, to calculate UTC time seem
> redundant.
>
> But why not, it is possible.
>
> Will you do it, practically implement it?
>
> >/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./
>
> That is why is better not to use TZ time zone abbreviation for future times!
>
> For past times, is somehow okay. For future no.
>
> Let me consult the database.
>
> #+BEGIN_SRC sql :engine postgresql :exports results :host localhost :cmdline
> :database rcdbusiness :dbuser maddox
> SELECT name, abbrev,  utc_offset, is_dst
> FROM pg_timezone_names where abbrev = '-08';
> #+END_SRC
>
> #+RESULTS:
> | name                   | abbrev | utc_offset | is_dst |
> |------------------------+--------+------------+--------|
> | Etc/GMT+8              |    -08 |  -08:00:00 | f      |
> | Pacific/Pitcairn       |    -08 |  -08:00:00 | f      |
> | posix/Etc/GMT+8        |    -08 |  -08:00:00 | f      |
> | posix/Pacific/Pitcairn |    -08 |  -08:00:00 | f      |
>
> In your example, you should not use time zone abbreviations to say
> that it is UTC time with offset.
>
> Better use accurate offset (which is not UTC offset, as that is changeable).
>
> This is better if you really wish to designate the time with offset
> which represents UTC time:
>
> 2030-02-09 12:00 -08:00
>
> Because you are rounding for no good reason! You have introduced new
> type of time storage, which is time with offset representing UTC time.
>
> While UTC offsets are mostly rounded, you are introducing not the UTC
> offset, but "offset".
>
> That means that following is also just fine:
>
> 2030-02-09 11:47 -08:12
>
> Which is not common. But you insist on using time with offset, that
> represents UTC time, however, then you should not be using "UTC
> offsets" for such representations, but leave to users what "offset" to
> add or deduce, for UTC calculation.
>
> I am against such storage, and representation, but either:
>
> - as UTC time, without offset
>
> - or as date, time, time zone, as UTC offset can be calculated in future time
> points
>
> But we can see that Org is different case, it is textual, not database.
>
> However, this time: <2023-02-12 13:29> was always considered floating,
> and then by changing anything it can become [2023-02-13 Mon 13:29],
> the day is "added" automatically.
>
> So one needs some "tag" for time represented as UTC time but with
> offset, like [2023-02-13 13:29 @TO-UTC -08:00]
>
> it cannot be "@UTC" 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)
>

[-- Attachment #2: Type: text/html, Size: 12451 bytes --]

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

[ypuntot]

[-- Attachment #1: Type: text/plain, Size: 738 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 1458 bytes --]

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 <ypuntot@gmail.com> [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)

[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)

[Jean Louis]

* Max Nikulin <manikulin@gmail.com> [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: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Daryl Manning]

[-- Attachment #1: Type: text/plain, Size: 3056 bytes --]

I'd argue that setting a specific datestamp  and time for DST would mean
that you expected to meet at that specific time and date as per DST. If the
clocks changed you'd be out of luck (that's where I'd argue you'd use a
non-specified timezone for a meeting that re-occurs at 10:05 regardless of
say PDT or PST).

But if this was an issue with a recurring meeting, then when the clocks
changed someone would be out an hour because they had specifically booked
with DST in mind (note: this is more useful than you think - being in
non-DST countries and having scheduled meetings in DST based countries, a
lot of cal applications get this wrong when what I actually want is for
that DST scheduled meeting to now be reflected in my calendar on the fact
they've switched to ST in their time zone - so shifted an hour.).

But I feel this is something that would be for people who need to take
advantage of this. And, more often than not, is a recurring meeting issue
when DST/ST changes occur.

Daryl.


On Tue, Jan 17, 2023 at 3:54 AM Robert Horn <rjhorn@panix.com> wrote:

>
> Ihor Radchenko <yantar92@posteo.net> writes:
>
> > Robert Horn <rjhorn@panix.com> writes:
> >
> >>> 1. Time (YYYY-MM-DD HH:MM) not continuous and may change arbitrarily at
> >>>    certain times a year or in future or in the past:
> >>>    - DST transitions are not stable and change from year to year
> >>>      according to strange rules that may involve Julian dates or
> >>>      counting weekdays
> >>>    - DST transition rules may change over time
> >>>    - The new year day itself is not necessarily fixed (England
> >>>    - Julian/Gregorian transitions happened at different times in
> >>>      different countries
> >>
> >> Note that as a result "time when it happened" has different rules than
> >> "future time when it is scheduled".  There are lots of other times that
> are
> >> scheduled as "future local time, subject to changing DST rules".  This
> >> is particularly tricky for repeating times for regularly scheduled
> events.
> >
> > Not really. Countries may change DST at any moment in future. Or decide
> > to switch calendars (consider countries near the day transition line).
> >
> > And "past local time, according to the DST rules in effect at the time"
> > is also an option that might be useful in certain scenarios.
> >
>
> The issue is clarity of the expected rules for the format.  If I
> schedule a meeting for 10:05 DST, but the rules change so that it is not
> DST at that location at that time in the future, what is the expected
> interpretation?  It could be:
>
>  a) the meeting should be at 10:05 ST, because the intent was to meet at
>  10AM in the then local time.
>
>  b) the meeting should be at 11:05 ST, because the time was chosen to
>  correspond to a particular sun angle.
>
> Getting the rules and explanation clear is the issue.  It's a mistake
> that a great many people make with scheduling meetings.  Those two
> behaviors need different encodings because they behave differently.
>
> --
> Robert Horn
> rjhorn@alum.mit.edu
>

[-- Attachment #2: Type: text/html, Size: 3996 bytes --]

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Tim Cross]

Daryl Manning <daryl@wakatara.com> writes:

> I'd argue that setting a specific datestamp  and time for DST would mean that you expected to meet at that
> specific time and date as per DST. If the clocks changed you'd be out of luck (that's where I'd argue you'd
> use a non-specified timezone for a meeting that re-occurs at 10:05 regardless of say PDT or PST).
>
> But if this was an issue with a recurring meeting, then when the clocks changed someone would be out an
> hour because they had specifically booked with DST in mind (note: this is more useful than you think -
> being in non-DST countries and having scheduled meetings in DST based countries, a lot of cal applications
> get this wrong when what I actually want is for that DST scheduled meeting to now be reflected in my
> calendar on the fact they've switched to ST in their time zone - so shifted an hour.). 
>
> But I feel this is something that would be for people who need to take advantage of this. And, more often
> than not, is a recurring meeting issue when DST/ST changes occur. 
>

Yes, this is one of the areas where there are some subtle issues to work
through. With regards to just meetings, I see 3 common scenarios

1. Meeting wiht all participants in the same time zone. The time (lets
say 3pm) should not change when daylight savings comes in or goes
out. The meeting is always at 3pm even though that 3pm might be
different when considered against UTC time.

2. A meeting where some participants are in different time zones to the
org user. Here it isn't clear exactly what should happen when there is a
daylight savings transition in the org user's time zone. Should the org
user's meeting time change or should the participants in the other time
zones update their time for the meeting. On one hand, it makes sense
that the local org user change the meeting time for themselves either
forward/back an hour because it is their time zone which has
changed. However, if the meting has a majority of participants in the
same time zone as the org user, perhaps those in the other time zones
should adjust. Point is, it isn't obvious and there isn't a 'right
solution'. Both needs to be supported and probably need to have some way
to indicate which is the preferred behaviour. 

3. An org user who travels and is often in a different time zone from
their 'home' time zone. IN this scenario, they probably want their
meeting times to be adjusted to the local time zone they are in (unless
they are already recorded in that time zone). Note that this was a
specific example form a previous feature request for time zone support
in org time stamps.

This is just wiht respect to timestamps used for meetings. There are
other scenarios with other subtle issues. For example, someone already
mentioned a scenario where org is being used to record details about
experiments. In this situation, the amount of 'real' time passed between
two timestamps is possibly the most important factor. The fact daylight
savings time transitions have occured are likely irrelevant - just
important any calculations relating to duration are accurate and not
thrown out by one hour due to the wall clock moving forward/abck an
hour.

So far, it seems clear that the solution needs to be flexible and
support timestamps without time zone information, with fully qualified
time zone specification, with time zone abbreviated names and with time
zone offsets.

It also seems that the solution will need some mechanism (possibly on a
per time stamp basis) for the user to specify what should happen when
either the time zone has a daylight savings transition, when the
timezone rules change or when the user's 'default' time zone changes
because they have changed locations. 

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Ihor Radchenko]

Tim Cross <theophilusx@gmail.com> writes:

> It also seems that the solution will need some mechanism (possibly on a
> per time stamp basis) for the user to specify what should happen when
> either the time zone has a daylight savings transition, when the
> timezone rules change or when the user's 'default' time zone changes
> because they have changed locations. 

Could you please elaborate here?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Tim Cross]

Ihor Radchenko <yantar92@posteo.net> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>
>> It also seems that the solution will need some mechanism (possibly on a
>> per time stamp basis) for the user to specify what should happen when
>> either the time zone has a daylight savings transition, when the
>> timezone rules change or when the user's 'default' time zone changes
>> because they have changed locations. 
>
> Could you please elaborate here?

I have some meetings scheduled in my org files which show up in the
agenda.

Meeting 1 is a reoccurring meeting which happens every 2 weeks. All of
the people in that meting are in the same timezone as I'm in. When we
transition into/out of daylight savings time, I don't want the timestamp
to change. THe meeting will remain at 3pm.

Meeting 2. This is also a reoccuring meeting. However, this meeting is
with people from a number of idfferent time zones. When my timezone
moves into or out of daylight savings time, I need the meeting time to
be updated - moved forward/back 1 hour.

Next week, I'm travelling to a different city for work and will be in a
different timezone. I need all my meetings to be adjusted except for
those I've already booked that are in the timezone I willl be in while
I'm away.

Finally, I have a few timestamps I use to track some projects and
progress on various tasks as well as reports showing actual and
estimated effort comparisons as well as managing billing/invoicing. The
actual timestamp times are less important than the calculation of
durations etc. When durations do cross daylight savings transition
points, it is critical that additonal hours are not accidentally
added/removed from the duration calculation. Mistakes here could result
in me loosing revenue or over charging clients.

So, for the first 2 I probably need to somehow flag/indicate that I do
or do not want the time adjusted as a result of a daylight savings
transition. For the 3rd group, I only want adjustments for timestamps
which are not in the 'current' (where I've travelled to) time zone. The
final one is really just about ensuring the transitions don't throw out
duration calculations accidentally.

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Ihor Radchenko]

Tim Cross <theophilusx@gmail.com> writes:

>> Could you please elaborate here?
>
> I have some meetings scheduled in my org files which show up in the
> agenda.
>
> Meeting 1 is a reoccurring meeting which happens every 2 weeks. All of
> the people in that meting are in the same timezone as I'm in. When we
> transition into/out of daylight savings time, I don't want the timestamp
> to change. THe meeting will remain at 3pm.

Specifying the timezone should be good enough.
Not specifying will put you at a risk if you travel (you default OS
timezone will likely change).

> Meeting 2. This is also a reoccuring meeting. However, this meeting is
> with people from a number of idfferent time zones. When my timezone
> moves into or out of daylight savings time, I need the meeting time to
> be updated - moved forward/back 1 hour.

Again, you can just specify the right timezone and let Org translate it
to local one when calculating agenda.

> Next week, I'm travelling to a different city for work and will be in a
> different timezone. I need all my meetings to be adjusted except for
> those I've already booked that are in the timezone I willl be in while
> I'm away.

If you don't specify the timezone for both old and new meetings, there
will be no easy way to deal with this. What you may have to do is: (1)
indicate explicit timezone for the meetings in the new place (there will
probably be less of them compared to all other meetings); (2) tell Org
to use your old time zone as default - it will make the previously
scheduled meetings without timezone info use the right time zone.

> Finally, I have a few timestamps I use to track some projects and
> progress on various tasks as well as reports showing actual and
> estimated effort comparisons as well as managing billing/invoicing. The
> actual timestamp times are less important than the calculation of
> durations etc. When durations do cross daylight savings transition
> points, it is critical that additonal hours are not accidentally
> added/removed from the duration calculation. Mistakes here could result
> in me loosing revenue or over charging clients.

For the past timestamps, you can either: (1) make Org put UTC offsets
when recording clock data; (2) use the idea we discussed about multiple
default time zones where you can specify different time zones at
different periods of time (before after travel).

Does it sound good enough?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Tim Cross]

Ihor Radchenko <yantar92@posteo.net> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>
>>> Could you please elaborate here?
>>
>> I have some meetings scheduled in my org files which show up in the
>> agenda.
>>
>> Meeting 1 is a reoccurring meeting which happens every 2 weeks. All of
>> the people in that meting are in the same timezone as I'm in. When we
>> transition into/out of daylight savings time, I don't want the timestamp
>> to change. THe meeting will remain at 3pm.
>
> Specifying the timezone should be good enough.
> Not specifying will put you at a risk if you travel (you default OS
> timezone will likely change).
>
>> Meeting 2. This is also a reoccuring meeting. However, this meeting is
>> with people from a number of idfferent time zones. When my timezone
>> moves into or out of daylight savings time, I need the meeting time to
>> be updated - moved forward/back 1 hour.
>
> Again, you can just specify the right timezone and let Org translate it
> to local one when calculating agenda.
>
>> Next week, I'm travelling to a different city for work and will be in a
>> different timezone. I need all my meetings to be adjusted except for
>> those I've already booked that are in the timezone I willl be in while
>> I'm away.
>
> If you don't specify the timezone for both old and new meetings, there
> will be no easy way to deal with this. What you may have to do is: (1)
> indicate explicit timezone for the meetings in the new place (there will
> probably be less of them compared to all other meetings); (2) tell Org
> to use your old time zone as default - it will make the previously
> scheduled meetings without timezone info use the right time zone.
>
>> Finally, I have a few timestamps I use to track some projects and
>> progress on various tasks as well as reports showing actual and
>> estimated effort comparisons as well as managing billing/invoicing. The
>> actual timestamp times are less important than the calculation of
>> durations etc. When durations do cross daylight savings transition
>> points, it is critical that additonal hours are not accidentally
>> added/removed from the duration calculation. Mistakes here could result
>> in me loosing revenue or over charging clients.
>
> For the past timestamps, you can either: (1) make Org put UTC offsets
> when recording clock data; (2) use the idea we discussed about multiple
> default time zones where you can specify different time zones at
> different periods of time (before after travel).
>
> Does it sound good enough?

No, I'm afraid not. How does org distinguish between meeting 1 and
meeting 2? IN meeting one, when the timezone transitions in/out of
daylight savings, nothing needs to change, but in meeting 2, when this
occurs, the meeting needs to be re-sechduled so that it keeps the same
offset relative to UTC. Some mechanism is needed so that the user can
identify timestamps like those fo rmeeting 1 from those for meeting
2. My idea was to have meeting 1 type timestamps without TZ info and
meeting 2 require fully qualified TZ info. However, while this would
probably work, I don't like it because it isn't explicit and would be
prone to errors.

Note that the above is a real scenario - I have to deal with this type
of problem frequently. The other types can, in general, be handled
through judicious use of TZ settings.

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Ihor Radchenko]

Tim Cross <theophilusx@gmail.com> writes:

>> Does it sound good enough?
>
> No, I'm afraid not. How does org distinguish between meeting 1 and
> meeting 2? IN meeting one, when the timezone transitions in/out of
> daylight savings, nothing needs to change, but in meeting 2, when this
> occurs, the meeting needs to be re-sechduled so that it keeps the same
> offset relative to UTC.
> Some mechanism is needed so that the user can
> identify timestamps like those fo rmeeting 1 from those for meeting
> 2. My idea was to have meeting 1 type timestamps without TZ info and
> meeting 2 require fully qualified TZ info. However, while this would
> probably work, I don't like it because it isn't explicit and would be
> prone to errors.

I still don't understand.

In Org, you will have a default time zone that will be used to build the
agenda.

In meeting 1, you set the time zone to your local zone
In meeting 2, you set the time zone to the time zone where the meeting
is scheduled.

The, both the meetings will be first converted to the default time zone
and appear in your agenda adjusted as required.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Tim Cross]

Ihor Radchenko <yantar92@posteo.net> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>
>>> Does it sound good enough?
>>
>> No, I'm afraid not. How does org distinguish between meeting 1 and
>> meeting 2? IN meeting one, when the timezone transitions in/out of
>> daylight savings, nothing needs to change, but in meeting 2, when this
>> occurs, the meeting needs to be re-sechduled so that it keeps the same
>> offset relative to UTC.
>> Some mechanism is needed so that the user can
>> identify timestamps like those fo rmeeting 1 from those for meeting
>> 2. My idea was to have meeting 1 type timestamps without TZ info and
>> meeting 2 require fully qualified TZ info. However, while this would
>> probably work, I don't like it because it isn't explicit and would be
>> prone to errors.
>
> I still don't understand.
>
> In Org, you will have a default time zone that will be used to build the
> agenda.
>
> In meeting 1, you set the time zone to your local zone
> In meeting 2, you set the time zone to the time zone where the meeting
> is scheduled.
>
> The, both the meetings will be first converted to the default time zone
> and appear in your agenda adjusted as required.

The problem is with meeting 2 and the assumption there is a definitive
timezone for the meeting.

Consider this scenario. I have a meeting with two other people. We are
all in different timezone. What is the timezone of the meeting?

Thinking more about it, in this situation, you probably just need to set the meeting time to UTC
and that would work. However, we would want some easy way to set this
when creating the timestamp (and that could be all that is needed - a
good enhancement to the interface to make it easy to set the timezone)
and good control over how values are displayed in the agenda and org
files (i.e. I imagine you might want a default where they are all shown
in your local time, but similar to working with links, the ability to
display the 'raw' version for editing and other purposes).

As yuou mentioned in another thread, it is likely many of these
scenarios can be adequately managed with good TZ support. It will be
critical that we also have a good UI for setting/adding TZ
information. Then, as you pointed out elsewhere, we will just need good
documentation/tutorials as some of these workflows are not terribly
intuitive and people find this stuff confusing. 

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Jean Louis]

* Tim Cross <theophilusx@gmail.com> [2023-01-19 00:31]:
> The problem is with meeting 2 and the assumption there is a definitive
> timezone for the meeting.
> 
> Consider this scenario. I have a meeting with two other people. We are
> all in different timezone. What is the timezone of the meeting?

Org in this state can't handle such things.

A person in any timezone shall be able to see that time in his local
time zone if we speak of distant meetings, and in case of face to face
meetings, that person shall have computer aid to show him the meeting
time in any time zone that user is located, during travel and upon
arrival to face to face meeting. 

User is supposed to be assisted by computer. And not to assist to
computer, or to get troubles from computer.

- Time zone shall be more or less recognizable by city and country. 

- User addresses in the address book shall be part of every computer system

- It is natural and common sense to know addresses of people one wants
  to meet

- By using location of person one wants to meet, computer has got
  enough information for representation of the time zone

- By sharing appointment record to user in other time zone, that user
  would see it in his time zone, or by choice in original time zone of
  the meeting place

A record of time, shall have two attributes, the UTC time and the time
zone to be displayed. By using system time zone setting, Org file time
zone settings, heading time zone settings or time stamp time zone
setting, any export of Org shall contain (by user's option) the
desired representation of time stamps.

Function of sharing of meetings shall ask local user:

- is user in different time zone? 

And then by choice of the user's location, the time representation
shall be prepared in such way that both parties understand each other.

That is really not in the sphere of Org where there is not even a
decent address book available.

Just re-write the time by hand for your friend at other part of the
world, write the timestamp in his time zone and your time zone, and
problem solved.

It is supposed to be text. It is not God.

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

[Tim Cross]

Jean Louis <bugs@gnu.support> writes:

> * Tim Cross <theophilusx@gmail.com> [2023-01-19 00:31]:
>> The problem is with meeting 2 and the assumption there is a definitive
>> timezone for the meeting.
>> 
>> Consider this scenario. I have a meeting with two other people. We are
>> all in different timezone. What is the timezone of the meeting?
>
> Org in this state can't handle such things.
>
> A person in any timezone shall be able to see that time in his local
> time zone if we speak of distant meetings, and in case of face to face
> meetings, that person shall have computer aid to show him the meeting
> time in any time zone that user is located, during travel and upon
> arrival to face to face meeting. 
>
> User is supposed to be assisted by computer. And not to assist to
> computer, or to get troubles from computer.
>
> - Time zone shall be more or less recognizable by city and country. 
>
> - User addresses in the address book shall be part of every computer system
>
> - It is natural and common sense to know addresses of people one wants
>   to meet
>
> - By using location of person one wants to meet, computer has got
>   enough information for representation of the time zone
>
> - By sharing appointment record to user in other time zone, that user
>   would see it in his time zone, or by choice in original time zone of
>   the meeting place
>
> A record of time, shall have two attributes, the UTC time and the time
> zone to be displayed. By using system time zone setting, Org file time
> zone settings, heading time zone settings or time stamp time zone
> setting, any export of Org shall contain (by user's option) the
> desired representation of time stamps.
>
> Function of sharing of meetings shall ask local user:
>
> - is user in different time zone? 
>
> And then by choice of the user's location, the time representation
> shall be prepared in such way that both parties understand each other.
>
> That is really not in the sphere of Org where there is not even a
> decent address book available.
>
> Just re-write the time by hand for your friend at other part of the
> world, write the timestamp in his time zone and your time zone, and
> problem solved.
>
> It is supposed to be text. It is not God.

You completely misunderstood the specific issue being discussed. You
clearly have not been following this specific point being discussed and
your long reply just confuses matters rather than helps.

This issue is in dealing with the meeting time when the local timezone
changes due to daylight savings time and the fact you have two different
requirements

1. For meeting where all people are in the same timezone, a transition
in/out of daylight savings changes nothing. The meeting time stays the same

2. For meetings wiht people from different time zones, when daylight
savings transition occurs, the timestamp needs to be changed.  Nothing
needs to happen for the people in other time zones - it isn't their
problem and their meeting time is not affected.

Ihor['s suggested solution was to just use the TZ of the 'meeting', but
that is ambiguous. A meeting doesn't have a time zone and picking just
one of the recipients doens't help as now you just have the issues of
their daylight savings transitions etc.

The 'solution' is to record this meeting in UTC tz. However, to make
this 'workable' for most people, the interface for managing timestamps
needs to make this easy.

For example, I would probablyh want an interface where by default, my
timestamps have no TZ data, but if I call the command to add a timestamp
with the universal argument, it will add a default tz and allow me to
easily change it to a different one.

My default 'no tz data' choice is best for me because I don't travel
much and am rarely in different time zones. Therefore, tz data not
needed and the smaller and easier to read/edit timestamps are
preferred. If on the other hand I was someone who travelled a lot, then
I would want the default to be to add full time zone information to
timestamps (though, I would probably want an overlay or similar to
display the timestamps in a more concise format converted to current
tz).

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Jean Louis]

* Tim Cross <theophilusx@gmail.com> [2023-01-19 10:48]:
> You completely misunderstood the specific issue being discussed. You
> clearly have not been following this specific point being discussed and
> your long reply just confuses matters rather than helps.
> 
> This issue is in dealing with the meeting time when the local timezone
> changes due to daylight savings time and the fact you have two different
> requirements

I do not use Org for time stamps. I am using PostgreSQL. My time
stamps show correctly (hopefully) as I rely on the design of that
software. I may be very wrong. Though as user I want simple thing, to
record time, and that time has to be displayed in my time zone, and I
want to have functions which will provide for example accounting
statement in the time zone of the recipient in Washington, USA. As
simple as that.

There is no need for Org to deal with daylight savings, as UTC
underlying functions are expected to deal with it. Time zone database,
C library, I cannot know. But any error there shall go to system
maker. Developing such complexity on Org level is not necessary.

For Emacs it makes fun to have various calendars, but for
international time, that has to be handled by system libraries.

> 1. For meeting where all people are in the same timezone, a transition
> in/out of daylight savings changes nothing. The meeting time stays the same
> 
> 2. For meetings wiht people from different time zones, when daylight
> savings transition occurs, the timestamp needs to be changed.  Nothing
> needs to happen for the people in other time zones - it isn't their
> problem and their meeting time is not affected.

Sure, but that is not calculation for higher level like Org, it is for
lower level, like system library. Discussion shall be given to
developers of GNU C library to solve calculations with daylight
savings. If such functions do not exist, then they can be made.

> Ihor['s suggested solution was to just use the TZ of the 'meeting', but
> that is ambiguous. A meeting doesn't have a time zone and picking just
> one of the recipients doens't help as now you just have the issues of
> their daylight savings transitions etc.

☺️ A meeting can have time zone. My friend, that is exactly how we do
meetings, I have even given examples from my life on meeting
scheduling on this mailing list. 

We say "Greek time 9 o'clock AM" -- and we meet and talk to each
other. If there is any daylight saving, so? My computer will think
about it. Not me. I have alarm that counts down, I must rely on my
devices. 

See:

System time and hardware clock
https://www.suse.com/support/kb/doc/?id=000016358

> The Linux kernel maintains a system time. This time is initialized at boot time using the hardware clock(also known as real time clock, RTC, BIOS clock or CMOS clock). As the hardware clock does not provide information as to whether it is kept in UTC or in local time, this needs to be configured explicitly, in YaST -> System -> /etc/sysconfig Editor -> System -> Environment -> Clock -> HWCLOCK.

> Linux changing to and from DST

> Linux will change to and from DST when the HWCLOCK setting is set to `-u', i.e. when the hardware clock is set to UTC (which is closely related to GMT), regardless of whether Linux was running at the time DST is entered or left.

> When the HWCLOCK setting is set to `--localtime', Linux will not
> adjust the time, operating under the assumption that your system may
> be a dual boot system at that time and that the other OS takes care of
> the DST switch. If that was not the case, the DST change needs to be
> made manually.

As you can see it is up to system libraries and user settings how to
provide DST. 

Org need not touch that, only convert from time zone time to UTC, from
UTC to time zone time.

> The 'solution' is to record this meeting in UTC tz. However, to make
> this 'workable' for most people, the interface for managing timestamps
> needs to make this easy.

Then again you have to tell that it is "UTC", which means you are
already specifying some time zone. 

You could tell that Org always thinks of UTC, but that again means UTC
as mark, must be somewhere placed, all users must know that it is UTC,
and again there is need for users to display time in their time zone.

What do you achieve by that design? 

You will get confusion, as you are forcing majority of the world first
to understand what is UTC.

Computers don't do that, they ask you, where are you? Athens, Greece?
Thanks, here is your time.

They don't tell you "let us keep meeting time in UTC" confusing users.

Follow the decade long trend human usability trend and use time zones.

> For example, I would probablyh want an interface where by default,
> my timestamps have no TZ data, but if I call the command to add a
> timestamp with the universal argument, it will add a default tz and
> allow me to easily change it to a different one.

Time stamp does not need to have TZ data, and your function desire is
just fine and correct.

Org file need not have any property of TZ data. 

What needs property is only when:

- Org files is shared or exported so that people in other time zones
  use that

- When single heading as task is shared or some text with embedded
  time stamps

- When user like you change time zone and that change is detected by
  computer (Org)

Which implies that ALL Org exports ever were ambigously created on
export! As in HTML export for example:

Created: 2023-01-19 Thu 17:31 (without time zone) is very ambigous.

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

[Tim Cross]

Jean Louis <bugs@gnu.support> writes:

> * Tim Cross <theophilusx@gmail.com> [2023-01-19 10:48]:
>> You completely misunderstood the specific issue being discussed. You
>> clearly have not been following this specific point being discussed and
>> your long reply just confuses matters rather than helps.
>> 
>> This issue is in dealing with the meeting time when the local timezone
>> changes due to daylight savings time and the fact you have two different
>> requirements
>
> I do not use Org for time stamps. I am using PostgreSQL.

Then your input here is not terribly relevant IMO.


> My time
> stamps show correctly (hopefully) as I rely on the design of that
> software. I may be very wrong. Though as user I want simple thing, to
> record time, and that time has to be displayed in my time zone, and I
> want to have functions which will provide for example accounting
> statement in the time zone of the recipient in Washington, USA. As
> simple as that.
>

Completely irrelevant to the point being discussed. Yet again, you are
just pushing your beliefs and pet peeves without actually comprehending
what is being discussed. 

> There is no need for Org to deal with daylight savings, as UTC
> underlying functions are expected to deal with it. Time zone database,
> C library, I cannot know. But any error there shall go to system
> maker. Developing such complexity on Org level is not necessary.
>

Yet more indication you don't understand the issue. Nobody has suggested
that org does daylight savings calculation - in fact, the one constant
from all the issues raised in this thread is that all the time zone
calculations, conversion between time zones, calculation/conversion to
display format etc is handled by system libraries not org. 


> For Emacs it makes fun to have various calendars, but for
> international time, that has to be handled by system libraries.
>
>> 1. For meeting where all people are in the same timezone, a transition
>> in/out of daylight savings changes nothing. The meeting time stays the same
>> 
>> 2. For meetings wiht people from different time zones, when daylight
>> savings transition occurs, the timestamp needs to be changed.  Nothing
>> needs to happen for the people in other time zones - it isn't their
>> problem and their meeting time is not affected.
>
> Sure, but that is not calculation for higher level like Org, it is for
> lower level, like system library. Discussion shall be given to
> developers of GNU C library to solve calculations with daylight
> savings. If such functions do not exist, then they can be made.
>

You still missed the point. It isn't about the calculation - where that
happens is largely irrelevant and as has been stated numerous times, org
will use the built-in Emacs interface to system facilities for this.

The issue is far more fundamental. Display the agenda with correct
meeting times regardless of daylight savings transitions. As only
meeting with participants from different timezones are affected by such
transitions, we need a way to distinguish those timestamps from
timestamps for meetings with all participants in the same time zone.

>> Ihor['s suggested solution was to just use the TZ of the 'meeting', but
>> that is ambiguous. A meeting doesn't have a time zone and picking just
>> one of the recipients doens't help as now you just have the issues of
>> their daylight savings transitions etc.
>
> ☺️ A meeting can have time zone. My friend, that is exactly how we do
> meetings, I have even given examples from my life on meeting
> scheduling on this mailing list. 
>

Nobody said meetings cannot have time zones. Again, work on your
comprehension. It seems you skim read then jump to the wrong
conclusion.

A meeting does NOT have a time zone. Participants in the meeting have
time zones and it is possible that every participant in the meeting is
in a different time zone. The meeting itself has no time zone.

<snipped a lot of irrelevant stuff>

>
>> The 'solution' is to record this meeting in UTC tz. However, to make
>> this 'workable' for most people, the interface for managing timestamps
>> needs to make this easy.
>
> Then again you have to tell that it is "UTC", which means you are
> already specifying some time zone.

hence the bit where I said 

"However, to make this 'workable' for most people, the interface for
 managing timestamps needs to make this easy."

>
> You could tell that Org always thinks of UTC, but that again means UTC
> as mark, must be somewhere placed, all users must know that it is UTC,
> and again there is need for users to display time in their time zone.
>
> What do you achieve by that design? 
>

It achieves exactly the flexibility needed. As has been made clear many
many times in this thread, what we are talking about is the ability to
add time zone information, not a requirement to do so. If your use case
needs that, then org becomes more useful. If it is of no benefit in your
case, then you don't have to use it.

To reiterate for the last time, there are 2 clear and different use
cases for timestamps associated with meetings.

1. A meeting timestamp for a meeting where all the participants are in
the same time zone. This meeting should remain at the same time
regardless of transitions in/out of daylight savings. The meeting is at
3pm every tuesday all year round.

2. A meeting timestamp for a meeting where all the participants are in
different time zones. When daylight savings transitions occur, the time
of that meeting needs to move forward/back by one hour (depending on
which transition occurs), but only forthe local participant.  Nothing
changes for the other participants and they do not need to know that the
local participants meeting time has changed.

The original question I posed is how would org distinguish between these
two timestamps and know that the second one needs to have the time
changed following a daylight savings transition and the first one does not. 

The answer is to use a timestamp in UTC timesone for the second
meeting. Note that this doesn't mean it is displayed to the user in UTC
time - it would be displayed to the user in their local time.

For org, this means everything would now work. When the user's time zone
transitions in/out of daylight savings time, timestamps with no timezone
data or in the local time zone say the same. TImestamps in UTC will
display an hour earlier/later depending on the transition and the person
will still turn up to the meeting at the correct time. 

> You will get confusion, as you are forcing majority of the world first
> to understand what is UTC.
>

That is an assumption on your part. If you had read and comprehended the
thread, you would have seen that once we identified that using the
different timestamp time zones could address the two use cases, the next
question was about how to implement this to make it easy for the
user.

For example, we could have functions specifically for booking meetings
with participants from different time zones or we could have a different
interface for booking meetings which gets additional details from the
user (such as the list of participants and their time zones) or any
number of other options which make this easy for the user and hides this
detail from them completely.


> Computers don't do that, they ask you, where are you? Athens, Greece?
> Thanks, here is your time.
>
> They don't tell you "let us keep meeting time in UTC" confusing users.
>
> Follow the decade long trend human usability trend and use time zones.
>

UTC is a time zone - just one where offset is +0000

>> For example, I would probablyh want an interface where by default,
>> my timestamps have no TZ data, but if I call the command to add a
>> timestamp with the universal argument, it will add a default tz and
>> allow me to easily change it to a different one.
>
> Time stamp does not need to have TZ data, and your function desire is
> just fine and correct.
>

No, as already explained, without TZ data, there is no way org can
distinguish the two different use cases outlined.

There have been numerous examples where TZ data in timestamps will be
extremely useful. What now needs to be clarified is

- Best interface for managing timestamps with TZ data
- Best way to deal with timestamps with tz data and export backends (for
- example, your workflow where you want exported documents to have the
  timestamps in the local time of your clients)
- Strategy for dealing with timestamps that may have different time
  zones when it comes to calculations such as duration, repeating etc,  

plus other things not yet thought of or discovered. This will be an
on-going refinement process that will expand
functionality/options. Precisely how it will evolve is not 100% clear at
this point. That will be determined by how people use it and future
feature requests.

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Thomas S. Dye]

Aloha Tim,

> UTC is a time zone - just one where offset is +0000

UTC is absolute time.  It lacks the spatial component that defines 
a time zone.

hth,
Tom

-- 
Thomas S. Dye
https://tsdye.online/tsdye

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Tim Cross]

"Thomas S. Dye" <tsd@tsdye.online> writes:

> Aloha Tim,
>
>> UTC is a time zone - just one where offset is +0000
>
> UTC is absolute time.  It lacks the spatial component that defines a time zone.
>

Really? I would have thought the prime meridian was the spacial
component for UTC? I thought the full long time zone name was Etc/UTC
and UTC as the abbreviation.

Regardless, in all the libraries I've used, you can use Etc/UTC or UTC
in exactly the same way you would use something like Australia/Sydney or
AEST. So perhaps, from a pedantic standpoint, it is not a time zone, but
for all intent and purpose in this discussion, I feel that point is
irrelevant.

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Thomas S. Dye]

Aloha Tim,

Tim Cross <theophilusx@gmail.com> writes:

> "Thomas S. Dye" <tsd@tsdye.online> writes:
>
>> Aloha Tim,
>>
>>> UTC is a time zone - just one where offset is +0000
>>
>> UTC is absolute time.  It lacks the spatial component that 
>> defines a time zone.
>>
>
> Really? I would have thought the prime meridian was the spacial
> component for UTC? I thought the full long time zone name was 
> Etc/UTC
> and UTC as the abbreviation.
>
> Regardless, in all the libraries I've used, you can use Etc/UTC 
> or UTC
> in exactly the same way you would use something like 
> Australia/Sydney or
> AEST. So perhaps, from a pedantic standpoint, it is not a time 
> zone, but
> for all intent and purpose in this discussion, I feel that point 
> is
> irrelevant.

Agreed.  It does seem irrelevant for time zone libraries.

Nevertheless, from the Org perspective it might not be.  An 
occurrence, which marks changes in the nature or relations of 
things at a time, requires absolute time.  Meetings, which involve 
a change in relation among participants, are occurrences.  IMO, 
this indicates Org should give occurrences a UTC timestamp, then 
translate that for each of the participants using their local time 
zone.  The insane interval problems that Ihor brought up are moot 
in absolute time.  A single timestamp serves a meeting regardless 
of whether the participants are all in one time zone or spread 
around the globe.

An occurrence contrasts with an event, which is tied to the user's 
space/time.  Time here is relative to the user.  IMO, this means 
that Org should give events a timestamp without reference to 
either absolute time or a particular time zone, like the one it 
uses now.

hth,
Tom

-- 
Thomas S. Dye
https://tsdye.online/tsdye

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Tim Cross]

"Thomas S. Dye" <tsd@tsdye.online> writes:

> Aloha Tim,
>
> Tim Cross <theophilusx@gmail.com> writes:
>
>> "Thomas S. Dye" <tsd@tsdye.online> writes:
>>
>>> Aloha Tim,
>>>
>>>> UTC is a time zone - just one where offset is +0000
>>>
>>> UTC is absolute time.  It lacks the spatial component that defines a time zone.
>>>
>>
>> Really? I would have thought the prime meridian was the spacial
>> component for UTC? I thought the full long time zone name was Etc/UTC
>> and UTC as the abbreviation.
>>
>> Regardless, in all the libraries I've used, you can use Etc/UTC or UTC
>> in exactly the same way you would use something like Australia/Sydney or
>> AEST. So perhaps, from a pedantic standpoint, it is not a time zone, but
>> for all intent and purpose in this discussion, I feel that point is
>> irrelevant.
>
> Agreed.  It does seem irrelevant for time zone libraries.
>
> Nevertheless, from the Org perspective it might not be.  An occurrence, which marks
> changes in the nature or relations of things at a time, requires absolute time.  Meetings,
> which involve a change in relation among participants, are occurrences.  IMO, this
> indicates Org should give occurrences a UTC timestamp, then translate that for each of the
> participants using their local time zone.  The insane interval problems that Ihor brought
> up are moot in absolute time.  A single timestamp serves a meeting regardless of whether
> the participants are all in one time zone or spread around the globe.
>
> An occurrence contrasts with an event, which is tied to the user's space/time.  Time here
> is relative to the user.  IMO, this means that Org should give events a timestamp without
> reference to either absolute time or a particular time zone, like the one it uses now.
>

Just checking if I understand. I think we are coming from the same
position and with the same conclusion.

In the situation where the meeting involves people from different time
zones, the time of the meeting as reported by org needs to be adjusted
after a daylight savings transition so that the time maintains the same
relative to UTC. i.e. meeting time reported in local time goes
forward/backward 1 hour depending on the daylight savings transition
(in/out). I guess this is what you call an occurrence? 

When all participants in a meeting are in the same time zone, you do not
want the time changed as the result of the daylight savings transition.
This is what you call an event?

So, using your terminology, what we now need is convenience functions
for setting an occurrence timestamp and an event timestamp. I'm not sure
if occurrence/event are the best terms, but I cannot think of better
ones. Just slightly concerned people will have trouble grasping the
difference and undersanding why some meetings are an occurrence while
others are an event. FOr the user, they are just meetings.    

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Thomas S. Dye]

Aloha Tim,

Tim Cross <theophilusx@gmail.com> writes:

> "Thomas S. Dye" <tsd@tsdye.online> writes:
>
>> Aloha Tim,
>>
>> Tim Cross <theophilusx@gmail.com> writes:
>>
>>> "Thomas S. Dye" <tsd@tsdye.online> writes:
>>>
>>>> Aloha Tim,
>>>>
>>>>> UTC is a time zone - just one where offset is +0000
>>>>
>>>> UTC is absolute time.  It lacks the spatial component that 
>>>> defines a time zone.
>>>>
>>>
>>> Really? I would have thought the prime meridian was the 
>>> spacial
>>> component for UTC? I thought the full long time zone name was 
>>> Etc/UTC
>>> and UTC as the abbreviation.
>>>
>>> Regardless, in all the libraries I've used, you can use 
>>> Etc/UTC or UTC
>>> in exactly the same way you would use something like 
>>> Australia/Sydney or
>>> AEST. So perhaps, from a pedantic standpoint, it is not a time 
>>> zone, but
>>> for all intent and purpose in this discussion, I feel that 
>>> point is
>>> irrelevant.
>>
>> Agreed.  It does seem irrelevant for time zone libraries.
>>
>> Nevertheless, from the Org perspective it might not be.  An 
>> occurrence, which marks
>> changes in the nature or relations of things at a time, 
>> requires absolute time.  Meetings,
>> which involve a change in relation among participants, are 
>> occurrences.  IMO, this
>> indicates Org should give occurrences a UTC timestamp, then 
>> translate that for each of the
>> participants using their local time zone.  The insane interval 
>> problems that Ihor brought
>> up are moot in absolute time.  A single timestamp serves a 
>> meeting regardless of whether
>> the participants are all in one time zone or spread around the 
>> globe.
>>
>> An occurrence contrasts with an event, which is tied to the 
>> user's space/time.  Time here
>> is relative to the user.  IMO, this means that Org should give 
>> events a timestamp without
>> reference to either absolute time or a particular time zone, 
>> like the one it uses now.
>>
>
> Just checking if I understand. I think we are coming from the 
> same
> position and with the same conclusion.
>
Thanks!

> In the situation where the meeting involves people from 
> different time
> zones, the time of the meeting as reported by org needs to be 
> adjusted
> after a daylight savings transition so that the time maintains 
> the same
> relative to UTC. i.e. meeting time reported in local time goes
> forward/backward 1 hour depending on the daylight savings 
> transition
> (in/out). I guess this is what you call an occurrence? 
>
> When all participants in a meeting are in the same time zone, 
> you do not
> want the time changed as the result of the daylight savings 
> transition.
> This is what you call an event?

Every meeting is an occurrence because it involves changes in 
relations of things at time; in this case meeting participants 
relate to one another via Jitsi, regardless of whether they are 
all in one time zone or spread over the globe.

An event's time is relative to the user's location, or space/time. 
So, the example I gave earlier "Brush teeth before bed" set to 
10:00 PM, which works whether I am home in Honolulu or enjoying 
the hustle and bustle of Manhattan, is a simple event.  It happens 
at that time in the timezone I happen to inhabit at the moment, 
because I intend to go to sleep shortly after 10:00 PM regardless 
of where I am.

>
> So, using your terminology, what we now need is convenience 
> functions
> for setting an occurrence timestamp and an event timestamp. I'm 
> not sure
> if occurrence/event are the best terms, but I cannot think of 
> better
> ones. Just slightly concerned people will have trouble grasping 
> the
> difference and undersanding why some meetings are an occurrence 
> while
> others are an event. FOr the user, they are just meetings.    

Yes, both meetings are occurrences.

I agree that the terms take some getting used to.  I got them from 
Frank Ramsey, who seemed to be happy with event, but not so happy 
with occurrence.

The difference is this: Will the happening being scheduled involve 
other people, who will share the Org timestamp, or will it take 
place at the same absolute time, regardless of where you are when 
it happens?  If so, then the timestamp should be stored as UTC (it 
is an occurrence that requires absolute time).

Or, is it something you want to do at a time, regardless of where 
you are.  If so, then the usual Org timestamp without UTC is what 
should be stored (it is an event that requires time local to the 
user).

In the case of a meeting, where the one who calls the meeting 
sends an Org file with a meeting agenda and a UTC timestamp to 
each of the participants, Org will translate the UTC timestamp 
into local time for each participant.  Similarly, when you are 
traveling, Org will translate the UTC timestamp to the timezone 
you happen to inhabit.  Here, I'm assuming that the timezone 
machinery is capable of determining local time relative to UTC.

hth,
Tom

-- 
Thomas S. Dye
https://tsdye.online/tsdye

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Sterling Hooten]

Hi all,

Collaborating around the subject of "time" is difficult; there are
subtleties abound in implementation, the perspectives people come from,
and the language used in discussions. I'm going to provide a glossary to
establish common terminology, use these terms to analyze our current
state, offer a roadmap for solving the problem in stages, suggest a
format for timestamps, urge compatibility with "exotic" use cases, and
finally call for outside help with implementing a timezone aware agenda
system.

Summary and references are at the end.

This is an initial glossary compiled from various standards and sources;
it's incomplete, probably incorrect, and open to critique, but is useful
in articulating a possible road map forward.

• Time

  Time (concept)
        What clocks measure (Einstein)
  Time axis
        Mathematical representation of the succession in time according
        to the space-time model of instantaneous events along a unique
        axis (ISO).

  Instant (object)
        A single point on time axis (ISO).
  Moment in time
        See: instant.
  Mark
        A set of symbols related to the object, or carrying some
        symbolic meaning
  Time scale
        System of ordered marks which can be attributed to instants on
        the time axis , one instant being chosen as the origin. e.g.,
        GMT, UTC, TAI.
  Basis time
        See: time scale.
  Time (mark)
        The designation of an instant on a selected time scale, used in
        the sense of time of day.
  Time interval (object)
        part of the time axis limited by two instants and, unless
        otherwise stated, the limiting instants themselves a part of
        time limited by two instants or moments in time (ISO). The
        elapsed time between two events (NIST).
  Duration (object)
        as a quantity characterizing a time interval. These can be
        written in different formats.
  UTC
        Time scale with the same rate as International Atomic Time
        (TAI), but differing from TAI only by an integral number of
        seconds.
  Offset
        Constant duration difference between times of two time scales
        (ISO). i.e., a quantity to combine with a time scale to produce
        a wall time. e.g., Nepal uses a +5:45 offset from the UTC time
        scale.
  Time shift
        See: offset.
• Calendar and civil time
  Wall time
        what shows on the clock on the wall at a location. Like "local
        system time" but needn't reference a computer to do the
        calculation.
  Standard time
        Time scale derived from UTC, by a time shift established in a
        given location by the competent authority (ISO).
  Local system time
        Local system time is determined by applying the system's time
        zone offset and year offset values to UTC. The Time of day
        system value displays the local system time. Local system time
        and system time are used interchangeably.
  Time Zone
        A place/region. Can map between wall time and a time scale with
        a table and an offset. A set of rules for determining the local
        observed time (wall time) as it relates to incremental time (as
        used in most computing systems) for a particular geographical
        region. e.g., Brasília time presently has an offset of −03:00
        from the UTC time.
  Calendar event
        A calendar object that is commonly used to represent things that
        mark time or use time. Examples include meetings, appointments,
        anniversaries, start times, arrival times, closing times.

• Implementation These concern how we actually decide to record,
  reference, or manipulate time.
  Representation
        Expression indicating a time point, time interval or recurring
        time interval. e.g., [2023-02-02 Thu 12:58 +1w], "this next
        suday at 2pm EST", 3600 seconds from Unix epoch
  Format
        A description of the abstract form used for a representation.
        e.g., [YYYY-MM-DD] 'Explain in prose relative to this moment in
        time using locale and include your timezone'
  Encoding
        The method of storing a representation of time e.g., datestruct
        in memory, Org timestamp in body of heading, value of a
        "created" key in a database
  Format syntax
        Rules that allow for parsing a encoding unambiguously into some
        time scale.
  Timestamp (mark)
        An encoded representation in a selected format. e.g., 24/01/2023
        or 2023-01-24
  Delimiting syntax
        Rules that allow for detection and extraction of an encoding.
        Necessary for encodings embedded in prose. e.g., '[]' for org
        timestamps.

  Displayed time
        The formatting of a representation exposed to a user.
  Calculating
        Manipulating a set of time points, time intervals, or recurring
        time intervals. e.g., determining instant from an offset,
        comparing two representations in some lattice.
  Incremental time
        A datetime value consisting of monotonically increasing integer
        units measured from a specific moment in time (epoch). For
        example, the moment 1970-01-02T00:00:00.000Z might have an
        incremental time value (measured in milliseconds) of 86400000,
        since there are 86,400 seconds in a day and 1000 ms in a second.
  Floating time
        A wall time value without time zone or offset information. E.g.,
        2023-01-24 or 6:45pm.
  Fixed time
        A representation of a (past or future) UTC time.
  Absolute time
        See: fixed time.
  Unfixed time (from UTC)
        A representation which is not referenced to a past or future UTC
        time. e.g., 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.
• Time formats
  Incremental timestamp
        Timestamps that can be directly compared: their integer values
        determine which is earlier or later. e.g., Unix seconds since
        epoch.
  Field-Based timestamp
        Timestamps which must be normalized and their individual fields
        compared. Field based times can have certain kinds of logical
        operations performed on them (for example, rolling the month
        forward or back), while incremental time requires a logical
        transformation. e.g., ISO8601 style timestamps.
  ISO Basic format
        A format which omits hyphen separators e.g., YYYYMMDD
  ISO Extended format
        A format which includes hyphen separators e.g., YYYY-MM-DD
  Extended Date/Time Format EDTF
        An extension of the ISO 8601 created by the Library of Congress
        to cover date formats and conditions useful in metadata systems
        but not handled in the ISO standard.


What does format does Org have now?

• The format currently in use for timestamps is floating, field-based,
  and has a resolution/precision of minutes.

What kinds of representations would a calendar system capable of
handling timezones require?

• Instant (fixed)
  • This is referring to an unambiguous moment in time
  • e.g., 2007-02-03T05:00:00.000Z
• Offset (fixed)
  • This captures the idea of "when did it happen for the person who
    made the observation"
  • e.g., 2007-02-03T04:00:00.000+01:00
• Instant with explicit offset and zone (fixed)
  • e.g., 2007-01-01T02:00:00.000+01:00[America/Chicago]
• Zoned local date time (floating)
  • Tricky, requires decisions about how to interpret timestamps after
    political changes.
  • e.g., 2007-01-01T01:00:00.000[America/Chicago]


I claim that before dealing with the nuances of calendar appointments,
repeating events, agenda displays etc, that Org must first support
fixed/absolute time instead of just floating time. Without some basis
time scale the conversions from time zones and offsets to some
incremental time point is impossible. Resolving this prerequisite will
also simplify the timezone discussion because we won't be mixing
calendar issues with time issues.

What would a roadmap be?

• Design and implement an absolute and offset timestamp system
  • Decide on a time scale
  • Decide on a format and syntax
  • Implement instant timestamps
  • Implement offeset timestamps
• Design and implement the time zone aware calendar system This is a
  separate project.

What time scale should Org use?

There are only two decent options, either TAI or UTC. The rest of the
world has agreed upon UTC, we should too. Conversion to TAI can be done
by users or on export.

What format and syntax should Org use?

A heretical suggestion: We should abandon the day of week abbreviation
and use a new format.

The current format generates a three leter abbreviation of the day of
the week [2023-01-25 Wed 12:12]. I suggest supporting this as a
legacy/simple format but switch to a format/encoding like
[2023-01-25T15:13:42Z] for the new system. Specifically I'm advocating
for an extended ISO 8601 format, compatible with expanded dates and
Level 2 of the EDTF, with some (bracket?) notation surrounding it such
that Org can parse the syntax as a timestamp. I advocate further for the
use of durations and repeating intervals to follow the same standard
format. Thus instead of a range being formatted as:

[2023-01-25 Wed 13:57]–[2023-01-26 Thu 13:57]

it would be:

[2023-01-25T16:57:42Z/2023-01-26T16:57:42Z].

If the square bracket delimiter syntax is insufficient or too difficult
to parse unambiguously, we could just encapsulate the ISO format in a
sub-syntax (e.g., [&&(ISO format)] similar to the [%%(diary sexp)]
technique). This is ugly, but perhaps a stepping stone during
development to separate syntax parsing concerns from calculating etc.

What are the problems with the day of the week in existing format?

• The day of the week is redundant information and can be rebuilt from
  an ISO date Any user who wishes to display a format with the day of
  the week can do so.
• It's a nonstandard format Although the Org documentation says that the
  timestamps are "inspired by the standard ISO 8601 date/time format"
  the use of a day name is not contained in the ISO specification. The
  present Org format is actually two ISO components, the date and the
  time, with a non-standard day name sandwiched between them with space
  separators. Spaces are no longer allowed in the ISO format. By
  deviating from an existing standard we place the burden of parsing on
  ourselves and make sharing more difficult.
• Day of the week is irrelevant in many situations Looking at timestamps
  from a year ago it's often the case that what day of the week it was
  created is unimportant.

What are the advantages of switching to a standard format for the new
system?

• We can allow the legacy/simple system to coexist and interpret it as a
  floating timestamp This simplifies the issues of maintaining
  compatibility with existing org documents. It also placates those who
  have single user systems in a single time zone who do not want to have
  any calendar complexity imposed on them.
• We have a way of distinguishing new timestamps from legacy/simple ones
  By making a change in syntax we reduce (or eliminate?) the possibility
  of ambiguity between "which version" of a timestamp is being parsed. A
  legacy timestamp can be treated as such, and new timestamps are easily
  identified by the 'T' present instead of spaces, or in the delimiters
  wrapping the representation.
• We free ourselves from the constraints of the legacy timestamp format
  Trying to engineer a new syntax which also parses as an extension of
  the legacy one is more complex and embeds things like "day of the
  week" and the use of spaces as separators into this new system. Easier
  to have two side by side.
• We can defer to existing parsing and calculating systems There are
  already programs written which support the ISO standard and EDTF.
  • We can directly (or nearly directly) import the regular expressions
    and parsing mechanisms already written.
  • These enable decent testing suites as we build the system, as we can
    check against existing packages to see if our parsing and
    calculations agree.
  • Users who wish to use external libraries (irrespective of language
    or license) can extract the new timestamp and parse or calculate
    externally.
• Org is part of a standard
  • We are able to defer to experts and 35 years of knowledge rather
    than debate among ourselves
  • Interfacing with other programs is simplified as the area inside the
    delimiter notation can be passed as a string without parsing.
  • New users and collaborators can be onboarded faster without needing
    to learn a new system
  • Org documentation can refer to the standard instead of bearing the
    burden of exposition.
• The move to include time zones in the format is simplified
  • The ISO standard has recently adopted a format for time zones from
    RFC3339 and JAVAZDT, we can adhere to 8601 and keep things
    consistent.


What other perspectives should the new format support?

In addition to the representations necessary for a timezone aware
calendar system, I suggest the new format be compatible with two other
representations: finer/ arbitrary resolution for scientific work, and
Level 2 of the Extended Date/Time Format for bibliographic and metadata
systems.

Although most implementations come from the computer/database
perspective, where precision is limited by clock speed, scientific data
may be finer grained. Adopting a format which allows for arbitrary
precision enables Org to be useful in more scenarios. This would allow
data of higher frequency to be collected and stored into org headings as
a plain text database. Even if the data was stored externally it would
be convenient to be able to comment or discuss collected data by
referencing its time point.

The Extended Data/Time Format (EDTF) was designed by the Library of
Congress to address limitations of the ISO standard for metadata and
archival purposes. A draft specification was created in 2012 and EDTF
functionality has now been integrated into ISO 8601-2019. Of great
interest is the ability to express the concepts of uncertainty and
approximation. Archival work includes scenarios where the precise date
may be unknown, so a format was created with qualifiers capable of
handling these situations. In the EDTF format '1984?' expresses possibly
the year 1984, but not definitely, while '2004-06~' expresses year-month
approximate. This format has been implemented by multiple library
systems and in 2021 Wikibase added an extension to support EDTF.

The initial technical or code burden to support these perspectives is
minimal. Both can be parsed and calculated with by existing libraries,
and the functionality to actually calculate with them can be delayed.
The important thing is selecting a format which won't exclude them.

That these features are omitted in many systems as result of the
restricted domain and the data types used for storage; Org does not have
these constraints. Further, both of these communities tend to attract
people who are talented and sympathetic with (even occasionally funded
to support!) open source projects. By expanding Org's format to be more
inclusive we provide a haven rather than shutting them out.

The calendar implementation should elicit help from experts

Everyone seems in agreement that leveraging existing libraries is
desirable. We should also read and defer to documentation and
recommendations available from legitimate projects (e.g., W3, ISO). But
I think these are still insufficient for architecting an elegent time
system capable of satisfying the various perspectives. Calendar
applications in particular contain many edge cases and decisions about
display and interface etc. The knowldege concerning these is more likely
tacit than explicit, so I suggest we reach out to people who have
already designed/engineered solutions and get their input.

Here are some projects, organizations, or perspectives we could seek
help from:

• Calendar applications
  • ical standard
  • CalConnect standard
  • Thunderbird/lightning calendar
  • Google calendar
  • Outlook
  • Lotus notes
• Standard organizations
  • NIST
  • ISO
• Database or computer applications
  • SQL
  • Oracle
  • Java's time system
  • Numpy
  • Rust
• Archival or research users
  • Library of congress
  • Metadata systems
• Academic users
  • History
• Scientific users
  • Astronomers
  • Physicists
  • Chemists
  • Geologists
  • Metrologists

To summarize:

Org presently only supports simple floating timestamps. A calendar
system capable of handling time zones requires some form of fixed or
incremental timestamp with offsets. We can solve the absolute timestamp
system first, and deal with calendar concerns after. If we're
implementing a new time system the format and syntax should allow for
"exotic" use cases like arbitrary precision, uncertainty, and expanded
dates. The mechanics for calculating with those exotic cases needn't be
implemented by Org immediately.

We should adopt UTC as the time scale, EDTF (an extension of ISO 8601)
as the time format, and merely encapsulate this format with a delimiting
syntax (using brackets if possible) that Org can parse and distinguish
from the present format. The existing Org format should be considered
simple/legacy and can be interpretted or translated internally into the
new system as calculations require. The new format can be implemented
alongside the simple/legacy system.

This discussion of absolute offset timestamps should be split off from
timezone, calendar, and display concerns. Implementing a calendar
application with timezones is complicated and we should seek help from
those who have built the systems from before.

References:

Time

https://www.iso.org/obp/ui/#iso:std:iso:8601:-1:ed-1:v1:en
https://www.w3.org/International/articles/definitions-time/
https://www.ibm.com/docs/en/i/7.3?topic=concepts-time
https://tc39.es/proposal-temporal/docs/ambiguity.html

EDTF

https://www.loc.gov/standards/datetime/ Main page on EDTF
https://edtf.wikibase.wiki/wiki/Property:P1 Has examples of EDTF codes
https://www.wikibase.consulting/wikibase-edtf/ Wikibase implemented
EDTF in 2021
https://github.com/ProfessionalWiki/WikibaseEdtf#wikibase-edtf
https://github.com/corylown/edtf-humanize Transform EDTF strings into
human friendly display https://github.com/unt-libraries/edtf-validate
Validate EDTF strings https://github.com/plk/biblatex/issues/656
Discussion of Biblatex's implementation of EDTF
https://www.npmjs.com/package/edtf Parser for EDTF
https://github.com/inukshuk/edtf.js/tree/main Parser for EDTF

Implemention details

https://www.w3.org/TR/international-specs/#loc_time
https://dev.mysql.com/doc/refman/5.7/en/date-and-time-type-syntax.html

Time zones

https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/
An extension syntax for representing time zone. We should follow this.
Very helpful for implementing time zones.
https://www.w3.org/TR/timezone/#representing Very relevant
https://www.w3.org/International/core/2005/09/timezone.html#IDALFAT

Calendar and scheduling

https://www.calconnect.org/resources/glossary

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Ihor Radchenko]

First of all, thanks for the detailed suggestion!
I will need more time to look through the provided links and think about
the ideas.

I will provide one important consideration you missed in the below comment.

Sterling Hooten <hooten@gmail.com> writes:

> What format and syntax should Org use?
>
> A heretical suggestion: We should abandon the day of week abbreviation
> and use a new format.
> ...
> [2023-01-25 Wed 13:57]–[2023-01-26 Thu 13:57]
>
> it would be:
>
> [2023-01-25T16:57:42Z/2023-01-26T16:57:42Z].

Following ISO and other standards is indeed a reasonable idea. However,
the standards are not necessarily designed for human consumption.
In contrast, Org mode is designed to be read by humans as well, even
without Emacs - just as plain text.

Design for human consumption is one of the reasons we do provide the
redundant information like week day (I personally did find it extremely
useful on multiple occasions) and do use spaces, deviating from ISO. The
above ISO example is barely readable by humans. Another example from
wiki page of ISO 8601 is even worse: R5/2008-03-01T13:00:00Z/P1Y2M10DT2H30M

And we need to deviate from ISO 8601 anyway. At least, because it does
not define time zones, only absolute UTC offsets. So, the ability to
conform with the existing formats remains questionable.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Greg Minshall]

Ihor, Sterling, et al.,

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)

in my experience, it is easiest to accomplish 2 and 3 by adopting the
encoding in the underlying spec/specs (if "specs" -- hopefully they are
compatible! :)

but, i don't doubt that other encodings that accomplish 1, and still
accomplish 2 and 3, exist.

possibly, an important step forward is to complete the sentence,
"Org-mode datestamps are intended to conform to the semantics (but not
necessarily the encoding) specified in the following specifications:
...".

cheers, Greg

[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 <minshall@umich.edu> 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

   YYYY-MM-DD [optional day name] HH:MM[^ \]>]*?[+-−]HH[MM]?
   YYYY-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

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

|-----------------------------------|
|              <end>                |
|-----------------------------------|

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
   2004-02-01/2005-02-08 (not supported and incompatible with Org)

4. Seasons
   2001-21 (Spring, 2001; not supported by Org)

5. Approximate dates
   1984? (year uncertain)
   2004-06~ (year-month approximate)
   2004-06-11% (entire date (year-month-day) uncertain and approximate)
   2004-06?-11 (year and month uncertain)
   2004-?06-11 (just month uncertain)

6. Unspecified digits
   1985-04-XX (day unspecified; might be an interesting idea for
   defining repeater intervals)

7. Open time intervals
   1985-04-12/.. (from 1985-04-12 to infinite)
   1985-04-12/ (from 1985-04-12 to unknown)

8. Negative calendar year
   -1985 (note: an alternative could be allowing AD/BC)

9. Set of dates
   [1667,1668,1670..1672] (one of)
   {1667,1668,1670..1672} (all)
   [1760-01,1760-02,1760-12..]
   (similar to regexp [...] groups; not compatible with Org syntax, but
   the idea could be interesting for repeater intervals)

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Daryl Manning]

[-- Attachment #1: Type: text/plain, Size: 10138 bytes --]

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 <yantar92@posteo.net> wrote:

> Greg Minshall <minshall@umich.edu> 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
>
>    YYYY-MM-DD [optional day name] HH:MM[^ \]>]*?[+-−]HH[MM]?
>    YYYY-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
>
>    YYYY-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.
>
> |-----------------------------------|
> |              <end>                |
> |-----------------------------------|
>
> 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
>    2004-02-01/2005-02-08 (not supported and incompatible with Org)
>
> 4. Seasons
>    2001-21 (Spring, 2001; not supported by Org)
>
> 5. Approximate dates
>    1984? (year uncertain)
>    2004-06~ (year-month approximate)
>    2004-06-11% (entire date (year-month-day) uncertain and approximate)
>    2004-06?-11 (year and month uncertain)
>    2004-?06-11 (just month uncertain)
>
> 6. Unspecified digits
>    1985-04-XX (day unspecified; might be an interesting idea for
>    defining repeater intervals)
>
> 7. Open time intervals
>    1985-04-12/.. (from 1985-04-12 to infinite)
>    1985-04-12/ (from 1985-04-12 to unknown)
>
> 8. Negative calendar year
>    -1985 (note: an alternative could be allowing AD/BC)
>
> 9. Set of dates
>    [1667,1668,1670..1672] (one of)
>    {1667,1668,1670..1672} (all)
>    [1760-01,1760-02,1760-12..]
>    (similar to regexp [...] groups; not compatible with Org syntax, but
>    the idea could be interesting for repeater intervals)
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>

[-- Attachment #2: Type: text/html, Size: 12379 bytes --]

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 <daryl@wakatara.com> 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 @<staff> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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 <daryl@wakatara.com> 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 <clamen@CS.CMU.EDU>
    ("NST" .  -330)			;by <clamen@CS.CMU.EDU>
    ("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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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 <yantar92@posteo.net> [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.

>    YYYY-MM-DD [optional day name] HH:MM[^ \]>]*?[+-−]HH[MM]?
>    YYYY-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]

Jean Louis <bugs@gnu.support> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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 <yantar92@posteo.net> [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)

[Ihor Radchenko]

Jean Louis <bugs@gnu.support> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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 <yantar92@posteo.net> [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)

[Ihor Radchenko]

Jean Louis <bugs@gnu.support> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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 <yantar92@posteo.net> [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)

[tomas]

[-- Attachment #1: Type: text/plain, Size: 794 bytes --]

On Tue, Jan 31, 2023 at 11:12:00PM +0300, Jean Louis wrote:
> * Ihor Radchenko <yantar92@posteo.net> [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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Jean Louis]

* tomas@tuxteam.de <tomas@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)

[Tim Cross]

<tomas@tuxteam.de> writes:

> [[PGP Signed Part:Undecided]]
> On Tue, Jan 31, 2023 at 11:12:00PM +0300, Jean Louis wrote:
>> * Ihor Radchenko <yantar92@posteo.net> [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)

[Jean Louis]

* Tim Cross <theophilusx@gmail.com> [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)

[Ihor Radchenko]

Tim Cross <theophilusx@gmail.com> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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 <yantar92@posteo.net> writes:

> Tim Cross <theophilusx@gmail.com> 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 <theophilusx@gmail.com> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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 <yantar92@posteo.net> [2023-02-01 13:30]:
> Tim Cross <theophilusx@gmail.com> 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)

[Ihor Radchenko]

Jean Louis <bugs@gnu.support> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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)

[Jean Louis]

* Tim Cross <theophilusx@gmail.com> [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]

Jean Louis <bugs@gnu.support> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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]

Max Nikulin <manikulin@gmail.com> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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 <yantar92@posteo.net> [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 well?

I wonder why?

Maybe it uses time zone specification?

And following will work:

$ sudo date -s '20230326 0300'
Sun Mar 26 03:00:00 AM CEST 2023

The demonstration will tell you that specifying invalid time stamps is
what? INVALID.

To avoid such time stamps is easy, just stop using crapy programs to
generate invalid time stamps.

File a bug, complain, but do not use wrong time.

Another practical exercises user can do:
----------------------------------------

1. Go to https://f-droid.org
----------------------------

   Try out the free application Etar, and try to enter such invalid
   time stamp by creating a task with the time of [2023-03-26 02:30
   @Europe/Berlin] and user will see that it will not work, the time
   will be written as 3:30 instead of 2:30 -- application is not
   lousy, thank you very much, PASS!


2. Do PostgreSQL exercise in shell:
-----------------------------------

$ psql
psql (14.6)
Type "help" for help.

[local] maddox@rcdbusiness=# set timezone to 'Europe/Berlin';
SET

[local] maddox@rcdbusiness=# select '2023-03-26 02:30'::timestamptz at time zone 'Europe/Berlin';
      timezone       
---------------------
 2023-03-26 03:30:00
(1 row)

The exercise will show that when user specify invalid time stamp
program recognizes it and assumes that one hour must be added to such
invalid timestamp. PASS for PostgreSQL!


3. Google Calendar on Android phone
-----------------------------------

I have asked friend to try to setup a task at 02:15 and Europe/Berlin
time zone:

Attempt to setup tasks worked by itself:
https://gnu.support/images/2023/02/2023-02-01/Screenshot_20230201-154514.jpg

But as soon as the task was saved, the specified time shifted 1 hour
forward:
https://gnu.support/images/2023/02/2023-02-01/Screenshot_20230201-154527.jpg


Conclusion:
-----------

1. Time stamp like [2023-03-26 02:30 @Europe/Berlin] is invalid. There
   is no problem at hand unless there is lousy program generating it.

2. People taking care of time should not use lousy programs generating
   invalid time stamps.

--
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 <louis@gnu.support> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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 <bugs@gnu.support> writes:

> * Ihor Radchenko <yantar92@posteo.net> [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]

* Thomas S. Dye <tsd@tsdye.online> [2023-02-01 10:05]:
> Aloha Jean Louis,
> 
> Jean Louis <bugs@gnu.support> writes:
> 
> > * Ihor Radchenko <yantar92@posteo.net> [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)

[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)

[Ihor Radchenko]

Greg Minshall <minshall@umich.edu> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[tomas]

[-- Attachment #1: Type: text/plain, Size: 591 bytes --]

On Wed, Feb 01, 2023 at 12:48:12PM +0000, Ihor Radchenko wrote:
> Greg Minshall <minshall@umich.edu> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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)

[Tim Cross]

Ihor Radchenko <yantar92@posteo.net> writes:

> Greg Minshall <minshall@umich.edu> 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
>
>    YYYY-MM-DD [optional day name] HH:MM[^ \]>]*?[+-−]HH[MM]?
>    YYYY-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
>
>    YYYY-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.
>
> |-----------------------------------|
> |              <end>                |
> |-----------------------------------|
>
> 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
>    2004-02-01/2005-02-08 (not supported and incompatible with Org)
>
> 4. Seasons
>    2001-21 (Spring, 2001; not supported by Org)
>
> 5. Approximate dates
>    1984? (year uncertain)
>    2004-06~ (year-month approximate)
>    2004-06-11% (entire date (year-month-day) uncertain and approximate)
>    2004-06?-11 (year and month uncertain)
>    2004-?06-11 (just month uncertain)
>
> 6. Unspecified digits
>    1985-04-XX (day unspecified; might be an interesting idea for
>    defining repeater intervals)
>
> 7. Open time intervals
>    1985-04-12/.. (from 1985-04-12 to infinite)
>    1985-04-12/ (from 1985-04-12 to unknown)
>
> 8. Negative calendar year
>    -1985 (note: an alternative could be allowing AD/BC)
>
> 9. Set of dates
>    [1667,1668,1670..1672] (one of)
>    {1667,1668,1670..1672} (all)
>    [1760-01,1760-02,1760-12..]
>    (similar to regexp [...] groups; not compatible with Org syntax, but
>    the idea could be interesting for repeater intervals)


I think that syntax looks pretty good. It seems to support all the
identified use cases and would therefore provide the flexibility users
require.

The big challenge will be in implementing a UI which encapsulates this
flexibility, but it intuitive and guides users to selecting the correct
format for the specific use case of the timestamp. We may also need
additional options to manage how timestamps are exported to various
backends (I'm assuming we will also have some form of overlay to improve
display of timestamps - it is likely users will also want similar
control over how timestamps appear in various back ends)

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 <yantar92@posteo.net> wrote:
> Greg Minshall <minshall@umich.edu> 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
>
>    YYYY-MM-DD [optional day name] HH:MM[^ \]>]*?[+-−]HH[MM]?
>    YYYY-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
>
>    YYYY-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.
>
> |-----------------------------------|
> |              <end>                |
> |-----------------------------------|
>
> 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
>    2004-02-01/2005-02-08 (not supported and incompatible with Org)
>
> 4. Seasons
>    2001-21 (Spring, 2001; not supported by Org)
>
> 5. Approximate dates
>    1984? (year uncertain)
>    2004-06~ (year-month approximate)
>    2004-06-11% (entire date (year-month-day) uncertain and approximate)
>    2004-06?-11 (year and month uncertain)
>    2004-?06-11 (just month uncertain)
>
> 6. Unspecified digits
>    1985-04-XX (day unspecified; might be an interesting idea for
>    defining repeater intervals)
>
> 7. Open time intervals
>    1985-04-12/.. (from 1985-04-12 to infinite)
>    1985-04-12/ (from 1985-04-12 to unknown)
>
> 8. Negative calendar year
>    -1985 (note: an alternative could be allowing AD/BC)
>
> 9. Set of dates
>    [1667,1668,1670..1672] (one of)
>    {1667,1668,1670..1672} (all)
>    [1760-01,1760-02,1760-12..]
>    (similar to regexp [...] groups; not compatible with Org syntax, but
>    the idea could be interesting for repeater intervals)
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>
>


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

[Ihor Radchenko]

Samuel Wales <samologist@gmail.com> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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 <yantar92@posteo.net> 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)

[Samuel Wales]

tldr: carry on.  :]


On 2/4/23, Samuel Wales <samologist@gmail.com> wrote:
> On 2/1/23, Ihor Radchenko <yantar92@posteo.net> 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)

[Ihor Radchenko]

Samuel Wales <samologist@gmail.com> writes:

> On 2/1/23, Ihor Radchenko <yantar92@posteo.net> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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
>
>    YYYY-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.
>
> |-----------------------------------|
> |              <end>                |
> |-----------------------------------|
>
> 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
>    2004-02-01/2005-02-08 (not supported and incompatible with Org)
>
> 4. Seasons
>    2001-21 (Spring, 2001; not supported by Org)
>
> 5. Approximate dates
>    1984? (year uncertain)
>    2004-06~ (year-month approximate)
>    2004-06-11% (entire date (year-month-day) uncertain and approximate)
>    2004-06?-11 (year and month uncertain)
>    2004-?06-11 (just month uncertain)
>
> 6. Unspecified digits
>    1985-04-XX (day unspecified; might be an interesting idea for
>    defining repeater intervals)
>
> 7. Open time intervals
>    1985-04-12/.. (from 1985-04-12 to infinite)
>    1985-04-12/ (from 1985-04-12 to unknown)
>
> 8. Negative calendar year
>    -1985 (note: an alternative could be allowing AD/BC)
>
> 9. Set of dates
>    [1667,1668,1670..1672] (one of)
>    {1667,1668,1670..1672} (all)
>    [1760-01,1760-02,1760-12..]
>    (similar to regexp [...] groups; not compatible with Org syntax, but
>    the idea could be interesting for repeater intervals)

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 <mail@christianmoe.com> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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 <yantar92@posteo.net> [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)

[Ihor Radchenko]

Jean Louis <bugs@gnu.support> writes:

> * Ihor Radchenko <yantar92@posteo.net> [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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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 <yantar92@posteo.net> [2023-02-02 11:38]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > * Ihor Radchenko <yantar92@posteo.net> [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: [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 <bugs@gnu.support> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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 <yantar92@posteo.net> [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)

[Ihor Radchenko]

Jean Louis <bugs@gnu.support> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Timothy]

[-- Attachment #1: Type: text/plain, Size: 6220 bytes --]

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
>
>    YYYY-MM-DD [optional day name] HH:MM[^ \]>]*?[+-−]HH[MM]?
>    YYYY-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
>
>    YYYY-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).

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

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
│ [2022-11-12 12:00 @!+07,Asia/Singapore] # use +07 over Asia/Singapore
└────

What are you thoughts on this?

Thanks again for your work on this,
Timothy

-- 
Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/tec>.

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 <orgmode@tec.tecosaur.net> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Timothy]

[-- Attachment #1: Type: text/plain, Size: 835 bytes --]

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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/tec>.

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 <orgmode@tec.tecosaur.net> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Timothy]

[-- Attachment #1: Type: text/plain, Size: 738 bytes --]

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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/tec>.