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

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

[Daryl Manning]

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

Following on from thread at
https://www.reddit.com/r/orgmode/comments/zrppqw/

[First off, I just wanted to say thank you to everyone that works on
org-mode. It is a wonder.]

While I realize a few kicks at this can may have been taken, I wanted to
(re-)propose Timezone support in org-mode. The world is much less local
these days and we're all more remote and coordinating globally these days.

*Background*

1. org-time-stamp-formats TZ currently only affects display and exports
2. org-agenda itself is not TZ aware
3. Several discussions on this have taken place over time
4. Concerns raise included breaking backwards compatibility

*Proposal*

1. org-mode sets an optional variable (org-timezone-aware t) which enables
TZ
2. org-agenda needs a way to determine which timezone it is in
3. Once enabled, any timestamp not exhibiting a TZ in it is considered
"local time" wherever that is (I do not think UTC would work for this)
4. org-agenda can calc local based on TZ differences

I understand this is by no means trivial and quite gnarly with DST and such
to figure out but I do believe libs exists to deal with that heavy lifting.
Currently, it does feel like a hole in org-mode as a 21st century organizer
(disclaimer: digital nomading so might feel it more keenly). Also, just
interested in making org-mode a more awesome tool for everybody.

I'd love an understanding of the alluded to reservations raised in the
reddit thread and in the mailing list threads mentioned that the format
change might break things (I was unsure if that was referring to say, how
time ranges were handled, or how say date ranges got dealt with (for
example, say a flight from Singapore to Vancouver which takes off in one
time zone and lands in another - something that is often in my cal.).

thanks!
Daryl.

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

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

[Tim Cross]

Daryl Manning <daryl@wakatara.com> writes:

> Following on from thread at https://www.reddit.com/r/orgmode/comments/zrppqw/
>
> [First off, I just wanted to say thank you to everyone that works on org-mode. It is a wonder.]
>
> While I realize a few kicks at this can may have been taken, I wanted to (re-)propose Timezone support in org-mode. The
> world is much less local these days and we're all more remote and coordinating globally these days.
>
> *Background*
>
> 1. org-time-stamp-formats TZ currently only affects display and exports
> 2. org-agenda itself is not TZ aware
> 3. Several discussions on this have taken place over time
> 4. Concerns raise included breaking backwards compatibility
>
> *Proposal*
>
> 1. org-mode sets an optional variable (org-timezone-aware t) which enables TZ
> 2. org-agenda needs a way to determine which timezone it is in
> 3. Once enabled, any timestamp not exhibiting a TZ in it is considered "local time" wherever that is (I do not think UTC
> would work for this)
> 4. org-agenda can calc local based on TZ differences
>
> I understand this is by no means trivial and quite gnarly with DST and such to figure out but I do believe libs exists to
> deal with that heavy lifting. Currently, it does feel like a hole in org-mode as a 21st century organizer (disclaimer:
> digital nomading so might feel it more keenly). Also, just interested in making org-mode a more awesome tool for
> everybody. 
>
> I'd love an understanding of the alluded to reservations raised in the reddit thread and in the mailing list threads
> mentioned that the format change might break things (I was unsure if that was referring to say, how time ranges were
> handled, or how say date ranges got dealt with (for example, say a flight from Singapore to Vancouver which takes off in
> one time zone and lands in another - something that is often in my cal.). 
>

I agree this would be a great feature to add. However, after having
looked at it in some detail, I realise that not only is it not a trivial
task, it is actually a very large and complex task and will require
extensive work which will almost certainly result in breakage with
regards to backwards compatibility.

At the risk of over simplifying the matter, I would suggest the big
challenge here is that there are two somewhat competing (and
conflicting) use cases. On one hand, you want a high level abstraction
which makes working with dates and times easy and clear. TO some extent,
that is what we have now. On the other hand, we need something far more
complex which is able to handle multiple time zones. This means being
able to handle both base timezone offsets as well as offset adjustments
for things like daylight savings time. There is a lot of hidden
complexity here. You have to handle the fact that daylight saving
chang-over dates/times are dynamic i.e. not necessarily the same every
year. This adds the additional complexity of having to somehow track
historical information regarding such changes, which isn't as readily
accessible in a consistent manner on all platforms.

Then there is the other 'messy' stuff. For example, when calculating
time ranges and number of days, hours/ minutes between two dates you
need to remember to add/remove the hour if the range crosses over a
daylight savings period. Similarly you need to ensure you make the
correct adjustment when changing timezones (consider emacs on a laptop
for someone who travels a lot between different time zones). Not only do
you need to take into account the different timezone offset, you also
need to look at the date and then adjust according to the timezone
offset for the current timezone at the time of the timestamp rather than
just considering the current time offset.  

I expect what is needed is an 'internal' UTC based representation which
is used for all calculations and an 'interface' layer, which converts
the UTC representation into the local display representation for
consumption by humans. The problem with this is that it is likely to
break the core feature of org files i.e. that they are in plain text. I
guess we could possibly do somehting clever with overlays such that UTC
date/times are rendered/presented in local time format. However, we
would then also require some type of interface for users to enter
dates/times (to ensure they are converted to the correct UTC internal
format).

However, the real challenge here is that this is a very large piece of
work and it needs someone who is prepared to take it on. I suspect until
someone who needs to scratch this itch sufficiently comes along, this is
a feature which will be unlikely to make it to the top of the todo
list. There are simply far too many existing feature improvements and
additions people will prefer to work on before taking on this
one. Things are made more difficult because it isn't the sort of task
which can be achieved with small increments over time. This is more
likely to be something which needs to be developed in a feature branch,
which once it reaches a sufficient level of completeness can be used and 
verified working for a wide variety of environments before then working
out how to fold it back into the core system and handle whatever change
management will be necessary. 

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

[Daryl Manning]

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

I agree this is perhaps not a trivial undertaking. It really depends on the
quality of date and time libraries that exist in the lisp ecosystem. For
example, in Rust I found my timezone woes in one of my own apps were
trivial due to the chronos package, but likewise the reliance of Go
depending on its underlying time and date type actually introduced a weird
timezone and DST bug in my own app.

Is/are there lisp packages which handle the complexity involved in time and
date difference calculations and DST changes? That would perhaps be the
first question. It makes things tremendously easier and would reduce much
of the work (perhaps to just the argument of the format and parsing the
datetime stamp and making org-agenda aware of which timezone it's in.).

To Jean Louis' point: using timestamps without timezones is a don't in much
of computing these days and perhaps hearkens back to the simpler age emacs
and org originated in.  =]  (kidding!).

My lips-fu is not adequate to taking this on myself so the issue of who
would want ot work on it over other features is perhaps the bigger
question. Could someone scope out the work and approach at least. I imagine
it is tricky and non-trivial, but perhaps less complex if good libraries
exist as above.

I'd simply make the timezone format a slowly to be evolved to standard over
time with exceptions as noted in my first note. not having tz in timestamps
was a "assume local" assumption and under-specification (or considered
"hidden".).

Daryl.


On Fri, Jan 13, 2023 at 8:34 PM Tim Cross <theophilusx@gmail.com> wrote:

>
> Daryl Manning <daryl@wakatara.com> writes:
>
> > Following on from thread at
> https://www.reddit.com/r/orgmode/comments/zrppqw/
> >
> > [First off, I just wanted to say thank you to everyone that works on
> org-mode. It is a wonder.]
> >
> > While I realize a few kicks at this can may have been taken, I wanted to
> (re-)propose Timezone support in org-mode. The
> > world is much less local these days and we're all more remote and
> coordinating globally these days.
> >
> > *Background*
> >
> > 1. org-time-stamp-formats TZ currently only affects display and exports
> > 2. org-agenda itself is not TZ aware
> > 3. Several discussions on this have taken place over time
> > 4. Concerns raise included breaking backwards compatibility
> >
> > *Proposal*
> >
> > 1. org-mode sets an optional variable (org-timezone-aware t) which
> enables TZ
> > 2. org-agenda needs a way to determine which timezone it is in
> > 3. Once enabled, any timestamp not exhibiting a TZ in it is considered
> "local time" wherever that is (I do not think UTC
> > would work for this)
> > 4. org-agenda can calc local based on TZ differences
> >
> > I understand this is by no means trivial and quite gnarly with DST and
> such to figure out but I do believe libs exists to
> > deal with that heavy lifting. Currently, it does feel like a hole in
> org-mode as a 21st century organizer (disclaimer:
> > digital nomading so might feel it more keenly). Also, just interested in
> making org-mode a more awesome tool for
> > everybody.
> >
> > I'd love an understanding of the alluded to reservations raised in the
> reddit thread and in the mailing list threads
> > mentioned that the format change might break things (I was unsure if
> that was referring to say, how time ranges were
> > handled, or how say date ranges got dealt with (for example, say a
> flight from Singapore to Vancouver which takes off in
> > one time zone and lands in another - something that is often in my
> cal.).
> >
>
> I agree this would be a great feature to add. However, after having
> looked at it in some detail, I realise that not only is it not a trivial
> task, it is actually a very large and complex task and will require
> extensive work which will almost certainly result in breakage with
> regards to backwards compatibility.
>
> At the risk of over simplifying the matter, I would suggest the big
> challenge here is that there are two somewhat competing (and
> conflicting) use cases. On one hand, you want a high level abstraction
> which makes working with dates and times easy and clear. TO some extent,
> that is what we have now. On the other hand, we need something far more
> complex which is able to handle multiple time zones. This means being
> able to handle both base timezone offsets as well as offset adjustments
> for things like daylight savings time. There is a lot of hidden
> complexity here. You have to handle the fact that daylight saving
> chang-over dates/times are dynamic i.e. not necessarily the same every
> year. This adds the additional complexity of having to somehow track
> historical information regarding such changes, which isn't as readily
> accessible in a consistent manner on all platforms.
>
> Then there is the other 'messy' stuff. For example, when calculating
> time ranges and number of days, hours/ minutes between two dates you
> need to remember to add/remove the hour if the range crosses over a
> daylight savings period. Similarly you need to ensure you make the
> correct adjustment when changing timezones (consider emacs on a laptop
> for someone who travels a lot between different time zones). Not only do
> you need to take into account the different timezone offset, you also
> need to look at the date and then adjust according to the timezone
> offset for the current timezone at the time of the timestamp rather than
> just considering the current time offset.
>
> I expect what is needed is an 'internal' UTC based representation which
> is used for all calculations and an 'interface' layer, which converts
> the UTC representation into the local display representation for
> consumption by humans. The problem with this is that it is likely to
> break the core feature of org files i.e. that they are in plain text. I
> guess we could possibly do somehting clever with overlays such that UTC
> date/times are rendered/presented in local time format. However, we
> would then also require some type of interface for users to enter
> dates/times (to ensure they are converted to the correct UTC internal
> format).
>
> However, the real challenge here is that this is a very large piece of
> work and it needs someone who is prepared to take it on. I suspect until
> someone who needs to scratch this itch sufficiently comes along, this is
> a feature which will be unlikely to make it to the top of the todo
> list. There are simply far too many existing feature improvements and
> additions people will prefer to work on before taking on this
> one. Things are made more difficult because it isn't the sort of task
> which can be achieved with small increments over time. This is more
> likely to be something which needs to be developed in a feature branch,
> which once it reaches a sufficient level of completeness can be used and
> verified working for a wide variety of environments before then working
> out how to fold it back into the core system and handle whatever change
> management will be necessary.
>

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

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

[Jean Louis]

* Daryl Manning <daryl@wakatara.com> [2023-01-14 09:30]:
> To Jean Louis' point: using timestamps without timezones is a don't in much
> of computing these days and perhaps hearkens back to the simpler age emacs
> and org originated in.  =]  (kidding!).

I see it that way, yes. Isn't it so.

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

[Ihor Radchenko]

Tim Cross <theophilusx@gmail.com> writes:

> I agree this would be a great feature to add. However, after having
> looked at it in some detail, I realise that not only is it not a trivial
> task, it is actually a very large and complex task and will require
> extensive work which will almost certainly result in breakage with
> regards to backwards compatibility.

Not really. Our timestamp format, in fact, provides sufficient
flexibility to add extra metadata to timestamps.

In anticipation to add time zones in future, I have added the following
to the Org timestamp spec (see
https://orgmode.org/worg/org-syntax.html#Timestamps):

DATE TIME REPEATER-OR-DELAY

TIME (optional)
An instance of the pattern H:MMREST where H represents a one to two digit number (and can start with 0), and M represents a single digit. REST can contain anything but \n or closing bracket.

Note that REST imply that almost arbitrary suffix can be in TIME without
braking the existing Org timestamp parsing code.

REST, among other things may be
https://en.wikipedia.org/wiki/ISO_8601#Time_offsets_from_UTC or a valid
value of TZ POSIX variable. Exact details can be discussed.

Note that TZ should be fully supported by `encode-time' (ZONE):

(SECOND MINUTE HOUR DAY MONTH YEAR IGNORED DST ZONE)

We do not need to worry about internal representation and conversions
and simply rely on Emacs.

> At the risk of over simplifying the matter, I would suggest the big
> challenge here is that there are two somewhat competing (and
> conflicting) use cases. On one hand, you want a high level abstraction
> which makes working with dates and times easy and clear. TO some extent,
> that is what we have now. On the other hand, we need something far more
> complex which is able to handle multiple time zones. This means being
> able to handle both base timezone offsets as well as offset adjustments
> for things like daylight savings time. There is a lot of hidden
> complexity here. You have to handle the fact that daylight saving
> chang-over dates/times are dynamic i.e. not necessarily the same every
> year. This adds the additional complexity of having to somehow track
> historical information regarding such changes, which isn't as readily
> accessible in a consistent manner on all platforms.

We do not care about the details as long as Emacs can handle this. As
long as the user supplies DST and ZONE somehow, we can rely on Emacs'
support and system TZ implementation.

> Then there is the other 'messy' stuff. For example, when calculating
> time ranges and number of days, hours/ minutes between two dates you
> need to remember to add/remove the hour if the range crosses over a
> daylight savings period. Similarly you need to ensure you make the
> correct adjustment when changing timezones (consider emacs on a laptop
> for someone who travels a lot between different time zones). Not only do
> you need to take into account the different timezone offset, you also
> need to look at the date and then adjust according to the timezone
> offset for the current timezone at the time of the timestamp rather than
> just considering the current time offset.  

Again, we don't need to worry about this. Once we use `encode-time',
operations on time should just work. This is what we do anyway in most
of Org code.

> I expect what is needed is an 'internal' UTC based representation which
> is used for all calculations and an 'interface' layer, which converts
> the UTC representation into the local display representation for
> consumption by humans.

This is what we already to via `encode-time' and `decode-time'.
Check out `org-time-string-to-time'.

> However, the real challenge here is that this is a very large piece of
> work and it needs someone who is prepared to take it on. I suspect until
> someone who needs to scratch this itch sufficiently comes along, this is
> a feature which will be unlikely to make it to the top of the todo
> list. There are simply far too many existing feature improvements and
> additions people will prefer to work on before taking on this
> one. Things are made more difficult because it isn't the sort of task
> which can be achieved with small increments over time. This is more
> likely to be something which needs to be developed in a feature branch,
> which once it reaches a sufficient level of completeness can be used and 
> verified working for a wide variety of environments before then working
> out how to fold it back into the core system and handle whatever change
> management will be necessary. 

Not as much as you describe. Not small work either though.
Most of the machinery is already in place, except some leftover pieces
from early Org days.

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

[Daryl Manning]

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

Hey Ihor,

Sorry, I had a little trouble understanding the way you have the syntax
written in that timestamps doc.

Can you give an example like below? What does it look like?
And say, with a recurring data like once a week and a warning of 5d early?

I believe /most/ people would be looking for something grokable like:
<2023-01-14 Sat 18:22 SGT> or say
<2023-01-14 Sat 18:22 +08>
(tho I imagine the second example would break repeats syntax though)
primarily useful in TODOs etc.

Daryl.









On Sat, Jan 14, 2023 at 6:18 PM Ihor Radchenko <yantar92@posteo.net> wrote:

> Tim Cross <theophilusx@gmail.com> writes:
>
> > I agree this would be a great feature to add. However, after having
> > looked at it in some detail, I realise that not only is it not a trivial
> > task, it is actually a very large and complex task and will require
> > extensive work which will almost certainly result in breakage with
> > regards to backwards compatibility.
>
> Not really. Our timestamp format, in fact, provides sufficient
> flexibility to add extra metadata to timestamps.
>
> In anticipation to add time zones in future, I have added the following
> to the Org timestamp spec (see
> https://orgmode.org/worg/org-syntax.html#Timestamps):
>
> DATE TIME REPEATER-OR-DELAY
>
> TIME (optional)
> An instance of the pattern H:MMREST where H represents a one to two digit
> number (and can start with 0), and M represents a single digit. REST can
> contain anything but \n or closing bracket.
>
> Note that REST imply that almost arbitrary suffix can be in TIME without
> braking the existing Org timestamp parsing code.
>
> REST, among other things may be
> https://en.wikipedia.org/wiki/ISO_8601#Time_offsets_from_UTC or a valid
> value of TZ POSIX variable. Exact details can be discussed.
>
> Note that TZ should be fully supported by `encode-time' (ZONE):
>
> (SECOND MINUTE HOUR DAY MONTH YEAR IGNORED DST ZONE)
>
> We do not need to worry about internal representation and conversions
> and simply rely on Emacs.
>
> > At the risk of over simplifying the matter, I would suggest the big
> > challenge here is that there are two somewhat competing (and
> > conflicting) use cases. On one hand, you want a high level abstraction
> > which makes working with dates and times easy and clear. TO some extent,
> > that is what we have now. On the other hand, we need something far more
> > complex which is able to handle multiple time zones. This means being
> > able to handle both base timezone offsets as well as offset adjustments
> > for things like daylight savings time. There is a lot of hidden
> > complexity here. You have to handle the fact that daylight saving
> > chang-over dates/times are dynamic i.e. not necessarily the same every
> > year. This adds the additional complexity of having to somehow track
> > historical information regarding such changes, which isn't as readily
> > accessible in a consistent manner on all platforms.
>
> We do not care about the details as long as Emacs can handle this. As
> long as the user supplies DST and ZONE somehow, we can rely on Emacs'
> support and system TZ implementation.
>
> > Then there is the other 'messy' stuff. For example, when calculating
> > time ranges and number of days, hours/ minutes between two dates you
> > need to remember to add/remove the hour if the range crosses over a
> > daylight savings period. Similarly you need to ensure you make the
> > correct adjustment when changing timezones (consider emacs on a laptop
> > for someone who travels a lot between different time zones). Not only do
> > you need to take into account the different timezone offset, you also
> > need to look at the date and then adjust according to the timezone
> > offset for the current timezone at the time of the timestamp rather than
> > just considering the current time offset.
>
> Again, we don't need to worry about this. Once we use `encode-time',
> operations on time should just work. This is what we do anyway in most
> of Org code.
>
> > I expect what is needed is an 'internal' UTC based representation which
> > is used for all calculations and an 'interface' layer, which converts
> > the UTC representation into the local display representation for
> > consumption by humans.
>
> This is what we already to via `encode-time' and `decode-time'.
> Check out `org-time-string-to-time'.
>
> > However, the real challenge here is that this is a very large piece of
> > work and it needs someone who is prepared to take it on. I suspect until
> > someone who needs to scratch this itch sufficiently comes along, this is
> > a feature which will be unlikely to make it to the top of the todo
> > list. There are simply far too many existing feature improvements and
> > additions people will prefer to work on before taking on this
> > one. Things are made more difficult because it isn't the sort of task
> > which can be achieved with small increments over time. This is more
> > likely to be something which needs to be developed in a feature branch,
> > which once it reaches a sufficient level of completeness can be used and
> > verified working for a wide variety of environments before then working
> > out how to fold it back into the core system and handle whatever change
> > management will be necessary.
>
> Not as much as you describe. Not small work either though.
> Most of the machinery is already in place, except some leftover pieces
> from early Org days.
>
> --
> 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: 7299 bytes --]

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

[Ihor Radchenko]

Daryl Manning <daryl@wakatara.com> writes:

> Can you give an example like below? What does it look like?
> And say, with a recurring data like once a week and a warning of 5d early?
>
> I believe /most/ people would be looking for something grokable like:
> <2023-01-14 Sat 18:22 SGT> or say
> <2023-01-14 Sat 18:22 +08>
> (tho I imagine the second example would break repeats syntax though)
> primarily useful in TODOs etc.

For example,

<2023-01-14 Sat 18:22@Asia/Singapore>  (SGD and similar abbreviations are often ambiguous)
<2023-01-14 Sat 18:22+0800>
<2023-01-14 Sat 18:22+08>
<2023-01-14 Sat 18:22@+0800>
<2023-01-14 Sat 18:22@+08>

<2023-01-14 Sat 18:22@+08 +1w -5d>

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

[Max Nikulin]

On 14/01/2023 18:42, Ihor Radchenko wrote:
> 
> <2023-01-14 Sat 18:22@Asia/Singapore>  (SGD and similar abbreviations are often ambiguous)

Such format is ambiguous for timezones with DST around backward time 
jump. Before/after time transition should be specified in addition, e.g. 
by combining identifier and offset or some way to state namely before or 
after.

> <2023-01-14 Sat 18:22+0800>
> <2023-01-14 Sat 18:22+08>
> <2023-01-14 Sat 18:22@+0800>
> <2023-01-14 Sat 18:22@+08>

May become incorrect for future events due to updates of timezone database.

> <2023-01-14 Sat 18:22@+08 +1w -5d>

May be not suitable for time zones with DST since offset changes due to 
time transitions.

I am afraid, sometimes rather long (maybe even redundant) specification 
is required, so overlays becomes must have (as for links) to keep 
readability.

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

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

> On 14/01/2023 18:42, Ihor Radchenko wrote:
>> 
>> <2023-01-14 Sat 18:22@Asia/Singapore>  (SGD and similar abbreviations are often ambiguous)
>
> Such format is ambiguous for timezones with DST around backward time 
> jump. Before/after time transition should be specified in addition, e.g. 
> by combining identifier and offset or some way to state namely before or 
> after.

Are you referring to one hour in year when the clock is moved one hour
forward?

<2023-10-29 Sun 3:00@+DST/Europe/Berlin> -> (+1 minute)
<2023-10-29 Sun 2:01@-DST/Europe/Berlin>

I, however, do not feel like we need this +/-DST special notation.
Chances that one needs a timestamp in this specific hour are slim. At
the end, countries deliberately choose the time transition to not
interfere with business activity.

Instead, we can simply allow
https://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html
formats. All of them are supported by `encode-time' anyway.

At least, in theory.
I just tried:

(time-subtract
(encode-time 0 1 3 29 10 2023 nil -1 ":Europe/Berlin")
(encode-time 0 59 2 29 10 2023 nil -1 ":Europe/Berlin"))

(see https://www.timeanddate.com/time/zone/germany/berlin)

and it looks like the expected return value should be 1 hour 2 minutes
(3720), but it is not, on my system.

I am probably missing something though.

>> <2023-01-14 Sat 18:22+0800>
>> <2023-01-14 Sat 18:22+08>
>> <2023-01-14 Sat 18:22@+0800>
>> <2023-01-14 Sat 18:22@+08>
>
> May become incorrect for future events due to updates of timezone database.

Emm. No? +8 is offset from UTC. It will not be affected by anything.
Or are you referring to scenarios when user actually wants to specify the
timestamp for specific country/city? Then the TZ variant should be used
instead.

What I am essentially proposing in these examples is allowing:
1. TZ format as described in https://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html
2. ISO 8601 format https://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators

Of course, individual variants of time zone specs may be ambiguous
depending on the purpose. Users are to choose what they prefer

>> <2023-01-14 Sat 18:22@+08 +1w -5d>
>
> May be not suitable for time zones with DST since offset changes due to 
> time transitions.
>
> I am afraid, sometimes rather long (maybe even redundant) specification 
> is required, so overlays becomes must have (as for links) to keep 
> readability.

Not necessarily. Most of the timestamps can do just fine specifying
either explicit offset or a time zone name:

<2023-01-14 Sat 18:22@Asia/Singapore>
<2023-01-14 Sat 18:22+08>

More exotic scenarios will not be common.

And, if the users wish, we do have `org-time-stamp-custom-formats'.

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

[Max Nikulin]

On 15/01/2023 20:41, Ihor Radchenko wrote:
> Max Nikulin writes:
>> On 14/01/2023 18:42, Ihor Radchenko wrote:
>>>
>>> <2023-01-14 Sat 18:22@Asia/Singapore>  (SGD and similar abbreviations are often ambiguous)
>>
>> Such format is ambiguous for timezones with DST around backward time
>> jump. Before/after time transition should be specified in addition, e.g.
>> by combining identifier and offset or some way to state namely before or
>> after.
> 
> Are you referring to one hour in year when the clock is moved one hour
> forward?
> 
> <2023-10-29 Sun 3:00@+DST/Europe/Berlin> -> (+1 minute)
> <2023-10-29 Sun 2:01@-DST/Europe/Berlin>
> 
> I, however, do not feel like we need this +/-DST special notation.
> Chances that one needs a timestamp in this specific hour are slim. At
> the end, countries deliberately choose the time transition to not
> interfere with business activity.

Yes, I do not mind to be able to represent 2023-10-29 Sun 2:01 before 
and after transition in the Europe/Berlin timezone. Notice that Python 
developers chose "fold" instead of "DST" for argument and field name:
https://peps.python.org/pep-0495/
PEP 495 – Local Time Disambiguation

We should have this in mind, but I agree the priority is not highest one.

> I just tried:
> 
> (time-subtract
> (encode-time 0 1 3 29 10 2023 nil -1 ":Europe/Berlin")
> (encode-time 0 59 2 29 10 2023 nil -1 ":Europe/Berlin"))

Pass list to `encode-time', not separate values in Emacs >= 27, since 
this case DST is -1 (guess) it is not important, but generally the value 
is ignored. It is a pitfall in API.

> (see https://www.timeanddate.com/time/zone/germany/berlin)

You can inspect your local database
     zdump -v Europe/Berlin

> and it looks like the expected return value should be 1 hour 2 minutes
> (3720), but it is not, on my system.

it is assumed that you should explicitly specify DST to get another 
branch (but at first you should determine somehow at which side DST 
should be applied):

(let* ((tz "Europe/Berlin")
        (t1 (encode-time `(0 1 3 29 10 2023 nil nil ,tz)))
        (t2 (encode-time `(0 59 2 29 10 2023 nil t ,tz))))
   (list
    (format-time-string "%F %T %z %Z" t1 tz)
    (format-time-string "%F %T %z %Z" t2 tz)
    (time-subtract t1 t2)))
("2023-10-29 03:01:00 +0100 CET" "2023-10-29 02:59:00 +0200 CEST" 3720)

Actually behavior is more funny, but I need more time to investigate it 
more close.

The real problem with libc is that TZ DB contains time transitions 
preserving DST value and DST argument of `encode-time' becomes useless:

Europe/Kyiv  Sat Jun 30 21:59:59 1990 UT = Sun Jul  1 01:59:59 1990 MSD 
isdst=1 gmtoff=14400
Europe/Kyiv  Sat Jun 30 22:00:00 1990 UT = Sun Jul  1 01:00:00 1990 EEST 
isdst=1 gmtoff=10800

zdump -v Africa/Juba
...
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

>>> <2023-01-14 Sat 18:22@+08>
>>
>> May become incorrect for future events due to updates of timezone database.
> 
> Emm. No? +8 is offset from UTC. It will not be affected by anything.
> Or are you referring to scenarios when user actually wants to specify the
> timestamp for specific country/city? Then the TZ variant should be used
> instead.

Certainly events are usually associated with some area. I think, users 
will prefer concise +0800 notation to full timezone ID like 
Asia/Singapore and will get unexpected results sometimes. Manual should 
stress that fixing time offset is not a bright idea for planning.

> What I am essentially proposing in these examples is allowing:
> 1. TZ format as described in https://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html

Some formats may be confusing for users, e.g. TZ=GMT+5 actually means 
-0500 offset.

> 2. ISO 8601 format https://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators

I do not see IANA identifiers here. Moreover currently there is no API 
to get list of IANA identifiers. On windows additional mapping may be 
required:
https://unicode-org.github.io/cldr-staging/charts/37/supplemental/zone_tzid.html

I do not mind to fix timestamps in past by adding offsets like +0100. 
For planning timezone identifiers should be strongly preferred unless 
time is really fixed in respect to UTC.

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

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

>> Are you referring to one hour in year when the clock is moved one hour
>> forward?
>> 
>> <2023-10-29 Sun 3:00@+DST/Europe/Berlin> -> (+1 minute)
>> <2023-10-29 Sun 2:01@-DST/Europe/Berlin>
>> 
>> I, however, do not feel like we need this +/-DST special notation.
>> Chances that one needs a timestamp in this specific hour are slim. At
>> the end, countries deliberately choose the time transition to not
>> interfere with business activity.
>
> Yes, I do not mind to be able to represent 2023-10-29 Sun 2:01 before 
> and after transition in the Europe/Berlin timezone. Notice that Python 
> developers chose "fold" instead of "DST" for argument and field name:
> https://peps.python.org/pep-0495/
> PEP 495 – Local Time Disambiguation
>
> We should have this in mind, but I agree the priority is not highest one.

I think we could allow the "double zone" idea I mentioned in another
discussion branch:

<2023-10-29 Sun 3:00+0200@Europe/Berlin> -> (+1 minute)
<2023-10-29 Sun 2:01+0100@Europe/Berlin>

Because 2:01 will happen twice that day, it will also be possible to specify 

<2023-10-29 Sun 2:01+0200@Europe/Berlin>

I think it is more intuitive compared to DST/no DST.
And we do not even need to parse this scenario specially:

The variants of the TZ spec will be:

HH:MM@[^\n>\]]+
HH:MMZ
HH:MM[+-−][0-9]{2}\([0-9]{2}\)?
(note that I don't list times like 12:00+02:00 because it will interfere
with time range syntax 08:00-09:00 is a time range, but might also be
08:00-0900 time zone)

then, "@Europe/Berlin" in 2:01+0200@Europe/Berlin will be simply ignored
and we will use the explicit UTC offset.

>> I just tried:
>> 
>> (time-subtract
>> (encode-time 0 1 3 29 10 2023 nil -1 ":Europe/Berlin")
>> (encode-time 0 59 2 29 10 2023 nil -1 ":Europe/Berlin"))
>
> Pass list to `encode-time', not separate values in Emacs >= 27, since 
> this case DST is -1 (guess) it is not important, but generally the value 
> is ignored. It is a pitfall in API.

I see. This is not the only pitfall though.

I just discussed the same issue with Tecosaur, and he noted
that <2023-10-29 2:59@Europe/Berlin> is ambiguous because 2:59 occurs
twice during that day:

  2:59 -> 3:00 (DST -1 hour transition) -> 2:01 -> ... -> 2:59 -> 3:00 -> 3:01

The fact that `encode-time' chose 2:59 after the transition is
implementation detail.

To deal with such cases, we may provide org-lint checker that will
compare timestamps with t and nil DST parameter for `encode-time' and
warn if there is a difference.

(encode-time '(0 59 2 29 10 2023 nil -1 ":Europe/Berlin")) ; => (25917 44628)
(encode-time '(0 59 2 29 10 2023 nil t ":Europe/Berlin")) ; => (25917 44!628) (same)
(encode-time '(0 59 2 29 10 2023 nil nil ":Europe/Berlin")) ; => (25917 48!!228) (different)

(encode-time 0 59 2 29 10 2023 nil -1 ":Europe/Berlin") ; => (25917 48!!228)
(encode-time 0 59 2 29 10 2023 nil t ":Europe/Berlin") ; same
(encode-time 0 59 2 29 10 2023 nil nil ":Europe/Berlin") ; same

So, there is a gotcha with `encode-time' API, and we must use the list
argument. (This gotcha is described in the docstring, but in rather
cryptic way)

>>>> <2023-01-14 Sat 18:22@+08>
>>>
>>> May become incorrect for future events due to updates of timezone database.
>> 
>> Emm. No? +8 is offset from UTC. It will not be affected by anything.
>> Or are you referring to scenarios when user actually wants to specify the
>> timestamp for specific country/city? Then the TZ variant should be used
>> instead.
>
> Certainly events are usually associated with some area. I think, users 
> will prefer concise +0800 notation to full timezone ID like 
> Asia/Singapore and will get unexpected results sometimes. Manual should 
> stress that fixing time offset is not a bright idea for planning.

Sure. Having per-file/heading time zone settings will also help.

I don't think that people will mind _occasional_ timestamps having
Asia/Singapore. I'd personally prefer this kind of verbosity for
overseas remote events.

>> What I am essentially proposing in these examples is allowing:
>> 1. TZ format as described in https://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html
>
> Some formats may be confusing for users, e.g. TZ=GMT+5 actually means 
> -0500 offset.

Let's just recommend +-XXXX and @location in the manual. And mention
briefly that TZ format is supported in addition.

We might also provide an optional linter for GMT, if necessary.

>> 2. ISO 8601 format https://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators
>
> I do not see IANA identifiers here. Moreover currently there is no API 
> to get list of IANA identifiers. On windows additional mapping may be 
> required:
> https://unicode-org.github.io/cldr-staging/charts/37/supplemental/zone_tzid.html
>
> I do not mind to fix timestamps in past by adding offsets like +0100. 
> For planning timezone identifiers should be strongly preferred unless 
> time is really fixed in respect to UTC.

Could you please elaborate? I don't fully understand what you are
referring to.

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

[Max Nikulin]

On 17/01/2023 01:37, Ihor Radchenko wrote:
>> Some formats may be confusing for users, e.g. TZ=GMT+5 actually means
>> -0500 offset.
> Let's just recommend +-XXXX and @location in the manual. And mention
> briefly that TZ format is supported in addition.
> 
> We might also provide an optional linter for GMT, if necessary.

"GMT" in this example is an arbitrary string. It adds some complications 
to the linter.

Notice that in POSIX "GMT+5" is *definition* of timezone with "GMT" 
abbreviation and shifted by 5 hours to the west. It is not a *reference* 
to IANA (Olson) Etc/GMT+5. I do not remember concerning "GMT", but Qt 
allows to use something like "UTC+5" (east like IANA, not west like 
POSIX). I am unsure concerning Windows, it may have an option of quite 
similar variant. That is why I am not sure to which degree Org should be 
liberal in respect to various time zones.

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

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

> ... I am unsure concerning Windows, it may have an option of quite 
> similar variant. That is why I am not sure to which degree Org should be 
> liberal in respect to various time zones.

May we just support whatever TZ supports (POSIX)?

I was also thinking about ISO 8601, but it interferes with time ranges
(4:00-8:00 may be both "from 2am to 8am" and "4am UTC-08"). Though other
ISO 8601 variants like 4:00-0800 might work.

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

[Jean Louis]

* Ihor Radchenko <yantar92@posteo.net> [2023-01-18 13:01]:
> Max Nikulin <manikulin@gmail.com> writes:
> 
> > ... I am unsure concerning Windows, it may have an option of quite 
> > similar variant. That is why I am not sure to which degree Org should be 
> > liberal in respect to various time zones.
> 
> May we just support whatever TZ supports (POSIX)?

Yes, not too much. It is impossible.

I would say this way, if user does not like Org task management
without time zones, go and find other one without Org. Simple.

Org does not have foundation where you can even think of complexities
discussed here.

-- 
Jean

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

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

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

[Jean Louis]

Just leave it out and let Org be single user, single time zone system.

You can't make the impossible. It is not database for sensitive work.

Let it be text.

If they want to convert to their time zone, let them do the home work.

If they don't want to use Org for timestamps, like me, let them be.

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

[Ihor Radchenko]

Ihor Radchenko <yantar92@posteo.net> writes:

> <2023-01-14 Sat 18:22@Asia/Singapore>  (SGD and similar abbreviations are often ambiguous)
> <2023-01-14 Sat 18:22+0800>
> <2023-01-14 Sat 18:22+08>
> <2023-01-14 Sat 18:22@+0800>
> <2023-01-14 Sat 18:22@+08>

One thing we all missed in the discussion is diary sexps.

In particular, "last Sunday of month" <%%(diary-float t 0)> may depend
on the time zone because the number of days in month may vary.

How can we approach this? What could the format to specify the time zone
for diary timestamps?

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

[Daryl Manning]

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

Perhaps a leading question (leading to outrage =p ), but does anybody even
use those anymore?

I don't believe I've used them at all in 5 years of using org-mode (and if
I did it was most likely because of some arcane older feature which
required them).

Daryl.

On Fri, Jan 20, 2023 at 5:57 PM Ihor Radchenko <yantar92@posteo.net> wrote:

> Ihor Radchenko <yantar92@posteo.net> writes:
>
> > <2023-01-14 Sat 18:22@Asia/Singapore>  (SGD and similar abbreviations
> are often ambiguous)
> > <2023-01-14 Sat 18:22+0800>
> > <2023-01-14 Sat 18:22+08>
> > <2023-01-14 Sat 18:22@+0800>
> > <2023-01-14 Sat 18:22@+08>
>
> One thing we all missed in the discussion is diary sexps.
>
> In particular, "last Sunday of month" <%%(diary-float t 0)> may depend
> on the time zone because the number of days in month may vary.
>
> How can we approach this? What could the format to specify the time zone
> for diary timestamps?
>
> --
> 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: 1949 bytes --]

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

[Ihor Radchenko]

Daryl Manning <daryl@wakatara.com> writes:

> Perhaps a leading question (leading to outrage =p ), but does anybody even
> use those anymore?
>
> I don't believe I've used them at all in 5 years of using org-mode (and if
> I did it was most likely because of some arcane older feature which
> required them).

diary exps is the only available way to limit the number of repetitions
of an even.

Also, see org-class, which will automatically skips holidays (let's just
ignore the issue with time zones and holidays, please; just accept the
limitation)

Some real word examples of diary sexps scheduling in the wild:
- https://emacs-apac.gitlab.io/ :: <%%(diary-float t 6 4)>
- https://emacs-berlin.org/ :: <%%(diary-float t 3 -1)>

Finally, religious holidays can be defined and Nth weekday before/after
month/date.

Some people even use diary sexps exclusively.

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

[Daryl Manning]

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

I just usually put those in the cal manually, with a date if they have
"unusual" recurrences that can;t be denoted by the standard datestamp
recurrences . =]

Though for religious holidays like Easter and, I imagine, some lunar based
ones, I imagine it might be handy. But honestly, I am surprised people use
them anymore. I certainly have managed to avoid them up to now. They feel
slightly anachronistic (much like putting in dates without timezones... =]
).

D.

On Fri, Jan 20, 2023 at 6:36 PM Ihor Radchenko <yantar92@posteo.net> wrote:

> Daryl Manning <daryl@wakatara.com> writes:
>
> > Perhaps a leading question (leading to outrage =p ), but does anybody
> even
> > use those anymore?
> >
> > I don't believe I've used them at all in 5 years of using org-mode (and
> if
> > I did it was most likely because of some arcane older feature which
> > required them).
>
> diary exps is the only available way to limit the number of repetitions
> of an even.
>
> Also, see org-class, which will automatically skips holidays (let's just
> ignore the issue with time zones and holidays, please; just accept the
> limitation)
>
> Some real word examples of diary sexps scheduling in the wild:
> - https://emacs-apac.gitlab.io/ :: <%%(diary-float t 6 4)>
> - https://emacs-berlin.org/ :: <%%(diary-float t 3 -1)>
>
> Finally, religious holidays can be defined and Nth weekday before/after
> month/date.
>
> Some people even use diary sexps exclusively.
>
> --
> 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: 2644 bytes --]

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

[Fraga, Eric]

On Friday, 20 Jan 2023 at 18:29, Daryl Manning wrote:
> Perhaps a leading question (leading to outrage =p ), but does anybody
> even use those anymore?

Yes.  I use them for repeating events, in particular those which have
repeating rules like "the first Monday of every month" that org does not
support.

However, having said this, I don't think it's org's responsibility to
address the Emacs Diary: that would be a feature request for Emacs more
generally...

-- 
: Eric S Fraga, with org release_9.6-201-gb58fba in Emacs 30.0.50

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

[Ihor Radchenko]

"Fraga, Eric" <e.fraga@ucl.ac.uk> writes:

> However, having said this, I don't think it's org's responsibility to
> address the Emacs Diary: that would be a feature request for Emacs more
> generally...

Well. Diary sexps do not support time. So, we may already need to add
time info to diary sexps (at least, it is partially supported
by agenda). But if we add time support, the time stamp question also
arises.

Of course, more generally, there is also a question of things like
calendar displaying time in different time zone (for example, when
choosing timestamp date and time in `org-read-date').

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

[Jean Louis]

* Ihor Radchenko <yantar92@posteo.net> [2023-01-20 14:50]:
> Of course, more generally, there is also a question of things like
> calendar displaying time in different time zone (for example, when
> choosing timestamp date and time in `org-read-date').

Also consider that calendar has these options

(setq calendar-location-name
(setq calendar-latitude 
(setq calendar-longitude 
(setq calendar-standard-time-zone-name 
(setq calendar-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: [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-01-20 14:50]:
>> Of course, more generally, there is also a question of things like
>> calendar displaying time in different time zone (for example, when
>> choosing timestamp date and time in `org-read-date').
>
> Also consider that calendar has these options
>
> (setq calendar-location-name
> (setq calendar-latitude 
> (setq calendar-longitude 
> (setq calendar-standard-time-zone-name 
> (setq calendar-time-zone 

Thanks!

32.7 Times of Sunrise and Sunset section of Emacs manual is relevant.
Also, 32.11 Daylight Saving Time. Note that the DST rules appear to be
manual instead of being automatically determined from the TZDB.
Though proper TZDB support is probably something we may eventually need
to ask upstream.

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

[Ihor Radchenko]

"Fraga, Eric" <e.fraga@ucl.ac.uk> writes:

> However, having said this, I don't think it's org's responsibility to
> address the Emacs Diary: that would be a feature request for Emacs more
> generally...

I looked into this further and I note that
`calendar-absolute-from-gregorian' does not account for time zones at
all:

          ((> year 0)
           (setq offset-years (1- year))
           (+ (calendar-day-number date) ; days this year
              (* 365 offset-years)       ; + days in prior years
              (/ offset-years 4)         ; + Julian leap years
              (- (/ offset-years 100))   ; - century years
              (/ offset-years 400)))     ; + Gregorian leap years

Diary sexps are using this function frequently.
In fact, Org also does use this function frequently.

Probably, the only sane way to address all the pitfalls with time zones
while using calendar functions is first converting the date to UTC
before passing it to diary sexps and calendar functions. I hope that UTC
is at least not affected by all the crazy time transitions various time
zones have.

Though I am not sure about the calendar displayed alongside the
`org-read-date'. It ought to be in local time zone, but the above means
that not everything is accounted for by Emacs calendar.

Also, agenda. Things like `org-extend-today-until' may be dramatically
affected if we try to convert things to UTC.

Or should we just bite the bullet and use "local" time zone for agenda
calculations and calendars? It will not be accurate, but I am afraid
that rewriting agenda to support UTC is going to transform into
rewriting agenda completely + rewriting Emacs diary.

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

[Max Nikulin]

On 21/01/2023 16:21, Ihor Radchenko wrote:
> 
> I looked into this further and I note that
> `calendar-absolute-from-gregorian' does not account for time zones at
> all:
> 
>            ((> year 0)
>             (setq offset-years (1- year))
>             (+ (calendar-day-number date) ; days this year
>                (* 365 offset-years)       ; + days in prior years
>                (/ offset-years 4)         ; + Julian leap years
>                (- (/ offset-years 100))   ; - century years
>                (/ offset-years 400)))     ; + Gregorian leap years
> 
> Diary sexps are using this function frequently.
> In fact, Org also does use this function frequently.

I have not look into this package yet, so I can not comment it.

Should we summon Paul Eggert?
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54764#10
Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list
  argument optional ones Sat, 9 Apr 2022 00:52:57 -0700
> Generally speaking, 
> when Org mode is doing calendrical calculations it should use 
> calendrical functions rather than encode-time+decode-time, which are 
> best used for time calculations not calendar calculations.

On 21/01/2023 16:21, Ihor Radchenko wrote:
> Probably, the only sane way to address all the pitfalls with time zones
> while using calendar functions is first converting the date to UTC
> before passing it to diary sexps and calendar functions. I hope that UTC
> is at least not affected by all the crazy time transitions various time
> zones have.

It may be tricky to get start of day / end of day or advance timestamp 
by given number of days having timestamp as seconds since epoch. If you 
mean broken-down time representation in UTC then I am unsure which way 
you are going to handle skipped 2011-12-30 case, since dates in UTC are 
rather regular.

> but I am afraid
> that rewriting agenda to support UTC is going to transform into
> rewriting agenda completely + rewriting Emacs diary.

I still suspect that to implement timezone support in Org it will be 
necessary to create a custom library to handle zoneinfo files.

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

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

>> Diary sexps are using this function frequently.
>> In fact, Org also does use this function frequently.
>
> I have not look into this package yet, so I can not comment it.
>
> Should we summon Paul Eggert?
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54764#10
> Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list
>   argument optional ones Sat, 9 Apr 2022 00:52:57 -0700

I am not sure. Maybe. The package in question is calendar. I can see
that Paul is the author of cal-dst.el. So, he might provide some
insights and non-obvious gotchas.

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

Daryl Manning <daryl@wakatara.com> writes:

> Perhaps a leading question (leading to outrage =p ), but does anybody even use those anymore? 
>
> I don't believe I've used them at all in 5 years of using org-mode (and if I did it was most likely because of
> some arcane older feature which required them). 
>
> Daryl. 
>
> On Fri, Jan 20, 2023 at 5:57 PM Ihor Radchenko <yantar92@posteo.net> wrote:
>
>  Ihor Radchenko <yantar92@posteo.net> writes:
>
>  > <2023-01-14 Sat 18:22@Asia/Singapore>  (SGD and similar abbreviations are often ambiguous)
>  > <2023-01-14 Sat 18:22+0800>
>  > <2023-01-14 Sat 18:22+08>
>  > <2023-01-14 Sat 18:22@+0800>
>  > <2023-01-14 Sat 18:22@+08>
>
>  One thing we all missed in the discussion is diary sexps.
>
>  In particular, "last Sunday of month" <%%(diary-float t 0)> may depend
>  on the time zone because the number of days in month may vary.
>
>  How can we approach this? What could the format to specify the time zone
>  for diary timestamps?
>
>  -- 
>  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>

If your speaking about diary sexp support, I don't use them, but I have
seen a number of threads within the last year regarding people wanting
assistance with getting them right and I get the impression for some use
cases, particularly for repeating events, diary seexp specification is
the easiest way to define them.

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:
>
>> I agree this would be a great feature to add. However, after having
>> looked at it in some detail, I realise that not only is it not a trivial
>> task, it is actually a very large and complex task and will require
>> extensive work which will almost certainly result in breakage with
>> regards to backwards compatibility.
>
> Not really. Our timestamp format, in fact, provides sufficient
> flexibility to add extra metadata to timestamps.
>
> In anticipation to add time zones in future, I have added the following
> to the Org timestamp spec (see
> https://orgmode.org/worg/org-syntax.html#Timestamps):
>
> DATE TIME REPEATER-OR-DELAY
>
> TIME (optional)
> An instance of the pattern H:MMREST where H represents a one to two digit number (and can
> start with 0), and M represents a single digit. REST can contain anything but \n or
> closing bracket.
>
> Note that REST imply that almost arbitrary suffix can be in TIME without
> braking the existing Org timestamp parsing code.
>
> REST, among other things may be
> https://en.wikipedia.org/wiki/ISO_8601#Time_offsets_from_UTC or a valid
> value of TZ POSIX variable. Exact details can be discussed.
>
> Note that TZ should be fully supported by `encode-time' (ZONE):
>
> (SECOND MINUTE HOUR DAY MONTH YEAR IGNORED DST ZONE)
>
> We do not need to worry about internal representation and conversions
> and simply rely on Emacs.
>
>> At the risk of over simplifying the matter, I would suggest the big
>> challenge here is that there are two somewhat competing (and
>> conflicting) use cases. On one hand, you want a high level abstraction
>> which makes working with dates and times easy and clear. TO some extent,
>> that is what we have now. On the other hand, we need something far more
>> complex which is able to handle multiple time zones. This means being
>> able to handle both base timezone offsets as well as offset adjustments
>> for things like daylight savings time. There is a lot of hidden
>> complexity here. You have to handle the fact that daylight saving
>> chang-over dates/times are dynamic i.e. not necessarily the same every
>> year. This adds the additional complexity of having to somehow track
>> historical information regarding such changes, which isn't as readily
>> accessible in a consistent manner on all platforms.
>
> We do not care about the details as long as Emacs can handle this. As
> long as the user supplies DST and ZONE somehow, we can rely on Emacs'
> support and system TZ implementation.
>
>> Then there is the other 'messy' stuff. For example, when calculating
>> time ranges and number of days, hours/ minutes between two dates you
>> need to remember to add/remove the hour if the range crosses over a
>> daylight savings period. Similarly you need to ensure you make the
>> correct adjustment when changing timezones (consider emacs on a laptop
>> for someone who travels a lot between different time zones). Not only do
>> you need to take into account the different timezone offset, you also
>> need to look at the date and then adjust according to the timezone
>> offset for the current timezone at the time of the timestamp rather than
>> just considering the current time offset.  
>
> Again, we don't need to worry about this. Once we use `encode-time',
> operations on time should just work. This is what we do anyway in most
> of Org code.
>
>> I expect what is needed is an 'internal' UTC based representation which
>> is used for all calculations and an 'interface' layer, which converts
>> the UTC representation into the local display representation for
>> consumption by humans.
>
> This is what we already to via `encode-time' and `decode-time'.
> Check out `org-time-string-to-time'.
>
>> However, the real challenge here is that this is a very large piece of
>> work and it needs someone who is prepared to take it on. I suspect until
>> someone who needs to scratch this itch sufficiently comes along, this is
>> a feature which will be unlikely to make it to the top of the todo
>> list. There are simply far too many existing feature improvements and
>> additions people will prefer to work on before taking on this
>> one. Things are made more difficult because it isn't the sort of task
>> which can be achieved with small increments over time. This is more
>> likely to be something which needs to be developed in a feature branch,
>> which once it reaches a sufficient level of completeness can be used and 
>> verified working for a wide variety of environments before then working
>> out how to fold it back into the core system and handle whatever change
>> management will be necessary. 
>
> Not as much as you describe. Not small work either though.
> Most of the machinery is already in place, except some leftover pieces
> from early Org days.

Hi Ihor,

I think you may only be looking at the representation and not
considering the actual mechanics which will be required to make this all
work.

Consider for example an agenda file where the TODO items have been added
while I am here in Australia (currently +11:00 w/ DST). Tomorrow I fly
to Europe where I will be working for the next 6 weeks. I need all my
TODOs with active timestamps to be updated to Berlin's TZ. How does this
work?

The representation of the timestamps is the easy part. It is the
management, display, calculations, etc where the complications
arise. From looking at the supported time related functions in Emacs,
while most of the key ones do have support for passing in time zone
data, there seems little (if any) code to support the lookup and
retrieval of time zone data - in particular, ability to lookup time zone
data for a specific date, not just a location.

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

[Ihor Radchenko]

Tim Cross <theophilusx@gmail.com> writes:

> Consider for example an agenda file where the TODO items have been added
> while I am here in Australia (currently +11:00 w/ DST). Tomorrow I fly
> to Europe where I will be working for the next 6 weeks. I need all my
> TODOs with active timestamps to be updated to Berlin's TZ. How does this
> work?

I am not sure what is the problem.
The timestamps that should stay in local time will be automatically
updated as your system TZ is updated.
The timestamps that should be tied to specific time zone will specify
that required time zone and will thus remain functional.

> The representation of the timestamps is the easy part. It is the
> management, display, calculations, etc where the complications
> arise. From looking at the supported time related functions in Emacs,
> while most of the key ones do have support for passing in time zone
> data, there seems little (if any) code to support the lookup and
> retrieval of time zone data - in particular, ability to lookup time zone
> data for a specific date, not just a location.

But why do we need any time zone data? All we need to converting from
and to internal Emacs' time representation supplying the correct time
zone to it.

Or are you trying to get an agenda where you plan to change the time
zone in the middle? That's indeed a tricky problem, but it is even
solved by any existing calendar app? Do we need to solve it?

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

[Jean Louis]

* Ihor Radchenko <yantar92@posteo.net> [2023-01-14 16:23]:
> But why do we need any time zone data? All we need to converting from
> and to internal Emacs' time representation supplying the correct time
> zone to it.

When Org file is very personal and location centric, then there is no
need for it.

When Org file has assigned, shared tasks, and is related to other
people in various locations over the world, then it becomes important.

And when people travel from place to place they change time zones. You
changed it personally I bet, sometimes, did you? But as your work is
very personal it does not matter.

A record in Org file must be Org specific record. I guess that with
the general timezone property, such Org file, provided it has all the
same time zone, can have that specific time zone, and if shared to
somebody in other zone, that other person will see accurate time.

Because Org is very much single user centric for majority will not
matter really.

I can just imagine person in Brazil writing time zone records, so it
makes sense to know in which time zone that record was done, as if
somebody reads it in India, it will make less sense and it could cause
confusion.

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

[Ihor Radchenko]

Jean Louis <bugs@gnu.support> writes:

> * Ihor Radchenko <yantar92@posteo.net> [2023-01-14 16:23]:
>> But why do we need any time zone data? All we need to converting from
>> and to internal Emacs' time representation supplying the correct time
>> zone to it.
>
> When Org file is very personal and location centric, then there is no
> need for it.
>
> When Org file has assigned, shared tasks, and is related to other
> people in various locations over the world, then it becomes important.

Sorry, I think you misunderstood what I am saying here.

I was referring to a need for Org code to retrieve some kind of
timezone-specific data other than converting timestamps with time zone to
and back from the internal time representation.

In another message, I also mentioned an idea of specifying time zone
globally or per file. Other suggestion was per-heading specification. In
addition to time zone being specified directly inside the timestamp.

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

[Daryl Manning]

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

I think timezone you're in should be declared globally, surely?  And then
defined in the timestamp?

The use cases for per file or even per-heading tz specifying seems very low
imho (and introducing a lot more complexity.).

Daryl.

On Mon, Jan 16, 2023 at 6:20 PM Ihor Radchenko <yantar92@posteo.net> wrote:

> Jean Louis <bugs@gnu.support> writes:
>
> > * Ihor Radchenko <yantar92@posteo.net> [2023-01-14 16:23]:
> >> But why do we need any time zone data? All we need to converting from
> >> and to internal Emacs' time representation supplying the correct time
> >> zone to it.
> >
> > When Org file is very personal and location centric, then there is no
> > need for it.
> >
> > When Org file has assigned, shared tasks, and is related to other
> > people in various locations over the world, then it becomes important.
>
> Sorry, I think you misunderstood what I am saying here.
>
> I was referring to a need for Org code to retrieve some kind of
> timezone-specific data other than converting timestamps with time zone to
> and back from the internal time representation.
>
> In another message, I also mentioned an idea of specifying time zone
> globally or per file. Other suggestion was per-heading specification. In
> addition to time zone being specified directly inside the timestamp.
>
> --
> 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: 2334 bytes --]

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

[Ihor Radchenko]

Daryl Manning <daryl@wakatara.com> writes:

> I think timezone you're in should be declared globally, surely?  And then
> defined in the timestamp?

It is always defined globally on OS level. In POSIX-complaint OSes, it is
TZ. Emacs obeys POSIX and time zone settings in other OSes. We don't
need anything special for it.

As for time zone in timestamps - it must be optional. Timestamps with
time zone will use that time zone. Timestamps without time zone will use
"default" time zone - be it OS time zone or whatever custom time zone
setting we come up with in future. This "default" time zone approach is
both useful for things like "brush teeth in 10pm in the evening" and
also, more importantly, for backwards compatibility.

> The use cases for per file or even per-heading tz specifying seems very low
> imho (and introducing a lot more complexity.).

Sure. As I mentioned in another message, not having these features should
not stop us from merging whatever working time zone code we can come up
with. They will be nice to have though.

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

[Daryl Manning]

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

I agree... TZ is optionally defined in a timestamp otherwise understood to
be "local".

I'd just be excited to have us run through the basic use cases and then see
some more "tricky" ones. I imagine there are things we'd just have to
say... too tricky for (eg. flight takes off in one TZ and range allows it
to land in timezone... stuff like that might be tricky.).

So, is the TS syntax you've described accepted and canonical now with
org-mode?

Daryl.



On Mon, Jan 16, 2023 at 6:39 PM Ihor Radchenko <yantar92@posteo.net> wrote:

> Daryl Manning <daryl@wakatara.com> writes:
>
> > I think timezone you're in should be declared globally, surely?  And then
> > defined in the timestamp?
>
> It is always defined globally on OS level. In POSIX-complaint OSes, it is
> TZ. Emacs obeys POSIX and time zone settings in other OSes. We don't
> need anything special for it.
>
> As for time zone in timestamps - it must be optional. Timestamps with
> time zone will use that time zone. Timestamps without time zone will use
> "default" time zone - be it OS time zone or whatever custom time zone
> setting we come up with in future. This "default" time zone approach is
> both useful for things like "brush teeth in 10pm in the evening" and
> also, more importantly, for backwards compatibility.
>
> > The use cases for per file or even per-heading tz specifying seems very
> low
> > imho (and introducing a lot more complexity.).
>
> Sure. As I mentioned in another message, not having these features should
> not stop us from merging whatever working time zone code we can come up
> with. They will be nice to have though.
>
> --
> 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: 2743 bytes --]

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

[Ihor Radchenko]

Daryl Manning <daryl@wakatara.com> writes:

> I'd just be excited to have us run through the basic use cases and then see
> some more "tricky" ones. I imagine there are things we'd just have to
> say... too tricky for (eg. flight takes off in one TZ and range allows it
> to land in timezone... stuff like that might be tricky.).

https://www.youtube.com/watch?v=-5wpm-gesOY gives various examples.
To summarize:

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

2. There might be arbitrary time gaps due to time transition, including
   time overlaps with the same time of the day happening multiple time a
   day:
   - One hour back during DST transition (northern and southern
     hemispheres do the transitions in opposite directions)
   - Multiple days skipped (Samoa skips a whole day during DST
     transition)
   - Great Britain used 2 hours DST offset during WWII
   - Julian/Gregorian calendar transitions in the past

3. We cannot assume that the same geographical area has fixed time zone
   even at given point of time:
   - Palestinian/Israeli people follow different time zones in the
     contested territories

4. Great Britain had new year on March 25 until 16th century
   (March 24, 1000 -> (+1 day) March 25, 1001)

5. Leap seconds! 23:59:59 -> 23:59:60 -> 00:00:00, according to
   astronomical Earth observations

> So, is the TS syntax you've described accepted and canonical now with
> org-mode?

We are still discussing it.

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

[Robert Horn]

Ihor Radchenko <yantar92@posteo.net> writes:

> https://www.youtube.com/watch?v=-5wpm-gesOY gives various examples.
> To summarize:
>
> 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.

> 5. Leap seconds! 23:59:59 -> 23:59:60 -> 00:00:00, according to
>    astronomical Earth observations
>

Fortunately, the most recent vote reached majority for eliminating leap
seconds, hopefully within 8 years.

-- 
Robert Horn
rjhorn@alum.mit.edu

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

[Ihor Radchenko]

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.

>> 5. Leap seconds! 23:59:59 -> 23:59:60 -> 00:00:00, according to
>>    astronomical Earth observations
>
> Fortunately, the most recent vote reached majority for eliminating leap
> seconds, hopefully within 8 years.

But we will have to keep supporting all the leap seconds that already
happened! So it does not really help all that much wrt timestamp
design.

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

[Robert Horn]

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

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

[Tom Gillespie]

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

This is related to why I suggested splitting timezones and offsets into
two separate categories. I think we have to assume that the written
content of timestamps in an org file cannot/will-not be changed
automatically.

Therefore if the timezone is specified then the numbers will never
change, but the actual time might if the timezone spec changes.

If an offset is used then it will not account for changes due
to DST, but it will always remain stable, shuffling a meeting an hour
one way or the other at some points in the year, which is usually
undesirable compared to say, shuffling a meeting 1 hour in one
direction for people who are not in the defining timezone for the
duration of the mismatch between DST changes in different regions.

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

[Robert Horn]

Tom Gillespie <tgbugs@gmail.com> writes:

>> 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.
>
> This is related to why I suggested splitting timezones and offsets into
> two separate categories. I think we have to assume that the written
> content of timestamps in an org file cannot/will-not be changed
> automatically.
>

The solution that we used in an operational scheduling system was to
invent a new family of time zones, the "Then Local Time There".  So you
would schedule something like "10:05 TLT (NorthAmerica/New York)".  This
was the most commonly used scheduled time.  It's what most people mean
when they schedule something.  Then the scheduled time encoding did not
change, but the displayed time could.  It was displayed in a format that
met the needs of the users.  When you're dealing with people in many
locations you need to separate the concept of scheduled time in the org
file from the concept of time display in a format useful to the user.

Those who wanted astronomical or other relationships would usually
specify UTC or TAI.  They might use a fixed offset for UTC.  People who
are into the demands of TAI (e.g., orbital mechanics) generally don't
want to deal with the offsets or other issues that come up with UTC, so
they wanted TAI.

-- 
Robert Horn
rjhorn@alum.mit.edu

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

[Ihor Radchenko]

Robert Horn <rjhorn@panix.com> writes:

> Those who wanted astronomical or other relationships would usually
> specify UTC or TAI.  They might use a fixed offset for UTC.  People who
> are into the demands of TAI (e.g., orbital mechanics) generally don't
> want to deal with the offsets or other issues that come up with UTC, so
> they wanted TAI.

Unless time zone database supports TAI, we cannot support it.
Does someone know if TAI is available somewhere in TZdb?

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

[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

[Thomas S. Dye]

Aloha all,

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?

Meetings are occurrences, which require absolute time, which has 
no timezones.  Org should record occurrences with timestamps in 
UTC, possibly translating from the user's local time.

>
> Org in this state can't handle such things.

Org can do the useful thing: translate the UTC timestamp into 
local time and report both UTC and local time.  User will be able 
quickly to determine if local time is incorrect for some reason, 
such as DST or travel.

Storing timestamps in UTC solves the interval problem Ihor raised. 
Intervals always make sense in absolute time.  Moving them to 
event time leads to the insanity Ihor mentioned.

hth,
Tom

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


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

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

[Jean Louis]

* Thomas S. Dye <tsd@tsdye.online> [2023-01-19 09:37]:
> Meetings are occurrences, which require absolute time, which has no
> timezones.  Org should record occurrences with timestamps in UTC,
> possibly translating from the user's local time.

User in Grece needs appointment at 9 o'clock, and writes it as:
<2023-01-20 Fri 09:00> He also has TIMEZONE (either system or Org file
based) set to "EET". That way the time has been recorded in UTC for
Org purposes, and UTC has been solved. For Greek user it is completely
solved. Org calculates UTC based on configured time zone. But when it
is 16:00 o'clock in Greece, it is 06:00 in Seattle.

Online appointment is sent to user in Seattle, with the time zone
PST. He receives the Org file from Greece, at 8:00 o'clock, which has
settings inside TIMEZONE="EET". At first user thinks that appointment
is in just 1 hour, because he can see "08:00", but Org gracefully
notifies user that appointment is (probably) in a different time zone,
and asks user if user would like to have it displayed in PST time
zone. User answers with "Yes" and on his screen appears that meeting
is actually at <2023-01-20 Fri 23:00>, he prepares himself for longer
evening, and waits for his Greek partner on Jitsi Meet:
https://meet.jit.si/ to get online.

It confirms your hypothesis, yes, all times are calculated as UTC, but
all time stamps at export, sharing, or change of time zone, shall be
displayable in understandable manner to human user.

> > Org in this state can't handle such things.
> 
> Org can do the useful thing: translate the UTC timestamp into local time and
> report both UTC and local time.  User will be able quickly to determine if
> local time is incorrect for some reason, such as DST or travel.

Other way around, it has to translate time stamp into UTC time in the first place. 

Expecting that all user among so many various time zones write their
time stamps in UTC is not reasonable. Org users are advanced, I know,
but majority of note takers with other applications will not even
think of different time zones, it is surprise they get when dealing
internationally. People are not ready for calculating or even viewing
their own time in UTC time zone, unless they are English or Icelandic,
Portuguese, or Africans in parts of the West Africa.

> Storing timestamps in UTC solves the interval problem Ihor
> raised. Intervals always make sense in absolute time.  Moving them
> to event time leads to the insanity Ihor mentioned.

The other way around. Assuming that time stamps are UTC raises
problems for all other people:
https://upload.wikimedia.org/wikipedia/commons/8/88/World_Time_Zones_Map.png

Org now does not support time stamps, right?

So people write timestamps in their own time zone! Is it right?

My time stamp here is <2023-01-19 Thu 17:12> now, what is yours?

Forcing users to write time stamps in UTC would cause havoc.

Thus time stamps already have their time zones, it is just not
recorded in Org file. 

Options can be created so that:

- user always and automatically record time zone in Org file, for
  example from system time zone, so that when first time property is
  invoked that it stays there:

#+TIMEZONE: EET

Or like this

* TODO Appointment on Jitsy Meet with Greek investor
  DEADLINE: <2023-01-20 Fri 09:00>
  :PROPERTIES:
  :TIMEZONE: EET
  :END:

or inside of the time zone.

When such heading is read in Seattle, Washington, Org will tell to
user or ask to translate it to PST time.

In such translations, EET time is first converted to UTC, for reason
of using system libraries, and not complicating Org, and then
converted to PST 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: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Thomas S. Dye]

Aloha Jean Louis,

Jean Louis <bugs@gnu.support> writes:

> * Thomas S. Dye <tsd@tsdye.online> [2023-01-19 09:37]:
>> Meetings are occurrences, which require absolute time, which 
>> has no
>> timezones.  Org should record occurrences with timestamps in 
>> UTC,
>> possibly translating from the user's local time.
>
> User in Grece needs appointment at 9 o'clock, and writes it as:
> <2023-01-20 Fri 09:00> He also has TIMEZONE (either system or 
> Org file
> based) set to "EET". That way the time has been recorded in UTC 
> for
> Org purposes, and UTC has been solved. For Greek user it is 
> completely
> solved. Org calculates UTC based on configured time zone. But 
> when it
> is 16:00 o'clock in Greece, it is 06:00 in Seattle.
>
> Online appointment is sent to user in Seattle, with the time 
> zone
> PST. He receives the Org file from Greece, at 8:00 o'clock, 
> which has
> settings inside TIMEZONE="EET". At first user thinks that 
> appointment
> is in just 1 hour, because he can see "08:00", but Org 
> gracefully
> notifies user that appointment is (probably) in a different time 
> zone,
> and asks user if user would like to have it displayed in PST 
> time
> zone. User answers with "Yes" and on his screen appears that 
> meeting
> is actually at <2023-01-20 Fri 23:00>, he prepares himself for 
> longer
> evening, and waits for his Greek partner on Jitsi Meet:
> https://meet.jit.si/ to get online.
>
> It confirms your hypothesis, yes, all times are calculated as 
> UTC, but
> all time stamps at export, sharing, or change of time zone, 
> shall be
> displayable in understandable manner to human user.
>
Only occurrences require absolute time, UTC.  Events do not.  They 
follow the user's space/time.

>> > Org in this state can't handle such things.
>> 
>> Org can do the useful thing: translate the UTC timestamp into 
>> local time and
>> report both UTC and local time.  User will be able quickly to 
>> determine if
>> local time is incorrect for some reason, such as DST or travel.
>
> Other way around, it has to translate time stamp into UTC time 
> in the first place. 

Yes, to store the time stamp, Org must take it from the event time 
of the user and translate it to UTC.  When reporting an occurrence 
to the user, then Org must translate from UTC to the user's 
space/time.  User might have a toggle, like pretty entities, that 
either shows UTC or translation to user's space/time.

> Expecting that all user among so many various time zones write 
> their
> time stamps in UTC is not reasonable. Org users are advanced, I 
> know,
> but majority of note takers with other applications will not 
> even
> think of different time zones, it is surprise they get when 
> dealing
> internationally. People are not ready for calculating or even 
> viewing
> their own time in UTC time zone, unless they are English or 
> Icelandic,
> Portuguese, or Africans in parts of the West Africa.
>
Org should translate from the user's space/time to absolute time, 
UTC.  The user has to tell Org what is the space/time relationship 
to absolute time.  Org might use the timezone machinery to suggest 
a space/time relationship to absolute time, and it might warn the 
user when the user's suggested relationship differs from the value 
reported by the timezone machinery.

>> Storing timestamps in UTC solves the interval problem Ihor
>> raised. Intervals always make sense in absolute time.  Moving 
>> them
>> to event time leads to the insanity Ihor mentioned.
>
> The other way around. Assuming that time stamps are UTC raises
> problems for all other people:
> https://upload.wikimedia.org/wikipedia/commons/8/88/World_Time_Zones_Map.png
>
> Org now does not support time stamps, right?
>
> So people write timestamps in their own time zone! Is it right?

IIUC, Org currently stores events, which are relative to the 
user's space/time.  This works for events, but breaks for 
occurrences, which require absolute time, UTC.

>
> My time stamp here is <2023-01-19 Thu 17:12> now, what is yours?

<2023-01-19 Thu 06:08>  This is an event, specified relative to my 
space/time.

>
> Forcing users to write time stamps in UTC would cause havoc.

Agreed, Org should help.

>
> Thus time stamps already have their time zones, it is just not
> recorded in Org file. 

Events don't need a time zone, only occurrences need absolute 
time.

>
> Options can be created so that:
>
> - user always and automatically record time zone in Org file, 
> for
>   example from system time zone, so that when first time 
>   property is
>   invoked that it stays there:
>
> #+TIMEZONE: EET
>
> Or like this
>
> * TODO Appointment on Jitsy Meet with Greek investor
>   DEADLINE: <2023-01-20 Fri 09:00>
>   :PROPERTIES:
>   :TIMEZONE: EET
>   :END:
>
> or inside of the time zone.
>
> When such heading is read in Seattle, Washington, Org will tell 
> to
> user or ask to translate it to PST time.
>
> In such translations, EET time is first converted to UTC, for 
> reason
> of using system libraries, and not complicating Org, and then
> converted to PST time zone.

The Org user in Seattle would either see UTC or toggle to see UTC 
translated to Seattle space/time, assuming user set space/time 
relationship to UTC correctly.  If not, then Org should warn user 
that the specified relationship differs from the one suggested by 
the timezone machinery.

hth,
Tom

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

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

[Jean Louis]

* Thomas S. Dye <tsd@tsdye.online> [2023-01-19 19:23]:
> Only occurrences require absolute time, UTC.  Events do not.  They
> follow the user's space/time.

I understand you got your context specific terminology, from the
mentioned book, where you are making philosophically different
distinction between occurence and event as opposed to distinction by
its ordinary meaning in English.

What really matters
-------------------

What matters is aid to users' life.

When arguing, try to make a checklist and TEST it:

- [ ] can user easily understand the time displayed?

- [ ] can user relate the displayed time to his local time without
  hesitation?

- [ ] is that program that programmer creates beneficial to user or to
  programmer, or theoretician of absolutes, rights and wrongs?

How to test it?

Usability Testing 101:
https://www.nngroup.com/articles/usability-testing-101/


Today there is in computing pretty much agreement that:
-------------------------------------------------------

- All computer time should be stored to UTC, UTC being basis for any
  other computations

- System libraries have (or should have) various configurations

- Computer users should be shown their local time


* Overview of noun occurrence
-----------------------------


The noun occurrence has 2 senses (first 2 from tagged texts)
1. (29) happening, occurrence, occurrent, natural event -- (an event that happens)
2. (3) occurrence -- (an instance of something occurring; "a disease of frequent occurrence"; "the occurrence (or presence) of life on other planets")

* Overview of noun event

The noun event has 4 senses (first 2 from tagged texts)
1. (62) event -- (something that happens at a given place and time)
2. (6) event, case -- (a special set of circumstances; "in that event, the first possibility is excluded"; "it may rain in which case the picnic will be canceled")
3. event -- (a phenomenon located at a single point in space-time; the fundamental observational entity in relativity theory)
4. consequence, effect, outcome, result, event, issue, upshot -- (a phenomenon that follows and is caused by some previous phenomenon; "the magnetic effect was greater when the rod was lengthwise"; "his decision had depressing consequences for business"; "he acted very wise after the event")

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

[Thomas S. Dye]

Aloha Jean Louis,

Jean Louis <bugs@gnu.support> writes:

> * Thomas S. Dye <tsd@tsdye.online> [2023-01-19 19:23]:
>> Only occurrences require absolute time, UTC.  Events do not. 
>> They
>> follow the user's space/time.
>
> I understand you got your context specific terminology, from the
> mentioned book, where you are making philosophically different
> distinction between occurence and event as opposed to 
> distinction by
> its ordinary meaning in English.
Ordinary meanings are often polysemous, so context is important. 
A big part of philosophy is limiting the confusion caused by 
polysemy. Ramsey was specifically concerned to distinguish two 
senses of the word event because he was certain that using event 
with this polysemy would sow confusion.   

> What really matters
> -------------------
>
> What matters is aid to users' life.
>
> When arguing, try to make a checklist and TEST it:
>
> - [ ] can user easily understand the time displayed?
>
> - [ ] can user relate the displayed time to his local time 
> without
>   hesitation?
>
> - [ ] is that program that programmer creates beneficial to user 
> or to
>   programmer, or theoretician of absolutes, rights and wrongs?
>
> How to test it?
>
> Usability Testing 101:
> https://www.nngroup.com/articles/usability-testing-101/
>
I'm hopeful that Ramsey's distinction between event and occurrence 
contributes to what really matters.  How that distinction is 
communicated to the user most effectively is an open question, 
IMO.

>
> Today there is in computing pretty much agreement that:
> -------------------------------------------------------
>
> - All computer time should be stored to UTC, UTC being basis for 
> any
>   other computations
>
> - System libraries have (or should have) various configurations
>
> - Computer users should be shown their local time
>
I was thinking that Org timestamps should record the information 
needed to let Org calculate user's local time so it is synchronous 
with other users' local times. This ought to make it possible to 
take into account unforeseen, arbitrary changes in timezone (as 
when a legislative body imposes or rescinds DST) that take place 
between the time an event is scheduled and when it takes place. 
Using absolute time (UTC) stored before the arbitrary change in 
timezone will cause problems.  Of course, arbitrary changes in 
timezone do not affect an occurrence, so storing UTC in this 
instance is correct.

>
> * Overview of noun occurrence
> -----------------------------
>
>
> The noun occurrence has 2 senses (first 2 from tagged texts)
> 1. (29) happening, occurrence, occurrent, natural event -- (an 
> event that happens)
> 2. (3) occurrence -- (an instance of something occurring; "a 
> disease of frequent occurrence"; "the occurrence (or presence) 
> of life on other planets")
>
> * Overview of noun event
>
> The noun event has 4 senses (first 2 from tagged texts)
> 1. (62) event -- (something that happens at a given place and 
> time)
> 2. (6) event, case -- (a special set of circumstances; "in that 
> event, the first possibility is excluded"; "it may rain in which 
> case the picnic will be canceled")
> 3. event -- (a phenomenon located at a single point in 
> space-time; the fundamental observational entity in relativity 
> theory)
> 4. consequence, effect, outcome, result, event, issue, upshot -- 
> (a phenomenon
> that follows and is caused by some previous phenomenon; "the 
> magnetic effect was
> greater when the rod was lengthwise"; "his decision had 
> depressing consequences
> for business"; "he acted very wise after the event")

Yes, you can see all the polysemy.  Also, you can see why Ramsey 
was happy with event, and less so with occurrence.  The important 
point is the distinction he proposed, not the words used to 
express it.  I think the distinction is germane to understanding 
what information is needed to let Org calculate user's local time 
so it is synchronous with other users' local times.  To my mind, 
it helps bring order out of complexity.

All the best,
Tom
-- 
Thomas S. Dye
https://tsdye.online/tsdye

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

[Jean Louis]

* Thomas S. Dye <tsd@tsdye.online> [2023-01-19 19:23]:
> Only occurrences require absolute time, UTC.  Events do not.  They follow
> the user's space/time.
> 
> > > > Org in this state can't handle such things.
> > > 
> > > Org can do the useful thing: translate the UTC timestamp into local
> > > time and
> > > report both UTC and local time.  User will be able quickly to
> > > determine if
> > > local time is incorrect for some reason, such as DST or travel.
> > 
> > Other way around, it has to translate time stamp into UTC time in the
> > first place.
> 
> Yes, to store the time stamp, Org must take it from the event time of the
> user and translate it to UTC.  When reporting an occurrence to the user,
> then Org must translate from UTC to the user's space/time.  User might have
> a toggle, like pretty entities, that either shows UTC or translation to
> user's space/time.

That is right. I have stated same.

How do you want Org to know that user's time is in X time zone? 

It means, that new settings, variables, functions, must be introduced
to handle it properly. Timestamp like this one: <2023-01-21 Sat 09:55>
at HTML export will be from 95% and upwards incorrect. To be correct,
time zone designation shall be placed in HTML export. User could be in
South America, not in London, that exports it. Time zone UTC does not
apply for South America. Representation is wrong.

When you say that Org must take it from the event time of the user,
that means that Org must take some parameter to understand what time
zone user was.

That means involving functions for export, or sharing of Org files.

In general, we speak about representation.

You may start making distinctions between "events" and "occurences",
but technically we speak of time stamps which lack relation to time
zone in Org. Whatever you "time stamp" without time zone,
representation of it in other time zone becomes difficult, as it lacks
the fundamental designation of time zone where it was recorded. 

And it does not matter if user records time zones in UTC, or other
time zones.

What matters is designation of time zone.

Parameter must exist, something like "#+TIMEZONE: PST"

As that property is then used by programs to understand time zone of
the file, or task.

In general computers store things in UTC. We are repeatedly discussing
what is already agreed before decades.

What we need in Org is representation in time zones.

All programs work by storing in UTC time zone:
----------------------------------------------

Observe file system:

$ touch MY-FILE
~
$  ls -l |grep MY-FILE 
-rw-r--r--     1 admin input       0 Jan 21 16:21 MY-FILE
~
$ TZ=UTC ls -l |grep MY-FILE 
-rw-r--r--     1 admin input       0 Jan 21 13:21 MY-FILE


UTC is basis for time. There are time zone libraries and calculations.

All that one has to think for Org is representation in familiar local time zone.

> > Expecting that all user among so many various time zones write their
> > time stamps in UTC is not reasonable. Org users are advanced, I know,
> > but majority of note takers with other applications will not even
> > think of different time zones, it is surprise they get when dealing
> > internationally. People are not ready for calculating or even viewing
> > their own time in UTC time zone, unless they are English or Icelandic,
> > Portuguese, or Africans in parts of the West Africa.
> > 
> Org should translate from the user's space/time to absolute time, UTC.  

That is right. So far I am telling same, maybe we think is not.

> The user has to tell Org what is the space/time relationship to
> absolute time.

That is right. I said that long ago. The way to "tell it to Org" is at
export, for Org to recognize it in terms of Lisp 
(or time-stamp-zone heading-time-zone file-time-zone system-time-zone)
whatever comes first, then at any sharing of Org directly to people in
other time zones, and in other uses cases. Such sharing and export
must have variables that help to interpolate time properly in other
zones, and Org shall recognize that time stamp displayed is not in
local time zone and ask user if to show or translate time stamps. Many
options exist.

Best is when it is automatic, as that is usual in many other software.

> Org might use the timezone machinery to suggest a space/time
> relationship to absolute time, and it might warn the user when the
> user's suggested relationship differs from the value reported by the
> timezone machinery.

That is right.

> > > Storing timestamps in UTC solves the interval problem Ihor
> > > raised. Intervals always make sense in absolute time.  Moving them
> > > to event time leads to the insanity Ihor mentioned.
> > 
> > The other way around. Assuming that time stamps are UTC raises
> > problems for all other people:
> > https://upload.wikimedia.org/wikipedia/commons/8/88/World_Time_Zones_Map.png
> > 
> > Org now does not support time stamps, right?
> > 
> > So people write timestamps in their own time zone! Is it right?
> 
> IIUC, Org currently stores events, which are relative to the user's
> space/time.  This works for events, but breaks for occurrences, which
> require absolute time, UTC.

You have got that theory from a book, it is different philosophical
concept that somebody finds useful. 

Though it is not directly related to the problem that Org does not
have time zone representation.

To solve the problem first one has to define it. 

You can call time stamps as you wish. How you call them it does not
matter. 

You can call it "event" or "completed" or "deadline" or "scheduled" or
"occurence", those are types useful for user.

Whatever they are called, local user shall get any time displayed in
local time or with proper time zone designation, so that time may be
displayed or converted to local time.

Nothing will break what designation get introduced in Org.

I mean to introduce variables analogous to following logic:

(or time-stamp-zone heading-time-zone file-time-zone system-time-zone)

> > Thus time stamps already have their time zones, it is just not
> > recorded in Org file.
> 
> Events don't need a time zone, only occurrences need absolute time.

When you introduce words that have different meaning in different
context in your book, you can't expect that it will be generally
expected.

No matter how you "name" the time zone, all time you write in your
computer beyond Org is already written in your local time zone.

Any time user designates in notes, calendars, etc. is already in local
time zone.

Any time displayed to user is in his local time zone.

Follow the steps!

It is that simple.

If event need time zone or not, because you think it does not need,
many others may disagree.

Why argue how you call that time? 

Just follow the steps to display it in local time zone, and any time
to accept as UTC, written in local time zone. Any time always is
related to UTC in computers, there is nothing unsolved.

Finally users who do not want to fiddle with time zone shall also be
left to do so.

Org could also give to user to designate how time stamp should look
like, by using format that user may specify:

%Y/%m/%d - %H:%M %Z

Which could display:

2023/01/21 - 16:40 EAT

by using:
https://linux.die.net/man/3/strftime

instead of trying to satisfy every possible way of formats of time
stamps (congratulation for that).

1. System time is always in local time
2. Org may introduce TIMEZONE property as already discussed
2. Org may introduce property "#+TIMEZONE_FORMAT" like "%Y/%m/%d - %H:%M %Z"
3. Any time stamp would use that format

Translation of timestamps to other time zones by using that format are
easier, than trying to satisfy every person on planet. For Org, which
is not even demanded apart from us here.

> >   :TIMEZONE: EET
> >   :END:
> > 
> > or inside of the time zone.
> > 
> > When such heading is read in Seattle, Washington, Org will tell to
> > user or ask to translate it to PST time.
> > 
> > In such translations, EET time is first converted to UTC, for reason
> > of using system libraries, and not complicating Org, and then
> > converted to PST time zone.
> 
> The Org user in Seattle would either see UTC or toggle to see UTC translated
> to Seattle space/time, assuming user set space/time relationship to UTC
> correctly.  If not, then Org should warn user that the specified
> relationship differs from the one suggested by the timezone
> machinery.

Why would you see UTC if you are not in UTC time zone? It is not
useful. 

But yes, user could or should be able to see it in any time zone, but
without much focus on that. Users can change local time zone, so let
them do that if they want, but displaying local time zone is decades
long standard in computin.

I have various software here, none of it asks me to look at UTC
time. UTC is for computer to calculat, not for human to see, it is not
useful for human unless to those who happen to be in that time zone.

All computer software calculates to and from UTC when showing local
time zone.

We basically speak of "calendar" applications where users need to
share various times. 

Then why not follow what is already successful elsewhere?

3.2.19. Time Zone Identifier | iCalendar (RFC 5545) | RFC Specifications:
https://icalendar.org/iCalendar-RFC-5545/3-2-19-time-zone-identifier.html

This parameter MUST be specified on the "DTSTART", "DTEND", "DUE",
"EXDATE", and "RDATE" properties when either a DATE-TIME or TIME value
type is specified and when the value is neither a UTC or a "floating"
time. Refer to the DATE-TIME or TIME value type definition for a
description of UTC and "floating time" formats. This property
parameter specifies a text value that uniquely identifies the
"VTIMEZONE" calendar component to be used when evaluating the time
portion of the property. The value of the "TZID" property parameter
will be equal to the value of the "TZID" property for the matching
time zone definition. An individual "VTIMEZONE" calendar component
MUST be specified for each unique "TZID" parameter value specified in
the iCalendar object.

The parameter MUST be specified on properties with a DATE-TIME value
if the DATE-TIME is not either a UTC or a "floating" time. Failure to
include and follow VTIMEZONE definitions in iCalendar objects may lead
to inconsistent understanding of the local time at any given location.

Thus in Org, we want to avoid also: "inconsistent understanding" at
any given location. That is why only iCalendar export supports the
conversion. 

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

[Max Nikulin]

On 21/01/2023 20:50, Jean Louis wrote:
> Parameter must exist, something like "#+TIMEZONE: PST"

Please, stop demonstrating your ignorance. You are repeating it despite 
even this thread have messages explaining that abbreviations are 
ambiguous. You are consistently ignoring warnings posted by other people.

See the following thread:

Neil Jerram to emacs-orgmode. Two problems with export to Google 
calendar. Wed, 7 Dec 2022 11:30:10 +0000. 
https://list.orgmode.org/CAKuG=vti=_1ZSe_AQh_OfrPf7YpBy+U2uUhXc--4GjBUxt=PKA@mail.gmail.com

X-WR-TIMEZONE:BST

Google recognized it as Bangladesh Standard Time instead of British 
Summer Time.

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

[Thomas S. Dye]

Aloha Jean Louis,

Jean Louis <bugs@gnu.support> writes:

> * Thomas S. Dye <tsd@tsdye.online> [2023-01-19 19:23]:
>> Only occurrences require absolute time, UTC.  Events do not. 
>> They follow
>> the user's space/time.
>> 
>> > > > Org in this state can't handle such things.
>> > > 
>> > > Org can do the useful thing: translate the UTC timestamp 
>> > > into local
>> > > time and
>> > > report both UTC and local time.  User will be able quickly 
>> > > to
>> > > determine if
>> > > local time is incorrect for some reason, such as DST or 
>> > > travel.
>> > 
>> > Other way around, it has to translate time stamp into UTC 
>> > time in the
>> > first place.
>> 
>> Yes, to store the time stamp, Org must take it from the event 
>> time of the
>> user and translate it to UTC.  When reporting an occurrence to 
>> the user,
>> then Org must translate from UTC to the user's space/time. 
>> User might have
>> a toggle, like pretty entities, that either shows UTC or 
>> translation to
>> user's space/time.
>
> That is right. I have stated same.
>
> How do you want Org to know that user's time is in X time zone? 
>
> It means, that new settings, variables, functions, must be 
> introduced
> to handle it properly. Timestamp like this one: <2023-01-21 Sat 
> 09:55>
> at HTML export will be from 95% and upwards incorrect. To be 
> correct,
> time zone designation shall be placed in HTML export. User could 
> be in
> South America, not in London, that exports it. Time zone UTC 
> does not
> apply for South America. Representation is wrong.
>
> When you say that Org must take it from the event time of the 
> user,
> that means that Org must take some parameter to understand what 
> time
> zone user was.
>
> That means involving functions for export, or sharing of Org 
> files.
>
> In general, we speak about representation.
>
> You may start making distinctions between "events" and 
> "occurences",
> but technically we speak of time stamps which lack relation to 
> time
> zone in Org. Whatever you "time stamp" without time zone,
> representation of it in other time zone becomes difficult, as it 
> lacks
> the fundamental designation of time zone where it was recorded. 
>
> And it does not matter if user records time zones in UTC, or 
> other
> time zones.
>
Here is a distinction that I think is important based on Ramsey's 
distinction between event and occurrence: UTC is absolute time and 
not a timezone.  UTC doesn't occupy a region of space/time, as 
does a timezone.  This is why UTC can be used to generate 
synchronous times for occurrences, but timezones are required to 
generate synchronous times for events.

hth,
Tom

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

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

[Daryl Manning]

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

Oh wow... this is a great idea. Good idea sending it round. Ought to make
things a bit easier when discussing and avoiding misunderstandings.  =]

On Fri, Jan 27, 2023 at 1:06 PM Sterling Hooten <hooten@gmail.com> wrote:

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

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

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

[Jean Louis]

* Sterling Hooten <hooten@gmail.com> [2023-01-27 09:06]:
>   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.

I would be careful calling it constant as time offset is changing
depending of daylight saving time. It is not constant.

Time offset time stamp may be derived from time zone time. I am sure
about this.

Time zone time stamp cannot be unambiguously derived from time
offset. I am mostly sure about this.

> 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

Offset is not that fixed, maybe from viewpoint of storage as maybe it
is considered fixed in it's representation, but you have to keep in
mind that time offset by it's definition is changing itself, suddenly,
depending of daylight saving and time zone.

I am trying to find well described reference to read, try here:

Time Zones vs. Offsets – What's the Difference? Which Is Best?:
https://spin.atomicobject.com/2016/07/06/time-zones-offsets/

,----
| Putting It All Together
| 
| 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.
`----

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

For calendars it is good to follow recommendation Internet Calendaring
and Schedulingn Core Object Specification (iCalendar)

iCalendar - Date and time format:
https://en.wikipedia.org/wiki/ICalendar#Date_and_time_format

In other words it is good to follow what other successful applications
are already doing. 

For example, if you open Evolution calendar in Gnome:

evolution -c calendar

and make task, and save that task as iCalendar, then you can see what
time stamp format is used there for exchange purposes.

Representation for user using Org file is different from
representation for sharing purposes, as user already (mostly) have
specified local time zone on this computer, while sharing object such
as iCalendar file must take that information of local time zone and
store it unambiguously.

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

Parameters needed to make it fixed are already in computer, only
disconnected. 

changing this time stamp for Org:
<2023-01-27 Fri 10:18>
to something "fixed" would break Org compatibility for past Org files.

While new unambigious time stamp formats may be introduced, the way to
go is with past time stamps is to understand the time stamp for
representation and calculation purposes by using OR logical function:

timestamp-time-zone OR heading-time-zone OR file-time-zone OR system-time-zone

as by using those, for now still disconnected parameters, one can get
the fixed time for representation purposes (Org export or sharing) or
calculation purposes (on local computer and by using some shared Org
objects).

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

I guess that OR consideration above may remedy it and keep past
compatibility while expanding more specific time stamp as option.

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

Sounds complex to me and over board for program that tries to define
data type by using simple text written ambiguously by many people.

> What format and syntax should Org use?
> 
> A heretical suggestion: We should abandon the day of week abbreviation
> and use a new format.

Day of week abbreviation is useful. Full day is even more
useful. Removing what is useful is not useful.

There is no calendar application that I know that does not specify
days of week.

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

Which format is more useful for people?

I find [2023-01-25 Wed 12:12] more useful, rather than the other one,
for reason that it has clear date, day of week and time.

And I always consider that Emacs packages like Org shall be designed
to be useful to majority of people, rather than to few who may have
the idea very right, but not comforting the majority of people.

There is no calendar application that I know that by default uses UTC
format, which representation is of course contradictory to large
majority of time zones and to people got used to, to display their
time in their time zone. 

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

Such representations should not become default to users, but used in
representation, or sharing, or re-writing of time stamps by user
option. 

Using such time stamps by default in Org file is confusing for people
and showing time which is not their time to majority of people.

I am surprised and in same time disappointed, that your analysis leads
to conclusion that users should represent their time in UTC.

> 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 is redundant or who? 

Is it redundant for majority of Org users?

Maybe it is reundant for you?

For some people?

Do you know for who?

I never even heard some user here complaining for day of week
representation. Let me add one big fricking LOL here.

Any user who wishes to do anything could be left to program it alone
and do what they wish.

But programming should be useful to people by majority of demands and
wants.

> • It's a nonstandard format

The statement above miss the context. Non-standard where? How? In
which context?

In context of Org file is prime standard.

In context of Evolution calendar it is not standard, but neither the
graphical representation of a task in such calendar is standard.

Program's representation of time is NOT REQUIRED to be standard,
rather it shall be useful to user using the program to understand the
information. 

In other words, representation shall be simple and readable,
understandable!

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

Being inspired does not mean "conforming to ISO 8601"

There is distinction, different context, of using time stamps inside
of Org file, and different context of "worldwide exchange and
communication of date and time related data", see ISO 8601 purposes.

I fully agree that in exchange or sharing of date/time information,
Org program should sometims use ISO 8601, but not in all exports.

For example in HTML export it is enough to say time and time zone. But
some people like to export it in ISO 8601. Such considerations could
be user option.

Right now HTML export is ambiguous as it does not have time zone.

The usage of ISO 8601 should rather depend on method exchange or
exporting.

But it should not be user's representation, as user is not a robot, or
program that is supposed to read computer-meant time stamps.

And you forgot to list disadvantages of making Org for robots, not for
human.

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

> * Sterling Hooten <hooten@gmail.com> [2023-01-27 09:06]:
>>   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.
>
> I would be careful calling it constant as time offset is changing
> depending of daylight saving time. It is not constant.
>
> Time offset time stamp may be derived from time zone time. I am sure
> about this.
>
> Time zone time stamp cannot be unambiguously derived from time
> offset. I am mostly sure about this.
>
>> 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
>
> Offset is not that fixed, maybe from viewpoint of storage as maybe it
> is considered fixed in it's representation, but you have to keep in
> mind that time offset by it's definition is changing itself, suddenly,
> depending of daylight saving and time zone.
>

I think your misinterpreting the intent here. If you specify a timestamp
with offset, it is fixed. It does not change with daylight savings or
any other change in rules for a time zone. It does not even specify a
time zone. While it is true that a specific location may have time zone
changes or that the offset from UTC might change as a result of daylight
savings, an offset specified in a times stamp does not change and is
fixed.  This is one of the limitaiton with using offset.

I also think it is a mistake (which I've seen others suggest in this
thread) to equate an offset as being an abbreviation for a time
zone. For example, some have suggested things like +10000 being the same
as AEST and both being abbreviations for Australia/Sydney outside of
daylight savings periods. I think that is incorrect. +1000 is a fixed
offset from UTC and while it may be the same offset used in a time zone
abbreviation like AEST or in a full time zone specification like
Australia/Sydney, it is not a time zone specification, only an offset
for a specific point in time.

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

[Jean Louis]

* Tim Cross <theophilusx@gmail.com> [2023-01-28 00:15]:
> >
> >> 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
> >
> > Offset is not that fixed, maybe from viewpoint of storage as maybe it
> > is considered fixed in it's representation, but you have to keep in
> > mind that time offset by it's definition is changing itself, suddenly,
> > depending of daylight saving and time zone.
> >
> 
> I think your misinterpreting the intent here. If you specify a timestamp
> with offset, it is fixed.

That is what you say. And I am pointing out to international standard
references.

If you use offset as "fixed" it means such use would not be by
standard, and you would confusing users and programmers who are using
standard for calculations in programs.

> It does not change with daylight savings or any other change in
> rules for a time zone. It does not even specify a time zone.

And while and before making that decision, did you review the standard
that time zone offset is influenced and changed by daylight savings?

It does not specify time zone. But it is derived from time zone, and
is not same from time zone.

Are you aware that time zone offset could have "skipped time" or
"added time" due to daylight savings?

That implies that by using time offset, you would forget daylight
savings which are international standard, and make calculations wrong,
because you started applying own standard in Org.

Time offset does not independently exists without time zone. While you
represent it without time zone, you have to observe time zone first,
before deriving time offset from it.

Read from:
https://en.wikipedia.org/wiki/UTC_offset

,----
| Daylight saving time
| 
| Several regions of the world use daylight saving time (DST) and the
| UTC offset during this season is typically obtained by adding one hour
| to local standard time. Central European Time UTC+01:00 is replaced by
| Central European Summer Time UTC+02:00, and Pacific Standard Time
| UTC−08:00 is replaced by Pacific Daylight Time UTC−07:00.
`----

Maybe you wish to include a new type of time representation, something
like "Org time offset", in that case you are involving Org developers
into even deeper problems, as then with the new type, you are left all
alone to make that thing work. 

That new type of "fixed" time offset, would not be standard, and would
confuse careful users and programmers.

Example:

- time offset would be PST UTC-08:00, for example 12:00 o'clock

- with daylight saving time event (the time when people switch
  clocks), the offset of PST UTC-08:00, would suddenly become
  UTC-07:00, and the time offset would suddenly become 11:00 o'clock
  in that moment

- now is your decision if you will keep counting 12 o'clock in Org,
  thus creating new type of time specific to Org or 11 o'clock as that
  is the international standard.

Time offset will change with daylight savings, and must be thus
derived from time zone.

> While it is true that a specific location may have time zone changes
> or that the offset from UTC might change as a result of daylight
> savings, an offset specified in a times stamp does not change and is
> fixed.  This is one of the limitaiton with using offset.

It is fixed only if you think is fixed when it is written once, and
then you think it is fixed. 

In the sense of calculation of time, it is not fixed and for any
calculation of time offset you need to observe in which time zone is
that time offset, and if you do not know time zone you can't calculate
it correctly.

Please read Wikipedia article explaining it clearly. 

Please read how in China time offset is not every 15 degrees, and how
there is wording "Although nominally" and "every 15 degrees".

Time offset is thus calculated based on time zone and other factors.

It is derived. 

It is not basic time type to be used for other calculations!

It is a difference of time that is mostly in this way, but shaped by
politics in other way.

Time zone is time added or deducted from UTC. But not just added in
mathematical sense, it is added by considering daylight savings, and
time zones and politics.

> I also think it is a mistake (which I've seen others suggest in this
> thread) to equate an offset as being an abbreviation for a time
> zone. 

That is very right. Time offset may be derived from time zone by using
tz database, but it cannot just be automatically derived.

Time offset is not derived from UTC, it is however, derived from tz
database, observing time zones, politics.

> For example, some have suggested things like +10000 being the same
> as AEST and both being abbreviations for Australia/Sydney outside of
> daylight savings periods. I think that is incorrect.

Using time offset for calculations is useless as it lacks the time
zone, and is only one way of representation for those people who do
not understand time zone.

However, time offset is NOT fixed, it is representation based on time
zone, politics, tz database.

Please read carefully here:
https://en.wikipedia.org/wiki/Daylight_saving_time

and search for time offset to find references.

> +1000 is a fixed offset from UTC

To say that it is fixed you will confuse people here. 

When you say "fixed" you must say in which context it has been fixed.

I have given you enough examples in this e-mail to understand that
time offset in the context of programming is not fixed, as programmer
would need to know the time zone, and time offset may be in different
time zones same! 

Thus deriving time zone unambiguously from time offset is not
possible. You could derive some time zones, but not all. In this
context is not fixed.

Deriving UTC time from time offset by using time offset time stamp IS
possible. In that context it is "fixed".

Deriving positive or negative time difference from time offset is not
unambiguously workable! (Unless you make Org new type of time) This is
not workable because time offset does change with daylight saving time
and also by politics. And to know how it change, again you will need
time zone. In this context it is NOT fixed.

Another good reference:
https://dba.stackexchange.com/questions/94841/how-to-check-the-timezone-for-a-given-datetime

Where the main Answer says: 

,----
| a DATETIME value and a Timezone (name) then you can determine the
| Offset by looking up what the Offset was at that point in time (see
| below for sources of such data)
`----

,----
| The "offset" is a property of the timezone, but it does not, and
| cannot, determine the timezone since:
| 
|    - several timezones can share the same offset
|    - timezones can come and go and can even shift their offset
|    - different regions can change their timezones
`----

And then this following, well expressed answer:

,----
| With only the Offset, the DATETIME value can be converted to UTC, but
| not to another Offset without first having a Timezone database and
| knowing which specific Timezone you are converting it to, which will
| indicate the Offset for that particular point in time
`----

Another problem is that several online explanations on Stack-what are
not giving proper explanation. Please be careful when you go searching
various programmers statements on Stack-what websites, as programmer
may make wrong functions in this or that programming language,
thinking:

"Oh, that ain't workin', that's the way you do it"

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

Time offset is offset to/from UTC time, derived from time zone, and is
only fixed for that specific time point. It cannot be used to derive
other offset, or for programming calculations without using time zone.

Time offset is only a different representation of time.

If it is valid representation depends who and how calculated it. But
let us assume good program did so.

When it is properly represented, it cannot be used as "fixed" time to
calculate differences in time as it lacks time zone information, and
because time offset is changing due to daylight savings and political
decisions. 

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

[Thomas S. Dye]

Jean Louis <bugs@gnu.support> writes:

> Time offset does not independently exists without time zone. 
> While you
> represent it without time zone, you have to observe time zone 
> first,
> before deriving time offset from it.
>

UTC offset exists without time zone.  UTC is absolute time and 
offsets from it do not refer to political time in a time zone. 
They refer to local *solar time* at a particular place.  

> Read from:
> https://en.wikipedia.org/wiki/UTC_offset
>
> ,----
> | Daylight saving time
> | 
> | Several regions of the world use daylight saving time (DST) 
> and the
> | UTC offset during this season is typically obtained by adding 
> one hour
> | to local standard time. Central European Time UTC+01:00 is 
> replaced by
> | Central European Summer Time UTC+02:00, and Pacific Standard 
> Time
> | UTC−08:00 is replaced by Pacific Daylight Time UTC−07:00.
> `----

Your wikipedia citation puts it like this: "The UTC offset (or 
time offset) is an amount of time subtracted from or added to 
Coordinated Universal Time (UTC) time to specify the local solar 
time (which may not be the current civil time, whether it is 
standard time or daylight saving time)."

Note that the quote distinguishes UTC offset from standard time 
and daylight saving time, which refer to time zones.

This distinction between absolute time (solar time) and space/time 
(time zone) is fundamental. Confusing them leads to no good.

hth,
Tom

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

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

[Daryl Manning]

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

All these discussions are really great, devil is in the details and all,
but is anyone working on implementation code for this? It’s tricky to have
visibility on WIP on org-mode - probs just me not knowing where to look tbh
(but big believer that working code is progress… 😊)

Daryl.

On Sun, 29 Jan 2023 at 13:36, Thomas S. Dye <tsd@tsdye.online> wrote:

>
> Jean Louis <bugs@gnu.support> writes:
>
> > Time offset does not independently exists without time zone.
> > While you
> > represent it without time zone, you have to observe time zone
> > first,
> > before deriving time offset from it.
> >
>
> UTC offset exists without time zone.  UTC is absolute time and
> offsets from it do not refer to political time in a time zone.
> They refer to local *solar time* at a particular place.
>
> > Read from:
> > https://en.wikipedia.org/wiki/UTC_offset
> >
> > ,----
> > | Daylight saving time
> > |
> > | Several regions of the world use daylight saving time (DST)
> > and the
> > | UTC offset during this season is typically obtained by adding
> > one hour
> > | to local standard time. Central European Time UTC+01:00 is
> > replaced by
> > | Central European Summer Time UTC+02:00, and Pacific Standard
> > Time
> > | UTC−08:00 is replaced by Pacific Daylight Time UTC−07:00.
> > `----
>
> Your wikipedia citation puts it like this: "The UTC offset (or
> time offset) is an amount of time subtracted from or added to
> Coordinated Universal Time (UTC) time to specify the local solar
> time (which may not be the current civil time, whether it is
> standard time or daylight saving time)."
>
> Note that the quote distinguishes UTC offset from standard time
> and daylight saving time, which refer to time zones.
>
> This distinction between absolute time (solar time) and space/time
> (time zone) is fundamental. Confusing them leads to no good.
>
> hth,
> Tom
>
> --
> Thomas S. Dye
> https://tsdye.online/tsdye
>

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

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

[Ihor Radchenko]

Daryl Manning <daryl@wakatara.com> writes:

> All these discussions are really great, devil is in the details and all,
> but is anyone working on implementation code for this? It’s tricky to have
> visibility on WIP on org-mode - probs just me not knowing where to look tbh
> (but big believer that working code is progress… 😊)

No WIP yet.
The purpose of the ongoing discussion is figuring out the pitfalls to
not fall into. We do not want to start writing code just to find out
that it has to be completely scraped because we did not account to some
important details.

We do not even know yet what will be the timestamp format with
timezones.

Once we know the format, we can slowly work through Org functions to
support the timezone info in the timestamps.

Later, we will need to implement the necessary new features for TZ
support in agenda/calendar/input prompts.

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

[Jean Louis]

Dear Thomas,

I give my best to find references for you and explain you the possible
problem in calculation of time stamps. That problems exist is clear.

To solve problem it is important to first define it. And when there
are developers reading it, I wish to provide best possible references
for the sake of people using Org mode.

So let me gently try explaining it with different words.

> UTC offset exists without time zone.

I have already stated that UTC offset is property of a time
zone. Single time zone may have different UTC offset. 

A time zone must have UTC offset as it's property, as how else would
people know what time is in Berlin/German? Is it by guessing?! So for
that reason on this planet countries agreed politically to define one
or more UTC offset for every time zone.

UTC offset is thus always derived from the time zone. That it "exists
without time zone" is something individual, but when we speak of UTC
offset, we know that it was derived from time zone. 

What we cannot know unambiguously is from which time zone it was
derived.

> UTC is absolute time

As we know absolutes are impossible, especially about representation
of "time", we people have only agreed on how to define UTC time, that
is what we count internationally. Let us assume it is absolute.

> and offsets from it do not refer to political time in a time
> zone.

It is good to observe the map to understand if UTC offset does not
refer to political time or maybe it does?

All time zones have their UTC offsets, as otherwise we would not be
able to calculate time by sole name of city like Berlin, so Berlin
must have defined UTC offset, and all time zones, from which UTC
offsets are derived are politically decided, this includes UTC offset,
which are very much political or in other words they are decided by
people in power or in authority.

> They refer to local *solar time* at a particular place.

They maybe should so, but that type of solar time is also politically
decided, it is not something calculated or really accurately
pinpointed time. You may observe it on the map, and decide if it
really refers to solar time or solar time is politically decided, or
maybe something else?

Solar time is also not much relevant for Org, as what I would like to
see in Org is precision with time calculations.

While I cannot guarantee for accuracy of these maps, it will be
beneficial to look at them and make a practical exercise.

Look at this nice map with time zones and UTC offsets:
https://qz.com/wp-content/uploads/2015/03/map.jpg?quality=80&strip=all&w=3000

I guess that only by looking one can see that it cannot be possibly
accurate "solar time", but we can speak of approximate solar time, as
differences of 1-4 or 5 hours in solar terms is nothing so
special. Anyway, solar time is not important for programming
calculations.

What we wish to observe is not to make mistake in programming by using
UTC offset incorrectly, as IMHO, that alone would be poor choice for
Org developers to stick to it.

Excercises:
-----------

1. Observe that tim zone in Iran has offset of 3.5+ hours, while North
   from Iran at the same Earth longitude in Turkmenistan, there is
   offset of UTC 5+ -- solar time can't be accurate that way.

2. UTC offset depends on time zone, it is the property of time
   zone. See the map to understand.

3. UTC offset may be changed by decisions of authorities and is
   dependant on daylight savings and political changes, as it has to
   be derived from time zone. 

4. By using UTC offset one can find UTC time, like Max say, that is
   for many applications alright, but it will not make it accurate.

   I am reluctant to accept that UTC offset is enough, unless it is
   demonstrated that it will bring the intended purpose in Org.

   As that is just one parameter that is derived from time zone. That
   is not how other applications work, they will either store time in
   UTC, or time with time zone representation including UTC, plus
   including the UTC offset.

   One need time zone to understand and calculate future times for
   people who change time zones, for example in Org Agenda, as by
   using UTC offset only, one would need to first convert it to time
   with time zone of the user viewing that time, and then to UTC
   offset of the user viewing that time representation.

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

[Thomas S. Dye]

Aloha Jean Louis,

Jean Louis <bugs@gnu.support> writes:

> Dear Thomas,
>
> I give my best to find references for you and explain you the 
> possible
> problem in calculation of time stamps. That problems exist is 
> clear.
>
> To solve problem it is important to first define it. And when 
> there
> are developers reading it, I wish to provide best possible 
> references
> for the sake of people using Org mode.
>
> So let me gently try explaining it with different words.

At this point, we appear to be talking past one another.

All the best,
Tom
-- 
Thomas S. Dye
https://tsdye.online/tsdye

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

[Jean Louis]

Dear Heinz,

Thanks, let me see.

* Heinz Tuechler <tuechler@gmx.at> [2023-01-31 01:02]:
> Dear Jean Louis,
> 
> it appears to me that you mix two aspects. I agree with you that a time
> zone needs an offset from UTC to be defined. Consequently the definition
> of a time zone requires an offset.

Yes, that is good our mutual understanding.

> But an offset does not need a time zone to define a time.

I am trying to understand what you wanted to say with the
above. 

Before representing time with the UTC offset:
---------------------------------------------

To derive the representation of time with the UTC offset, one needs
time zone, as UTC offset is defined in the time zone. That is what you
also said above.

After representing time with the UTC offset:
--------------------------------------------

That time is defined, and at that time point does not need time zone. 

I am not concerned of time representation after UTC offset has been
derived, but of programming calculations to users' local time, as for
example in Org Agenda.

> For example, true mean local solar time of a specific longitude can
> be described by UTC plus offset.

Solar time - Wikipedia:
https://en.wikipedia.org/wiki/Solar_time

By meaning that solar time should be related to longitude, I am
totally with you Heinz. It is also true that one could disregard the
definition of UTC offset from the political reality, and calculate it
absolutely.

That condition I have already mentioned, when I said, that means we
are making "new type of time" in Org, if we start calculating it that
way. 

The meaning of "UTC offset" is however, political. Please see the UTC
offsets here:
https://upload.wikimedia.org/wikipedia/commons/8/88/World_Time_Zones_Map.png

Look at the map, find Kazakhstan with UTC offset +6 on the same
longitude with Russian Federation with UTC offset +5.

Observe Kazakhstan with UTC offset +6 on the same longitude with China
with the UTC offset +8.

That alone should tell you that solar time is not really related to
UTC offset, but we could say it is "approximate" with few hours more
or less.

Of course you can describe solar time with UTC offset, but do not
assume it will be accurate.

> I agree with your criticism of "They refer to local *solar time* at a
> particular place." This is written in
> https://en.wikipedia.org/wiki/UTC_offset , but not even there the
> description is consistent.

We can say it is approximate what they mean.

> Of course, for every finite offset, we can find a corresponding
> particular place (a longitude).

I wish it would be so, but it is not so. It is approximate, just look
at the map.

And please tell me if after this you still think there is something
wrong?

-- 
Jean

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

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

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

[Max Nikulin]

On 29/01/2023 11:09, Jean Louis wrote:
> * Tim Cross [2023-01-28 00:15]:
>>>> • Offset (fixed)
>>>>    • This captures the idea of "when did it happen for the person who
------------------------------------^^^^^^^^^^^^^^^^^^^
Jean, you missed it.

>>>>      made the observation"
>>>>    • e.g., 2007-02-03T04:00:00.000+01:00
>>>
>>> Offset is not that fixed, maybe from viewpoint of storage as maybe it
...
>> I think your misinterpreting the intent here. If you specify a timestamp
>> with offset, it is fixed.
> 
> That is what you say. And I am pointing out to international standard
> references.

You reference and verbose message are hardly relevant. Since something 
has already happened, time offset is known. DST can not change it, 
either it is effective or not at this moment.

2007-02-03T04:00:00.000+01:00

can not be unambiguously attributed to an IANA timezone ID, however it 
precisely specifies UTC time (time in seconds since epoch, etc.).

Usually (but not necessary) it means 04:00 local time in a timezone 1 
hour ahead of UTC that moment (you may use it to specify 05:00 in 
timezone having +02:00 offset). It is enough for a lot of applications.

There are important enough reasons to consider (and maybe discard to 
still use offset) IANA timezone ID for scheduling an event in future. 
Both options should be possible.

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

[Jean Louis]

* Max Nikulin <manikulin@gmail.com> [2023-01-29 09:33]:
> On 29/01/2023 11:09, Jean Louis wrote:
> > * Tim Cross [2023-01-28 00:15]:
> > > > > • Offset (fixed)
> > > > >    • This captures the idea of "when did it happen for the person who
> ------------------------------------^^^^^^^^^^^^^^^^^^^
> Jean, you missed it.

It is always pleasure to see how I missed it.

I suggest that you define the problem in Org mode for purposes of
calculations. That way you can solve issues.

> > > > >      made the observation"
> > > > >    • e.g., 2007-02-03T04:00:00.000+01:00
> > > > 
> > > > Offset is not that fixed, maybe from viewpoint of storage as maybe it
> ...
> > > I think your misinterpreting the intent here. If you specify a timestamp
> > > with offset, it is fixed.
> > 
> > That is what you say. And I am pointing out to international standard
> > references.
> 
> You reference and verbose message are hardly relevant. Since something has
> already happened, time offset is known. DST can not change it, either it is
> effective or not at this moment.
> 
> 2007-02-03T04:00:00.000+01:00
> 
> can not be unambiguously attributed to an IANA timezone ID, however it
> precisely specifies UTC time (time in seconds since epoch, etc.).

Yes, and I do not say different. We understand each other in it.

> Usually (but not necessary) it means 04:00 local time in a timezone 1 hour
> ahead of UTC that moment (you may use it to specify 05:00 in timezone having
> +02:00 offset). It is enough for a lot of applications.

If you are sure, of course, go ahead, I am not sure that using UTC
offset, alone, is good idea for future time calculations.

-- 
Jean

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

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

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

[Jean Louis]

* Max Nikulin <manikulin@gmail.com> [2023-01-29 09:33]:
> On 29/01/2023 11:09, Jean Louis wrote:
> > * Tim Cross [2023-01-28 00:15]:
> > > > > • Offset (fixed)
> > > > >    • This captures the idea of "when did it happen for the person who
> ------------------------------------^^^^^^^^^^^^^^^^^^^
> Jean, you missed it.

Above are not my words, I do not use those fat dots.

-- 
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-28 00:15]:
>> >
>> >> 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
>> >
>> > Offset is not that fixed, maybe from viewpoint of storage as maybe it
>> > is considered fixed in it's representation, but you have to keep in
>> > mind that time offset by it's definition is changing itself, suddenly,
>> > depending of daylight saving and time zone.
>> >
>> 
>> I think your misinterpreting the intent here. If you specify a timestamp
>> with offset, it is fixed.
>
> That is what you say. And I am pointing out to international standard
> references.
>
> If you use offset as "fixed" it means such use would not be by
> standard, and you would confusing users and programmers who are using
> standard for calculations in programs.
>
>> It does not change with daylight savings or any other change in
>> rules for a time zone. It does not even specify a time zone.
>
> And while and before making that decision, did you review the standard
> that time zone offset is influenced and changed by daylight savings?
>
> It does not specify time zone. But it is derived from time zone, and
> is not same from time zone.
>
> Are you aware that time zone offset could have "skipped time" or
> "added time" due to daylight savings?
>
> That implies that by using time offset, you would forget daylight
> savings which are international standard, and make calculations wrong,
> because you started applying own standard in Org.
>

I think your still misunderstanding what is meant by offset.

Yes, a timezone is defined by the offset it has from UTC
Yes, a location time zone may change due to various reasons, such as
daylight savings time, which also means the offset for that timezone
changes. However, it is the time zone definition which has
changed. THink of it as a time zone with a new offset rather than a time
zone with a chagned offset. 

When you specify a date+time wiht an explicit offset, that offset is
fixed. That date+time is fixed. It will not change when daylight davings
comes in or goes out because it isn't a time zone. It is only an offset
and has no location reference and therefore no time zone.

Saying that an offset is a fixed value is very different from saying
that a time zone has a fixed offset. I think this is where your
confusion is coming from. 

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

[Jean Louis]

* Tim Cross <theophilusx@gmail.com> [2023-01-29 23:38]:
> Yes, a timezone is defined by the offset it has from UTC

Other way around Tim, the UTC offset is defined for the time zone.

Time zone is not derived fro UTC offset, that does not work. UTC
offset is derived from time zone.

> Yes, a location time zone may change due to various reasons, such as
> daylight savings time, which also means the offset for that timezone
> changes.

Including that offset for that time zone can be changed for political
reasons, and did change in past, and some time zones may multiple UTC
offsets.

> However, it is the time zone definition which has changed.

Yes, and that change is about UTC offset. As time zone represents
location but UTC offset must be tied to it, otherwise how would you
know what time has the time zone?

> When you specify a date+time wiht an explicit offset, that offset is
> fixed.

It is fixed for that time moment. I have not said anything
different. 

I am only worried that if calculation go straight from UTC offset to
UTC offset without observig time zones, one will get proper UTC time,
but not proper representation in users' time zone.

I do believe that Org developers will make right decisions.

> That date+time is fixed. It will not change when daylight davings
> comes in or goes out because it isn't a time zone. It is only an
> offset and has no location reference and therefore no time zone.

For the above, I have already sent a map, by only observing the map,
one can see that time offset is directly related to time zone, it is
property of time zone, and it will change depending of political
changes, and it does change with daylight savings time. I have given
enough references, feel free to read it.

What does not change is the fact that UTC offset representation will
accurately provide UTC time.

From UTC time, by using user's time zone and various embedded
parameters one could arrive to user's local time, including users UTC
offset.

Excercise:

When there is daylight savings time (clock goes forward or backward),
it shall be clear that UTC offset changes as well. That means one hour
more or less must be accounted for in every calculations of Org
Agenda.

But by using UTC offset alone, one cannot even include daylight
savings time changes! As for that one needs time zone.

Here is another good reference:
https://spin.atomicobject.com/2016/07/06/time-zones-offsets/

,----
| Our Example
| 
| America/Coral_Harbour is a time zone (for simplicity, I will focus
| only on IANA* time zones). America/Detroit is a time zone. With laws
| as they are now, the America/Coral_Harbour time zone has an unchanging
| offset of -0500, or five hours “behind” GMT, which for our purposes
| here matches UTC. America/Detroit changes during the year from an
| -0400 offset to an -0500 offset. So sometimes, the good people of
| Coral Harbour and the good people of Detroit have the same
| offset. Sometimes, they don’t.
`----

What do you think, is that information true?

Does UTC offset "change" or "remain fixed"?

Is it possible for programmer to convert UTC offset by using direct
calculations?

Or programmer needs to know information about time zones?

This makes calculations of Org Agenda or future time stamps difficult
when using solely UTC time offset.

Time offset is best expressed as representation of time at that time
point, and is always derived from the time zone.

> Saying that an offset is a fixed value is very different from saying
> that a time zone has a fixed offset. I think this is where your
> confusion is coming from. 

I said neither of those. I never said that UTC offset is fixed. I am
trying to give you references that you understand what people agreed
on this planet.

I never said that time zone has fixed offset, some time zones have it
fixed, some not, as UTC offset changes for daylight savings and
political reasons.

-- 
Jean

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

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

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-29 23:38]:
>> Saying that an offset is a fixed value is very different from saying
>> that a time zone has a fixed offset. I think this is where your
>> confusion is coming from. 
>
> I said neither of those. I never said that UTC offset is fixed. I am
> trying to give you references that you understand what people agreed
> on this planet.
>
> I never said that time zone has fixed offset, some time zones have it
> fixed, some not, as UTC offset changes for daylight savings and
> political reasons.

Jean,

you have a very irritating habit of changing the topic of the discussion
in order to push whatever you feel you want to argue about. My response
to you had nothing to do with all the irrelevant points you insist on
repeating despite numerous attempts by many to explain why what you are
sending is adding little value.

I was simply responding to your response to Sterling's glossary of
definitions where you argue against defining offset (the term) as a
fixed value.

I will not be engaging with you further.

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

[Jean Louis]

* Tim Cross <theophilusx@gmail.com> [2023-01-31 01:05]:
> Jean,
> 
> you have a very irritating habit of changing the topic of the discussion
> in order to push whatever you feel you want to argue about. My response
> to you had nothing to do with all the irrelevant points you insist on
> repeating despite numerous attempts by many to explain why what you are
> sending is adding little value.
> 
> I was simply responding to your response to Sterling's glossary of
> definitions where you argue against defining offset (the term) as a
> fixed value.
> 
> I will not be engaging with you further.

UTC offsets have been assigned by authorities, that they are
political, change due to daylight savings -- and for that reason
cannot alone as such be used for calculations of time, for example in
Org Agenda.

I fully understand that representation of time with UTC offset alone
is as such fine and good, never said anything opposite.

Adding some hours, days, as absolute time to it, or deducting, it is
of course always possible.

I have given facts, and references with the sole intention to help in
understanding so that Org programmers do not start relying on UTC
offset alone, as that is not how other programs work.

My intention is of course not what you stated. 

I have not get bad intentions. Please do not assume it.

You got references showing that it is politically related, that UTC
offset does change suddenly, and for that reason one cannot just use
it for calculations in program.

I am fully aware and never stated different, that once you place UTC
offset as representation somewhere in text, that it is offset from UTC
time and that time point is fine and remains fixed.

What I am saying is that calculating that time point to local time is
tricky, as using UTC offset alone is not going to give accurate local
time unambiguously. Sometimes it will give, but sometimes not if
programmer uses direct calculation.

"fixed" is thus only fixed in context of representation.

I was thinking we speak here of using time objects for calculating
times in future, not only of representation, as I did not argue about
it.

UTC offset is representation as it has to be derived from time zone to
be represented as such. Provided that program knew how to derive
correct UTC offset, that is "fixed" as representation.

Programmer can now add some time or deduct some time and directly
added or deducted time will also represent some point in time.

But will it be that time that user was thinking for another user in
different time zone?

Unambiguously is not possible to use only UTC offset for such
calculation, due to reason that UTC offset changes how authorities
decide on it.

Let me try to make exercise example both for me and other people, and
feel free to correct me:

From:
https://www.timeanddate.com/news/time/europe-starts-dst-2022.html

,----
| Daylight Saving in Europe
| 
| Time changes in Europe are synchronized. According to the current EU
| law, DST starts on the last Sunday of March and ends on the last
| Sunday of October. Participating countries are:
| 
| The European Union (EU), including Bulgaria, France, Germany,
| Italy, Poland, and Spain. 
`----

- Last Sunday of March in 2022 was 27th March 2022, or 2022-03-27

- the clock forward had to be done at 1 hour UTC time on March 27th
  2022, because Berlin before 27th March 2022, was with UTC offset +1,
  that time should be 2022-03-27 01:00 UTC time, which is also same as
  Berlin time. 

- Let us say one second after 2022-03-27 01:00 UTC time or UTC +1, the
  clock will not be 2022-03-27 01:00 UTC, but 2022-03-27 02:00 UTC,
  loosing one hour, as clock moved forward. UTC offset changed
  suddenly.

- person in Berlin plans meeting for on 26th March with somebody in
  China, for 27th March 2022 at 10 o'clock, how is he going to
  represent this? Let us see, maybe as
  following. <2022-03-27 Sun 10:00>

- on 26th March 2022, the UTC offset in Berlin was +1

- on 26th March 2022, when user exports that appointment, the time was
  for example 16 o'clock, something like 2022-03-27 16:00+01 because
  UTC offset was +1 at that time.

- If Org programmer decides to use UTC offset only for calculations,
  then the program will know that UTC offset in China is +8 hours.

- What will program do? By using UTC offset only, program will know
  that now is 2022-03-27 16:00+01 and that timestamp like
  <2022-03-27 Sun 10:00> is also with UTC offset +1 (which is not
  true). But program would think it is 2022-03-27 10:00+01 if program
  uses UTC offset only.

- Program may wish to provide new UTC offset for Chinese user, by
  knowing that in China on 26th March 2022, at 16 o'clock is +8 and
  not +1, the difference of 7 hours will be added on the time stamp of
  appointment, which is 2022-03-27 17:00+01

- However the time of 27th March 2022 at 10 o'clock Berlin time the
  time in Shanghai was 16 o'clock.

- While Chinese user was in restaurant at 16 o'clock and waiting for
  appointment at 17 o'clock, because he has got calculation with UTC
  offset only, he will be surprised that he missed the appointment.

- Because Org used UTC offset for calculations considering it
  "absolute" or "fixed".

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

Using UTC offset time stamps alone cannot be used unambigously to
represent time for Org Agenda or shared appointments or meetings, due
to possible political changes and daylight savings times.

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

[Max Nikulin]

On 31/01/2023 14:04, Jean Louis wrote:
> I have given facts, and references with the sole intention to help in
> understanding so that Org programmers do not start relying on UTC
> offset alone, as that is not how other programs work.

 From my point of view at the beginning you were promoting that Org must 
use purely UTC timestamps just because PostgreSQL recommends timestamptz 
type. Now you are insisting that every timestamp must have timezone with 
rules describing DST and other transitions. In both cases you are doing 
it with excessive passion. Currently you are arguing with people who 
have already agreed that location-based timezones are important, e.g. 
Tim and Thomas. I am in doubts if it is helpful to someone.

P.S.
- There are cases when local time + time zone must be stored.
- There are cases when UTC or UTC + fixed offset must be stored.
- There are cases when UTC or UTC + fixed offset is enough, however time 
zone can be added.

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

[Jean Louis]

* Max Nikulin <manikulin@gmail.com> [2023-01-31 11:16]:
> On 31/01/2023 14:04, Jean Louis wrote:
> > I have given facts, and references with the sole intention to help in
> > understanding so that Org programmers do not start relying on UTC
> > offset alone, as that is not how other programs work.
> 
> From my point of view at the beginning you were promoting that Org must use
> purely UTC timestamps just because PostgreSQL recommends timestamptz
> type.

I am not promoter of "UTC timestamps", you have mixed me maybe with
some other person. Last time you misquoted me.

That PostgreSQL recommends time stamp with time zone is only in so far
related to Org as for program design decisions.

There is plethore of other programs using time, just look in any
calendar and underground.

I do not promote anything, I give suggestions to developers to make
decisions that will not impact people. 

My proposal is not that what you describe, but I will repeat it here
for clarity:

- Timestamps may be left how they are now with small addition

- Time stamp could get time zone (I never said UTC, neither UTC
  offset) -- I would myself never suggest to people to place
  timestamps in time zone, but to simply use the local system time
  zone. Case to use time stamps with time zone would be then when such
  time stamp is isolated in the whole Org file and as such, the task
  has to be sent to other people, shared, or published. This is finely
  grained.

- Heading could have time zone property, then all time stamps in that
  heading would easily be calculated for sharing purposes.

- If not heading, then user could set up file #+TIMEZONE property, if
  such is or should be different to system time zone

- Without any settings in Org, Org may use system time zone to
  calculate future time difference.

And I said that is in Emacs Lisp similar to logical OR:

timestamp-time-zone OR heading-time-zone OR file-time-zone OR system-time-ZONE

So please do not misinterpret and reiterate what I never proposed or suggested.

> Now you are insisting that every timestamp must have timezone with
> rules describing DST and other transitions.

Absolutely not, I cannot find myself in your description.

> In both cases you are doing it with excessive passion.

You are free to describe it as you wish. And?

> Currently you are arguing with people who have already agreed that
> location-based timezones are important, e.g. Tim and Thomas. I am in
> doubts if it is helpful to someone.

I do not argue with people nothing as because of their name or
position, as people are not object of discussion.

Neither my last writing was related to "location based time zone" but
to UTC offset.

All my writing is directed to Org developers to get access to
references before making any decisions how to calculate times.

-- 
Jean

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

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

Re: [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

[Sterling Hooten]

Thanks for the quick feedback!

> On 2023-01-27, at 08:09, Ihor Radchenko <yantar92@posteo.net> wrote:
> 
> 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

Certainly agree that the ISO format can be difficult for humans to read, both from 
the lack of spaces and terse syntax.

This isn’t (much) of a problem from a display format perspective because we can parse 
the encoded format and present the user with a human readable version. So the readability 
issue is more about the encoded format. But unlike the display format, which could follow 
whatever grammar or locale preference of the user, the encoded format must be 
unambiguously parseable. If it’s possible to make the ISO format more human readable 
while still preserving parseability this could be viable.

I’m less arguing against the option for encoding things in a variation of the ISO standard, 
but urging that Org support using an encoding of the ISO format in its raw state.

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

This is correct for the 2019 version of the ISO 8601.

From my understanding the newest ISO draft is incorporating an existing syntax used 
in java.time.ZonedDateTime [JAVAZDT] to allow for time zones. So we could still aim for 
compliance with published standards.

The Internet Extended Date/Time Format  (IXDTF) is a forthcoming standard which 
defines an extension syntax for timestamps as specified in [RFC3339]  which itself is 
compatible with the [JAVAZDT] syntax.

The IXDTF is of particular interest in this situation because the format provides a 
general way to attach any additional information to a timestamp. The authors have done 
a great job of lucidly explaining some of the nuances of timestamps.

https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/

> I will need more time to look through the provided links and think about
> the ideas.

Look forward to your comments!

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

[Ihor Radchenko]

Sterling Hooten <hooten@gmail.com> writes:

>> 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
>
> Certainly agree that the ISO format can be difficult for humans to read, both from 
> the lack of spaces and terse syntax.
>
> This isn’t (much) of a problem from a display format perspective because we can parse 
> the encoded format and present the user with a human readable version. So the readability 
> issue is more about the encoded format. But unlike the display format, which could follow 
> whatever grammar or locale preference of the user, the encoded format must be 
> unambiguously parseable. If it’s possible to make the ISO format more human readable 
> while still preserving parseability this could be viable.

You miss that Org should be readable outside Emacs and also outside text
editor that understands Org specifically. Ideally, one should be able to
read Org files in raw form, using notepad or simple cat command. There
is no such thing as "encoding" vs. "display". The encoded format should
be readable by default as well.

Think of Org tables - would take a great care adding all the redundant
spaces to align things nicely despite an alternative possible approach
purely using fontification. Same for heading tags where the alignment is
done by extra spaces.

> I’m less arguing against the option for encoding things in a variation of the ISO standard, 
> but urging that Org support using an encoding of the ISO format in its raw state.

I do not mind supporting raw ISO as an option. But not as the default representation.

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

[Jean Louis]

* Sterling Hooten <hooten@gmail.com> [2023-01-27 15:50]:
> This isn’t (much) of a problem from a display format perspective
> because we can parse the encoded format and present the user with a
> human readable version.

Org files shall still be readable as plain text IMHO.

As Org textual structure has been adopted by other text editors, and
various applications, it is not feasible to expect that other
editors and applications would be re-writing the displayed text to
show to user their local time.

Only user's local time is friendly to user.

Other options may be added, though focus should be on helping human
and making things easy.

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

[Ihor Radchenko]

Sterling Hooten <hooten@gmail.com> writes:

>> 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.
>
> This is correct for the 2019 version of the ISO 8601.
>
> From my understanding the newest ISO draft is incorporating an existing syntax used 
> in java.time.ZonedDateTime [JAVAZDT] to allow for time zones. So we could still aim for 
> compliance with published standards.

Unfortunately, we have to modify the newer version as well.
2022-07-08T00:14:07+01:00[Europe/Paris] clashes with Org delimiter
syntax.

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

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


I strongly agree with Ihor here. We want our timestamps to be easily
read and understood by users. I have also found the redundant day of the
week information very useful.

While we could argue that with overlays or similar, you could get the
best of both worlds i.e. a storage format which is easy for functions to
parse and a display format which is easy for humans to parse, but that
would also work only when you view your org files within org mode. One
of the benefits of org mode is its plain text nature and that you can
read most org mode files 'raw' and they are quite easy to understand. 

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

[Stefan Nobis]

Ihor Radchenko <yantar92@posteo.net> writes:

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

I think you mean [2023-10-29 02:30 @Europe/Berlin]. :)

-- 
Until the next mail...,
Stefan.

Re: [POLL] Proposed syntax for timestamps with time zone info

[Ihor Radchenko]

Stefan Nobis <stefan-ml@snobis.de> writes:

> Ihor Radchenko <yantar92@posteo.net> writes:
>
>> [2023-03-29 02:30 @Europe/Berlin] is special.
>
> I think you mean [2023-10-29 02:30 @Europe/Berlin]. :)

Yes, indeed. Thanks for pointing it out!

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

[Stefan Nobis]

Jean Louis <louis@gnu.support> writes:

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

That's wrong and you know it. For example

   [2023-10-29 02:30 @Europe/Berlin]

is ambiguous. Period.

And that some examples got a bit off has been quite obvious and has
already been stated. So its not necessary to flog dead horses.

It would also be nice to eventually recognize, that we are talking
about readable syntax for humans, that is sometimes generated,
sometimes manually typed. Most of you comments does not really
resonate with this crucial design goal.

-- 
Until the next mail...,
Stefan.

Re: [POLL] Proposed syntax for timestamps with time zone info

[Jean Louis]

* Stefan Nobis <stefan-ml@snobis.de> [2023-02-03 18:50]:
> Jean Louis <louis@gnu.support> writes:
> 
> > Specifying time zone is not ambiguous as long as you use the TZ
> > database for specifications!
> 
> That's wrong and you know it.

What I know is based on research and good references. It seems you did
not follow it.

> For example
> 
>    [2023-10-29 02:30 @Europe/Berlin]
> 
> is ambiguous. Period.

You may put as many periods as you want.

If you do not know how to generate timestamp that they are conclusive,
then they will be always invalid or ambigous.

Computer program that knows that your timestamp is most probably try
to correct it, as saving time with invalid timestamp with some
programs does not work, as I have demonstrated.

Fact is that some timestamps mentioned in the conversations are
invalid. 

Such invalid timestamps were generated by human, not by computer.

Agree on what people internationally agreed.

Do not generate it in first place.

I can place any kind of text anywhere and I could say it is
"timestamp", but that is valid for me, not for community that relies
on international agreements.

If user wish to do timestamp generation by hand, or some looney
program wish to generate invalid timestamps, I can only say "good
luck", but it is good to warn users and file bug reports for such
program.

Timestamp of course may be generated by human, and it can be ambigous. 

But why would you do that? 

Isn't it better to learn how to write non-ambigous timestamps?

Or even better, to use good program to generate non-amgibious
timestamp?

Every user and programmer should strive to make computer, in this case
Org program, to generate and calculate useful timestamps and how to
increase that usefulness for users by being accurate.

Programmer should not strive to generate invalid timestamps, and then
prolong discussions how timestamp is invalid.

That is programmer's problem. 

We have that problem in Org, solutions are in sight.

It is not international problem at all as it is solved by ISO
representation.

All computer programs should use the internationally accepted time
zone database and not those invalid timestamp representation but valid
timestamp representation.

And user should file bugs when they see that timestamps are either
incorrectly represented, invalid, or there are some problems.

It is easy to observe how will PostgreSQL understand those times with
time zone being Europe/Berlin:

Here it will tell that time of 01:30 has UTC offset of +02:

select '2023-10-29 01:30:00'::timestamp at time zone 'Europe/Berlin';
        timezone        
------------------------
 2023-10-29 01:30:00+02
(1 row)

Here it will tell that time of 02:30 has UTC offset of +01:

select '2023-10-29 02:30:00'::timestamp at time zone 'Europe/Berlin';
        timezone        
------------------------
 2023-10-29 02:30:00+01
(1 row)

Here it will tell that time of 02:30 has UTC offset of +01:

select '2023-10-29 03:30:00'::timestamp at time zone 'Europe/Berlin';
        timezone        
------------------------
 2023-10-29 03:30:00+01
(1 row)

Observe how the timesamp representation changes 
from '2023-10-29 01:59:59+02' to '2023-10-29 02:00:00+01'
and how UTC offset is there to make it very clear.

select '2023-10-29 01:59:59'::timestamp at time zone 'Europe/Berlin';
        timezone        
------------------------
 2023-10-29 01:59:59+02
(1 row)

select '2023-10-29 02:00:00'::timestamp at time zone 'Europe/Berlin';
        timezone        
------------------------
 2023-10-29 02:00:00+01
(1 row)

Above is happening because PostgreSQL observes time zone definition
and knows how to represent that timestamp correctly.

A looney program will not observe time zone, it will generate invalid
or ambigious timestamps.

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

Do use looney programs.

Use timezone database information and international standards to
represent and exchange time related information.

> It would also be nice to eventually recognize, that we are talking
> about readable syntax for humans, that is sometimes generated,
> sometimes manually typed. Most of you comments does not really
> resonate with this crucial design goal.

Teach that human how to represent time correctly.

Teach computer program to help human to correct incorrectly hand
written timestamps to something that is reasonable, like Etar calendar
does 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

[Stefan Nobis]

<tomas@tuxteam.de> writes:

> 2023-03-23 02:30 @Europe/Berlin refers to /two/ points in time, thus
> it /is/ ambiguous.

As far as I understand the definitions, the point in time "2023-03-23
02:30 @Europe/Berlin" is clearly defined as 2023-03-23 02:30 UTC+0100.

A bit more problematic would be "2023-03-26 02:30 @Europe/Berlin".
Strictly speaking, this point in time does not exist, because in the
night from 2023-03-25 to 2023-03-26 the clock will jump from 02:00
directly to 03:00 in the time zone Europe/Berlin. Therefore the
/interpretation/ of this timestamp is ambiguous.

The real problem would be e.g. "2023-10-29 02:30 @Europe/Berlin". This
point in time really exist twice, there is 02A:30 (02:30 UTC+0200) and
02B:30 (02:30 UTC+0100) in this night of switching back from DST to
normal time!

So, in general, only using the time zone name may indeed lead to
ambiguous interpretations of timestamps.

-- 
Until the next mail...,
Stefan.

Re: [POLL] Proposed syntax for timestamps with time zone info

[tomas]

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

On Wed, Feb 01, 2023 at 10:06:15AM +0100, Stefan Nobis wrote:
> <tomas@tuxteam.de> writes:
> 
> > 2023-03-23 02:30 @Europe/Berlin refers to /two/ points in time, thus
> > it /is/ ambiguous.
> 
> As far as I understand the definitions, the point in time "2023-03-23
> 02:30 @Europe/Berlin" is clearly defined as 2023-03-23 02:30 UTC+0100.
> 
> A bit more problematic would be "2023-03-26 02:30 @Europe/Berlin".

[...]

This has already been cleared in the thread: I got the year the
wrong way around.

> The real problem would be e.g. "2023-10-29 02:30 @Europe/Berlin". This
> point in time really exist twice, there is 02A:30 (02:30 UTC+0200) and
> 02B:30 (02:30 UTC+0100) in this night of switching back from DST to
> normal time!
> 
> So, in general, only using the time zone name may indeed lead to
> ambiguous interpretations of timestamps.

...which stems from the fact that the very concept of "time zone"
is somewhat ambiguous, too. Some time zone designations carry the
fact of whether they are supposed to be summer times or not with
them (as with CET/CEST), some not (as above). The time zone database
is only known for a limited time into future and may change with
political vagaries. Yadda, yadda.

If you really want to have fun with this (and this thread hasn't
satisfied your thirst ;-) see [1].

Cheers

[1] https://en.wikipedia.org/wiki/British_Summer_Time#Early_history
-- 
t

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

Re: [POLL] Proposed syntax for timestamps with time zone info

[Stefan Nobis]

<tomas@tuxteam.de> writes:

> ...which stems from the fact that the very concept of "time zone" is
> somewhat ambiguous, too.

Yes - I think most of us here see that. Therefore I really appreciate
the flexible timestamp format Ihor suggested.

> If you really want to have fun with this (and this thread hasn't
> satisfied your thirst ;-) see [1].

Thanks for the link. Very interesting details that I didn't know
about yet.

-- 
Until the next mail...,
Stefan.

Re: [POLL] Proposed syntax for timestamps with time zone info

[Jean Louis]

* tomas@tuxteam.de <tomas@tuxteam.de> [2023-02-01 12:22]:
> ...which stems from the fact that the very concept of "time zone"
> is somewhat ambiguous, too. 

For human who reads it without calculating anything, yes.

For computer which is supposed to be programmed by using the time zone
database, no.

> Some time zone designations carry the fact of whether they are
> supposed to be summer times or not with them (as with CET/CEST),
> some not (as above). The time zone database is only known for a
> limited time into future and may change with political
> vagaries. Yadda, yadda.

Very right. 

At least the history is more certain than the future in regards to
time calculations with computer.

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

[Marcin Borkowski]

Out of curiosity: in what time zone you were when you sent this???


On 2023-10-29, at 02:04, Jean Louis <bugs@gnu.support> wrote:

> * tomas@tuxteam.de <tomas@tuxteam.de> [2023-02-01 12:22]:
>> ...which stems from the fact that the very concept of "time zone"
>> is somewhat ambiguous, too. 
>
> For human who reads it without calculating anything, yes.
>
> For computer which is supposed to be programmed by using the time zone
> database, no.
>
>> Some time zone designations carry the fact of whether they are
>> supposed to be summer times or not with them (as with CET/CEST),
>> some not (as above). The time zone database is only known for a
>> limited time into future and may change with political
>> vagaries. Yadda, yadda.
>
> Very right. 
>
> At least the history is more certain than the future in regards to
> time calculations with computer.


-- 
Marcin Borkowski
http://mbork.pl

Re: [POLL] Proposed syntax for timestamps with time zone info

[tomas]

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

On Mon, Feb 06, 2023 at 04:34:15PM +0100, Marcin Borkowski wrote:
> Out of curiosity: in what time zone you were when you sent this???
> 
> 
> On 2023-10-29, at 02:04, Jean Louis <bugs@gnu.support> wrote:
> 
> > * tomas@tuxteam.de <tomas@tuxteam.de> [2023-02-01 12:22]:

Sorry. I've lost the thread's thread. Are you asking Jean Louis
or me?

Cheers
-- 
t

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

Re: [POLL] Proposed syntax for timestamps with time zone info

[Jean Louis]

* Marcin Borkowski <mbork@mbork.pl> [2023-02-06 18:34]:
> Out of curiosity: in what time zone you were when you sent this???

In EAT, by heart in Berlin, Europe, at time in future during
DST, as to test various features.

Forgot to change time back by using NTP.

And e-mail went, discovering few problems in the mailing list
software, and Dino messenger.

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

[Jean Louis]

* Stefan Nobis <stefan-ml@snobis.de> [2023-02-01 12:13]:
> <tomas@tuxteam.de> writes:
> 
> > 2023-03-23 02:30 @Europe/Berlin refers to /two/ points in time, thus
> > it /is/ ambiguous.
> 
> As far as I understand the definitions, the point in time "2023-03-23
> 02:30 @Europe/Berlin" is clearly defined as 2023-03-23 02:30 UTC+0100.
> 
> A bit more problematic would be "2023-03-26 02:30 @Europe/Berlin".
> Strictly speaking, this point in time does not exist, because in the
> night from 2023-03-25 to 2023-03-26 the clock will jump from 02:00
> directly to 03:00 in the time zone Europe/Berlin. Therefore the
> /interpretation/ of this timestamp is ambiguous.

Thank you!

The generation of invalid time stamps is programming bug.

> The real problem would be e.g. "2023-10-29 02:30 @Europe/Berlin". This
> point in time really exist twice, there is 02A:30 (02:30 UTC+0200) and
> 02B:30 (02:30 UTC+0100) in this night of switching back from DST to
> normal time!
> 
> So, in general, only using the time zone name may indeed lead to
> ambiguous interpretations of timestamps.

Exactly! Thank you!

With the correction that "this point in time really exists twice" --
well, not like that, you have specified 2 different time points by
specifying different UTC offset, so those are different time
points. Though I got your ▲

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

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

[Fraga, Eric]

Ihor,

given a choice, I would vote for the second (using @) but would be happy
with either.  My needs are simple, however, so whatever is easiest to
implement would be fine with me.  I'm not bothered, for instance, about
the daylight savings transition as I'm usually in bed... ;-)

But I definitely would love to have time zones of some sort as I'm
frequently travelling between different zones and having meetings across
zones.

Thank you in advance!

eric

-- 
: Eric S Fraga, with org release_9.6.1-199-g7ad779 in Emacs 30.0.50

Re: [POLL] Proposed syntax for timestamps with time zone info

[Ihor Radchenko]

"Fraga, Eric" <e.fraga@ucl.ac.uk> writes:

> given a choice, I would vote for the second (using @) but would be happy
> with either.  My needs are simple, however, so whatever is easiest to
> implement would be fine with me.  I'm not bothered, for instance, about
> the daylight savings transition as I'm usually in bed... ;-)

To clarify, it is not first or second. (1), (2), and (3) are all the
options to be incorporated. It is not a choice. Users just might need
different combinations depending on specific needs.

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

[Fraga, Eric]

Hi Ihor,

On Tuesday, 31 Jan 2023 at 18:13, Ihor Radchenko wrote:
> To clarify, it is not first or second. (1), (2), and (3) are all the
> options to be incorporated. It is not a choice. Users just might need
> different combinations depending on specific needs.

Ahhh, my bad.  Okay, works for me then!  More than I need (at the
moment, of course).

Thanks again,
eric

-- 
: Eric S Fraga, with org release_9.6.1-199-g7ad779 in Emacs 30.0.50

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>

POSIX TS spec reverses the meaning of TZ offset compared to ISO (was: [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 ]

Christian Moe <mail@christianmoe.com> writes:

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

This is probably something we need to discuss further.

Dear All,

There is potential confusion coming from the different interpretations
of the time zone offsets used in ISO8601 and POSIX TZ specs:

https://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators:

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

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

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

So, the equivalent time zone offsets in, say, Singapore will be:

[2023-02-01 12:00 @Asia/Singapore]
[2023-02-01 12:00+08] ;; local time 8 hours earlier than UTC as in ISO8601 spec
[2023-02-01 12:00 @UTC-08] ;; UTC is 8 hours earlier than local time as in POSIX TZ spec

This is potentially confusing.

We may, in theory, reverse the meaning of @UTC[+-]NN manually, but then
values like @EST+5 will remain reversed, again creating the confusion.
Or, if we reverse everything in @..., users more familiar with POSIX TZ
will get confused.

Any ideas?

-- 
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: POSIX TS spec reverses the meaning of TZ offset compared to ISO (was: [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: 757 bytes --]

On Wed, Feb 01, 2023 at 01:26:36PM +0000, Ihor Radchenko wrote:
> [ adding Org ML back to CC ]
> 
> Christian Moe <mail@christianmoe.com> writes:
> 
> >> Note, however, that because we are conforming to POSIX TZ, @UTC+2 is two
> >> hours _behind_ the Greenwich.
> >
> > Ouch.
> 
> This is probably something we need to discuss further.
> 
> Dear All,
> 
> There is potential confusion coming from the different interpretations
> of the time zone offsets used in ISO8601 and POSIX TZ specs:

This is unfortunate indeed. I'd tend to pick one and not to allow
both, out of fear of counfusion. And if I had to pick one, I'd pick
ISO, which I've seen more often in the wild. But this might quite
well be some sort of bias.

Cheers
-- 
t

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

Re: POSIX TS spec reverses the meaning of TZ offset compared to ISO (was: [POLL] Proposed syntax for timestamps with time zone info

[Heinz Tuechler]

tomas@tuxteam.de wrote/hat geschrieben on/am 01.02.2023 14:51:
> On Wed, Feb 01, 2023 at 01:26:36PM +0000, Ihor Radchenko wrote:
>> [ adding Org ML back to CC ]
>>
>> Christian Moe <mail@christianmoe.com> writes:
>>
>>>> Note, however, that because we are conforming to POSIX TZ, @UTC+2 is two
>>>> hours _behind_ the Greenwich.
>>>
>>> Ouch.
>>
>> This is probably something we need to discuss further.
>>
>> Dear All,
>>
>> There is potential confusion coming from the different interpretations
>> of the time zone offsets used in ISO8601 and POSIX TZ specs:
>
> This is unfortunate indeed. I'd tend to pick one and not to allow
> both, out of fear of counfusion. And if I had to pick one, I'd pick
> ISO, which I've seen more often in the wild. But this might quite
> well be some sort of bias.
>
> Cheers
>
Same for me, I usually see ISO offset. Further, I am used to exchange
time designations (CET, EST, PDT,...) instead of [continent/city]
timezone names. My impression is that many of non experts like me don't
know in which time zone they are living. Is it trivial to find the
[continent/city] timezone name to a specific place?
best, Heinz

Re: POSIX TS spec reverses the meaning of TZ offset compared to ISO (was: [POLL] Proposed syntax for timestamps with time zone info

[Samuel Wales]

perhaps some cities are not listed?  what is one supposed to do then?
find a city with equivalent geography and tz policy?


On 2/1/23, Heinz Tuechler <tuechler@gmx.at> wrote:
> tomas@tuxteam.de wrote/hat geschrieben on/am 01.02.2023 14:51:
>> On Wed, Feb 01, 2023 at 01:26:36PM +0000, Ihor Radchenko wrote:
>>> [ adding Org ML back to CC ]
>>>
>>> Christian Moe <mail@christianmoe.com> writes:
>>>
>>>>> Note, however, that because we are conforming to POSIX TZ, @UTC+2 is
>>>>> two
>>>>> hours _behind_ the Greenwich.
>>>>
>>>> Ouch.
>>>
>>> This is probably something we need to discuss further.
>>>
>>> Dear All,
>>>
>>> There is potential confusion coming from the different interpretations
>>> of the time zone offsets used in ISO8601 and POSIX TZ specs:
>>
>> This is unfortunate indeed. I'd tend to pick one and not to allow
>> both, out of fear of counfusion. And if I had to pick one, I'd pick
>> ISO, which I've seen more often in the wild. But this might quite
>> well be some sort of bias.
>>
>> Cheers
>>
> Same for me, I usually see ISO offset. Further, I am used to exchange
> time designations (CET, EST, PDT,...) instead of [continent/city]
> timezone names. My impression is that many of non experts like me don't
> know in which time zone they are living. Is it trivial to find the
> [continent/city] timezone name to a specific place?
> best, Heinz
>
>


-- 
The Kafka Pandemic

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

Re: POSIX TS spec reverses the meaning of TZ offset compared to ISO (was: [POLL] Proposed syntax for timestamps with time zone info

[Ihor Radchenko]

Samuel Wales <samologist@gmail.com> writes:

> perhaps some cities are not listed?  what is one supposed to do then?
> find a city with equivalent geography and tz policy?

Time zones have nothing to do with cities. The same city may have
multiple time zones in some cases. You just need to know that current
time zone in the area of interest. There is no universal automatic way.
The best we can do it providing completion mechanism, like for time zone
abbreviations.

-- 
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: POSIX TS spec reverses the meaning of TZ offset compared to ISO (was: [POLL] Proposed syntax for timestamps with time zone info

[Max Nikulin]

On 02/02/2023 04:57, Heinz Tuechler wrote:
> My impression is that many of non experts like me don't
> know in which time zone they are living.

For you own time zone: Open Development tools in a browser ([F12]), 
switch to console, type

      new Intl.DateTimeFormat().resolvedOptions().timeZone

I am sure there are a lot of web pages that do the same.

On linux you can use the following tool

     timedatectl

Unfortunately Emacs does not have API to obtain time zone identifier, 
only offset and abbreviation are exposed by GNU libc. POSIX does not 
have such requirement.

> Is it trivial to find the [continent/city] timezone name to a specific
> place?

For other places: since data to build time zone map are available, there 
should be web sites that allows to find identifier for any location. 
Sorry, I do not use them, so I can not recommend a particular one.

An application that is able to read locally installed tzdata may assist 
by filtering the list by time offset or by the continent (or the ocean, 
see e.g. Pacific/Apia trips across the International date line to 
America and back to Asia with Australia).

Re: POSIX TS spec reverses the meaning of TZ offset compared to ISO

[Heinz Tuechler]

Max Nikulin wrote/hat geschrieben on/am 02.02.2023 04:22:
> On 02/02/2023 04:57, Heinz Tuechler wrote:
>> My impression is that many of non experts like me don't
>> know in which time zone they are living.
>
> For you own time zone: Open Development tools in a browser ([F12]),
> switch to console, type
>
>      new Intl.DateTimeFormat().resolvedOptions().timeZone
>

Thank you, Max.
It seems to me that this shows the time zone I selected at set up of the
computer, in my case Europe/Berlin. Using package lutz in R with correct
coordinates I see Europe/Vienna, based on open street map.
Days ago I did not even know that Berlin and Vienna are in different
time zones.

> I am sure there are a lot of web pages that do the same.
>
> On linux you can use the following tool
>
>     timedatectl
>
> Unfortunately Emacs does not have API to obtain time zone identifier,
> only offset and abbreviation are exposed by GNU libc. POSIX does not
> have such requirement.
>
>> Is it trivial to find the [continent/city] timezone name to a specific
>> place?
>
> For other places: since data to build time zone map are available, there
> should be web sites that allows to find identifier for any location.
> Sorry, I do not use them, so I can not recommend a particular one.
>
> An application that is able to read locally installed tzdata may assist
> by filtering the list by time offset or by the continent (or the ocean,
> see e.g. Pacific/Apia trips across the International date line to
> America and back to Asia with Australia).
>

Re: POSIX TS spec reverses the meaning of TZ offset compared to ISO

[tomas]

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

On Thu, Feb 02, 2023 at 08:45:51AM +0100, Heinz Tuechler wrote:
> Max Nikulin wrote/hat geschrieben on/am 02.02.2023 04:22:
> > On 02/02/2023 04:57, Heinz Tuechler wrote:
> > > My impression is that many of non experts like me don't
> > > know in which time zone they are living.
> > 
> > For you own time zone: Open Development tools in a browser ([F12]),
> > switch to console, type
> > 
> >      new Intl.DateTimeFormat().resolvedOptions().timeZone
> > 
> 
> Thank you, Max.
> It seems to me that this shows the time zone I selected at set up of the
> computer, in my case Europe/Berlin. Using package lutz in R with correct
> coordinates I see Europe/Vienna, based on open street map.
> Days ago I did not even know that Berlin and Vienna are in different
> time zones.

Vienna is special :)

But no: there's no /usr/share/zoneinfo/Europe/Vienna. I think what you
are seeing is just a trick to improve "User Experience".

Cheers
-- 
t

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

Re: POSIX TS spec reverses the meaning of TZ offset compared to ISO

[Heinz Tuechler]

tomas@tuxteam.de wrote/hat geschrieben on/am 02.02.2023 09:33:
> On Thu, Feb 02, 2023 at 08:45:51AM +0100, Heinz Tuechler wrote:
>> Max Nikulin wrote/hat geschrieben on/am 02.02.2023 04:22:
>>> On 02/02/2023 04:57, Heinz Tuechler wrote:
>>>> My impression is that many of non experts like me don't
>>>> know in which time zone they are living.
>>>
>>> For you own time zone: Open Development tools in a browser ([F12]),
>>> switch to console, type
>>>
>>>      new Intl.DateTimeFormat().resolvedOptions().timeZone
>>>
>>
>> Thank you, Max.
>> It seems to me that this shows the time zone I selected at set up of the
>> computer, in my case Europe/Berlin. Using package lutz in R with correct
>> coordinates I see Europe/Vienna, based on open street map.
>> Days ago I did not even know that Berlin and Vienna are in different
>> time zones.
>
> Vienna is special :)

Not sure, in
https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
Europe/Vienna is listed as a canonical TZ database name.

>
> But no: there's no /usr/share/zoneinfo/Europe/Vienna. I think what you
> are seeing is just a trick to improve "User Experience".
>
Searching for /usr/share/zoneinfo/Europe/Vienna
with startpage.com I see it e.g. in
https://packages.ubuntu.com/focal/all/tzdata/filelist or
https://www.apt-browse.org/browse/debian/wheezy/main/all/tzdata/2016d-0+deb7u1/file/usr/share/zoneinfo/Europe

> Cheers
>

Re: POSIX TS spec reverses the meaning of TZ offset compared to ISO

[Max Nikulin]

On 02/02/2023 16:37, Heinz Tuechler wrote:
> tomas wrote/hat geschrieben on/am 02.02.2023 09:33:
>> On Thu, Feb 02, 2023 at 08:45:51AM +0100, Heinz Tuechler wrote:
>>> It seems to me that this shows the time zone I selected at set up of the
>>> computer, in my case Europe/Berlin. Using package lutz in R with correct
>>> coordinates I see Europe/Vienna, based on open street map.
>>> Days ago I did not even know that Berlin and Vienna are in different
>>> time zones.

It is not uncommon problem. People set a time zone having the same 
offset and later complain that historical data can not be trusted.

Ubuntu guesses timezone likely using their GeoIP service. For me it 
works correctly. Approach implemented in Debian installer can be called 
at least questionable. They allows to choose from incomplete subset of 
time zones that is based on locale (selected several steps before). 
Developers refuse requests to add an option with complete list of time 
zones. So some users either finishes with incorrect time zone or have to 
run dpkg-reconfigure tzdata.

I forgot to mention some methods to guess location and so time zone when 
I was writing https://list.orgmode.org/orgmode/tqj9af$vhk$1@ciao.gmane.io/

>> Vienna is special :)

There is no reason to add a timezone if there is nothing special.

zdump -v Europe/Berlin

Europe/Berlin  Sun Sep 28 00:59:59 1980 UT = Sun Sep 28 02:59:59 1980 
CEST isdst=1 gmtoff=7200
Europe/Berlin  Sun Sep 28 01:00:00 1980 UT = Sun Sep 28 02:00:00 1980 
CET isdst=0 gmtoff=3600

zdump -v Europe/Vienna

Europe/Vienna  Sat Sep 27 21:59:59 1980 UT = Sat Sep 27 23:59:59 1980 
CEST isdst=1 gmtoff=7200
Europe/Vienna  Sat Sep 27 22:00:00 1980 UT = Sat Sep 27 23:00:00 1980 
CET isdst=0 gmtoff=3600

03:00 -> 02:00 vs 24:00 -> 23:00 transition time.

Re: POSIX TS spec reverses the meaning of TZ offset compared to ISO (was: [POLL] Proposed syntax for timestamps with time zone info

[tomas]

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

On Wed, Feb 01, 2023 at 10:57:47PM +0100, Heinz Tuechler wrote:
> tomas@tuxteam.de wrote/hat geschrieben on/am 01.02.2023 14:51:

[...]

> > This is unfortunate indeed. I'd tend to pick one and not to allow
> > both, out of fear of counfusion. And if I had to pick one, I'd pick
> > ISO [...]

> Same for me, I usually see ISO offset. Further, I am used to exchange
> time designations (CET, EST, PDT,...) instead of [continent/city]
> timezone names [...]

Note that they mean subtly different things: CET is "Central European
Time", which has a fixed offset of one hour. Europe/Berlin rather means
"whatever offset is valid at this time" (which, as we have seen, is
ambiguous some of the time and faulty at the other end).

You want the second if you want to schedule a regular meeting in your
city at the local bar. You want the first in a log file.

Cheers
-- 
t

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

Re: POSIX TS spec reverses the meaning of TZ offset compared to ISO (was: [POLL] Proposed syntax for timestamps with time zone info

[Ihor Radchenko]

Heinz Tuechler <tuechler@gmx.at> writes:

> Same for me, I usually see ISO offset. Further, I am used to exchange
> time designations (CET, EST, PDT,...) instead of [continent/city]
> timezone names.

While I see a push towards using time zone abbreviations, we should not
make them a part of the syntax.

If we take a look at https://en.wikipedia.org/wiki/List_of_time_zone_abbreviations
it states:

    Time zones are often represented by alphabetic abbreviations such as
    "EST", "WST", and "CST", but these are not part of the international
    time and date standard ISO 8601 and their use as sole designator for
    a time zone is discouraged. Such designations can be ambiguous; for
    example, "CST" can mean China Standard Time (UTC+8), Cuba Standard
    Time (UTC−5), and (North American) Central Standard Time (UTC−6),
    and it is also a widely used variant of ACST (Australian Central
    Standard Time, UTC+9:30). Such designations predate both ISO 8601
    and the internet era; in an earlier era, they were sufficiently
    unambiguous for many practical uses within a national context (for
    example, in railway timetables and business correspondence), but
    their ambiguity explains their deprecation in the internet era, when
    communications more often cannot rely on implicit geographic context
    to supply part of the meaning.

The best we can do is supply a completion dialogue and using TZ POSIX
format that is able to understand "SOMERANDOMZONENAME+07" disregarding
the unknown zone and only using the offset.

> ...My impression is that many of non experts like me don't
> know in which time zone they are living. Is it trivial to find the
> [continent/city] timezone name to a specific place?

If you don't need to worry about time zones than honestly you probably
don't need time zones in your timestamps. And at least you know the UTC
offset, don't you? Time zone abbreviation will gain you nothing if you
know UTC offset because time zone abbreviations don't code information
about the daylight savings and the likes.

-- 
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: POSIX TS spec reverses the meaning of TZ offset compared to ISO (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Max Nikulin]

On 01/02/2023 20:26, Ihor Radchenko wrote:
> 
> There is potential confusion coming from the different interpretations
> of the time zone offsets used in ISO8601 and POSIX TZ specs:

Ihor, I am sorry that I did not reply to your early question.

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

In a link posted in this thread I noticed the following:
http://naggum.no/lugm-time.html
Erik Naggum. The Long, Painful History of Time. 1999
> 8.2 Timezone Representation
> 
> David Olsen of Digital Equipment Corporation has laid down a tremendous
> amount of work in collecting the timezones of the world and their
> daylight saving time boundaries. Contrary to the Unix System V approach
> from New Jersey (insert appropriate booing for best effect), which
> codifies a daylight saving time regime only for the current year, and
> apply it to all years, David Olsen's approach is to maintain tables of
> all the timezone changes.

POSIX spec neglects history of changes. At certain moment Firefox used 
IANA TZ DB with accurate data while Chrome followed JavaScript spec that 
required POSIX-like approach for local time zone. The latter was pain. I 
consider POSIX TZ as legacy.

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

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

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

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

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

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

[Max Nikulin]

On 02/02/2023 15:34, Ihor Radchenko wrote:
> Max Nikulin writes:
>> Is there a strong reason to support POSIX TZ? Time zones with fixed
>> offsets are available as e.g. Etc/GMT-8 (unfortunately inverted sign as
>> well).
> 
> Because `encode-time' accepts POSIX TZ as argument. So, may as well.
> Note that Etc/GMT-8 is also accepted as POSIX TZ.

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

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

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

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

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

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

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

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

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <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>.

Re: [POLL] Proposed syntax for timestamps with time zone info

[Stefan Nobis]

Ihor Radchenko <yantar92@posteo.net> writes:

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

Hmmm... is it? I read a lot different timestamps these days and
currently I'm very careful reading them, especially while considering
syntax details. Therefore I'm reading slowly and only few timestamps
at once.

But real life sometimes get hectic and stressful. And then I might
only throw a glance at timestamps, hoping to get the important details
- surely I will remember all the important details. :) In these cases I
would much prefer a syntax that is a bit less terse like

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

So I would vote for Timothys variant.

Considering Timothys other proposal:

>> 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 do not like the semantics.

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

I read "@+07,!Asia/Singapore" as "use UTC offset +07 but be aware of
time zone Asia/Singapore, from which I got the offset in the first
place".

On the other hand, I read "@+07,Asia/Singapore" as "use UTC offset
+07, which I got from the Asia/Singapore time zone".

So for me a possible warning should go with the "!" variant. In the
case without "!", for me the syntax suggests a more informative
meaning for the time zone name part.

Therefore I would vote for Ihors variant for this part. :)

-- 
Until the next mail...,
Stefan.

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

[Ihor Radchenko]

Sterling Hooten <hooten@gmail.com> writes:

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

Do I understand correctly that the terms are simply taken from ISO (https://www.iso.org/obp/ui/#iso:std:iso:8601:-1:ed-1:v1:en)? 

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

Note that representing the time zone does not require second/sub-second
precision. Let's not complicate the matters.

Also, [time zone] is not compatible with Org's delimiting syntax. We
need to come up with something else.

> What would a roadmap be?
>
> • Design and implement an absolute and offset timestamp system
>   • Decide on a time scale

UTC. Because we are bound by capabilities of Emacs time API.

>   • Decide on a format and syntax

Sure.

>   • Implement instant timestamps
>   • Implement offeset timestamps

This is all available via Emacs time API as implemented in glibc.
Time db is supported. Time zone names are supported. Fixed offsets are
also supported via TZ POSIX standard
(https://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html).

> • Design and implement the time zone aware calendar system This is a
>   separate project.

Org support for time zones is exactly the calendar system you are
talking about. This will be most of the work TBD.

> What format and syntax should Org use?
>
> A heretical suggestion: We should abandon the day of week abbreviation
> and use a new format.

As you saw from a number of replies, people do find week abbreviation
useful.

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

As I (and others) replied, we will not do it. We aim for human-readable
representation. Hence, while we can draw ideas from EDTF and ISO, we
will not follow them precisely.

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

This would be a breaking change that will force all the libraries adapt.
If we need supporting raw ISO syntax at any point, it can be simply made
a subset of [%%(diary sexp)]. At the end, diary sexps are nothing but
Elisp functions. We don't need to invent yet another syntax for ISO.

> What are the advantages of switching to a standard format for the new
> system?
> ...
> • 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 should not introduce this problem to start with. The versions should
be mutually compatible if at all possible. Note, for example, that
<2023-01-30 Mon 14:00 @Europe/Berlin> does not even break the existing
Org versions, except that time zone part is ignored.

I am strongly against introducing a brand-new timestamp syntax and
abandoning (or maintaining infinitely) the current one.

Proliferation of multiple parallel syntax variants is something we
really want to avoid maintenance-wise.

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

This should only be the last resort. We are not quite there.

> • We can defer to existing parsing and calculating systems There are
>   already programs written which support the ISO standard and EDTF.

No. We can only defer the existing parsing to Elisp time API. Which does
not support EDTF. And supporting approximate dates from EDTF would be
hard to implement anyway - do we really need those?

>   • We can directly (or nearly directly) import the regular expressions
>     and parsing mechanisms already written.

It's not like these regular expressions are particularly complex. And we
are not going to make them complex either way.

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

Or we can write a simple converter from Org syntax to ISO and do the
same. Though I do not know any existing testing suite we could utilize
here.

>   • Users who wish to use external libraries (irrespective of language
>     or license) can extract the new timestamp and parse or calculate
>     externally.

I would not be so dramatic here. We do provide syntax description in
https://orgmode.org/worg/org-syntax.html#Timestamps It is not a big deal
to follow it.

> • Org is part of a standard
>   • We are able to defer to experts and 35 years of knowledge rather
>     than debate among ourselves

How so?

>   • Interfacing with other programs is simplified as the area inside the
>     delimiter notation can be passed as a string without parsing.

No. Org is not context-free. Parsing will be required anyway.

>   • New users and collaborators can be onboarded faster without needing
>     to learn a new system

Is it really so much decisive factor? I doubt so.

>   • Org documentation can refer to the standard instead of bearing the
>     burden of exposition.

That's a plus. But not decisive one.

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

We have to follow POSIX TZ anyway. Maybe with minor additions.

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

Please frame it as a separate proposal. We have enough complexities with
time zones to add this on top.

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

That's all nice but what a headache will it be to implement. What will
2004-06~ mean for agenda, for example?

In any case, it is also out of scope of this specific feature request.

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

No. They cannot. Not by the existing Elisp libraries, available in Emacs
core.

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

> That's all nice but what a headache will it be to implement. What will
> 2004-06~ mean for agenda, for example?

i don't know the specific "2004-06~", but i do think that for the agenda
(i assume), being able to express ambiguity to the user will be
important.  as people have pointed out (and it was new to me), future
time-zoned times are not clearly defined as "political" changes (in
daylight savings time definitions, for example) can change the UTC value
of that time.

- it's exactly at this moment of time

- it's almost certainly at this moment of time (i.e., that's today's
  politics), but that may change as we get closer to that date

- it seems like it might be at, or near, this moment of time

i guess the third is what "2004-06~" might mean (i visualize, in
amusement, a very light pink background over all of June, with some
decay function coming earlier into May, later into July :).

yours in favor of ibuprofen!  cheers, Greg

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

[Ihor Radchenko]

Greg Minshall <minshall@umich.edu> writes:

> i guess the third is what "2004-06~" might mean (i visualize, in
> amusement, a very light pink background over all of June, with some
> decay function coming earlier into May, later into July :).

Maybe. But my point states - it is not trivial thing to implement.
For context, the actual EDTF format is:

Example 1                ‘2004-06-11%’
year, month, and day uncertain and approximate
Example 2                 ‘2004-06~-11’
year and month approximate
Example  3              ‘2004?-06-11’
year uncertain

I do not want to go into this within the scope of this feature request.
Because imprecise dates is completely different feature.

-- 
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, makes sense.  that we probably need to *display* imprecision
doesn't mean we need to accept/parse it.

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

[Max Nikulin]

On 20/01/2023 03:09, Tim Cross wrote:
> 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.
...> 2. A meeting timestamp for a meeting where all the participants are in
> different time zones....

Tim, every scheduled meeting event is associated with some particular 
time zone, often implicitly. So it is single use case.

It is up to participants to negotiate which timezone is the primary one 
for each event. It is matter of people communication, not technical issue.

First Monday 15:00 is (almost) equally precise for
- Australia/Canberra having DST
- Australia/Darwin where currently no DST
- +1000 (the highest chance of improper use unfortunately)
- UTC

Aside from time transition intervals, it is possible to take any of this 
variant and to present time local for other participant across the globe.

Storage timezone may differ from the current user preference which time 
zone should be used to display timestamp or to export it.

The problem arises when several participants believe that their 
timezones are primary ones and they do not sync their schedules through 
a shared file or a DB entry. An application can not solve this problem, 
but it might try to help to identify it. Some efforts are necessary from 
user side. Timestamp should contain list of timezones of other 
participants and cached local time. In such case an application may warn 
users that local time values become inconsistent due to DST transitions 
or due to update of time zone database. Unsure to what degree it should 
be implemented in Org.

So
- It is participants fault if a meeting is not associated with 
particular timezone
- Having a fair time handling library, it does not matter what time zone 
is used to schedule the meeting.

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

[Tim Cross]

Max Nikulin <manikulin@gmail.com> writes:

> On 20/01/2023 03:09, Tim Cross wrote:
>> 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.
> ...> 2. A meeting timestamp for a meeting where all the participants are in
>> different time zones....
>
> Tim, every scheduled meeting event is associated with some particular time zone, often
> implicitly. So it is single use case.
>

No, I disagree with that statement. That is old thinking based when
meetings meant face to face meetings. Only meeting which have a specific
location can have a time zone and even then, it isn't really the
meetings time zone, but instead the time zone of the participants at the
meeting.

Meetings without a specific location do not have time zones, implicit or
otherwise. If you have an on-line meeting with 5 people from 5 different
time zones, there is no time zone which takes precedence and cna be
thought of as the meeting time zone. You could decide to do that if you
wanted, but it doesn't achieve anything useful. 

> It is up to participants to negotiate which timezone is the primary one for each event. It
> is matter of people communication, not technical issue.
>

The issue I'm talking about has nothing to do with the other
participants of the meeting. It is irrelevant to them when my time zone
changes due to daylight savings.

> First Monday 15:00 is (almost) equally precise for
> - Australia/Canberra having DST
> - Australia/Darwin where currently no DST
> - +1000 (the highest chance of improper use unfortunately)
> - UTC
>

That is a bad example and is wrong. Australia/Canberra and
Australia/Darwin are different timezones regardless. Darwin is +930 and
Canberra is +1000 (+1100 with DS). So Monday 15;00 in Darwin will be at
15:30 in Canberra outside DS time and 16:30 during DS time.

> Aside from time transition intervals, it is possible to take any of this variant and to
> present time local for other participant across the globe.
>
> Storage timezone may differ from the current user preference which time zone should be
> used to display timestamp or to export it.
>
> The problem arises when several participants believe that their timezones are primary ones
> and they do not sync their schedules through a shared file or a DB entry. An application
> can not solve this problem, but it might try to help to identify it. Some efforts are
> necessary from user side. Timestamp should contain list of timezones of other participants
> and cached local time. In such case an application may warn users that local time values
> become inconsistent due to DST transitions or due to update of time zone database. Unsure
> to what degree it should be implemented in Org.
>

and this is not the issue I'm trying to solve here. At no time did I
reference booking meetings or scheduling meetings with others. This has
nothing to do with eh use case I was outlining. 

> So
> - It is participants fault if a meeting is not associated with particular timezone
> - Having a fair time handling library, it does not matter what time zone is used to
>  schedule the meeting.

OK, I just give up.

I don't understand why my very simple point seems so hard for anyone to
grasp and why everyone seems so focused on the booking and scheduling of
meetings with outhers. This was never in the scope of the very simple
issue I want solved. 

All I want is for org to tell me when my meeting is. I don't care about
other people's time zones or when the meeting is for them, I don't care
who books the meeting and I don't care whether someone feels the meeting
has a time zone or not because it is all totally irrelevant for my use
case.

This is very very simple and doesn't need to be over thought.

I have two reoccurring meetings.

Meeting 1. All of the people for this meeting are in my time zone. When
daylight savings transitions occur, there is no impact. THis is how org
timestamps work now. Nothing is required.

Meeting 2. This meeting has 5 participants. They are all in different
time zones. When daylight savings time transitions occur in my timezone,
I need the time stamp to report an adjusted time based on the change
(either forward or back 1 hour). Currently, org cannot manage this and
my meeting time is out by one hour for 6 months of the year. 

How is this handled by org?

My suggested solution, which I feel is quite simple is to simply use a
timestamp with a UTC or Etc/UTC value for the time zone for meetings
with participants from different time zones and where the time of the
meeting must remain constant with respect to UTC. Assuming that once org
timestamps handling has been updated to display timestamps according to
the local time zone, the issue with the second meeting example is
solved. Thats it, done.

You might sayh this isn't a technical issue, but it can obviously be
solved adopting a technical solution.

All that remains is to work out a good interface to make it easy to set
the correct timestamp type (i.e. in local time or UTC) based on the
requirements for that meeting (which is determined by whether the
meeting has any participants in different time zones). How sophisticated
we want ot make this is undecided. My simple sugestion wa that have the
commands which insert timestamps use the universal argument - when
called with the universal argument, set the timestamp using UTC and when
it isn't, set it as it is now (or set it with the local TZ added, based
on user preference).

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

[Max Nikulin]

On 20/01/2023 12:39, Tim Cross wrote:
> 
> No, I disagree with that statement. That is old thinking based when
> meetings meant face to face meetings. Only meeting which have a specific
> location can have a time zone and even then, it isn't really the
> meetings time zone, but instead the time zone of the participants at the
> meeting.

Tim, I am trying to say that any meeting either face to face or on-line 
may be associated with arbitrary primary timezone. Even when all 
participants are in Sydney they may decide to fix time in Darwin. It is 
strange, but it is possible. UTC is just one of time zones that may be 
convenient for on-line meeting despite no participant really use it. 
Local timezone is usually preferred for purely face to face meetings. 
You are not realizing that is decision since it is not verbalized. 
Consider timezone as something unrelated to location but just a set of 
rules how time offset in respect to epoch evolves in time.

UI might offer you to choose time in your timezone and to select another 
timezone for storage. For your convenience it still may be presented to 
you in your local timezone even it is stored in UTC or some other one.

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

[Tim Cross]

Max Nikulin <manikulin@gmail.com> writes:

> On 20/01/2023 12:39, Tim Cross wrote:
>> No, I disagree with that statement. That is old thinking based when
>> meetings meant face to face meetings. Only meeting which have a specific
>> location can have a time zone and even then, it isn't really the
>> meetings time zone, but instead the time zone of the participants at the
>> meeting.
>
> Tim, I am trying to say that any meeting either face to face or on-line may be associated
> with arbitrary primary timezone. Even when all participants are in Sydney they may decide
> to fix time in Darwin. It is strange, but it is possible. UTC is just one of time zones
> that may be convenient for on-line meeting despite no participant really use it. Local
> timezone is usually preferred for purely face to face meetings. You are not realizing that
> is decision since it is not verbalized. Consider timezone as something unrelated to
> location but just a set of rules how time offset in respect to epoch evolves in time.
>

and what you are saying is helpful how? In what way does what you are
sayhing help address my use case?




> UI might offer you to choose time in your timezone and to select another timezone for
> storage. For your convenience it still may be presented to you in your local timezone even
> it is stored in UTC or some other one.

and I have said as much. So, how exactly is your contribution assisting
with the use case I've outlined?

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

[Max Nikulin]

On 20/01/2023 15:11, Tim Cross wrote:
> Max Nikulin writes:
> 
>> Tim, I am trying to say that any meeting either face to face or on-line may be associated
>> with arbitrary primary timezone.
> 
> and what you are saying is helpful how? In what way does what you are
> sayhing help address my use case?

Tim, are you trying to convince me that for Org it is enough to have 
timestamps either as local time <2023-02-20 15:00> or as UTC something 
like <2023-02-20 05:00Z> and ability to specify arbitrary timezone 
instead of UTC is redundant?

I believe that in the case of support of optional arbitrary timezone in 
Org files there is no point of distinction between you cases when all 
participants meet face to face (<2023-02-20 15:00> or <2023-02-20 
15:00@Australia/Sydney>) or it is online meeting scheduled as 
<2023-02-20 09:00@Etc/UTC>.

>> UI might offer you to choose time in your timezone and to select another timezone for
>> storage. For your convenience it still may be presented to you in your local timezone even
>> it is stored in UTC or some other one.
> 
> and I have said as much. So, how exactly is your contribution assisting
> with the use case I've outlined?

I had a hope to assure you that unifying the cases you are considering 
as distinct should not make user experience worse.

Local event and UTC is meaningful for UI to enter or adjust timestamp 
where such cases should be easier to select than arbitrary timezone. For 
parsing, generating agenda, or export a more abstract model can be used.

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

[Tim Cross]

Max Nikulin <manikulin@gmail.com> writes:

> On 20/01/2023 15:11, Tim Cross wrote:
>> Max Nikulin writes:
>> 
>>> Tim, I am trying to say that any meeting either face to face or on-line may be associated
>>> with arbitrary primary timezone.
>> and what you are saying is helpful how? In what way does what you are
>> sayhing help address my use case?
>
> Tim, are you trying to convince me that for Org it is enough to have timestamps either as
> local time <2023-02-20 15:00> or as UTC something like <2023-02-20 05:00Z> and ability to
> specify arbitrary timezone instead of UTC is redundant?
>

No. I have never stated anything like that. 

> I believe that in the case of support of optional arbitrary timezone in Org files there is
> no point of distinction between you cases when all participants meet face to face
> (<2023-02-20 15:00> or <2023-02-20 15:00@Australia/Sydney>) or it is online meeting
> scheduled as <2023-02-20 09:00@Etc/UTC>.

That is all I've been saying! For meetings where everyone is in same
time zone, just use either <yyyyy-mm-dd hh:mm> OR <yyyy-mm-dd hh:ss
<local timezone>> and for meetings where there are participants from
different time zones, use <yyyy-mm-dd hh:mm ETc/UTC>. That simple.

All that remains is to figure out the best interface to make it easy for
the user to have the correct timestamp for the correct meeting type. 

>
>>> UI might offer you to choose time in your timezone and to select another timezone for
>>> storage. For your convenience it still may be presented to you in your local timezone even
>>> it is stored in UTC or some other one.
>> and I have said as much. So, how exactly is your contribution assisting
>> with the use case I've outlined?
>
> I had a hope to assure you that unifying the cases you are considering as distinct should
> not make user experience worse.
>
> Local event and UTC is meaningful for UI to enter or adjust timestamp where such cases
> should be easier to select than arbitrary timezone. For parsing, generating agenda, or
> export a more abstract model can be used.

I really don't understand your continued reference to 'arbitrary
timezone' or how it is relevant. I also am not clear what you mean by
'unifying the cases'. If you mean handling the two different cases in
the same UI, that is exactly what I've been suggesting. If you mean
using the same time zone for both cases, I don't see how that could
possibly work and if you mean something else, I don't understand.

My position is very simple and very specific. Either use no TZ info or
local TZ spec for meetings where all participants are in the same TZ and
ust UTC where you have participants from different TZs. Note that htis
says nothing about how the timestamp is displayed (I would argue for
user's local time using an overlay or similar, like we do for links and
markup) and it says nothing about how the other participants record the
meeting (it is specific to the org user) and it says nothing about other
users for timestamps - only in reference to scheduled events.

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

[Fraga, Eric]

On Friday, 20 Jan 2023 at 16:39, Tim Cross wrote:
> My simple sugestion wa that have the commands which insert timestamps
> use the universal argument -when called with the universal argument,
> set the timestamp using UTC and when it isn't, set it as it is now (or
> set it with the local TZ added, based on user preference).

+1

I travel a lot; I have meetings arranged with others (online) where I
don't know where I will be.  I simply want to be able to have meeting
times set as UTC and let org tell me when it is depending on which time
zone I am in (as I always update the timezone on my laptop when I change
timezones).

Getting caught up with what happens at the transition to daylight
savings etc. is just a distraction, in my view.  Being able to specify
UTC timestamps and have them displayed in local time will be an
incredible step forward for time related management in org.  Does it
solve everything?  No.  But the current situation is a mess for timezone
related issues and this enhancement would be very welcome.

Thank you,
eric
-- 
: Eric S Fraga, with org release_9.6-201-gb58fba in Emacs 30.0.50

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

[Ihor Radchenko]

Tim Cross <theophilusx@gmail.com> writes:

> OK, I just give up.
>
> I don't understand why my very simple point seems so hard for anyone to
> grasp and why everyone seems so focused on the booking and scheduling of
> meetings with outhers. This was never in the scope of the very simple
> issue I want solved. 

FYI, I feel like you two and some other people in the thread are talking
about the same thing and simply misunderstand the terms used in
each-other's explanations.

> All that remains is to work out a good interface to make it easy to set
> the correct timestamp type (i.e. in local time or UTC) based on the
> requirements for that meeting (which is determined by whether the
> meeting has any participants in different time zones). How sophisticated
> we want ot make this is undecided. My simple sugestion wa that have the
> commands which insert timestamps use the universal argument - when
> called with the universal argument, set the timestamp using UTC and when
> it isn't, set it as it is now (or set it with the local TZ added, based
> on user preference).

Universal argument is already taken to insert time in addition to date.

I instead suggest allowing `org-read-date' provide completion interface
for TZ once user presses @ (for example) in the date prompt.
When the user press Z (for example), @UTC is inserted and the user can
simply add +XX or -XX as needed to complete the 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: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Thomas S. Dye]

Aloha Max,

Max Nikulin <manikulin@gmail.com> writes:

> On 20/01/2023 03:09, Tim Cross wrote:
>> 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.
> ...> 2. A meeting timestamp for a meeting where all the 
> participants are in
>> different time zones....
>
> Tim, every scheduled meeting event is associated with some 
> particular time zone,
> often implicitly. So it is single use case.
>
> It is up to participants to negotiate which timezone is the 
> primary one for each
> event. It is matter of people communication, not technical 
> issue.
>
> First Monday 15:00 is (almost) equally precise for
> - Australia/Canberra having DST
> - Australia/Darwin where currently no DST
> - +1000 (the highest chance of improper use unfortunately)
> - UTC
>
> Aside from time transition intervals, it is possible to take any 
> of this variant
> and to present time local for other participant across the 
> globe.
>
> Storage timezone may differ from the current user preference 
> which time zone
> should be used to display timestamp or to export it.
>
> The problem arises when several participants believe that their 
> timezones are
> primary ones and they do not sync their schedules through a 
> shared file or a DB
> entry. An application can not solve this problem, but it might 
> try to help to
> identify it. Some efforts are necessary from user side. 
> Timestamp should contain
> list of timezones of other participants and cached local time. 
> In such case an
> application may warn users that local time values become 
> inconsistent due to DST
> transitions or due to update of time zone database. Unsure to 
> what degree it
> should be implemented in Org.
>
> So
> - It is participants fault if a meeting is not associated with 
> particular
>  timezone
> - Having a fair time handling library, it does not matter what 
> time zone is used
>  to schedule the meeting.

Or, one can recognize that the meeting is an occurrence that 
requires absolute time and a timestamp with UTC.  Each participant 
will resolve UTC to the local time where they happen to be when 
the meeting takes place.  The user might toggle between UTC and 
the local time translation using overlays, like pretty entities. 
This avoids the problem of negotiating a timezone caused by 
forcing an occurrence to be represented as an event relative to a 
fictitious space/time.

hth,
Tom

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

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

[Max Nikulin]

On 20/01/2023 13:46, Thomas S. Dye wrote:
> 
> Or, one can recognize that the meeting is an occurrence that requires 
> absolute time and a timestamp with UTC.

Thomas, events and occurrences is something different. The real issue 
that you cannot predict future, so, strictly speaking, you do not know 
what offset from UTC you timezone will have several months later. That 
is why fixing UTC timestamp may cause issues:

http://www.creativedeletion.com/2015/03/19/persisting_future_datetimes.html
Lau Taarnskov. How to save datetimes for future events - (when UTC is 
not the right answer)

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

[Tim Cross]

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

> Aloha Max,
>
> Max Nikulin <manikulin@gmail.com> writes:
>
>> On 20/01/2023 03:09, Tim Cross wrote:
>>> 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.
>> ...> 2. A meeting timestamp for a meeting where all the participants are in
>>> different time zones....
>>
>> Tim, every scheduled meeting event is associated with some particular time zone,
>> often implicitly. So it is single use case.
>>
>> It is up to participants to negotiate which timezone is the primary one for each
>> event. It is matter of people communication, not technical issue.
>>
>> First Monday 15:00 is (almost) equally precise for
>> - Australia/Canberra having DST
>> - Australia/Darwin where currently no DST
>> - +1000 (the highest chance of improper use unfortunately)
>> - UTC
>>
>> Aside from time transition intervals, it is possible to take any of this variant
>> and to present time local for other participant across the globe.
>>
>> Storage timezone may differ from the current user preference which time zone
>> should be used to display timestamp or to export it.
>>
>> The problem arises when several participants believe that their timezones are
>> primary ones and they do not sync their schedules through a shared file or a DB
>> entry. An application can not solve this problem, but it might try to help to
>> identify it. Some efforts are necessary from user side. Timestamp should contain
>> list of timezones of other participants and cached local time. In such case an
>> application may warn users that local time values become inconsistent due to DST
>> transitions or due to update of time zone database. Unsure to what degree it
>> should be implemented in Org.
>>
>> So
>> - It is participants fault if a meeting is not associated with particular
>>  timezone
>> - Having a fair time handling library, it does not matter what time zone is used
>>  to schedule the meeting.
>
> Or, one can recognize that the meeting is an occurrence that requires absolute time and a
> timestamp with UTC.  Each participant will resolve UTC to the local time where they happen
> to be when the meeting takes place.  The user might toggle between UTC and the local time
> translation using overlays, like pretty entities. This avoids the problem of negotiating a
> timezone caused by forcing an occurrence to be represented as an event relative to a
> fictitious space/time.
>

Exactly.

I am really confused by the constant reference to negotiating between
participants or finding a shared/agreed time zone etc. That is all
totally irrelevant in this use case as outlined. If we were talking
about booking meetings or communicating information about booked
meetings between participants or a different bit of software which
manages sceduling of meetings like one of those many web meeting booking
systems, then that would be a different matter. However, that isn't what
we are talking about. We are talking about org mode. All I am talking
about here is being able to identify two different types of meetings -
ones which need to have times adjusted as a result of daylight savings
time transitions and ones which don't and what mechanism org could use
to distinguish the two. It is that simple. Your occurrence v event
terminology provides two different names which may help label the two
different use cases.

So far, nobody has shown any reason why using UTC to distinguish the
case where the times need to be adjusted and local tz when they don't
won't work a a  mechanism that can be used to allow org to handle things
better than it does now. 

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

[Max Nikulin]

On 20/01/2023 15:17, Tim Cross wrote:
> So far, nobody has shown any reason why using UTC to distinguish the
> case where the times need to be adjusted and local tz when they don't
> won't work a a  mechanism that can be used to allow org to handle things
> better than it does now.

Let's try to move in small steps. UTC as storage format.

An issue with events scheduled as local time in some particular timezone 
(not your current one) and stored as UTC timestamp when IANA tzdata is 
updated to use new timezone offset:

https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/
Storing UTC is not a silver bullet

Do you think it should be ignored? I faced such issue.

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

[Thomas S. Dye]

Aloha Max,

Max Nikulin <manikulin@gmail.com> writes:

> On 20/01/2023 15:17, Tim Cross wrote:
>> So far, nobody has shown any reason why using UTC to 
>> distinguish the
>> case where the times need to be adjusted and local tz when they 
>> don't
>> won't work a a  mechanism that can be used to allow org to 
>> handle things
>> better than it does now.
>
> Let's try to move in small steps. UTC as storage format.
>
> An issue with events scheduled as local time in some particular 
> timezone (not
> your current one) and stored as UTC timestamp when IANA tzdata 
> is updated to use
> new timezone offset:
>
> https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/
> Storing UTC is not a silver bullet
>
> Do you think it should be ignored? I faced such issue.

Good example!  Thanks for the link.

Note that the problem of arbitrary change of a timezone's relation 
to UTC might be handled differently for occurrences and events.

The blog example is 9AM in Amsterdam at a date some years in the 
future.  Because the example includes a place, it refers to 
space/time, and is an event (not an occurrence).  Now, if 
Amsterdam's timezone arbitrarily changes its relation to UTC 
before the conference takes place, then everyone who participates 
in the conference must notice this (or miss the start of the 
conference).

Let's consider an occurrence.  A virtual conference is organized 
by someone in Amsterdam, who sets a start time corresponding to 
9AM in Amsterdam at a date some years in the future and invites 
participants from all over the world.  Now, if Amsterdam's 
timezone arbitrarily changes its relation to UTC before the 
conference takes place, then must everyone notice this?  Or, 
should Org, from the time the arbitrary change is made public, 
simply adjust the conference time for all the participants in the 
Amsterdam timezone?  The latter makes sense to me--all the 
participants in Amsterdam will be aware of the arbitrary change, 
so will not be surprised when Org calculates a different start 
time. Such a change would almost certainly confuse participants 
unaware of the arbitrary change in Amsterdam timezone.

hth,
Tom



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

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

[Max Nikulin]

On 20/01/2023 23:09, Thomas S. Dye wrote:
> Max Nikulin writes:
> 
> Now, if Amsterdam's timezone 
> arbitrarily changes its relation to UTC before the conference takes 
> place, then everyone who participates in the conference must notice this 
> (or miss the start of the conference).

My point is that if timestamp is stored in UTC than it becomes incorrect 
in the case of time offset change. If such timestamp is stored as local 
time + time zone identifier then application presenting the timestamp to 
users will show correct time as soon as zoneinfo data is updated.

> A virtual conference is organized by 
> someone in Amsterdam, who sets a start time corresponding to 9AM in 
> Amsterdam at a date some years in the future and invites participants 
> from all over the world.  Now, if Amsterdam's timezone arbitrarily 
> changes its relation to UTC before the conference takes place, then must 
> everyone notice this?  Or, should Org, from the time the arbitrary 
> change is made public, simply adjust the conference time for all the 
> participants in the Amsterdam timezone?

Both variants are possible and a planning application should support 
them. It is matter of negotiation between the committee and the 
participants. Timestamp should be stored in UTC only in one case.

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

[Thomas S. Dye]

Aloha Max,

Max Nikulin <manikulin@gmail.com> writes:

> On 20/01/2023 23:09, Thomas S. Dye wrote:
>> Max Nikulin writes:
>> Now, if Amsterdam's timezone 
>> arbitrarily changes its relation to UTC before the conference 
>> takes place,
>> then everyone who participates in the conference must notice 
>> this (or miss the
>> start of the conference).
>
> My point is that if timestamp is stored in UTC than it becomes 
> incorrect in the
> case of time offset change. If such timestamp is stored as local 
> time + time
> zone identifier then application presenting the timestamp to 
> users will show
> correct time as soon as zoneinfo data is updated.
>
>> A virtual conference is organized by someone in Amsterdam, who 
>> sets a start
>> time corresponding to 9AM in Amsterdam at a date some years in 
>> the future and
>> invites participants from all over the world.  Now, if 
>> Amsterdam's timezone
>> arbitrarily changes its relation to UTC before the conference 
>> takes place,
>> then must everyone notice this?  Or, should Org, from the time 
>> the arbitrary 
>> change is made public, simply adjust the conference time for 
>> all the
>> participants in the Amsterdam timezone?
>
> Both variants are possible and a planning application should 
> support them. It is
> matter of negotiation between the committee and the 
> participants. Timestamp
> should be stored in UTC only in one case.

Agreed.  So, IIUC, there are three cases:

1) Occurrence, where the timestamp includes UTC;
2) Event relative to user, where the timestamp does not include 
UTC or a time zone; and 
3) Event not relative to user, where the timestamp includes the 
relevant time zone.

For completeness, Case 3 might benefit from a procedure to change 
the relevant time zone.  For instance, when the boss has scheduled 
time for you at 9:00 AM her time, but doesn't know where she will 
be on that day.

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 Max,
>
> Max Nikulin <manikulin@gmail.com> writes:
>
>> On 20/01/2023 23:09, Thomas S. Dye wrote:
>>> Max Nikulin writes:
>>> Now, if Amsterdam's timezone arbitrarily changes its relation to UTC before the
>>> conference takes place,
>>> then everyone who participates in the conference must notice this (or miss the
>>> start of the conference).
>>
>> My point is that if timestamp is stored in UTC than it becomes incorrect in the
>> case of time offset change. If such timestamp is stored as local time + time
>> zone identifier then application presenting the timestamp to users will show
>> correct time as soon as zoneinfo data is updated.
>>
>>> A virtual conference is organized by someone in Amsterdam, who sets a start
>>> time corresponding to 9AM in Amsterdam at a date some years in the future and
>>> invites participants from all over the world.  Now, if Amsterdam's timezone
>>> arbitrarily changes its relation to UTC before the conference takes place,
>>> then must everyone notice this?  Or, should Org, from the time the arbitrary change is
>>> made public, simply adjust the conference time for all the
>>> participants in the Amsterdam timezone?
>>
>> Both variants are possible and a planning application should support them. It is
>> matter of negotiation between the committee and the participants. Timestamp
>> should be stored in UTC only in one case.
>
> Agreed.  So, IIUC, there are three cases:
>
> 1) Occurrence, where the timestamp includes UTC;
> 2) Event relative to user, where the timestamp does not include UTC or a time zone; and 3)
> Event not relative to user, where the timestamp includes the relevant time zone.
>

I would argue case 2 is really just a specialisation of case 3 i.e. it
has an implicit time zone which is the user's local time zone. 

> For completeness, Case 3 might benefit from a procedure to change the relevant time zone.
> For instance, when the boss has scheduled time for you at 9:00 AM her time, but doesn't
> know where she will be on that day.
>

If it is to be a fact-to-face meeting (event), implying it therefore has
a location, you would assume your local time zone. If not face-to-face
(occurrence), it needs a UTC offset in order to ensure same point in
time for all participants. The boss either needs to specify the time
zone they are referencing the 9am to or the user will need to make a
guess, which may or may not be correct.

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 Max,
>>
>> Max Nikulin <manikulin@gmail.com> writes:
>>
>>> On 20/01/2023 23:09, Thomas S. Dye wrote:
>>>> Max Nikulin writes:
>>>> Now, if Amsterdam's timezone arbitrarily changes its relation 
>>>> to UTC before the
>>>> conference takes place,
>>>> then everyone who participates in the conference must notice 
>>>> this (or miss the
>>>> start of the conference).
>>>
>>> My point is that if timestamp is stored in UTC than it becomes 
>>> incorrect in the
>>> case of time offset change. If such timestamp is stored as 
>>> local time + time
>>> zone identifier then application presenting the timestamp to 
>>> users will show
>>> correct time as soon as zoneinfo data is updated.
>>>
>>>> A virtual conference is organized by someone in Amsterdam, 
>>>> who sets a start
>>>> time corresponding to 9AM in Amsterdam at a date some years 
>>>> in the future and
>>>> invites participants from all over the world.  Now, if 
>>>> Amsterdam's timezone
>>>> arbitrarily changes its relation to UTC before the conference 
>>>> takes place,
>>>> then must everyone notice this?  Or, should Org, from the 
>>>> time the arbitrary change is
>>>> made public, simply adjust the conference time for all the
>>>> participants in the Amsterdam timezone?
>>>
>>> Both variants are possible and a planning application should 
>>> support them. It is
>>> matter of negotiation between the committee and the 
>>> participants. Timestamp
>>> should be stored in UTC only in one case.
>>
>> Agreed.  So, IIUC, there are three cases:
>>
>> 1) Occurrence, where the timestamp includes UTC;
>> 2) Event relative to user, where the timestamp does not include 
>> UTC or a time zone; and 3)
>> Event not relative to user, where the timestamp includes the 
>> relevant time zone.
>>
>
> I would argue case 2 is really just a specialisation of case 3 
> i.e. it
> has an implicit time zone which is the user's local time zone. 
>
Case 2 covers things the user wants to do at a particular time, 
regardless of where they are and the time zone they are in.  For a 
repeating task the time zone might change from one instance to the 
next.  It needs to follow the user around and can presumably rely 
on software to keep track of that.

>> For completeness, Case 3 might benefit from a procedure to 
>> change the relevant time zone.
>> For instance, when the boss has scheduled time for you at 9:00 
>> AM her time, but doesn't
>> know where she will be on that day.
>>
>
> If it is to be a fact-to-face meeting (event), implying it 
> therefore has
> a location, you would assume your local time zone. If not 
> face-to-face
> (occurrence), it needs a UTC offset in order to ensure same 
> point in
> time for all participants. The boss either needs to specify the 
> time
> zone they are referencing the 9am to or the user will need to 
> make a
> guess, which may or may not be correct.

Or, it might be a recurring virtual meeting that the boss wants to 
initiate at 9:00 AM her time, regardless of the time zone she 
happens to inhabit, as might happen on a business trip.  Here, the 
virtual meeting is an event because the boss relates it to her own 
space/time.  Inconvenient for employees, but some bosses are like 
that.  Here, the time zone needs to follow the boss around.

My current hypothesis is that the three cases are exhaustive.

All the best,
Tom

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

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

[Max Nikulin]

On 21/01/2023 07:37, Thomas S. Dye wrote:
>>> 1) Occurrence, where the timestamp includes UTC;
>>> 2) Event relative to user, where the timestamp does not include UTC 
>>> or a time zone; and 3)
>>> Event not relative to user, where the timestamp includes the relevant 
>>> time zone.

For a while I prefer to concentrate on future timestamps and postpone 
discussion of ones in the past.

As to format for storage timestamps in Org files, particular timestamps 
may have or not explicitly specified timezones, but it is unrelated to 
these 3 cases. It may be convenient to keep work.org file with TIMEZONE 
keyword for location of the office and do not specify it for each 
timestamps, so during a trip it allows to see correct time of regular 
meetings. In addition you may have personal.org file where most 
timestamps assumes timezone of your current presence. In both files some 
timestamps may have explicit timezone either "local follow me", UTC, or 
for particular location.

 From my point of view these, 3 cases might be relevant to date-time 
picker UI, but not for storage format. While parsing, interpretation of 
each timestamp without explicit timezone depends on preferences chosen 
at higher scope.

> Or, it might be a recurring virtual meeting that the boss wants to 
> initiate at 9:00 AM her time, regardless of the time zone she happens to 
> inhabit, as might happen on a business trip.

I believe that some manual action is required in this case anyway. You 
almost certainly already have 9:00 AM in your agenda as a reoccurring 
timestamp either with implicit or explicit timezone of usual presence. 
For the period of the trip it is necessary to add series of meetings 
with explicitly specified timezones (UTC or locations during the trip). 
Another approach is to define ad hoc "boss" timezone and update it to 
reflect all trips.

At the Org side it might be support of multiple ad hoc "timezones": a 
one for you personal trips and several ones for people you frequently 
communicate with. It is a nice option, but might be too complicated for 
usage. It may be easier to suspend regular entry and to add custom ones 
with no requirements related to the code. Anyway it assumes some 
communication between participants.

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

[Thomas S. Dye]

Aloha Max,

Max Nikulin <manikulin@gmail.com> writes:

> On 21/01/2023 07:37, Thomas S. Dye wrote:
>>>> 1) Occurrence, where the timestamp includes UTC;
>>>> 2) Event relative to user, where the timestamp does not 
>>>> include UTC or a
>>>> time zone; and 3)
>>>> Event not relative to user, where the timestamp includes the 
>>>> relevant time
>>>> zone.
>
> For a while I prefer to concentrate on future timestamps and 
> postpone discussion
> of ones in the past.

I'm curious to find out how the distinction between past and 
future makes a difference.  

> As to format for storage timestamps in Org files, particular 
> timestamps may have
> or not explicitly specified timezones, but it is unrelated to 
> these 3 cases.

I'm curious to learn the classification unrelated to these three 
cases used to determine when to store UTC and timezone.

> It
> may be convenient to keep work.org file with TIMEZONE keyword 
> for location of
> the office and do not specify it for each timestamps, so during 
> a trip it allows
> to see correct time of regular meetings. In addition you may 
> have personal.org
> file where most timestamps assumes timezone of your current 
> presence. In both
> files some timestamps may have explicit timezone either "local 
> follow me", UTC,
> or for particular location.
>
> From my point of view these, 3 cases might be relevant to 
> date-time picker UI,
> but not for storage format. While parsing, interpretation of 
> each timestamp
> without explicit timezone depends on preferences chosen at 
> higher scope.

I'm curious what these preferences are, or might be.

>
>> Or, it might be a recurring virtual meeting that the boss wants 
>> to initiate at
>> 9:00 AM her time, regardless of the time zone she happens to 
>> inhabit, as might
>> happen on a business trip.
>
> I believe that some manual action is required in this case 
> anyway. You almost
> certainly already have 9:00 AM in your agenda as a reoccurring 
> timestamp either
> with implicit or explicit timezone of usual presence. For the 
> period of the trip
> it is necessary to add series of meetings with explicitly 
> specified timezones
> (UTC or locations during the trip). Another approach is to 
> define ad hoc "boss"
> timezone and update it to reflect all trips.

Agreed.  The boss needs to inform you what her local time will be 
for the meeting by sending you a timestamp with a time zone. 
Ideally, Org would know how to associate the timestamp with a 
recurring item stored locally.

>
> At the Org side it might be support of multiple ad hoc 
> "timezones": a one for
> you personal trips and several ones for people you frequently 
> communicate with.
> It is a nice option, but might be too complicated for usage. It 
> may be easier to
> suspend regular entry and to add custom ones with no 
> requirements related to the
> code. Anyway it assumes some communication between participants.

Nowadays, I am frequently asked by applications to give permission 
for using my location.  When I give it, the application reports 
back with my local postal code, etc.  I'm assuming Org can use 
location to determine my current timezone.

All the best,
Tom

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

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

[Max Nikulin]

On 21/01/2023 22:55, Thomas S. Dye wrote:
> Aloha Max,
> 
> Max Nikulin <manikulin@gmail.com> writes:
> 
>> On 21/01/2023 07:37, Thomas S. Dye wrote:
>>>>> 1) Occurrence, where the timestamp includes UTC;
>>>>> 2) Event relative to user, where the timestamp does not include UTC 
>>>>> or a
>>>>> time zone; and 3)
>>>>> Event not relative to user, where the timestamp includes the 
>>>>> relevant time
>>>>> zone.
> 
> I'm curious to find out how the distinction between past and future 
> makes a difference.

For timestamps in the past "absolute" time is almost always known, so 
beside timezone identifiers like Australia/Sydney it is possible to use 
UTC or fixed offset 2023-01-21 Sat 05:55:54 -1000. If a timestamp in 
future is bound to specific timezone then its identifier must be used 
since the government may change time offset. Of course there are cases 
when UTC or timestamps with fixed offsets are used as well: e.g. Lunar 
eclipse or participants with multiple locations are expected.

So it is "feature" of some timestamps in future that attempt to store 
them in UTC may lead to their invalidation later.

>> As to format for storage timestamps in Org files, particular 
>> timestamps may have
>> or not explicitly specified timezones, but it is unrelated to these 3 
>> cases.
> 
> I'm curious to learn the classification unrelated to these three cases 
> used to determine when to store UTC and timezone.
...
>> From my point of view these, 3 cases might be relevant to date-time 
>> picker UI,
>> but not for storage format. While parsing, interpretation of each 
>> timestamp
>> without explicit timezone depends on preferences chosen at higher scope.
> 
> I'm curious what these preferences are, or might be.

Is the following timestamp is in user local timezone or in UTC?

<2023-02-01 Wed 15:00>

If features like the following is implemented then it will not be in 
local time zone:
- file-local
   #+TIMEZONE: UTC
   or
   #+TIMEZONE: Australia/Sydney
- subtree-local
   * H1
   :PROPERTIES:
   :TIMEZONE: Australia/Sydney
   :END:

So looking at such timestamp it would be hard to choose particular case 
from the set you proposed.

Of course it leads to tricky cases when some timestamp is copied to a 
scope with another time zone. It requires some yank handler and text 
properties. When timezone is added to a subtree, perhaps, all timestamps
inside may need to be changed from implicit timezone.

For storage format I would use another types
- explicit/implicit time zone
- Specific timezone/fixed offset. UTC and Etc/GMT-11 zones are identical 
to +0000 and +1100 offsets accordingly.

For UI it is better to choose some terms to make the manual and UI 
dialogues more clear.

I am not a native English speaker and terms "event", "occurrence" sounds 
confusing for me. E.g. a conference is an event. A regular meeting (even 
when scheduled in another time zone) or "brush teeth" are more close to 
occurrence. As soon as you have to split "event" category into 2 parts 
perhaps it is better to pick 3 different names. I may ask for fourth 
that is absolute, but not UTC, but I would prefer to not insist on 
namely UTC and use fixed offset instead.

For UI it is meaningful to name
- default time zone for this scope (with a hint if it is currently 
system-wide, file-local, or specific to subtree), so no explicit 
timezone will be set.
- absolute (UTC or fixed offset) preferred for global event
- bound to location (e.g. Australia/Sydney)
- ad-hoc timezone that follows user in their trips (close to Ramsey's 
"occurrence").

The problem is to push users to timezone identifiers for future 
timestamps associated with some location. Offsets must be discouraged 
this case, but encouraged for on-line meetings. For past timestamps 
particular choice is less important. That is why I separated future/past 
timestamps.

> Agreed.  The boss needs to inform you what her local time will be for 
> the meeting by sending you a timestamp with a time zone. Ideally, Org 
> would know how to associate the timestamp with a recurring item stored 
> locally.

Unsure it it may be implemented reliably.

> Nowadays, I am frequently asked by applications to give permission for 
> using my location.  When I give it, the application reports back with my 
> local postal code, etc.  I'm assuming Org can use location to determine 
> my current timezone.

libc has a concept of timezone. I think, it should be the primary 
source. It is initialized on application startup (roughly) from 
system-wide settings, may be overridden by TZ environment and changed 
later by setting another value of TZ. The problem is that identifier 
like "Australia/Sydney" is considered implementation specific and is not 
directly accessible from the code, it is sealed inside the library. 
Another issue is that I do not know if Emacs is able to receive 
notifications on change of system-wide timezone.

Web-application may request time zone settings from the browser:
     new Intl.DateTimeFormat().resolvedOptions().timeZone

Android devices may have outdated and incomplete zoneinfo database. This 
case either computations should be performed on the server or tzdata 
copy should be bundled into the app.

Client-server application may use resources maintained on servers, emacs 
must be able to run off-line and enough user will be unhappy noticed 
some outgoing queries.

Ubuntu installer or e.g. Google relies on GeoIP databases.

Geodata for timezones is available, but laptops or desktops mostly do 
not have GPS receivers. IP behind NAT is not useful to determine location.

It is possible to make GeoIP database (quality of ones available for 
free are not high) and map of timezones, but I do not think it is 
reasonable.

I suppose, system timezone would be enough for Org. Third party packages 
might implement another way.

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

[Thomas S. Dye]

Aloha Max,

Max Nikulin <manikulin@gmail.com> writes:

> On 21/01/2023 22:55, Thomas S. Dye wrote:
>> Aloha Max,
>>
>> Max Nikulin <manikulin@gmail.com> writes:
>>
>>> On 21/01/2023 07:37, Thomas S. Dye wrote:
>>>>>> 1) Occurrence, where the timestamp includes UTC;
>>>>>> 2) Event relative to user, where the timestamp does not 
>>>>>> include UTC
>>>>>> or a
>>>>>> time zone; and 3)
>>>>>> Event not relative to user, where the timestamp includes 
>>>>>> the
>>>>>> relevant time
>>>>>> zone.
>>
>> I'm curious to find out how the distinction between past and 
>> future
>> makes a difference.
>
> For timestamps in the past "absolute" time is almost always 
> known, so
> beside timezone identifiers like Australia/Sydney it is possible 
> to use
> UTC or fixed offset 2023-01-21 Sat 05:55:54 -1000. If a 
> timestamp in
> future is bound to specific timezone then its identifier must be 
> used
> since the government may change time offset. Of course there are 
> cases
> when UTC or timestamps with fixed offsets are used as well: e.g. 
> Lunar
> eclipse or participants with multiple locations are expected.

Yes, of course!

FYI, lunar eclipse was Ramsey's example of an occurrence, which 
has to do with changes in the relations of things at a time.

>
> So it is "feature" of some timestamps in future that attempt to 
> store
> them in UTC may lead to their invalidation later.

Yes, these are events, which are relative to a timezone, either 
implicit or explicit.

>
>>> As to format for storage timestamps in Org files, particular
>>> timestamps may have
>>> or not explicitly specified timezones, but it is unrelated to 
>>> these 3
>>> cases.
>>
>> I'm curious to learn the classification unrelated to these 
>> three cases
>> used to determine when to store UTC and timezone.
> ...
>>> From my point of view these, 3 cases might be relevant to 
>>> date-time
>>> picker UI,
>>> but not for storage format. While parsing, interpretation of 
>>> each
>>> timestamp
>>> without explicit timezone depends on preferences chosen at 
>>> higher scope.
>>
>> I'm curious what these preferences are, or might be.
>
> Is the following timestamp is in user local timezone or in UTC?
>
> <2023-02-01 Wed 15:00>
>
> If features like the following is implemented then it will not 
> be in
> local time zone:
> - file-local
>
>    #+TIMEZONE: UTC
>    or
>
>    #+TIMEZONE: Australia/Sydney
> - subtree-local
>
>    * H1
>    :PROPERTIES:
>    :TIMEZONE: Australia/Sydney
>    :END:
>
> So looking at such timestamp it would be hard to choose 
> particular case
> from the set you proposed.
>
This might be a feature, not a bug.  A timestamp that does not 
indicate absolute time (UTC or fixed offset) and does not include 
a timezone relies on the timezone set by user.  So user changes 
timezone preference during trips and these timestamps become 
relative to user's local time.

A timestamp with absolute time or with a timezone would ignore 
user's timezone preference.

> Of course it leads to tricky cases when some timestamp is copied 
> to a
> scope with another time zone. It requires some yank handler and 
> text
> properties. When timezone is added to a subtree, perhaps, all 
> timestamps
> inside may need to be changed from implicit timezone.
>
Perhaps the solution here is to consider this a feature, not a 
bug.  When displaying an event timestamp, the timezone should 
always be indicated.  For an event relative to user, this would be 
the preference currently in scope.  For an event not relative to 
user, the timezone will be part of the timestamp.

> For storage format I would use another types
> - explicit/implicit time zone
Yes, explicit for events not relative to user, implicit for events 
relative to user.

> - Specific timezone/fixed offset. UTC and Etc/GMT-11 zones are 
> identical
> to +0000 and +1100 offsets accordingly.

Here, absolute time is best, either UTC or fixed offset from UTC 
(don't underestimate legislators' folly changing timezones).
>
> For UI it is better to choose some terms to make the manual and 
> UI
> dialogues more clear.

Agreed, though I don't have suggestions atm.

> I am not a native English speaker and terms "event", 
> "occurrence" sounds
> confusing for me. E.g. a conference is an event. A regular 
> meeting (even
> when scheduled in another time zone) or "brush teeth" are more 
> close to
> occurrence. As soon as you have to split "event" category into 2 
> parts
> perhaps it is better to pick 3 different names. I may ask for 
> fourth
> that is absolute, but not UTC, but I would prefer to not insist 
> on
> namely UTC and use fixed offset instead.
>
Yes, UTC and fixed offset (from UTC) are two ways of specifying 
absolute time.  Neither one refers to a timezone.

> For UI it is meaningful to name
> - default time zone for this scope (with a hint if it is 
> currently
> system-wide, file-local, or specific to subtree), so no explicit
> timezone will be set.
> - absolute (UTC or fixed offset) preferred for global event
> - bound to location (e.g. Australia/Sydney)
> - ad-hoc timezone that follows user in their trips (close to 
> Ramsey's
> "occurrence").

I think the first and last can be considered identical (see 
above).

Also note that ad-hoc timezone is an event because it specifies a 
timezone, which is a space/time unit.

> The problem is to push users to timezone identifiers for future
> timestamps associated with some location. Offsets must be 
> discouraged
> this case, but encouraged for on-line meetings. For past 
> timestamps
> particular choice is less important. That is why I separated 
> future/past
> timestamps.
>
Yes, good point.

>> Agreed.  The boss needs to inform you what her local time will 
>> be for
>> the meeting by sending you a timestamp with a time zone. 
>> Ideally, Org
>> would know how to associate the timestamp with a recurring item 
>> stored
>> locally.
>
> Unsure it it may be implemented reliably.
Then Org user must understand that repeating timestamp for an 
event not relative to user is fixed to one timezone and is not 
appropriate for an event that might change timezones, as when the 
boss travels but insists on fixing staff meeting to her local 
time.

>
>> Nowadays, I am frequently asked by applications to give 
>> permission for
>> using my location.  When I give it, the application reports 
>> back with my
>> local postal code, etc.  I'm assuming Org can use location to 
>> determine
>> my current timezone.
>
> libc has a concept of timezone. I think, it should be the 
> primary
> source. It is initialized on application startup (roughly) from
> system-wide settings, may be overridden by TZ environment and 
> changed
> later by setting another value of TZ. The problem is that 
> identifier
> like "Australia/Sydney" is considered implementation specific 
> and is not
> directly accessible from the code, it is sealed inside the 
> library.
> Another issue is that I do not know if Emacs is able to receive
> notifications on change of system-wide timezone.
>
> Web-application may request time zone settings from the browser:
>      new Intl.DateTimeFormat().resolvedOptions().timeZone
>
> Android devices may have outdated and incomplete zoneinfo 
> database. This
> case either computations should be performed on the server or 
> tzdata
> copy should be bundled into the app.
>
> Client-server application may use resources maintained on 
> servers, emacs
> must be able to run off-line and enough user will be unhappy 
> noticed
> some outgoing queries.
>
> Ubuntu installer or e.g. Google relies on GeoIP databases.
>
> Geodata for timezones is available, but laptops or desktops 
> mostly do
> not have GPS receivers. IP behind NAT is not useful to determine 
> location.
>
> It is possible to make GeoIP database (quality of ones available 
> for
> free are not high) and map of timezones, but I do not think it 
> is
> reasonable.
>
> I suppose, system timezone would be enough for Org. Third party 
> packages
> might implement another way.

Thanks.  Much appreciated.  So, Org user will need to understand 
that timezone calculations will only be as current as libc and 
that user is responsible for setting local timezone.

All the best,
Tom

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

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

[Max Nikulin]

On 22/01/2023 19:14, Max Nikulin wrote:
> - ad-hoc timezone that follows user in their trips (close to Ramsey's 
> "occurrence").

Sorry, it should be "event", not "occurrence". It was not intentional 
demonstration of my confusion.

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

[Tim Cross]

Max Nikulin <manikulin@gmail.com> writes:

> On 20/01/2023 15:17, Tim Cross wrote:
>> So far, nobody has shown any reason why using UTC to distinguish the
>> case where the times need to be adjusted and local tz when they don't
>> won't work a a  mechanism that can be used to allow org to handle things
>> better than it does now.
>
> Let's try to move in small steps. UTC as storage format.
>
> An issue with events scheduled as local time in some particular timezone (not your current
> one) and stored as UTC timestamp when IANA tzdata is updated to use new timezone offset:
>
> https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/
> Storing UTC is not a silver bullet
>
> Do you think it should be ignored? I faced such issue.

I now think I can see where you have become confused.

I am NOT arguing that all timestamps should be stored in UTC.

I am only saying that when you have a meeting which is not face to face
and involves people from various time zones, the date+time for that
meeting should be stored in UTC. This is the only way org will be able
to ensure the meeting time (which would be converted into local time for
the user) stays relative to the other participants after a daylight
savings transition.

The use cases here is completely different from the example outlined in
that long article.  Firstly, much of the complications arising in that
example are due to tryhing to coordinate dates and times for multiple
parties. Here we are only focusing on 1 party. Secondly, I am only
proposing UTC for meetings where there is no physical location for the
meeting. In the case where there is a physical location, that is a
fact-to-face meeting and it should be recorded in the time zone of the
location of that meeting. In most cases, that will be the user's local
time zone, so for most face=to=face meetings, no explicit time zone is
necessary as the local time zone will be assumed.

So in summary, my argument is

- Use UTC for meetings which are not face-to-face and which involve
  people form different time zones.

- Use the time zone of the location of a meeting when the meeting is
  face-to-face and has a physical locaiton.

- Provide an interface in org to make it easier for users to select the
  correct format (UTC or lcoal/meeting tz). Exactly the best way to do
  this is yet to be determined. It could be just a general solution
  which allows you to select the TZ when you call the functions with C-u
  or it could be something more sophisticated and specific to booking
  meetings which asks questions (i.e. type of record meeting wiard).

- It is assumed that in most cases, timestamps will b displayed to the
  user in their local time zone regardless of how they are actualy
  recorded int he org file.

I suspect where you have become confused is because you read my first
post in the thread where I suggested using UTC for meetings would be
sufficient. However, I revised that based on responses and then proposed
only using UTC for meetings which are not face-to-face and where
participants are from different time zones. It appears you have missed
those posts. 

I would also argue UTC is good for 'traditional' timestamps which record
a specific point in time and for situations where you want accurate
calculations of time durations. In fact, I would argue that UTC is a
good choice for a majority of time stamps, but acknowledge there are
some situations, notably when scheduling an event with a physical
location, where it is better to use the time zone of the location. 

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

[Max Nikulin]

On 21/01/2023 06:38, Tim Cross wrote:
> 
> - Use UTC for meetings which are not face-to-face and which involve
>    people form different time zones.

I agree with you that it should considered as first option by whose who 
are planning an event. They still may prefer to choose timezone of 
particular location because it is mixed meeting with attenders of both 
types: face to face and online, or just because most of on-line 
participants are expected from particular area.

However timezone may be out of your control if you receive invitation to 
join on-line to some meeting. Attempt to convert it to UTC may lead to 
problems. So the reason to choose UTC or specific timezone for 
particular timestamp is not really technical one. It is just decision of 
some people.

Do you have any objection to the following statements:
- UTC is a recommendation for planning when participants are scattered 
over multiple timezones.
- You admit that some timestamps in your files may be specified as time 
zone identifier + local time relative to this zone.
- In both cases you may configure overlays to use local timezone or 
another one whatever you currently find convenient.
- Time chooser offers several time zone options.

> I would also argue UTC is good for 'traditional' timestamps which record
> a specific point in time and for situations where you want accurate
> calculations of time durations.

Mostly agree, so I prefer to postpone discussion of details till 
confirming agreement in respect to future timestamps.

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

[Tim Cross]

Max Nikulin <manikulin@gmail.com> writes:

> On 21/01/2023 06:38, Tim Cross wrote:
>> - Use UTC for meetings which are not face-to-face and which involve
>>    people form different time zones.
>
> I agree with you that it should considered as first option by whose who are planning an
> event. They still may prefer to choose timezone of particular location because it is mixed
> meeting with attenders of both types: face to face and online, or just because most of
> on-line participants are expected from particular area.
>
> However timezone may be out of your control if you receive invitation to join on-line to
> some meeting. Attempt to convert it to UTC may lead to problems. So the reason to choose
> UTC or specific timezone for particular timestamp is not really technical one. It is just
> decision of some people.
>
> Do you have any objection to the following statements:
> - UTC is a recommendation for planning when participants are scattered over multiple
>  timezones.
> - You admit that some timestamps in your files may be specified as time zone identifier +
>  local time relative to this zone.
> - In both cases you may configure overlays to use local timezone or another one whatever
>  you currently find convenient.
> - Time chooser offers several time zone options.
>

That seems to be in-line with what I was arguing, so yes, would agree.



>> I would also argue UTC is good for 'traditional' timestamps which record
>> a specific point in time and for situations where you want accurate
>> calculations of time durations.
>
> Mostly agree, so I prefer to postpone discussion of details till confirming agreement in
> respect to future timestamps.

Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode)

[Max Nikulin]

On 22/01/2023 04:29, Tim Cross wrote:
> Max Nikulin writes:
>> - UTC is a recommendation for planning when participants are scattered over multiple
>>   timezones.
>> - You admit that some timestamps in your files may be specified as time zone identifier +
>>   local time relative to this zone.
>> - In both cases you may configure overlays to use local timezone or another one whatever
>>   you currently find convenient.
>> - Time chooser offers several time zone options.
> 
> That seems to be in-line with what I was arguing, so yes, would agree.

Great. At this stage my goal is to convince people that local time and 
UTC for future timestamps are not enough for real life use cases. 
Arbitrary timezone may be crucial to arrive at proper time despite it 
matters in rare cases. My concern is mostly storage format, timestamp 
syntax in Org files.

On 21/01/2023 06:38, Tim Cross wrote:
>>> I would also argue UTC is good for 'traditional' timestamps which record
>>> a specific point in time and for situations where you want accurate
>>> calculations of time durations.

Let's consider the following timestamp

[2023-01-22 Sun 08:29@+1100]

"@" is unimportant here, I take it from Ihor's examples. This timestamp 
is from the "Date:" header of your message. It is not UTC, but in my 
opinion it is equally precise (disregarding seconds) to a UTC timestamp.

Would you prefer to have timestamps in your files in such form or as

[2023-01-21 Sat 21:29Z] ([2023-01-21 Sat 21:29@UTC], [2023-01-21 Sat 
21:29@+00:00], etc)?

Maybe [@1674336588] (seconds since epoch)?

I consider storage format as a part of Org UI, so I believe that 
[2023-01-22 Sun 08:29@+1100] with offset of the usual time zone is more 
convenient than [2023-01-21 Sat 21:29@+0000]. Overlays may present your 
local time in both cases, but raw value with usual offset is easier to 
comprehend.

When a file is shared by a group of people spread across the globe, they 
are free to use UTC or another fixed timezone or do not care at all 
concerning particular offset, it just should present.

Postgres has a reason to insist on UTC since timestamps are stored in 
binary format as microseconds since epoch. It is important for 
performance and there is no room to specify offset. Org has to parse 
timestamps from strings anyway, so it is better to use format more 
convenient for humans.

A side note. In my opinion, *by default* timestamps should be created in 
local time with no offset or timezone. There are should be some 
preferences to enable absolute timestamps and a function to fix offsets 
or timezone identifiers for existing timestamp when the user realizes 
that they become necessary (e.g. before a trip).

So I do not see any advantages of UTC in comparison to time offset 
specific to particular time zone, usually user's local one. My vote is 
[2023-01-22 Sun 08:29@+1100] and not [2023-01-21 Sat 21:29@UTC] (of 
course, only in cases when identifiers like Australia/Sydney do not 
matter) with a configuration option with timezone used fix offsets in 
stored timestamps.

Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode)

[Thomas S. Dye]

Aloha Max,

Max Nikulin <manikulin@gmail.com> writes:

> Let's consider the following timestamp
>
> [2023-01-22 Sun 08:29@+1100]
>
> "@" is unimportant here, I take it from Ihor's examples. This 
> timestamp is from
> the "Date:" header of your message. It is not UTC, but in my 
> opinion it is
> equally precise (disregarding seconds) to a UTC timestamp.
>
> Would you prefer to have timestamps in your files in such form 
> or as
>
> [2023-01-21 Sat 21:29Z] ([2023-01-21 Sat 21:29@UTC], [2023-01-21 
> Sat
> 21:29@+00:00], etc)?
>
> Maybe [@1674336588] (seconds since epoch)?
>
> I consider storage format as a part of Org UI, so I believe that 
> [2023-01-22 Sun
> 08:29@+1100] with offset of the usual time zone is more 
> convenient than
> [2023-01-21 Sat 21:29@+0000]. Overlays may present your local 
> time in both
> cases, but raw value with usual offset is easier to comprehend.
>
> When a file is shared by a group of people spread across the 
> globe, they are
> free to use UTC or another fixed timezone or do not care at all 
> concerning
> particular offset, it just should present.

UTC is not a timezone.  It is absolute time.

> Postgres has a reason to insist on UTC since timestamps are 
> stored in binary
> format as microseconds since epoch. It is important for 
> performance and there is
> no room to specify offset. Org has to parse timestamps from 
> strings anyway, so
> it is better to use format more convenient for humans.

Agreed.

> A side note. In my opinion, *by default* timestamps should be 
> created in local
> time with no offset or timezone. There are should be some 
> preferences to enable
> absolute timestamps and a function to fix offsets or timezone 
> identifiers for
> existing timestamp when the user realizes that they become 
> necessary (e.g.
> before a trip).

I don't think there should be a default.  If I'm correct that 
occurrences, events relative to user, and events not relative to 
user exhaustively classify the possibilities, then Org should 
insist that timestamps conform to one of these three 
possibilities.  If the classification is complete, then there is 
no need for a catch-all default.

> So I do not see any advantages of UTC in comparison to time 
> offset specific to
> particular time zone, usually user's local one. My vote is 
> [2023-01-22 Sun
> 08:29@+1100] and not [2023-01-21 Sat 21:29@UTC] (of course, only 
> in cases when
> identifiers like Australia/Sydney do not matter) with a 
> configuration option
> with timezone used fix offsets in stored timestamps.

The disadvantage of time offset specific to a particular timezone 
is that the timezone offset wrt UTC can change arbitrarily. This 
is a potential problem if the arbitrary change takes place between 
the creation of the timestamp and the happening it identifies.  In 
contrast, UTC is guaranteed not to change.  It is not a timezone, 
it is absolute time, a pure continuum.  It is a requirement of 
occurrences.

I'm not sure offset is necessary for events, given that offset can 
change arbitrarily.  WDYT?  It seems to me that once an event has 
been tied to a particular time in a particular time zone that 
Org's job is to take into account changes to that timezone, such 
as DST and arbitrary legislation.  These changes in the event's 
timezone need to be propagated through the schedule for each user, 
so it is possible to synchronize local timestamps around the 
globe.

All the best,
Tom

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

Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode)

[Max Nikulin]

Thomas, notice that I resumed a postponed earlier part of discussion 
related to timestamps in the past. Offset from UTC is almost always well 
defined this case.

My perception is that discussing timestamps in future, we came to 
agreement with Tom that timestamps can be specified with timezone 
<2024-02-22 08:29@Australia/Sydney>, in UTC <2024-02-21
21:29@UTC>, or in local timezone <2024-02-22 08:29>

Now I had a hope to convince at least some participants that explicit 
time offset may be used interchangeably with UTC. It is applicable to 
timestamps in the past and to future timestamps when the person who 
created appointment respects remote participants, so decided to rule out 
DST and fix absolute time.

On 22/01/2023 13:17, Thomas S. Dye wrote:
> 
> UTC is not a timezone.  It is absolute time.

I do not see any point to consider UTC too special.

Both timestamps [2023-01-21 Sat 21:29@UTC] and [2023-01-22 Sun 
08:29@+1100] specify absolute time. "+1100" means 11 hours, not 
particular location. Do you have an example of a case where I am wrong?

I use the term "time zone" as a set of rules how to calculate offset at 
particular time moment. UTC is a degenerate case of fixed zero offset. 
In this sense "+11:00" is not a timezone, it is time offset. Several 
time zones (as set of rules) may have such offset at some specific time 
moments including "Etc/GMT-11" that is a timezone.

>> A side note. In my opinion, *by default* timestamps should be created 
>> in local
>> time with no offset or timezone. There are should be some preferences 
>> to enable
>> absolute timestamps and a function to fix offsets or timezone 
>> identifiers for
>> existing timestamp when the user realizes that they become necessary 
>> (e.g.
>> before a trip).
> 
> I don't think there should be a default.

Unfortunately hard choice of default value or behavior is unavoidable 
during development of software. Consider a user who just have installed 
Org. Till it is explicitly configured, perhaps it is better to add e.g. 
clocking entries without offset or timezone assuming local time. It 
should be possible to change it later.

>> So I do not see any advantages of UTC in comparison to time offset 
>> specific to
>> particular time zone, usually user's local one. My vote is [2023-01-22 
>> Sun
>> 08:29@+1100] and not [2023-01-21 Sat 21:29@UTC] (of course, only in 
>> cases when
>> identifiers like Australia/Sydney do not matter) with a configuration 
>> option
>> with timezone used fix offsets in stored timestamps.
> 
> The disadvantage of time offset specific to a particular timezone is 
> that the timezone offset wrt UTC can change arbitrarily. This is a 
> potential problem if the arbitrary change takes place between the 
> creation of the timestamp and the happening it identifies.  In contrast, 
> UTC is guaranteed not to change.  It is not a timezone, it is absolute 
> time, a pure continuum.  It is a requirement of occurrences.

I consider the case when offset is already known because it is a time 
moment in the past. Besides rare corner cases offset can be considered 
as a part of authoritative data. Timestamps like [2023-01-22 Sun 
08:29@+1100] can be unambiguously mapped to UTC.

> I'm not sure offset is necessary for events, given that offset can 
> change arbitrarily.  WDYT?  It seems to me that once an event has been 
> tied to a particular time in a particular time zone that Org's job is to 
> take into account changes to that timezone, such as DST and arbitrary 
> legislation.  These changes in the event's timezone need to be 
> propagated through the schedule for each user, so it is possible to 
> synchronize local timestamps around the globe.

For timestamp in the past offsets simplifies calculation of duration. 
Offsets may be used to fix absolute time before changing location when 
time zone was omitted. Perhaps I will add more in another part of this 
thread.

After all, for a person in Berlin [2023-01-22 Sun 08:29@+1100] may tell 
more than [2023-01-22 Sun 08:29@Australia/Sydney].

Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode)

[Thomas S. Dye]

Aloha Max,

Max Nikulin <manikulin@gmail.com> writes:

> Thomas, notice that I resumed a postponed earlier part of 
> discussion related to
> timestamps in the past. Offset from UTC is almost always well 
> defined this case.
>
> My perception is that discussing timestamps in future, we came 
> to agreement with
> Tom that timestamps can be specified with timezone <2024-02-22
> 08:29@Australia/Sydney>, in UTC <2024-02-21
> 21:29@UTC>, or in local timezone <2024-02-22 08:29>
>
> Now I had a hope to convince at least some participants that 
> explicit time
> offset may be used interchangeably with UTC. It is applicable to 
> timestamps in
> the past and to future timestamps when the person who created 
> appointment
> respects remote participants, so decided to rule out DST and fix 
> absolute time.

Agreed, offset relative to UTC is absolute time.

>
> On 22/01/2023 13:17, Thomas S. Dye wrote:
>> UTC is not a timezone.  It is absolute time.
>
> I do not see any point to consider UTC too special.
>
It is independent of the legislative tampering (DST, etc.) that 
makes timezones difficult to work with.

> Both timestamps [2023-01-21 Sat 21:29@UTC] and [2023-01-22 Sun 
> 08:29@+1100]
> specify absolute time. "+1100" means 11 hours, not particular 
> location. Do you
> have an example of a case where I am wrong?

No, not if +1100 is relative to UTC.

> I use the term "time zone" as a set of rules how to calculate 
> offset at
> particular time moment. UTC is a degenerate case of fixed zero 
> offset. 
> In this sense "+11:00" is not a timezone, it is time offset. 
> Several time zones
> (as set of rules) may have such offset at some specific time 
> moments including
> "Etc/GMT-11" that is a timezone.
>
This confuses me.  Calculating offset relative to a timezone, such 
as HST, refers to space/time and yields an event.  Calculating 
offset relative to UTC does not refer to space/time and yields 
absolute time.  IMO, using "time zone", which typically refers to 
a region of space/time, to refer to a set of rules that might 
yield absolute time invites the confusion Ramsey was hoping to 
avoid.

>>> A side note. In my opinion, *by default* timestamps should be 
>>> created in
>>> local
>>> time with no offset or timezone. There are should be some 
>>> preferences to
>>> enable
>>> absolute timestamps and a function to fix offsets or timezone 
>>> identifiers for
>>> existing timestamp when the user realizes that they become 
>>> necessary (e.g.
>>> before a trip).
>> I don't think there should be a default.
>
> Unfortunately hard choice of default value or behavior is 
> unavoidable during
> development of software. Consider a user who just have installed 
> Org. Till it is
> explicitly configured, perhaps it is better to add e.g. clocking 
> entries without
> offset or timezone assuming local time. It should be possible to 
> change it
> later.
>
Is there some way for Org to identify when it is likely that user 
has not specified time zone?  If so, a query might be useful.

>>> So I do not see any advantages of UTC in comparison to time 
>>> offset specific
>>> to
>>> particular time zone, usually user's local one. My vote is 
>>> [2023-01-22 Sun
>>> 08:29@+1100] and not [2023-01-21 Sat 21:29@UTC] (of course, 
>>> only in cases
>>> when
>>> identifiers like Australia/Sydney do not matter) with a 
>>> configuration option
>>> with timezone used fix offsets in stored timestamps.
>> The disadvantage of time offset specific to a particular 
>> timezone is 
>> that the timezone offset wrt UTC can change arbitrarily. This 
>> is a potential
>> problem if the arbitrary change takes place between the 
>> creation of the
>> timestamp and the happening it identifies.  In contrast, UTC is 
>> guaranteed not
>> to change.  It is not a timezone, it is absolute time, a pure 
>> continuum.  It
>> is a requirement of occurrences.
>
> I consider the case when offset is already known because it is a 
> time moment in
> the past. Besides rare corner cases offset can be considered as 
> a part of
> authoritative data. Timestamps like [2023-01-22 Sun 08:29@+1100] 
> can be
> unambiguously mapped to UTC.
>
Yes, if +1100 is relative to UTC.  If not, then it assumes a 
timezone library that correctly includes the past time.

>> I'm not sure offset is necessary for events, given that offset 
>> can change
>> arbitrarily.  WDYT?  It seems to me that once an event has been 
>> tied to a
>> particular time in a particular time zone that Org's job is to 
>> take into
>> account changes to that timezone, such as DST and arbitrary 
>> legislation. 
>> These changes in the event's timezone need to be propagated 
>> through the
>> schedule for each user, so it is possible to synchronize local 
>> timestamps
>> around the globe.
>
> For timestamp in the past offsets simplifies calculation of 
> duration. Offsets
> may be used to fix absolute time before changing location when 
> time zone was
> omitted. Perhaps I will add more in another part of this thread.
>
> After all, for a person in Berlin [2023-01-22 Sun 08:29@+1100] 
> may tell more
> than [2023-01-22 Sun 08:29@Australia/Sydney].

I'm not sure to follow this.  IIUC, the timestamp with offset 
refers to absolute time, whereas the timestamp with the 
Australia/Sydney timezone refers to a region of space/time whose 
relation to absolute time is fixed for any moment, but potentially 
variable over time.

All the best,
Tom

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

Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode)

[Jean Louis]

* Thomas S. Dye <tsd@tsdye.online> [2023-01-22 20:36]:
> > After all, for a person in Berlin [2023-01-22 Sun 08:29@+1100] may
> > tell more than [2023-01-22 Sun 08:29@Australia/Sydney].
> 
> I'm not sure to follow this.  IIUC, the timestamp with offset refers to
> absolute time, whereas the timestamp with the Australia/Sydney timezone
> refers to a region of space/time whose relation to absolute time is fixed
> for any moment, but potentially variable over time.

I understand above that it is easier understandable when reading
[2023-01-22 Sun 08:29@+1100] as it is assumed by poster (I guess Max)
that user will understand that there is +11 hours ahead.

That is assumption by poster. I do not find it easier.

As when user sees 08:29 that user will think of time in Berlin, of
time which is not in UTC, and not time in UTC plus 11 hours.

What is easier is what is generally accepted in any type of software
worldwide, just represent it in local time zone.

Difference between offset time and time with time zone is that time
zone includes rules of daylight savings and other anomalies.

-- 
Jean

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

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

Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode)

[Thomas S. Dye]

Aloha Jean Louis,
Jean Louis <bugs@gnu.support> writes:

> * Thomas S. Dye <tsd@tsdye.online> [2023-01-22 20:36]:
>> > After all, for a person in Berlin [2023-01-22 Sun 
>> > 08:29@+1100] may
>> > tell more than [2023-01-22 Sun 08:29@Australia/Sydney].
>> 
>> I'm not sure to follow this.  IIUC, the timestamp with offset 
>> refers to
>> absolute time, whereas the timestamp with the Australia/Sydney 
>> timezone
>> refers to a region of space/time whose relation to absolute 
>> time is fixed
>> for any moment, but potentially variable over time.
>
> I understand above that it is easier understandable when reading
> [2023-01-22 Sun 08:29@+1100] as it is assumed by poster (I guess 
> Max)
> that user will understand that there is +11 hours ahead.
>
Yes, the offset here is ambiguous--is it offset from some timezone 
or from UTC?

> That is assumption by poster. I do not find it easier.
>
> As when user sees 08:29 that user will think of time in Berlin, 
> of
> time which is not in UTC, and not time in UTC plus 11 hours.
>
> What is easier is what is generally accepted in any type of 
> software
> worldwide, just represent it in local time zone.
>
> Difference between offset time and time with time zone is that 
> time
> zone includes rules of daylight savings and other anomalies.

Right.  The difficulty with scheduling is that it has to take into 
account two time zones in some cases.

Here is a proposal for a terminology of events that honors 
Ramsey's distinction between events and occurrences and hopes to 
cover all of Org's use cases.

* Kinds of event
 - No-host event :: An event that takes place at an absolute time. 
 Participants must know their local timezone offset from UTC. 
 Example [2023-01-23 06:00@UTC].
 - Situated event :: An event that takes place at a time local to 
 the event site.  Participants must know their local timezone 
 offset from UTC and the event site timezone offset from UTC at 
 the time of the event.  Example [2023-01-22 Sun 
 08:29@Australia/Sydney].
 - [Itinerant | Traveling | Mobile] event :: An event that takes 
 place at a time local to the event site, which might change after 
 the event has been scheduled.  Participants must know their local 
 timezone offset from UTC and the event site timezone offset from 
 UTC at the time of the event.  Examples might be a regular staff 
 meeting that takes place at 9:00 AM wherever the boss happens to 
 be, or a proposal to meet with a traveler when it is noon on 
 Sunday for the traveler. Example [2023-01-23 06:00].  In this 
 case timezone is set according to user timezone preference in 
 scope.

The Org user should be able to toggle timestamp representation. 
In the case of a no-host event, user might toggle between UTC and 
local time.  In the case of situated or itinerant event, user 
might toggle among UTC, local time, and local time at the event 
site.

WDYT?

All the best,
Tom

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

Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode)

[Max Nikulin]

On 23/01/2023 23:04, Thomas S. Dye wrote:
>> I understand above that it is easier understandable when reading
>> [2023-01-22 Sun 08:29@+1100] as it is assumed by poster (I guess Max)
>> that user will understand that there is +11 hours ahead.
>>
> Yes, the offset here is ambiguous--is it offset from some timezone or 
> from UTC?

Are you aware of usage base time other than UTC nowadays? My impression 
is that various libraries do not allow to get such formats easily. That 
is why e.g. web sites tends to present time in the server timezone 
(often not explicitly specified) or use JavaScript to convert it to 
browser timezone.

I believed that [2023-01-22 Sun 08:29@+1100] unambiguously suggests 
offset from UTC.

Are there local references that may confuse users? I mean something like 
9 hours ahead of Moscow (Asia/Kamchatka) used in USSR.

Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode)

[Thomas S. Dye]

Aloha Max,

Max Nikulin <manikulin@gmail.com> writes:

> On 23/01/2023 23:04, Thomas S. Dye wrote:
>>> I understand above that it is easier understandable when 
>>> reading
>>> [2023-01-22 Sun 08:29@+1100] as it is assumed by poster (I 
>>> guess Max)
>>> that user will understand that there is +11 hours ahead.
>>>
>> Yes, the offset here is ambiguous--is it offset from some 
>> timezone or from
>> UTC?
>
> Are you aware of usage base time other than UTC nowadays? My 
> impression is that
> various libraries do not allow to get such formats easily. That 
> is why e.g. web
> sites tends to present time in the server timezone (often not 
> explicitly
> specified) or use JavaScript to convert it to browser timezone.
>
> I believed that [2023-01-22 Sun 08:29@+1100] unambiguously 
> suggests offset from
> UTC.

Not for a casual programmer like me. The timestamp alone might 
easily be read as 11 hours ahead of local time. Nevertheless, Org 
is certainly free to interpret it as relative to UTC.

> Are there local references that may confuse users? I mean 
> something like 9 hours
> ahead of Moscow (Asia/Kamchatka) used in USSR.

I think 9 hours ahead of a timezone with a potentially variable 
offset from UTC has the potential to sow confusion, yes.

All the best,
Tom

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

Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode)

[Max Nikulin]

On 24/01/2023 09:44, Thomas S. Dye wrote:
> Max Nikulin writes:
>>
>> I believed that [2023-01-22 Sun 08:29@+1100] unambiguously suggests 
>> offset from UTC.
> 
> Not for a casual programmer like me. The timestamp alone might easily be 
> read as 11 hours ahead of local time. Nevertheless, Org is certainly 
> free to interpret it as relative to UTC.

My primary concern is that I might be wrong assuming that format like 
[2023-01-22 Sun 08:29@+1100] with offset in respect to UTC is reciprocal 
identity  mapping to UTC.

Of course there are a lot of people unaware of UTC. Org users may be 
educated by the manual and by hints in UI pushing toward time fixed in 
respect to UTC when "global" timestamp should be added. (In the sense of 
e.g. Lunar eclipse or an on-line meeting, not to confuse with set of 
events appointed on specific date but starting at the same local time in 
each location).

I am afraid of confusion with repeater intervals, but syntax has not 
fixed yet.

So we had different types of ambiguity in mind. Base time for offset was 
unclear for you, I was writing about mapping to UTC. Your point should 
be taken into account during consideration of storage format.

I still believe that something like [2023-01-21 Sat 21:29:00Z] and 
[2023-01-22 Sun 08:29@+1100] may be used to store timestamps 
interchangeably.

>> Are there local references that may confuse users? I mean something 
>> like 9 hours
>> ahead of Moscow (Asia/Kamchatka) used in USSR.
> 
> I think 9 hours ahead of a timezone with a potentially variable offset 
> from UTC has the potential to sow confusion, yes.

If someone has examples of local time offsets (unrelated to UTC) widely 
used in some area, please, post them.

MSK+3 style was not a real issue because daylight saving time was active 
during the same period in the whole country and iron curtain was 
efficiently isolating most of people form variety of DST rules in other 
areas.

Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode)

[Jean Louis]

* Max Nikulin <manikulin@gmail.com> [2023-01-24 07:51]:
> On 24/01/2023 09:44, Thomas S. Dye wrote:
> > Max Nikulin writes:
> > > 
> > > I believed that [2023-01-22 Sun 08:29@+1100] unambiguously suggests
> > > offset from UTC.
> > 
> > Not for a casual programmer like me. The timestamp alone might easily be
> > read as 11 hours ahead of local time. Nevertheless, Org is certainly
> > free to interpret it as relative to UTC.
> 
> My primary concern is that I might be wrong assuming that format like
> [2023-01-22 Sun 08:29@+1100] with offset in respect to UTC is reciprocal
> identity  mapping to UTC.

ISO 8601 is international standard on which you should make decisions.

https://en.wikipedia.org/wiki/ISO_8601#Time_offsets_from_UTC
https://en.wikipedia.org/wiki/UTC_offset

,----
| The UTC offset (or time offset) is an amount of time subtracted from
| or added to Coordinated Universal Time (UTC) time to specify the local
| solar time (which may not be the current civil time, whether it is
| standard time or daylight saving time). 
`----

I hope your concern clarifies itself.

-- 
Jean

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

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

Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode)

[Ihor Radchenko]

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

>> I understand above that it is easier understandable when reading
>> [2023-01-22 Sun 08:29@+1100] as it is assumed by poster (I guess 
>> Max)
>> that user will understand that there is +11 hours ahead.
>>
> Yes, the offset here is ambiguous--is it offset from some timezone 
> or from UTC?

It is not ambiguous if the user is familiar with standard time format.
The representation above is derived from
https://en.wikipedia.org/wiki/ISO_8601, which allows the following:

    <time>Z

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

    <time>±hh:mm
    <time>±hhmm
    <time>±hh

    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".
    
    Positive UTC offsets describe a time zone at or east of UTC±00:00, where
    the civil time is the same as or ahead (or later) than UTC so the zone
    designator will look like "+02:00","+0200", or "+02".

> Here is a proposal for a terminology of events that honors 
> Ramsey's distinction between events and occurrences and hopes to 
> cover all of Org's use cases.
> ...
> ...
> The Org user should be able to toggle timestamp representation. 
> In the case of a no-host event, user might toggle between UTC and 
> local time.  In the case of situated or itinerant event, user 
> might toggle among UTC, local time, and local time at the event 
> site.

Instead of toggling, would it be better to echo the different formats
like eldoc does + mouse-echo?

-- 
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: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode)

[Thomas S. Dye]

Aloha Ihor,

Ihor Radchenko <yantar92@posteo.net> writes:

> "Thomas S. Dye" <tsd@tsdye.online> writes:
>
>>> I understand above that it is easier understandable when 
>>> reading
>>> [2023-01-22 Sun 08:29@+1100] as it is assumed by poster (I 
>>> guess 
>>> Max)
>>> that user will understand that there is +11 hours ahead.
>>>
>> Yes, the offset here is ambiguous--is it offset from some 
>> timezone 
>> or from UTC?
>
> It is not ambiguous if the user is familiar with standard time 
> format.
> The representation above is derived from
> https://en.wikipedia.org/wiki/ISO_8601, which allows the 
> following:
>
>     <time>Z
>
>     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".
>
>     <time>±hh:mm
>     <time>±hhmm
>     <time>±hh
>
>     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".
>     
>     Positive UTC offsets describe a time zone at or east of 
>     UTC±00:00, where
>     the civil time is the same as or ahead (or later) than UTC 
>     so the zone
>     designator will look like "+02:00","+0200", or "+02".
>

Got it.  Thanks for the full explanation!  The ambiguity I 
mentioned was due to my ignorance of the time standard format 
variants.

>> Here is a proposal for a terminology of events that honors 
>> Ramsey's distinction between events and occurrences and hopes 
>> to 
>> cover all of Org's use cases.
>> ...
>> ...
>> The Org user should be able to toggle timestamp representation. 
>> In the case of a no-host event, user might toggle between UTC 
>> and 
>> local time.  In the case of situated or itinerant event, user 
>> might toggle among UTC, local time, and local time at the event 
>> site.
>
> Instead of toggling, would it be better to echo the different 
> formats
> like eldoc does + mouse-echo?

Or both?  Toggling globally and echoing individually, IIUC?

All the best,
Tom

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

Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode)

[Max Nikulin]

On 23/01/2023 23:04, Thomas S. Dye wrote:
> * Kinds of event
> - No-host event :: An event that takes place at an absolute time. 
> Participants must know their local timezone offset from UTC. Example 
> [2023-01-23 06:00@UTC].
> - Situated event :: An event that takes place at a time local to the 
> event site.  Participants must know their local timezone offset from UTC 
> and the event site timezone offset from UTC at the time of the event.  
> Example [2023-01-22 Sun 08:29@Australia/Sydney].
> - [Itinerant | Traveling | Mobile] event :: An event that takes place at 
> a time local to the event site, which might change after the event has 
> been scheduled.  Participants must know their local timezone offset from 
> UTC and the event site timezone offset from UTC at the time of the 
> event.  Examples might be a regular staff meeting that takes place at 
> 9:00 AM wherever the boss happens to be, or a proposal to meet with a 
> traveler when it is noon on Sunday for the traveler. Example [2023-01-23 
> 06:00].  In this case timezone is set according to user timezone 
> preference in scope.

Thomas, I mostly agree with the set of event kinds your suggested. 
Perhaps names should be justified to have precise and concise terms in 
UI. From my point of view their value is association with appropriate 
storage format for particular timestamp.

An additional parameter (or sometimes first one to choose) is if 
explicit or implicit time zone should be used in the file. In the latter 
case the same kinds of events are possible, particular one is determined 
from a parent scope. User should be just aware what is actual time zone 
if it is implicit one.

The following concept is aside from event kinds, but might (or might 
not) be useful to present agenda, to schedule events, to implement the 
feature. Perhaps a trip may be considered as an ad hoc timezone that 
follows offsets of time in locations to visit. (Several such ad hoc time 
zones may allow to track schedule of several people, but it may be too 
complex to use.) It may be considered close to "mobile" event, but the 
purpose is not to ensure correct time of particular event. It may 
facilitate presentation of timeline during the trip.

Perhaps it is more correct to talk about how events are scheduled, not 
of event kinds. Consider Christmas and similar events. It is personal 
and local for each user. If you share your .org file (with specified 
file-local time zone) with other persons they celebrate accordingly to 
their local time. In addition they may decide that it should be pleasant 
for you to receive a greeting close to your local time.

It seems during discussion we use terms in slightly different meaning, 
so I will try to clarify my point of view.

I had a course on general relativity theory, so "absolute time" does 
make much sense for me. UTC is just a widely accepted agreement. I was 
bound to Earth rotation and accumulated some offset from more precise 
atomic clocks. UTC however currently is easiest way to perform time 
related calculations.

My perception is still that UTC is one of timezones that may be used to 
specify event time. It is a bit special since it is used as a reference 
for other time zones, so it may be preferable for global events. If UTC 
considered as an ordinary time zone then the whole set of time zones may 
be divided into 2 classes: with fixed time offset (including UTC, 
Etc/GMT+3 that may be specified as -03:00, etc) and with time zones 
associated to specific locations. Second class is affected by DST, 
changes of offsets that may be source of uncertainty. The role of UI is 
to help user to choose a timezone that is suited best for particular 
event. For events in the future often it is necessary to use a 
location-based time zone, in other cases it is UTC or anyone with fixed 
offset. When you recording current time, explicit offset may be better. 
I am still unsure what is better to use: kinds of events or kinds of 
time zones.

I agree that offset as a part of timestamp may be confusing, but I am 
afraid that significant part of affected users are unaware of UTC as 
well. That is why proper UI may be a challenging task.

Thomas, for me event kinds are less important than understanding that 
UTC timestamps are not enough achieve properly working schedule. 
Currently you see that timezones associated with locations in some cases 
must be used in stored timestamps. Have you noticed that I missed 
anything significant in your messages?

Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode)

[Thomas S. Dye]

Aloha Max,

Max Nikulin <manikulin@gmail.com> writes:

> On 23/01/2023 23:04, Thomas S. Dye wrote:
>> * Kinds of event
>> - No-host event :: An event that takes place at an absolute 
>> time. Participants
>> must know their local timezone offset from UTC. Example 
>> [2023-01-23
>> 06:00@UTC].
>> - Situated event :: An event that takes place at a time local 
>> to the event
>> site.  Participants must know their local timezone offset from 
>> UTC and the
>> event site timezone offset from UTC at the time of the event. 
>> Example
>> [2023-01-22 Sun 08:29@Australia/Sydney].
>> - [Itinerant | Traveling | Mobile] event :: An event that takes 
>> place at a
>> time local to the event site, which might change after the 
>> event has been
>> scheduled.  Participants must know their local timezone offset 
>> from UTC and
>> the event site timezone offset from UTC at the time of the 
>> event.  Examples
>> might be a regular staff meeting that takes place at 9:00 AM 
>> wherever the boss
>> happens to be, or a proposal to meet with a traveler when it is 
>> noon on Sunday
>> for the traveler. Example [2023-01-23 06:00].  In this case 
>> timezone is set
>> according to user timezone preference in scope.
>
> Thomas, I mostly agree with the set of event kinds your 
> suggested. Perhaps names
> should be justified to have precise and concise terms in UI. 
> From my point of
> view their value is association with appropriate storage format 
> for particular
> timestamp.
>
Agreed.  Another idea for the mobile event is "variably situated 
event".  I don't doubt that better terms might be proposed.

> An additional parameter (or sometimes first one to choose) is if 
> explicit or
> implicit time zone should be used in the file. In the latter 
> case the same kinds
> of events are possible, particular one is determined from a 
> parent scope. User
> should be just aware what is actual time zone if it is implicit 
> one.

I was trying to capture this in the timestamp, where an explicit 
time zone is indicated and an implicit time zone is simply a date 
and time.
>
> The following concept is aside from event kinds, but might (or 
> might not) be
> useful to present agenda, to schedule events, to implement the 
> feature. Perhaps
> a trip may be considered as an ad hoc timezone that follows 
> offsets of time in
> locations to visit. (Several such ad hoc time zones may allow to 
> track schedule
> of several people, but it may be too complex to use.) It may be 
> considered close
> to "mobile" event, but the purpose is not to ensure correct time 
> of particular
> event. It may facilitate presentation of timeline during the 
> trip.

An alternative would be to have headlines for each stop on the 
trip, each of which has a #+TIMEZONE property.  Under each 
headline would be subheads for events, each with a timestamp for a 
"mobile event".  Org would let me toggle the times of these events 
relative to my current location, the event location, and UTC.

>
> Perhaps it is more correct to talk about how events are 
> scheduled, not of event
> kinds. Consider Christmas and similar events. It is personal and 
> local for each
> user. If you share your .org file (with specified file-local 
> time zone) with
> other persons they celebrate accordingly to their local time. In 
> addition they
> may decide that it should be pleasant for you to receive a 
> greeting close to
> your local time.

In the first case, "Open Christmas presents at 8:00 AM", the event 
would be variably situated because I want to do this on the years 
I celebrate at home and also the years when I celebrate with 
friends and family in other parts of the world.  A timestamp for a 
variably situated event shares well--the recipient user needs to 
ensure that the event is stored within user's local time zone 
scope.

In the second case, "Send Christmas greetings to Max when he opens 
presents at 8:00 AM" would be an event situated at the place Max 
is celebrating--it is separate from the first case.  If I know 
where Max will celebrate Christmas, then I could use a timestamp 
for a situated event.  Otherwise, I would use a timestamp for a 
mobile event and make certain to ensure that the time zone scope 
for the event tracks Max's whereabouts.
>
> It seems during discussion we use terms in slightly different 
> meaning, so I will
> try to clarify my point of view.
>
> I had a course on general relativity theory, so "absolute time" 
> does make much
> sense for me. UTC is just a widely accepted agreement. I was 
> bound to Earth
> rotation and accumulated some offset from more precise atomic 
> clocks. UTC
> however currently is easiest way to perform time related 
> calculations.

Yes, UTC is the sign we've widely agreed to interpret as absolute 
time.  A key property is that UTC is a continuum, absent the 
potential discontinuities that characterize space/time units like 
time zones.

> My perception is still that UTC is one of timezones that may be 
> used to specify
> event time. It is a bit special since it is used as a reference 
> for other time
> zones, so it may be preferable for global events. If UTC 
> considered as an
> ordinary time zone then the whole set of time zones may be 
> divided into 2
> classes: with fixed time offset (including UTC, Etc/GMT+3 that 
> may be specified
> as -03:00, etc) and with time zones associated to specific 
> locations. Second
> class is affected by DST, changes of offsets that may be source 
> of uncertainty.
> The role of UI is to help user to choose a timezone that is 
> suited best for
> particular event. For events in the future often it is necessary 
> to use a 
> location-based time zone, in other cases it is UTC or anyone 
> with fixed offset.
> When you recording current time, explicit offset may be better. 
> I am still
> unsure what is better to use: kinds of events or kinds of time 
> zones.
>
Well, you know where I stand on this---UTC is not a time zone and 
no good comes from confusing it with one.  Nevertheless, the UI 
issue need not require the user to grasp the distinction between 
event and occurrence.  My idea was to use "no host event" to refer 
to an occurrence.  To my mind, "no host" gets to the point of "not 
associated with a particular region of space/time", so that 
calling it an event, a fundamental space/time unit, is less likely 
to cause confusion.

> I agree that offset as a part of timestamp may be confusing, but 
> I am afraid
> that significant part of affected users are unaware of UTC as 
> well. That is why
> proper UI may be a challenging task.
>
The discussion around this point confuses me.  One the one hand, a 
timestamp for absolute time (UTC or offset from UTC) should be 
stored in the format that minimizes computations that will 
subsequently involve it.  On the other hand, the user can toggle 
or otherwise see (Ihor's eldoc solution) the timestamp in the 
format that makes the most sense, so the readability of the 
storage format is not really at issue.

> Thomas, for me event kinds are less important than understanding 
> that UTC
> timestamps are not enough achieve properly working schedule. 
> Currently you see
> that timezones associated with locations in some cases must be 
> used in stored
> timestamps. Have you noticed that I missed anything significant 
> in your
> messages?

No, I don't think you've missed anything significant.  Thanks very 
much for your patience during a discussion that was interesting 
for me.  I learned quite a bit from you and the other contributors 
to the thread and look forward now to learning how Org mode 
evolves to handle events and occurrences.

Let me know if you have questions.

All the best,
Tom

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

Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode)

[Tim Cross]

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

> No, I don't think you've missed anything significant.  Thanks very much for your patience
> during a discussion that was interesting for me.  I learned quite a bit from you and the
> other contributors to the thread and look forward now to learning how Org mode evolves to
> handle events and occurrences.
>
> Let me know if you have questions.
>

Agreed. I also think this latest discussion is extremely valuable as
coming up with some clear terminology which can be used to reference
different use cases for timestamps is very likely going to make
documentation and exmaples/tutorials much cleaner and could help define
a more intuitive interface which helps users select the right option in
the right circumstance.

Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode)

[Tim Cross]

Max Nikulin <manikulin@gmail.com> writes:

> On 22/01/2023 04:29, Tim Cross wrote:
>> Max Nikulin writes:
>>> - UTC is a recommendation for planning when participants are scattered over multiple
>>>   timezones.
>>> - You admit that some timestamps in your files may be specified as time zone identifier +
>>>   local time relative to this zone.
>>> - In both cases you may configure overlays to use local timezone or another one whatever
>>>   you currently find convenient.
>>> - Time chooser offers several time zone options.
>> That seems to be in-line with what I was arguing, so yes, would agree.
>
> Great. At this stage my goal is to convince people that local time and UTC for future
> timestamps are not enough for real life use cases. Arbitrary timezone may be crucial to
> arrive at proper time despite it matters in rare cases. My concern is mostly storage
> format, timestamp syntax in Org files.
>
> On 21/01/2023 06:38, Tim Cross wrote:
>>>> I would also argue UTC is good for 'traditional' timestamps which record
>>>> a specific point in time and for situations where you want accurate
>>>> calculations of time durations.
>
> Let's consider the following timestamp
>
> [2023-01-22 Sun 08:29@+1100]
>
> "@" is unimportant here, I take it from Ihor's examples. This timestamp is from the
> "Date:" header of your message. It is not UTC, but in my opinion it is equally precise
> (disregarding seconds) to a UTC timestamp.
>
> Would you prefer to have timestamps in your files in such form or as
>
> [2023-01-21 Sat 21:29Z] ([2023-01-21 Sat 21:29@UTC], [2023-01-21 Sat 21:29@+00:00], etc)?
>
> Maybe [@1674336588] (seconds since epoch)?
>

It really depends on what the timestamp is for as to what my preference
would be.  For example, timestamp for an email message is likely best as
your initial example or date with remote senders TZ. Timestamp for a log
record I would probably want <YYYY-MM-DD HH:MM Z> or one of the
variants because the most common way I use those types of timestamp is
in diagnosing problems and comparing revords from various locations
where I don't care about the local time where the record was generated,
but with when it occurred in relation to other log recores.  

> I consider storage format as a part of Org UI, so I believe that [2023-01-22 Sun
> 08:29@+1100] with offset of the usual time zone is more convenient than [2023-01-21 Sat
> 21:29@+0000]. Overlays may present your local time in both cases, but raw value with usual
> offset is easier to comprehend.
>

I would argue that all depends on how you use the information. My org
files are consumed by me (reading) and by scripts, elisp and other
programs. 

> When a file is shared by a group of people spread across the globe, they are free to use
> UTC or another fixed timezone or do not care at all concerning particular offset, it just
> should present.
>

Guess I agree, but this is such a rare/small use case, I really don't
consider it terribly relevant. While I do share data relating to
projects I work on with others, I am the only one who uses org mode and
I suspect I'm the only one who uses Emacs. Sharing org mode files simply
isn't a use case I need to worry about and sharing timestamp data from
those files is rare as well - if I do need to, they will likely be
processed into some other more standard format anyway. 

> Postgres has a reason to insist on UTC since timestamps are stored in binary format as
> microseconds since epoch. It is important for performance and there is no room to specify
> offset. Org has to parse timestamps from strings anyway, so it is better to use format
> more convenient for humans.
>

Again, depends on the use case and how you use the data. 

> A side note. In my opinion, *by default* timestamps should be created in local time with
> no offset or timezone. There are should be some preferences to enable absolute timestamps
> and a function to fix offsets or timezone identifiers for existing timestamp when the user
> realizes that they become necessary (e.g. before a trip).
>
> So I do not see any advantages of UTC in comparison to time offset specific to particular
> time zone, usually user's local one. My vote is [2023-01-22 Sun 08:29@+1100] and not
> [2023-01-21 Sat 21:29@UTC] (of course, only in cases when identifiers like
> Australia/Sydney do not matter) with a configuration option with timezone used fix offsets
> in stored timestamps.

My preference is for a timestamp syntax which lets the user select the
format they want and not attempt to restrict it more than that. Provided
you can specify timestamp with and without TZ information and you
support full and abbreviated time zone names as well as UTC, I don't
think it mattters - let the user choose what suits them best. I
definitely have use cases where timestamp in UTC is the most convenient
format. 

My default would be without time zones, but enable easy adding of
timezones when needed e.g. by calling the function with C-u.

The availability of configurable display overlays would be very useful,
but you also need to be able to turn that off easily and you probably
need an easy way to temporarily update/change the overlay format. 

Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode)

[Max Nikulin]

On 22/01/2023 14:48, Tim Cross wrote:
> Timestamp for a log
> record I would probably want <YYYY-MM-DD HH:MM Z> or one of the
> variants because the most common way I use those types of timestamp is
> in diagnosing problems and comparing revords from various locations
> where I don't care about the local time where the record was generated,
> but with when it occurred in relation to other log recores.

I agree that it is more convenient to have uniform offset in such case, 
especially in the case of multiple files having their specific timezone. 
During trips I do not expect so much changes of timezone to make 
comparison of timestamps significantly harder.

> I would argue that all depends on how you use the information. My org
> files are consumed by me (reading) and by scripts, elisp and other
> programs.

For scripts given offset should not be an issue at all. And it is up to 
you if you prefer to have UTC instead of local time offset in you files.

> My preference is for a timestamp syntax which lets the user select the
> format they want and not attempt to restrict it more than that.

I do not mind to provide a user option for preferred storage format used 
for clock entries and similar stuff.

> Provided
> you can specify timestamp with and without TZ information and you
> support full and abbreviated time zone names as well as UTC, I don't
> think it mattters - let the user choose what suits them best.

Concerning time zone abbreviations, I would discourage them as much as 
possible for storage format. They may be added to overlay though. 
Perhaps US residents would be unhappy by such decision, but there are 
enough examples of the same abbreviation for completely unrelated 
locations. Abbreviation may be useful in addition to timezone ID to 
disambiguate local time close to a backward time jump.

Tim, in your last messages I do not see statements causing my objections 
any more. It seems we came to agreement: flexible enough storage format 
and configurable display format for overlays. Have I forgot anything?

Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode)

[Jean Louis]

* Max Nikulin <manikulin@gmail.com> [2023-01-24 20:12]:
> On 22/01/2023 14:48, Tim Cross wrote:
> > Timestamp for a log
> > record I would probably want <YYYY-MM-DD HH:MM Z> or one of the
> > variants because the most common way I use those types of timestamp is
> > in diagnosing problems and comparing revords from various locations
> > where I don't care about the local time where the record was generated,
> > but with when it occurred in relation to other log recores.
> 
> I agree that it is more convenient to have uniform offset in such case,
> especially in the case of multiple files having their specific timezone.
> During trips I do not expect so much changes of timezone to make comparison
> of timestamps significantly harder.
> 
> > I would argue that all depends on how you use the information. My org
> > files are consumed by me (reading) and by scripts, elisp and other
> > programs.
> 
> For scripts given offset should not be an issue at all. And it is up to you
> if you prefer to have UTC instead of local time offset in you files.

Surely I understand your point of view, but offset does not provide to
people their local time, that would just make confusion.

-- 
Jean

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

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

Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode)

[Tim Cross]

Max Nikulin <manikulin@gmail.com> writes:

> On 22/01/2023 14:48, Tim Cross wrote:
>> Timestamp for a log
>> record I would probably want <YYYY-MM-DD HH:MM Z> or one of the
>> variants because the most common way I use those types of timestamp is
>> in diagnosing problems and comparing revords from various locations
>> where I don't care about the local time where the record was generated,
>> but with when it occurred in relation to other log recores.
>
> I agree that it is more convenient to have uniform offset in such case, especially in the
> case of multiple files having their specific timezone. During trips I do not expect so
> much changes of timezone to make comparison of timestamps significantly harder.
>
>> I would argue that all depends on how you use the information. My org
>> files are consumed by me (reading) and by scripts, elisp and other
>> programs.
>
> For scripts given offset should not be an issue at all. And it is up to you if you prefer
> to have UTC instead of local time offset in you files.
>
>> My preference is for a timestamp syntax which lets the user select the
>> format they want and not attempt to restrict it more than that.
>
> I do not mind to provide a user option for preferred storage format used for clock entries
> and similar stuff.
>
>> Provided
>> you can specify timestamp with and without TZ information and you
>> support full and abbreviated time zone names as well as UTC, I don't
>> think it mattters - let the user choose what suits them best.
>
> Concerning time zone abbreviations, I would discourage them as much as possible for
> storage format. They may be added to overlay though. Perhaps US residents would be unhappy
> by such decision, but there are enough examples of the same abbreviation for completely
> unrelated locations. Abbreviation may be useful in addition to timezone ID to disambiguate
> local time close to a backward time jump.
>
> Tim, in your last messages I do not see statements causing my objections any more. It
> seems we came to agreement: flexible enough storage format and configurable display format
> for overlays. Have I forgot anything?

No, I think you have covered everything.

I think most of your remaining concerns can be adequately covered via
some updated documentation and with some luck, people will add some use
case workflows to worg showing how using different storage formats and
display overlays can address various scenarios.  

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

[Ihor Radchenko]

Tim Cross <theophilusx@gmail.com> writes:

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

You need to come to an agreement about when to do the meeting. Be it
your TZ, and other participant's TZ, or some other fixed TZ (including
UTC or offsets from it).

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

`org-read-date' should definitely be extended to understand time zones.
As for the display, we have `org-display-custom-times'. Might need to
extend it in future, but maybe the existing functionality is already
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

[Alexander Adolf]

Tim Cross <theophilusx@gmail.com> writes:

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

Or to any other timezone. The key point here is that you _do_ specify a
timezone. Then, everybody can convert that and have it displayed in any
timezone they find useful.

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

[Jean Louis]

* Alexander Adolf <alexander.adolf@condition-alpha.com> [2023-01-19 20:59]:
> Or to any other timezone. The key point here is that you _do_ specify a
> timezone. Then, everybody can convert that and have it displayed in any
> timezone they find useful.

Concise and very right, thanks!


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

[Max Nikulin]

On 17/01/2023 16:45, Tim Cross wrote:
> 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.
> When we
> transition into/out of daylight savings time, I don't want the timestamp
> to change. THe meeting will remain at 3pm.

You specify time zone (globally, for the file, for the subtree, or for 
the particular timestamp) using IANA ID (e.g. Australia/Canberra)

TZ=Australia/Canberra date -d "15:00" '+%F %a %T %z %Z'
2023-01-19 Thu 15:00:00 +1100 AEDT

TZ=Australia/Canberra date -d "+6 month 15:00" '+%F %a %T %z %Z'
2023-07-19 Wed 15:00:00 +1000 AEST

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

You either specify time offset or a timezone with fixed offset

TZ=Australia/Canberra date -d "09:00 +0500" '+%F %a %T %z %Z'
2023-01-19 Thu 15:00:00 +1100 AEDT

TZ=Australia/Canberra date -d "+6month 09:00 +0500" '+%F %a %T %z %Z'
2023-07-19 Wed 14:00:00 +1000 AEST

TZ=Australia/Canberra date -d 'TZ="Etc/GMT-5" 09:00' '+%F %a %T %z %Z'
2023-01-18 Wed 15:00:00 +1100 AEDT

TZ=Australia/Canberra date -d 'TZ="Etc/GMT-5" +6month 09:00' '+%F %a %T 
%z %Z'
2023-07-18 Tue 14:00:00 +1000 AEST

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

You specify that you original time zone e.g. Australia/Canberra, since 
2023-01-25 15:00 +0100 Europe/Berlin should be used and that agenda 
should be presented in either the "time zome" following you, or some 
fixed one (Australia/Canberra, Europe/Berlin, or Asia/Singapore)

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

[Ihor Radchenko]

Robert Horn <rjhorn@panix.com> writes:

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

Let me clarify. I do not think that we need to offer selecting DST/no
DST in the timestamp. Instead, we offer something like
<2028-12-11 18:00@Europe/Berlin>, specifying local time, including
possible DST transitions or any other political decisions the country
might make regarding the local time rules.

Or, if the preference is specifying time in such a way that it is
unaffected by the local time rules (for example, "+10000 hours from now,
no matter what the DST/no DST or whatever rules will happen in the
middle"), one can use explicit UTC offsets like <2028-12-11 18:00@UTC+02>

Can you think of any situations when these two variants are not
sufficient? AFAIU, they should cover your example just fine.

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

[Robert Horn]

Ihor Radchenko <yantar92@posteo.net> writes:

> Robert Horn <rjhorn@panix.com> writes:
>
>>> 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:
>
> Let me clarify. I do not think that we need to offer selecting DST/no
> DST in the timestamp. Instead, we offer something like
> <2028-12-11 18:00@Europe/Berlin>, specifying local time, including
> possible DST transitions or any other political decisions the country
> might make regarding the local time rules.
>

That would cover it for me.  So, 18:00@Europe/Berlin is the "then local
time", 18:00@CET would be Central European standard time and 18:00@CEST
would be Central European Summer Time.  18:00@UTC would be 19:00@CET and
18:00@CEST. I've found that by far the most common scheduling uses the
"then local time" because that's what people usually want.  I know when
someone schedules a meeting in late March they rarely figure out whether
it will be summer time or standard time.


> Or, if the preference is specifying time in such a way that it is
> unaffected by the local time rules (for example, "+10000 hours from now,
> no matter what the DST/no DST or whatever rules will happen in the
> middle"), one can use explicit UTC offsets like <2028-12-11
> 18:00@UTC+02>

Interesting question.  Some uses (like scheduling physical process) want
+4 hours to mean 4 hours later regardless of leap seconds or summer time
changes.  But most people scheduling issues where they say "in 24 hours"
they actually mean +24 in local time.  At the transition to or from
summer time the phrase "within 24 hours" usually means 24 hours except
on the transition days when it's 23 or 25 hours.

Don't worry about TAI.  People who are working in TAI are unlikely to
expect org to support TAI. 


-- 
Robert Horn
rjhorniii@gmail.com

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

[Alexander Adolf]

Robert Horn <rjhorn@panix.com> writes:

> [...]
> The issue is clarity of the expected rules for the format.  If I
> schedule a meeting for 10:05 DST,
> [...]

In all calendaring software I have used thus far, I don't do that. I can
specify a date and time of day only (but never "DST"). The software then
works out (likely with the help of the OS, and using POSIX APIs) whether
that is DST or not, whenever the event's offset to UTC is needed (e.g.
to display the event in another timezone).

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

[Alexander Adolf]

Robert Horn <rjhorn@panix.com> writes:

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

AFAIU, setting "clear rules" for this seems impossible. Around DST
changeovers, there are ambiguous time-of-day specifications, which occur
more than once on that date. Hence, for such events UTC time
specifications must be used, or everybody is doomed to either arrive
hours early, or hours late for the appointment.

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

[Jean Louis]

* Ihor Radchenko <yantar92@posteo.net> [2023-01-16 22:08]:
> 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:

I am sure that system library must be responsible to know those
changes. It is not for Org. 

So the calculation which transforms +1 time zone to -5 time zone shall
be done by using system libraries which are supposed to have those
options. I have no idea if they have.

> 2. There might be arbitrary time gaps due to time transition, including

>    - One hour back during DST transition (northern and southern
>      hemispheres do the transitions in opposite directions)
>    - Multiple days skipped (Samoa skips a whole day during DST
>      transition)

Interesting, but I still think that shall be in system library, and
system libraries shall provide calculation functions. 

Does that exist in C library?

> 3. We cannot assume that the same geographical area has fixed time zone
>    even at given point of time:
>    - Palestinian/Israeli people follow different time zones in the
>      contested territories

They may, sure, I can also follow my own, but Org and system libraries
shall use internationally accepted norms.

> 4. Great Britain had new year on March 25 until 16th century
>    (March 24, 1000 -> (+1 day) March 25, 1001)

Of course, that is why December is called by that way, as the tenth
month, not twelfth. That may be part of representation of calendar,
but because it is history, it is not so important for us in future.

> 5. Leap seconds! 23:59:59 -> 23:59:60 -> 00:00:00, according to
>    astronomical Earth observations

Should be part of C library to observe those things.

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

[Ihor Radchenko]

Jean Louis <bugs@gnu.support> writes:

> ...
> Should be part of C library to observe those things.

Sure. My previous proposals are all relying on `encode-time' which uses
time.h from system libraries and utilizing TZDB that is taking care
about all this insanity.

We, however, might need to be careful about applying date increments. In
`org-read-date' and `org-timestamp-change', which are implemented in
Elisp without considering these complexities. (maybe also other
functions; these are just the ones I can think about)

What should we do when:

1. It is close to DST transition 2:59 -> 2:00 -> 2:01 -> ... -> 2:59 -> 3:00
   and the users asks to create a timestamp +1h from now
   or, worse, a timestamp +1h from now in a different time zone

2. A user asks +1w date shift and the time zone has a 1-day jump during DST?
   what about +7d? +1d?

3. What will be +1d 2:30am timestamp refer to when there DST transition
   as in (1)?


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

[Jean Louis]

* Ihor Radchenko <yantar92@posteo.net> [2023-01-18 12:29]:
> What should we do when:
> 
> 1. It is close to DST transition 2:59 -> 2:00 -> 2:01 -> ... -> 2:59 -> 3:00
>    and the users asks to create a timestamp +1h from now
>    or, worse, a timestamp +1h from now in a different time zone

I still understand that it should be job of underlying system
functions. Org is only invoking addition by using system time:

From Org timestamp with time zone one has to use system functions, to
add, or deduct time, then again to Org time representation.

> 2. A user asks +1w date shift and the time zone has a 1-day jump during DST?
>    what about +7d? +1d?

That is all for system functions to know. Is not good on the higher
level (of Org) to start deciding about international issues that shall
be recorded in C libraries somewhere, time zone databases, etc


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

Ihor Radchenko <yantar92@posteo.net> writes:

> Jean Louis <bugs@gnu.support> writes:
>
>> ...
>> Should be part of C library to observe those things.
>
> Sure. My previous proposals are all relying on `encode-time' which uses
> time.h from system libraries and utilizing TZDB that is taking care
> about all this insanity.
>
> We, however, might need to be careful about applying date increments. In
> `org-read-date' and `org-timestamp-change', which are implemented in
> Elisp without considering these complexities. (maybe also other
> functions; these are just the ones I can think about)
>
> What should we do when:
>
> 1. It is close to DST transition 2:59 -> 2:00 -> 2:01 -> ... -> 2:59 -> 3:00
>    and the users asks to create a timestamp +1h from now
>    or, worse, a timestamp +1h from now in a different time zone
>
> 2. A user asks +1w date shift and the time zone has a 1-day jump during DST?
>    what about +7d? +1d?
>
> 3. What will be +1d 2:30am timestamp refer to when there DST transition
>    as in (1)?

Yep, these are exactly the sorts of issues I was worried about wrt
adding time zone support. Challenge here is I'm not sure there is one
right answer. It will depend on individual use cases. I guess the best
we can do is select what seems to be the most 'sane' approach and
document th elimitations (and possibly how to work around them). The key
is likely to avoid user surprise. Limitations are often better accepted
when flagged up front and when 'discovered' later.

Initially, my thoughts on the 3 above are "I have no clue what the sane
default is" - all options seem to have equal pros and cons. Guess the
best we can do is go with the simplest solution and 'suck it and see". 

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

[Ihor Radchenko]

Tim Cross <theophilusx@gmail.com> writes:

> Initially, my thoughts on the 3 above are "I have no clue what the sane
> default is" - all options seem to have equal pros and cons. Guess the
> best we can do is go with the simplest solution and 'suck it and see". 

I am leaning towards this approach.
We already do things like

<2023-01-31 Thu +1m> -> <2023-03-03 Fri +1m>

and people are OK with it, seemingly.

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

[Max Nikulin]

On 17/01/2023 02:07, Ihor Radchenko wrote:
> https://www.youtube.com/watch?v=-5wpm-gesOY gives various examples.

More links:
- https://stackoverflow.com/tags/timezone/info
- 
https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time
   Falsehoods programmers believe about time

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

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

> https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time
>    Falsehoods programmers believe about time

Some potentially relevant items:

- Each calendar date is followed by the next in sequence, without
  skipping.
- The standard library supports negative years and years above 10000
- The day of the month always advances contiguously from N to either N+1
  or 1, with no discontinuities.
- There are 60 seconds in every minute.

All the above statements are FALSE!

All the above statements may affect, in particular, timestamps with
repeaters. Repeaters like +1h or +1d may require querying the TZdb (time
API).

Some good news is that all the above edge cases would equally affect the
current Org's timestamp handling code. Yet, we have no bug reports in
this area. I'd even go further and say that we should not try hard to
make things 100% accurate: (1) it will waste a lot of resources; (2)
users dealing with these edge cases are likely already accustomed to
most programs not handling things correctly for their special time zone
situations.

That said, if there is an easy way to handle some of the edge cases, we
can implement them.

Important: if some edge cases with time zones are buggy in OS time API,
it is not Org's job to work around the problem - we should rather report
those bugs upstream. What we should check, however, is the Org's own
ad-hoc code that is dealing with timestamps. In particular, I am
concerned about the repeater intervals. We will need to carefully review
the code to avoid nasty surprises.

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

[Jean Louis]

* Ihor Radchenko <yantar92@posteo.net> [2023-01-17 22:51]:
> Some good news is that all the above edge cases would equally affect the
> current Org's timestamp handling code. Yet, we have no bug reports in
> this area. I'd even go further and say that we should not try hard to
> make things 100% accurate: (1) it will waste a lot of resources; (2)
> users dealing with these edge cases are likely already accustomed to
> most programs not handling things correctly for their special time zone
> situations.

Org shall not handle that, only conversion between Emacs Lisp and
system functions.

Any maintenance shall be done on underlying level of system functions.

-- 
Jean

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

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

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

[Jean Louis]

* Max Nikulin <manikulin@gmail.com> [2023-01-17 20:31]:
> On 17/01/2023 02:07, Ihor Radchenko wrote:
> > https://www.youtube.com/watch?v=-5wpm-gesOY gives various examples.
> 
> More links:
> - https://stackoverflow.com/tags/timezone/info
> - https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time
>   Falsehoods programmers believe about time

Seems overwhelming to satisfy all requirement.

Is there any program, software, system, that is really so good with
time, apart from PostgreSQL database that I know with 1195 defined
time zones?

SELECT
    name,
    abbrev,
    utc_offset,
    is_dst
FROM pg_timezone_names;

                  name                  | abbrev | utc_offset | is_dst 
----------------------------------------+--------+------------+--------
 NZ                                     | NZDT   | 13:00:00   | t
 GB-Eire                                | GMT    | 00:00:00   | f
 Canada/Yukon                           | MST    | -07:00:00  | f
 Canada/Atlantic                        | AST    | -04:00:00  | f
 Canada/Pacific                         | PST    | -08:00:00  | f
 Canada/Eastern                         | EST    | -05:00:00  | f
 Canada/Central                         | CST    | -06:00:00  | f
 Canada/Saskatchewan                    | CST    | -06:00:00  | f
 Canada/Newfoundland                    | NST    | -03:30:00  | f
 Canada/Mountain                        | MST    | -07:00:00  | f
 Japan                                  | JST    | 09:00:00   | f
 Kwajalein                              | +12    | 12:00:00   | f
 Egypt                                  | EET    | 02:00:00   | f
 Poland                                 | CET    | 01:00:00   | f
 Turkey                                 | +03    | 03:00:00   | f
 CET                                    | CET    | 01:00:00   | f
 Brazil/DeNoronha                       | -02    | -02:00:00  | f
 Brazil/East                            | -03    | -03:00:00  | f
 Brazil/West                            | -04    | -04:00:00  | f
 Brazil/Acre                            | -05    | -05:00:00  | f
 Chile/Continental                      | -03    | -03:00:00  | t
 Chile/EasterIsland                     | -05    | -05:00:00  | t
 EST5EDT                                | EST    | -05:00:00  | f
 Atlantic/Jan_Mayen                     | CET    | 01:00:00   | f
 Atlantic/Cape_Verde                    | -01    | -01:00:00  | f
 Atlantic/South_Georgia                 | -02    | -02:00:00  | f
 Atlantic/Faroe                         | WET    | 00:00:00   | f
 Atlantic/St_Helena                     | GMT    | 00:00:00   | f
 Atlantic/Azores                        | -01    | -01:00:00  | f
 Atlantic/Madeira                       | WET    | 00:00:00   | f
 Atlantic/Stanley                       | -03    | -03:00:00  | f
 Atlantic/Bermuda                       | AST    | -04:00:00  | f
 Atlantic/Canary                        | WET    | 00:00:00   | f
 Atlantic/Reykjavik                     | GMT    | 00:00:00   | f
 Atlantic/Faeroe                        | WET    | 00:00:00   | f
 Iceland                                | GMT    | 00:00:00   | f
 GMT0                                   | GMT    | 00:00:00   | f
 EST                                    | EST    | -05:00:00  | f
 PRC                                    | CST    | 08:00:00   | f
 Cuba                                   | CST    | -05:00:00  | f
 Eire                                   | GMT    | 00:00:00   | t
 HST                                    | HST    | -10:00:00  | f
 GMT                                    | GMT    | 00:00:00   | f
 Greenwich                              | GMT    | 00:00:00   | f
 CST6CDT                                | CST    | -06:00:00  | f
 W-SU                                   | MSK    | 03:00:00   | f
 GMT+0                                  | GMT    | 00:00:00   | f
 EET                                    | EET    | 02:00:00   | f
 Etc/GMT-2                              | +02    | 02:00:00   | f
 Etc/GMT-13                             | +13    | 13:00:00   | f
 Etc/GMT+2                              | -02    | -02:00:00  | f
 Etc/GMT+7                              | -07    | -07:00:00  | f
 Etc/GMT-12                             | +12    | 12:00:00   | f
 Etc/GMT-5                              | +05    | 05:00:00   | f
 Etc/GMT-11                             | +11    | 11:00:00   | f
 Etc/GMT0                               | GMT    | 00:00:00   | f
 Etc/GMT+6                              | -06    | -06:00:00  | f
 Etc/GMT                                | GMT    | 00:00:00   | f
 Etc/Greenwich                          | GMT    | 00:00:00   | f
 Etc/GMT+0                              | GMT    | 00:00:00   | f
 Etc/GMT+4                              | -04    | -04:00:00  | f
 Etc/GMT-6                              | +06    | 06:00:00   | f
 Etc/GMT+11                             | -11    | -11:00:00  | f
 Etc/GMT+8                              | -08    | -08:00:00  | f
 Etc/GMT-8                              | +08    | 08:00:00   | f
 Etc/GMT+3                              | -03    | -03:00:00  | f
 Etc/GMT+5                              | -05    | -05:00:00  | f
 Etc/Universal                          | UTC    | 00:00:00   | f
 Etc/GMT+1                              | -01    | -01:00:00  | f
 Etc/UCT                                | UTC    | 00:00:00   | f
 Etc/GMT+12                             | -12    | -12:00:00  | f
 Etc/GMT-10                             | +10    | 10:00:00   | f
 Etc/GMT-7                              | +07    | 07:00:00   | f
 Etc/GMT-0                              | GMT    | 00:00:00   | f
 Etc/Zulu                               | UTC    | 00:00:00   | f
 Etc/GMT-14                             | +14    | 14:00:00   | f
 Etc/UTC                                | UTC    | 00:00:00   | f
 Etc/GMT-1                              | +01    | 01:00:00   | f
 Etc/GMT+9                              | -09    | -09:00:00  | f
 Etc/GMT-3                              | +03    | 03:00:00   | f
 Etc/GMT-4                              | +04    | 04:00:00   | f
 Etc/GMT+10                             | -10    | -10:00:00  | f
 Etc/GMT-9                              | +09    | 09:00:00   | f
 Pacific/Wake                           | +12    | 12:00:00   | f
 Pacific/Saipan                         | ChST   | 10:00:00   | f
 Pacific/Kwajalein                      | +12    | 12:00:00   | f
 Pacific/Chuuk                          | +10    | 10:00:00   | f
 Pacific/Chatham                        | +1345  | 13:45:00   | t
 Pacific/Pitcairn                       | -08    | -08:00:00  | f
 Pacific/Honolulu                       | HST    | -10:00:00  | f
 Pacific/Johnston                       | HST    | -10:00:00  | f
 Pacific/Niue                           | -11    | -11:00:00  | f
 Pacific/Yap                            | +10    | 10:00:00   | f
 Pacific/Guadalcanal                    | +11    | 11:00:00   | f
 Pacific/Tarawa                         | +12    | 12:00:00   | f
 Pacific/Palau                          | +09    | 09:00:00   | f
 Pacific/Samoa                          | SST    | -11:00:00  | f
 Pacific/Majuro                         | +12    | 12:00:00   | f
 Pacific/Port_Moresby                   | +10    | 10:00:00   | f
 Pacific/Apia                           | +13    | 13:00:00   | f
 Pacific/Truk                           | +10    | 10:00:00   | f
 Pacific/Marquesas                      | -0930  | -09:30:00  | f
 Pacific/Efate                          | +11    | 11:00:00   | f
 Pacific/Pago_Pago                      | SST    | -11:00:00  | f
 Pacific/Kosrae                         | +11    | 11:00:00   | f
 Pacific/Nauru                          | +12    | 12:00:00   | f
 Pacific/Enderbury                      | +13    | 13:00:00   | f
 Pacific/Bougainville                   | +11    | 11:00:00   | f
 Pacific/Wallis                         | +12    | 12:00:00   | f
 Pacific/Fakaofo                        | +13    | 13:00:00   | f
 Pacific/Kanton                         | +13    | 13:00:00   | f
 Pacific/Midway                         | SST    | -11:00:00  | f
 Pacific/Tongatapu                      | +13    | 13:00:00   | f
 Pacific/Noumea                         | +11    | 11:00:00   | f
 Pacific/Tahiti                         | -10    | -10:00:00  | f
 Pacific/Gambier                        | -09    | -09:00:00  | f
 Pacific/Rarotonga                      | -10    | -10:00:00  | f
 Pacific/Pohnpei                        | +11    | 11:00:00   | f
 Pacific/Fiji                           | +12    | 12:00:00   | f
 Pacific/Auckland                       | NZDT   | 13:00:00   | t
 Pacific/Kiritimati                     | +14    | 14:00:00   | f
 Pacific/Guam                           | ChST   | 10:00:00   | f
 Pacific/Norfolk                        | +12    | 12:00:00   | t
 Pacific/Galapagos                      | -06    | -06:00:00  | f
 Pacific/Easter                         | -05    | -05:00:00  | t
 Pacific/Funafuti                       | +12    | 12:00:00   | f
 Pacific/Ponape                         | +11    | 11:00:00   | f
 ROC                                    | CST    | 08:00:00   | f
 Europe/Vaduz                           | CET    | 01:00:00   | f
 Europe/Belfast                         | GMT    | 00:00:00   | f
 Europe/Volgograd                       | +03    | 03:00:00   | f
 Europe/Copenhagen                      | CET    | 01:00:00   | f
 Europe/Minsk                           | +03    | 03:00:00   | f
 Europe/Sofia                           | EET    | 02:00:00   | f
 Europe/Warsaw                          | CET    | 01:00:00   | f
 Europe/San_Marino                      | CET    | 01:00:00   | f
 Europe/Riga                            | EET    | 02:00:00   | f
 Europe/Kiev                            | EET    | 02:00:00   | f
 Europe/Isle_of_Man                     | GMT    | 00:00:00   | f
 Europe/Chisinau                        | EET    | 02:00:00   | f
 Europe/Prague                          | CET    | 01:00:00   | f
 Europe/Brussels                        | CET    | 01:00:00   | f
 Europe/Tiraspol                        | EET    | 02:00:00   | f
 Europe/Podgorica                       | CET    | 01:00:00   | f
 Europe/Guernsey                        | GMT    | 00:00:00   | f
 Europe/Vienna                          | CET    | 01:00:00   | f
 Europe/Sarajevo                        | CET    | 01:00:00   | f
 Europe/Kaliningrad                     | EET    | 02:00:00   | f
 Europe/Busingen                        | CET    | 01:00:00   | f
 Europe/Zaporozhye                      | EET    | 02:00:00   | f
 Europe/Ljubljana                       | CET    | 01:00:00   | f
 Europe/Bucharest                       | EET    | 02:00:00   | f
 Europe/Berlin                          | CET    | 01:00:00   | f
 Europe/Tallinn                         | EET    | 02:00:00   | f
 Europe/London                          | GMT    | 00:00:00   | f
 Europe/Paris                           | CET    | 01:00:00   | f
 Europe/Amsterdam                       | CET    | 01:00:00   | f
 Europe/Istanbul                        | +03    | 03:00:00   | f
 Europe/Vilnius                         | EET    | 02:00:00   | f
 Europe/Nicosia                         | EET    | 02:00:00   | f
 Europe/Astrakhan                       | +04    | 04:00:00   | f
 Europe/Saratov                         | +04    | 04:00:00   | f
 Europe/Jersey                          | GMT    | 00:00:00   | f
 Europe/Moscow                          | MSK    | 03:00:00   | f
 Europe/Helsinki                        | EET    | 02:00:00   | f
 Europe/Belgrade                        | CET    | 01:00:00   | f
 Europe/Kirov                           | +03    | 03:00:00   | f
 Europe/Kyiv                            | EET    | 02:00:00   | f
 Europe/Gibraltar                       | CET    | 01:00:00   | f
 Europe/Samara                          | +04    | 04:00:00   | f
 Europe/Ulyanovsk                       | +04    | 04:00:00   | f
 Europe/Andorra                         | CET    | 01:00:00   | f
 Europe/Oslo                            | CET    | 01:00:00   | f
 Europe/Uzhgorod                        | EET    | 02:00:00   | f
 Europe/Budapest                        | CET    | 01:00:00   | f
 Europe/Skopje                          | CET    | 01:00:00   | f
 Europe/Mariehamn                       | EET    | 02:00:00   | f
 Europe/Stockholm                       | CET    | 01:00:00   | f
 Europe/Zurich                          | CET    | 01:00:00   | f
 Europe/Zagreb                          | CET    | 01:00:00   | f
 Europe/Monaco                          | CET    | 01:00:00   | f
 Europe/Simferopol                      | MSK    | 03:00:00   | f
 Europe/Vatican                         | CET    | 01:00:00   | f
 Europe/Tirane                          | CET    | 01:00:00   | f
 Europe/Madrid                          | CET    | 01:00:00   | f
 Europe/Athens                          | EET    | 02:00:00   | f
 Europe/Dublin                          | GMT    | 00:00:00   | t
 Europe/Malta                           | CET    | 01:00:00   | f
 Europe/Rome                            | CET    | 01:00:00   | f
 Europe/Luxembourg                      | CET    | 01:00:00   | f
 Europe/Lisbon                          | WET    | 00:00:00   | f
 Europe/Bratislava                      | CET    | 01:00:00   | f
 Navajo                                 | MST    | -07:00:00  | f
 PST8PDT                                | PST    | -08:00:00  | f
 ROK                                    | KST    | 09:00:00   | f
 Portugal                               | WET    | 00:00:00   | f
 MET                                    | MET    | 01:00:00   | f
 Antarctica/McMurdo                     | NZDT   | 13:00:00   | t
 Antarctica/Vostok                      | +06    | 06:00:00   | f
 Antarctica/South_Pole                  | NZDT   | 13:00:00   | t
 Antarctica/Syowa                       | +03    | 03:00:00   | f
 Antarctica/Mawson                      | +05    | 05:00:00   | f
 Antarctica/DumontDUrville              | +10    | 10:00:00   | f
 Antarctica/Rothera                     | -03    | -03:00:00  | f
 Antarctica/Davis                       | +07    | 07:00:00   | f
 Antarctica/Palmer                      | -03    | -03:00:00  | f
 Antarctica/Troll                       | +00    | 00:00:00   | f
 Antarctica/Macquarie                   | AEDT   | 11:00:00   | t
 Antarctica/Casey                       | +11    | 11:00:00   | f
 NZ-CHAT                                | +1345  | 13:45:00   | t
 Universal                              | UTC    | 00:00:00   | f
 MST                                    | MST    | -07:00:00  | f
 Jamaica                                | EST    | -05:00:00  | f
 UCT                                    | UTC    | 00:00:00   | f
 Factory                                | -00    | 00:00:00   | f
 GB                                     | GMT    | 00:00:00   | f
 US/Aleutian                            | HST    | -10:00:00  | f
 US/Hawaii                              | HST    | -10:00:00  | f
 US/Arizona                             | MST    | -07:00:00  | f
 US/Indiana-Starke                      | CST    | -06:00:00  | f
 US/Pacific                             | PST    | -08:00:00  | f
 US/Samoa                               | SST    | -11:00:00  | f
 US/Michigan                            | EST    | -05:00:00  | f
 US/Eastern                             | EST    | -05:00:00  | f
 US/Central                             | CST    | -06:00:00  | f
 US/Alaska                              | AKST   | -09:00:00  | f
 US/Mountain                            | MST    | -07:00:00  | f
 US/East-Indiana                        | EST    | -05:00:00  | f
 Indian/Chagos                          | +06    | 06:00:00   | f
 Indian/Comoro                          | EAT    | 03:00:00   | f
 Indian/Maldives                        | +05    | 05:00:00   | f
 Indian/Antananarivo                    | EAT    | 03:00:00   | f
 Indian/Christmas                       | +07    | 07:00:00   | f
 Indian/Mauritius                       | +04    | 04:00:00   | f
 Indian/Mayotte                         | EAT    | 03:00:00   | f
 Indian/Cocos                           | +0630  | 06:30:00   | f
 Indian/Reunion                         | +04    | 04:00:00   | f
 Indian/Kerguelen                       | +05    | 05:00:00   | f
 Indian/Mahe                            | +04    | 04:00:00   | f
 Singapore                              | +08    | 08:00:00   | f
 GMT-0                                  | GMT    | 00:00:00   | f
 Zulu                                   | UTC    | 00:00:00   | f
 Australia/Lord_Howe                    | +11    | 11:00:00   | t
 Australia/Broken_Hill                  | ACDT   | 10:30:00   | t
 Australia/Adelaide                     | ACDT   | 10:30:00   | t
 Australia/Sydney                       | AEDT   | 11:00:00   | t
 Australia/Canberra                     | AEDT   | 11:00:00   | t
 Australia/NSW                          | AEDT   | 11:00:00   | t
 Australia/Yancowinna                   | ACDT   | 10:30:00   | t
 Australia/LHI                          | +11    | 11:00:00   | t
 Australia/West                         | AWST   | 08:00:00   | f
 Australia/South                        | ACDT   | 10:30:00   | t
 Australia/Melbourne                    | AEDT   | 11:00:00   | t
 Australia/Eucla                        | +0845  | 08:45:00   | f
 Australia/Tasmania                     | AEDT   | 11:00:00   | t
 Australia/Hobart                       | AEDT   | 11:00:00   | t
 Australia/Currie                       | AEDT   | 11:00:00   | t
 Australia/Perth                        | AWST   | 08:00:00   | f
 Australia/ACT                          | AEDT   | 11:00:00   | t
 Australia/Queensland                   | AEST   | 10:00:00   | f
 Australia/North                        | ACST   | 09:30:00   | f
 Australia/Lindeman                     | AEST   | 10:00:00   | f
 Australia/Darwin                       | ACST   | 09:30:00   | f
 Australia/Brisbane                     | AEST   | 10:00:00   | f
 Australia/Victoria                     | AEDT   | 11:00:00   | t
 UTC                                    | UTC    | 00:00:00   | f
 Libya                                  | EET    | 02:00:00   | f
 Arctic/Longyearbyen                    | CET    | 01:00:00   | f
 America/Ciudad_Juarez                  | MST    | -07:00:00  | f
 America/Ojinaga                        | CST    | -06:00:00  | f
 America/Godthab                        | -03    | -03:00:00  | f
 America/Fort_Nelson                    | MST    | -07:00:00  | f
 America/Paramaribo                     | -03    | -03:00:00  | f
 America/Sao_Paulo                      | -03    | -03:00:00  | f
 America/Campo_Grande                   | -04    | -04:00:00  | f
 America/Bahia                          | -03    | -03:00:00  | f
 America/Detroit                        | EST    | -05:00:00  | f
 America/Winnipeg                       | CST    | -06:00:00  | f
 America/Belem                          | -03    | -03:00:00  | f
 America/Boise                          | MST    | -07:00:00  | f
 America/Araguaina                      | -03    | -03:00:00  | f
 America/Belize                         | CST    | -06:00:00  | f
 America/Anguilla                       | AST    | -04:00:00  | f
 America/Marigot                        | AST    | -04:00:00  | f
 America/Yakutat                        | AKST   | -09:00:00  | f
 America/Danmarkshavn                   | GMT    | 00:00:00   | f
 America/Indianapolis                   | EST    | -05:00:00  | f
 America/Maceio                         | -03    | -03:00:00  | f
 America/Caracas                        | -04    | -04:00:00  | f
 America/Swift_Current                  | CST    | -06:00:00  | f
 America/Coral_Harbour                  | EST    | -05:00:00  | f
 America/El_Salvador                    | CST    | -06:00:00  | f
 America/Argentina/San_Luis             | -03    | -03:00:00  | f
 America/Argentina/La_Rioja             | -03    | -03:00:00  | f
 America/Argentina/Jujuy                | -03    | -03:00:00  | f
 America/Argentina/Mendoza              | -03    | -03:00:00  | f
 America/Argentina/Catamarca            | -03    | -03:00:00  | f
 America/Argentina/Buenos_Aires         | -03    | -03:00:00  | f
 America/Argentina/San_Juan             | -03    | -03:00:00  | f
 America/Argentina/Cordoba              | -03    | -03:00:00  | f
 America/Argentina/Rio_Gallegos         | -03    | -03:00:00  | f
 America/Argentina/ComodRivadavia       | -03    | -03:00:00  | f
 America/Argentina/Salta                | -03    | -03:00:00  | f
 America/Argentina/Ushuaia              | -03    | -03:00:00  | f
 America/Argentina/Tucuman              | -03    | -03:00:00  | f
 America/Santa_Isabel                   | PST    | -08:00:00  | f
 America/Fort_Wayne                     | EST    | -05:00:00  | f
 America/St_Kitts                       | AST    | -04:00:00  | f
 America/Juneau                         | AKST   | -09:00:00  | f
 America/Tegucigalpa                    | CST    | -06:00:00  | f
 America/Los_Angeles                    | PST    | -08:00:00  | f
 America/St_Lucia                       | AST    | -04:00:00  | f
 America/Atikokan                       | EST    | -05:00:00  | f
 America/La_Paz                         | -04    | -04:00:00  | f
 America/Guyana                         | -04    | -04:00:00  | f
 America/Cayenne                        | -03    | -03:00:00  | f
 America/Metlakatla                     | AKST   | -09:00:00  | f
 America/Monterrey                      | CST    | -06:00:00  | f
 America/Toronto                        | EST    | -05:00:00  | f
 America/Denver                         | MST    | -07:00:00  | f
 America/Kralendijk                     | AST    | -04:00:00  | f
 America/Montreal                       | EST    | -05:00:00  | f
 America/Grand_Turk                     | EST    | -05:00:00  | f
 America/Hermosillo                     | MST    | -07:00:00  | f
 America/Rankin_Inlet                   | CST    | -06:00:00  | f
 America/Miquelon                       | -03    | -03:00:00  | f
 America/Jujuy                          | -03    | -03:00:00  | f
 America/Mendoza                        | -03    | -03:00:00  | f
 America/Guayaquil                      | -05    | -05:00:00  | f
 America/Port-au-Prince                 | EST    | -05:00:00  | f
 America/Nassau                         | EST    | -05:00:00  | f
 America/Panama                         | EST    | -05:00:00  | f
 America/Regina                         | CST    | -06:00:00  | f
 America/Catamarca                      | -03    | -03:00:00  | f
 America/Asuncion                       | -03    | -03:00:00  | t
 America/Iqaluit                        | EST    | -05:00:00  | f
 America/Santo_Domingo                  | AST    | -04:00:00  | f
 America/Antigua                        | AST    | -04:00:00  | f
 America/Grenada                        | AST    | -04:00:00  | f
 America/Merida                         | CST    | -06:00:00  | f
 America/Buenos_Aires                   | -03    | -03:00:00  | f
 America/Nuuk                           | -03    | -03:00:00  | f
 America/Scoresbysund                   | -01    | -01:00:00  | f
 America/Chihuahua                      | CST    | -06:00:00  | f
 America/Dominica                       | AST    | -04:00:00  | f
 America/Ensenada                       | PST    | -08:00:00  | f
 America/Blanc-Sablon                   | AST    | -04:00:00  | f
 America/Adak                           | HST    | -10:00:00  | f
 America/Vancouver                      | PST    | -08:00:00  | f
 America/Yellowknife                    | MST    | -07:00:00  | f
 America/Edmonton                       | MST    | -07:00:00  | f
 America/Cancun                         | EST    | -05:00:00  | f
 America/Kentucky/Monticello            | EST    | -05:00:00  | f
 America/Kentucky/Louisville            | EST    | -05:00:00  | f
 America/Thunder_Bay                    | EST    | -05:00:00  | f
 America/Thule                          | AST    | -04:00:00  | f
 America/Noronha                        | -02    | -02:00:00  | f
 America/Recife                         | -03    | -03:00:00  | f
 America/Port_of_Spain                  | AST    | -04:00:00  | f
 America/Chicago                        | CST    | -06:00:00  | f
 America/Bogota                         | -05    | -05:00:00  | f
 America/Indiana/Indianapolis           | EST    | -05:00:00  | f
 America/Indiana/Winamac                | EST    | -05:00:00  | f
 America/Indiana/Marengo                | EST    | -05:00:00  | f
 America/Indiana/Knox                   | CST    | -06:00:00  | f
 America/Indiana/Vincennes              | EST    | -05:00:00  | f
 America/Indiana/Petersburg             | EST    | -05:00:00  | f
 America/Indiana/Tell_City              | CST    | -06:00:00  | f
 America/Indiana/Vevay                  | EST    | -05:00:00  | f
 America/St_Johns                       | NST    | -03:30:00  | f
 America/Tijuana                        | PST    | -08:00:00  | f
 America/Cordoba                        | -03    | -03:00:00  | f
 America/Knox_IN                        | CST    | -06:00:00  | f
 America/New_York                       | EST    | -05:00:00  | f
 America/Shiprock                       | MST    | -07:00:00  | f
 America/Cambridge_Bay                  | MST    | -07:00:00  | f
 America/Whitehorse                     | MST    | -07:00:00  | f
 America/Fortaleza                      | -03    | -03:00:00  | f
 America/St_Thomas                      | AST    | -04:00:00  | f
 America/Guatemala                      | CST    | -06:00:00  | f
 America/Rosario                        | -03    | -03:00:00  | f
 America/Manaus                         | -04    | -04:00:00  | f
 America/Matamoros                      | CST    | -06:00:00  | f
 America/Managua                        | CST    | -06:00:00  | f
 America/Guadeloupe                     | AST    | -04:00:00  | f
 America/Jamaica                        | EST    | -05:00:00  | f
 America/Barbados                       | AST    | -04:00:00  | f
 America/Dawson                         | MST    | -07:00:00  | f
 America/Mexico_City                    | CST    | -06:00:00  | f
 America/Tortola                        | AST    | -04:00:00  | f
 America/Nome                           | AKST   | -09:00:00  | f
 America/Glace_Bay                      | AST    | -04:00:00  | f
 America/Eirunepe                       | -05    | -05:00:00  | f
 America/Rio_Branco                     | -05    | -05:00:00  | f
 America/St_Barthelemy                  | AST    | -04:00:00  | f
 America/Creston                        | MST    | -07:00:00  | f
 America/Nipigon                        | EST    | -05:00:00  | f
 America/Phoenix                        | MST    | -07:00:00  | f
 America/Martinique                     | AST    | -04:00:00  | f
 America/Cuiaba                         | -04    | -04:00:00  | f
 America/Mazatlan                       | MST    | -07:00:00  | f
 America/Louisville                     | EST    | -05:00:00  | f
 America/Goose_Bay                      | AST    | -04:00:00  | f
 America/Menominee                      | CST    | -06:00:00  | f
 America/Pangnirtung                    | EST    | -05:00:00  | f
 America/Rainy_River                    | CST    | -06:00:00  | f
 America/Resolute                       | CST    | -06:00:00  | f
 America/Halifax                        | AST    | -04:00:00  | f
 America/Curacao                        | AST    | -04:00:00  | f
 America/Santarem                       | -03    | -03:00:00  | f
 America/Punta_Arenas                   | -03    | -03:00:00  | f
 America/Puerto_Rico                    | AST    | -04:00:00  | f
 America/Dawson_Creek                   | MST    | -07:00:00  | f
 America/Aruba                          | AST    | -04:00:00  | f
 America/Virgin                         | AST    | -04:00:00  | f
 America/Anchorage                      | AKST   | -09:00:00  | f
 America/Sitka                          | AKST   | -09:00:00  | f
 America/North_Dakota/Beulah            | CST    | -06:00:00  | f
 America/North_Dakota/New_Salem         | CST    | -06:00:00  | f
 America/North_Dakota/Center            | CST    | -06:00:00  | f
 America/Montserrat                     | AST    | -04:00:00  | f
 America/Boa_Vista                      | -04    | -04:00:00  | f
 America/Bahia_Banderas                 | CST    | -06:00:00  | f
 America/Montevideo                     | -03    | -03:00:00  | f
 America/Costa_Rica                     | CST    | -06:00:00  | f
 America/Cayman                         | EST    | -05:00:00  | f
 America/Porto_Velho                    | -04    | -04:00:00  | f
 America/Moncton                        | AST    | -04:00:00  | f
 America/Lower_Princes                  | AST    | -04:00:00  | f
 America/Havana                         | CST    | -05:00:00  | f
 America/Lima                           | -05    | -05:00:00  | f
 America/Atka                           | HST    | -10:00:00  | f
 America/Porto_Acre                     | -05    | -05:00:00  | f
 America/Inuvik                         | MST    | -07:00:00  | f
 America/Santiago                       | -03    | -03:00:00  | t
 America/St_Vincent                     | AST    | -04:00:00  | f
 Israel                                 | IST    | 02:00:00   | f
 MST7MDT                                | MST    | -07:00:00  | f
 Africa/Accra                           | GMT    | 00:00:00   | f
 Africa/Malabo                          | WAT    | 01:00:00   | f
 Africa/Kigali                          | CAT    | 02:00:00   | f
 Africa/El_Aaiun                        | +01    | 01:00:00   | f
 Africa/Juba                            | CAT    | 02:00:00   | f
 Africa/Abidjan                         | GMT    | 00:00:00   | f
 Africa/Bujumbura                       | CAT    | 02:00:00   | f
 Africa/Lome                            | GMT    | 00:00:00   | f
 Africa/Dakar                           | GMT    | 00:00:00   | f
 Africa/Dar_es_Salaam                   | EAT    | 03:00:00   | f
 Africa/Asmera                          | EAT    | 03:00:00   | f
 Africa/Mbabane                         | SAST   | 02:00:00   | f
 Africa/Harare                          | CAT    | 02:00:00   | f
 Africa/Freetown                        | GMT    | 00:00:00   | f
 Africa/Tripoli                         | EET    | 02:00:00   | f
 Africa/Conakry                         | GMT    | 00:00:00   | f
 Africa/Monrovia                        | GMT    | 00:00:00   | f
 Africa/Lagos                           | WAT    | 01:00:00   | f
 Africa/Khartoum                        | CAT    | 02:00:00   | f
 Africa/Casablanca                      | +01    | 01:00:00   | f
 Africa/Maseru                          | SAST   | 02:00:00   | f
 Africa/Blantyre                        | CAT    | 02:00:00   | f
 Africa/Cairo                           | EET    | 02:00:00   | f
 Africa/Algiers                         | CET    | 01:00:00   | f
 Africa/Kampala                         | EAT    | 03:00:00   | f
 Africa/Brazzaville                     | WAT    | 01:00:00   | f
 Africa/Douala                          | WAT    | 01:00:00   | f
 Africa/Niamey                          | WAT    | 01:00:00   | f
 Africa/Porto-Novo                      | WAT    | 01:00:00   | f
 Africa/Timbuktu                        | GMT    | 00:00:00   | f
 Africa/Libreville                      | WAT    | 01:00:00   | f
 Africa/Ceuta                           | CET    | 01:00:00   | f
 Africa/Banjul                          | GMT    | 00:00:00   | f
 Africa/Bissau                          | GMT    | 00:00:00   | f
 Africa/Windhoek                        | CAT    | 02:00:00   | f
 Africa/Nouakchott                      | GMT    | 00:00:00   | f
 Africa/Maputo                          | CAT    | 02:00:00   | f
 Africa/Lubumbashi                      | CAT    | 02:00:00   | f
 Africa/Ndjamena                        | WAT    | 01:00:00   | f
 Africa/Nairobi                         | EAT    | 03:00:00   | f
 Africa/Kinshasa                        | WAT    | 01:00:00   | f
 Africa/Bamako                          | GMT    | 00:00:00   | f
 Africa/Asmara                          | EAT    | 03:00:00   | f
 Africa/Lusaka                          | CAT    | 02:00:00   | f
 Africa/Sao_Tome                        | GMT    | 00:00:00   | f
 Africa/Gaborone                        | CAT    | 02:00:00   | f
 Africa/Djibouti                        | EAT    | 03:00:00   | f
 Africa/Luanda                          | WAT    | 01:00:00   | f
 Africa/Tunis                           | CET    | 01:00:00   | f
 Africa/Addis_Ababa                     | EAT    | 03:00:00   | f
 Africa/Ouagadougou                     | GMT    | 00:00:00   | f
 Africa/Johannesburg                    | SAST   | 02:00:00   | f
 Africa/Bangui                          | WAT    | 01:00:00   | f
 Africa/Mogadishu                       | EAT    | 03:00:00   | f
 Asia/Katmandu                          | +0545  | 05:45:00   | f
 Asia/Aden                              | +03    | 03:00:00   | f
 Asia/Srednekolymsk                     | +11    | 11:00:00   | f
 Asia/Tbilisi                           | +04    | 04:00:00   | f
 Asia/Macao                             | CST    | 08:00:00   | f
 Asia/Phnom_Penh                        | +07    | 07:00:00   | f
 Asia/Ujung_Pandang                     | WITA   | 08:00:00   | f
 Asia/Kuala_Lumpur                      | +08    | 08:00:00   | f
 Asia/Krasnoyarsk                       | +07    | 07:00:00   | f
 Asia/Hovd                              | +07    | 07:00:00   | f
 Asia/Baghdad                           | +03    | 03:00:00   | f
 Asia/Vladivostok                       | +10    | 10:00:00   | f
 Asia/Kuwait                            | +03    | 03:00:00   | f
 Asia/Dili                              | +09    | 09:00:00   | f
 Asia/Tomsk                             | +07    | 07:00:00   | f
 Asia/Dhaka                             | +06    | 06:00:00   | f
 Asia/Qyzylorda                         | +05    | 05:00:00   | f
 Asia/Yerevan                           | +04    | 04:00:00   | f
 Asia/Kabul                             | +0430  | 04:30:00   | f
 Asia/Gaza                              | EET    | 02:00:00   | f
 Asia/Kuching                           | +08    | 08:00:00   | f
 Asia/Yangon                            | +0630  | 06:30:00   | f
 Asia/Amman                             | +03    | 03:00:00   | f
 Asia/Taipei                            | CST    | 08:00:00   | f
 Asia/Kathmandu                         | +0545  | 05:45:00   | f
 Asia/Ulaanbaatar                       | +08    | 08:00:00   | f
 Asia/Almaty                            | +06    | 06:00:00   | f
 Asia/Yekaterinburg                     | +05    | 05:00:00   | f
 Asia/Qatar                             | +03    | 03:00:00   | f
 Asia/Barnaul                           | +07    | 07:00:00   | f
 Asia/Anadyr                            | +12    | 12:00:00   | f
 Asia/Makassar                          | WITA   | 08:00:00   | f
 Asia/Istanbul                          | +03    | 03:00:00   | f
 Asia/Rangoon                           | +0630  | 06:30:00   | f
 Asia/Jerusalem                         | IST    | 02:00:00   | f
 Asia/Nicosia                           | EET    | 02:00:00   | f
 Asia/Choibalsan                        | +08    | 08:00:00   | f
 Asia/Famagusta                         | EET    | 02:00:00   | f
 Asia/Atyrau                            | +05    | 05:00:00   | f
 Asia/Karachi                           | PKT    | 05:00:00   | f
 Asia/Riyadh                            | +03    | 03:00:00   | f
 Asia/Muscat                            | +04    | 04:00:00   | f
 Asia/Tashkent                          | +05    | 05:00:00   | f
 Asia/Chungking                         | CST    | 08:00:00   | f
 Asia/Ust-Nera                          | +10    | 10:00:00   | f
 Asia/Hong_Kong                         | HKT    | 08:00:00   | f
 Asia/Bishkek                           | +06    | 06:00:00   | f
 Asia/Samarkand                         | +05    | 05:00:00   | f
 Asia/Dushanbe                          | +05    | 05:00:00   | f
 Asia/Ashgabat                          | +05    | 05:00:00   | f
 Asia/Chongqing                         | CST    | 08:00:00   | f
 Asia/Dubai                             | +04    | 04:00:00   | f
 Asia/Shanghai                          | CST    | 08:00:00   | f
 Asia/Novosibirsk                       | +07    | 07:00:00   | f
 Asia/Chita                             | +09    | 09:00:00   | f
 Asia/Colombo                           | +0530  | 05:30:00   | f
 Asia/Irkutsk                           | +08    | 08:00:00   | f
 Asia/Beirut                            | EET    | 02:00:00   | f
 Asia/Kolkata                           | IST    | 05:30:00   | f
 Asia/Khandyga                          | +09    | 09:00:00   | f
 Asia/Manila                            | PST    | 08:00:00   | f
 Asia/Novokuznetsk                      | +07    | 07:00:00   | f
 Asia/Damascus                          | +03    | 03:00:00   | f
 Asia/Singapore                         | +08    | 08:00:00   | f
 Asia/Sakhalin                          | +11    | 11:00:00   | f
 Asia/Hebron                            | EET    | 02:00:00   | f
 Asia/Dacca                             | +06    | 06:00:00   | f
 Asia/Tel_Aviv                          | IST    | 02:00:00   | f
 Asia/Kashgar                           | +06    | 06:00:00   | f
 Asia/Qostanay                          | +06    | 06:00:00   | f
 Asia/Baku                              | +04    | 04:00:00   | f
 Asia/Kamchatka                         | +12    | 12:00:00   | f
 Asia/Aqtau                             | +05    | 05:00:00   | f
 Asia/Yakutsk                           | +09    | 09:00:00   | f
 Asia/Thimphu                           | +06    | 06:00:00   | f
 Asia/Tokyo                             | JST    | 09:00:00   | f
 Asia/Thimbu                            | +06    | 06:00:00   | f
 Asia/Omsk                              | +06    | 06:00:00   | f
 Asia/Bahrain                           | +03    | 03:00:00   | f
 Asia/Jakarta                           | WIB    | 07:00:00   | f
 Asia/Brunei                            | +08    | 08:00:00   | f
 Asia/Bangkok                           | +07    | 07:00:00   | f
 Asia/Calcutta                          | IST    | 05:30:00   | f
 Asia/Urumqi                            | +06    | 06:00:00   | f
 Asia/Pyongyang                         | KST    | 09:00:00   | f
 Asia/Ho_Chi_Minh                       | +07    | 07:00:00   | f
 Asia/Magadan                           | +11    | 11:00:00   | f
 Asia/Jayapura                          | WIT    | 09:00:00   | f
 Asia/Macau                             | CST    | 08:00:00   | f
 Asia/Pontianak                         | WIB    | 07:00:00   | f
 Asia/Ashkhabad                         | +05    | 05:00:00   | f
 Asia/Aqtobe                            | +05    | 05:00:00   | f
 Asia/Oral                              | +05    | 05:00:00   | f
 Asia/Harbin                            | CST    | 08:00:00   | f
 Asia/Ulan_Bator                        | +08    | 08:00:00   | f
 Asia/Seoul                             | KST    | 09:00:00   | f
 Asia/Vientiane                         | +07    | 07:00:00   | f
 Asia/Saigon                            | +07    | 07:00:00   | f
 Asia/Tehran                            | +0330  | 03:30:00   | f
 posixrules                             | EST    | -05:00:00  | f
 Hongkong                               | HKT    | 08:00:00   | f
 WET                                    | WET    | 00:00:00   | f
 posix/NZ                               | NZDT   | 13:00:00   | t
 posix/GB-Eire                          | GMT    | 00:00:00   | f
 posix/Canada/Yukon                     | MST    | -07:00:00  | f
 posix/Canada/Atlantic                  | AST    | -04:00:00  | f
 posix/Canada/Pacific                   | PST    | -08:00:00  | f
 posix/Canada/Eastern                   | EST    | -05:00:00  | f
 posix/Canada/Central                   | CST    | -06:00:00  | f
 posix/Canada/Saskatchewan              | CST    | -06:00:00  | f
 posix/Canada/Newfoundland              | NST    | -03:30:00  | f
 posix/Canada/Mountain                  | MST    | -07:00:00  | f
 posix/Japan                            | JST    | 09:00:00   | f
 posix/Kwajalein                        | +12    | 12:00:00   | f
 posix/Egypt                            | EET    | 02:00:00   | f
 posix/Poland                           | CET    | 01:00:00   | f
 posix/Turkey                           | +03    | 03:00:00   | f
 posix/CET                              | CET    | 01:00:00   | f
 posix/Brazil/DeNoronha                 | -02    | -02:00:00  | f
 posix/Brazil/East                      | -03    | -03:00:00  | f
 posix/Brazil/West                      | -04    | -04:00:00  | f
 posix/Brazil/Acre                      | -05    | -05:00:00  | f
 posix/Chile/Continental                | -03    | -03:00:00  | t
 posix/Chile/EasterIsland               | -05    | -05:00:00  | t
 posix/EST5EDT                          | EST    | -05:00:00  | f
 posix/Atlantic/Jan_Mayen               | CET    | 01:00:00   | f
 posix/Atlantic/Cape_Verde              | -01    | -01:00:00  | f
 posix/Atlantic/South_Georgia           | -02    | -02:00:00  | f
 posix/Atlantic/Faroe                   | WET    | 00:00:00   | f
 posix/Atlantic/St_Helena               | GMT    | 00:00:00   | f
 posix/Atlantic/Azores                  | -01    | -01:00:00  | f
 posix/Atlantic/Madeira                 | WET    | 00:00:00   | f
 posix/Atlantic/Stanley                 | -03    | -03:00:00  | f
 posix/Atlantic/Bermuda                 | AST    | -04:00:00  | f
 posix/Atlantic/Canary                  | WET    | 00:00:00   | f
 posix/Atlantic/Reykjavik               | GMT    | 00:00:00   | f
 posix/Atlantic/Faeroe                  | WET    | 00:00:00   | f
 posix/Iceland                          | GMT    | 00:00:00   | f
 posix/GMT0                             | GMT    | 00:00:00   | f
 posix/EST                              | EST    | -05:00:00  | f
 posix/PRC                              | CST    | 08:00:00   | f
 posix/Cuba                             | CST    | -05:00:00  | f
 posix/Eire                             | GMT    | 00:00:00   | t
 posix/HST                              | HST    | -10:00:00  | f
 posix/GMT                              | GMT    | 00:00:00   | f
 posix/Greenwich                        | GMT    | 00:00:00   | f
 posix/CST6CDT                          | CST    | -06:00:00  | f
 posix/W-SU                             | MSK    | 03:00:00   | f
 posix/GMT+0                            | GMT    | 00:00:00   | f
 posix/EET                              | EET    | 02:00:00   | f
 posix/Etc/GMT-2                        | +02    | 02:00:00   | f
 posix/Etc/GMT-13                       | +13    | 13:00:00   | f
 posix/Etc/GMT+2                        | -02    | -02:00:00  | f
 posix/Etc/GMT+7                        | -07    | -07:00:00  | f
 posix/Etc/GMT-12                       | +12    | 12:00:00   | f
 posix/Etc/GMT-5                        | +05    | 05:00:00   | f
 posix/Etc/GMT-11                       | +11    | 11:00:00   | f
 posix/Etc/GMT0                         | GMT    | 00:00:00   | f
 posix/Etc/GMT+6                        | -06    | -06:00:00  | f
 posix/Etc/GMT                          | GMT    | 00:00:00   | f
 posix/Etc/Greenwich                    | GMT    | 00:00:00   | f
 posix/Etc/GMT+0                        | GMT    | 00:00:00   | f
 posix/Etc/GMT+4                        | -04    | -04:00:00  | f
 posix/Etc/GMT-6                        | +06    | 06:00:00   | f
 posix/Etc/GMT+11                       | -11    | -11:00:00  | f
 posix/Etc/GMT+8                        | -08    | -08:00:00  | f
 posix/Etc/GMT-8                        | +08    | 08:00:00   | f
 posix/Etc/GMT+3                        | -03    | -03:00:00  | f
 posix/Etc/GMT+5                        | -05    | -05:00:00  | f
 posix/Etc/Universal                    | UTC    | 00:00:00   | f
 posix/Etc/GMT+1                        | -01    | -01:00:00  | f
 posix/Etc/UCT                          | UTC    | 00:00:00   | f
 posix/Etc/GMT+12                       | -12    | -12:00:00  | f
 posix/Etc/GMT-10                       | +10    | 10:00:00   | f
 posix/Etc/GMT-7                        | +07    | 07:00:00   | f
 posix/Etc/GMT-0                        | GMT    | 00:00:00   | f
 posix/Etc/Zulu                         | UTC    | 00:00:00   | f
 posix/Etc/GMT-14                       | +14    | 14:00:00   | f
 posix/Etc/UTC                          | UTC    | 00:00:00   | f
 posix/Etc/GMT-1                        | +01    | 01:00:00   | f
 posix/Etc/GMT+9                        | -09    | -09:00:00  | f
 posix/Etc/GMT-3                        | +03    | 03:00:00   | f
 posix/Etc/GMT-4                        | +04    | 04:00:00   | f
 posix/Etc/GMT+10                       | -10    | -10:00:00  | f
 posix/Etc/GMT-9                        | +09    | 09:00:00   | f
 posix/Pacific/Wake                     | +12    | 12:00:00   | f
 posix/Pacific/Saipan                   | ChST   | 10:00:00   | f
 posix/Pacific/Kwajalein                | +12    | 12:00:00   | f
 posix/Pacific/Chuuk                    | +10    | 10:00:00   | f
 posix/Pacific/Chatham                  | +1345  | 13:45:00   | t
 posix/Pacific/Pitcairn                 | -08    | -08:00:00  | f
 posix/Pacific/Honolulu                 | HST    | -10:00:00  | f
 posix/Pacific/Johnston                 | HST    | -10:00:00  | f
 posix/Pacific/Niue                     | -11    | -11:00:00  | f
 posix/Pacific/Yap                      | +10    | 10:00:00   | f
 posix/Pacific/Guadalcanal              | +11    | 11:00:00   | f
 posix/Pacific/Tarawa                   | +12    | 12:00:00   | f
 posix/Pacific/Palau                    | +09    | 09:00:00   | f
 posix/Pacific/Samoa                    | SST    | -11:00:00  | f
 posix/Pacific/Majuro                   | +12    | 12:00:00   | f
 posix/Pacific/Port_Moresby             | +10    | 10:00:00   | f
 posix/Pacific/Apia                     | +13    | 13:00:00   | f
 posix/Pacific/Truk                     | +10    | 10:00:00   | f
 posix/Pacific/Marquesas                | -0930  | -09:30:00  | f
 posix/Pacific/Efate                    | +11    | 11:00:00   | f
 posix/Pacific/Pago_Pago                | SST    | -11:00:00  | f
 posix/Pacific/Kosrae                   | +11    | 11:00:00   | f
 posix/Pacific/Nauru                    | +12    | 12:00:00   | f
 posix/Pacific/Enderbury                | +13    | 13:00:00   | f
 posix/Pacific/Bougainville             | +11    | 11:00:00   | f
 posix/Pacific/Wallis                   | +12    | 12:00:00   | f
 posix/Pacific/Fakaofo                  | +13    | 13:00:00   | f
 posix/Pacific/Kanton                   | +13    | 13:00:00   | f
 posix/Pacific/Midway                   | SST    | -11:00:00  | f
 posix/Pacific/Tongatapu                | +13    | 13:00:00   | f
 posix/Pacific/Noumea                   | +11    | 11:00:00   | f
 posix/Pacific/Tahiti                   | -10    | -10:00:00  | f
 posix/Pacific/Gambier                  | -09    | -09:00:00  | f
 posix/Pacific/Rarotonga                | -10    | -10:00:00  | f
 posix/Pacific/Pohnpei                  | +11    | 11:00:00   | f
 posix/Pacific/Fiji                     | +12    | 12:00:00   | f
 posix/Pacific/Auckland                 | NZDT   | 13:00:00   | t
 posix/Pacific/Kiritimati               | +14    | 14:00:00   | f
 posix/Pacific/Guam                     | ChST   | 10:00:00   | f
 posix/Pacific/Norfolk                  | +12    | 12:00:00   | t
 posix/Pacific/Galapagos                | -06    | -06:00:00  | f
 posix/Pacific/Easter                   | -05    | -05:00:00  | t
 posix/Pacific/Funafuti                 | +12    | 12:00:00   | f
 posix/Pacific/Ponape                   | +11    | 11:00:00   | f
 posix/ROC                              | CST    | 08:00:00   | f
 posix/Europe/Vaduz                     | CET    | 01:00:00   | f
 posix/Europe/Belfast                   | GMT    | 00:00:00   | f
 posix/Europe/Volgograd                 | +03    | 03:00:00   | f
 posix/Europe/Copenhagen                | CET    | 01:00:00   | f
 posix/Europe/Minsk                     | +03    | 03:00:00   | f
 posix/Europe/Sofia                     | EET    | 02:00:00   | f
 posix/Europe/Warsaw                    | CET    | 01:00:00   | f
 posix/Europe/San_Marino                | CET    | 01:00:00   | f
 posix/Europe/Riga                      | EET    | 02:00:00   | f
 posix/Europe/Kiev                      | EET    | 02:00:00   | f
 posix/Europe/Isle_of_Man               | GMT    | 00:00:00   | f
 posix/Europe/Chisinau                  | EET    | 02:00:00   | f
 posix/Europe/Prague                    | CET    | 01:00:00   | f
 posix/Europe/Brussels                  | CET    | 01:00:00   | f
 posix/Europe/Tiraspol                  | EET    | 02:00:00   | f
 posix/Europe/Podgorica                 | CET    | 01:00:00   | f
 posix/Europe/Guernsey                  | GMT    | 00:00:00   | f
 posix/Europe/Vienna                    | CET    | 01:00:00   | f
 posix/Europe/Sarajevo                  | CET    | 01:00:00   | f
 posix/Europe/Kaliningrad               | EET    | 02:00:00   | f
 posix/Europe/Busingen                  | CET    | 01:00:00   | f
 posix/Europe/Zaporozhye                | EET    | 02:00:00   | f
 posix/Europe/Ljubljana                 | CET    | 01:00:00   | f
 posix/Europe/Bucharest                 | EET    | 02:00:00   | f
 posix/Europe/Berlin                    | CET    | 01:00:00   | f
 posix/Europe/Tallinn                   | EET    | 02:00:00   | f
 posix/Europe/London                    | GMT    | 00:00:00   | f
 posix/Europe/Paris                     | CET    | 01:00:00   | f
 posix/Europe/Amsterdam                 | CET    | 01:00:00   | f
 posix/Europe/Istanbul                  | +03    | 03:00:00   | f
 posix/Europe/Vilnius                   | EET    | 02:00:00   | f
 posix/Europe/Nicosia                   | EET    | 02:00:00   | f
 posix/Europe/Astrakhan                 | +04    | 04:00:00   | f
 posix/Europe/Saratov                   | +04    | 04:00:00   | f
 posix/Europe/Jersey                    | GMT    | 00:00:00   | f
 posix/Europe/Moscow                    | MSK    | 03:00:00   | f
 posix/Europe/Helsinki                  | EET    | 02:00:00   | f
 posix/Europe/Belgrade                  | CET    | 01:00:00   | f
 posix/Europe/Kirov                     | +03    | 03:00:00   | f
 posix/Europe/Kyiv                      | EET    | 02:00:00   | f
 posix/Europe/Gibraltar                 | CET    | 01:00:00   | f
 posix/Europe/Samara                    | +04    | 04:00:00   | f
 posix/Europe/Ulyanovsk                 | +04    | 04:00:00   | f
 posix/Europe/Andorra                   | CET    | 01:00:00   | f
 posix/Europe/Oslo                      | CET    | 01:00:00   | f
 posix/Europe/Uzhgorod                  | EET    | 02:00:00   | f
 posix/Europe/Budapest                  | CET    | 01:00:00   | f
 posix/Europe/Skopje                    | CET    | 01:00:00   | f
 posix/Europe/Mariehamn                 | EET    | 02:00:00   | f
 posix/Europe/Stockholm                 | CET    | 01:00:00   | f
 posix/Europe/Zurich                    | CET    | 01:00:00   | f
 posix/Europe/Zagreb                    | CET    | 01:00:00   | f
 posix/Europe/Monaco                    | CET    | 01:00:00   | f
 posix/Europe/Simferopol                | MSK    | 03:00:00   | f
 posix/Europe/Vatican                   | CET    | 01:00:00   | f
 posix/Europe/Tirane                    | CET    | 01:00:00   | f
 posix/Europe/Madrid                    | CET    | 01:00:00   | f
 posix/Europe/Athens                    | EET    | 02:00:00   | f
 posix/Europe/Dublin                    | GMT    | 00:00:00   | t
 posix/Europe/Malta                     | CET    | 01:00:00   | f
 posix/Europe/Rome                      | CET    | 01:00:00   | f
 posix/Europe/Luxembourg                | CET    | 01:00:00   | f
 posix/Europe/Lisbon                    | WET    | 00:00:00   | f
 posix/Europe/Bratislava                | CET    | 01:00:00   | f
 posix/Navajo                           | MST    | -07:00:00  | f
 posix/PST8PDT                          | PST    | -08:00:00  | f
 posix/ROK                              | KST    | 09:00:00   | f
 posix/Portugal                         | WET    | 00:00:00   | f
 posix/MET                              | MET    | 01:00:00   | f
 posix/Antarctica/McMurdo               | NZDT   | 13:00:00   | t
 posix/Antarctica/Vostok                | +06    | 06:00:00   | f
 posix/Antarctica/South_Pole            | NZDT   | 13:00:00   | t
 posix/Antarctica/Syowa                 | +03    | 03:00:00   | f
 posix/Antarctica/Mawson                | +05    | 05:00:00   | f
 posix/Antarctica/DumontDUrville        | +10    | 10:00:00   | f
 posix/Antarctica/Rothera               | -03    | -03:00:00  | f
 posix/Antarctica/Davis                 | +07    | 07:00:00   | f
 posix/Antarctica/Palmer                | -03    | -03:00:00  | f
 posix/Antarctica/Troll                 | +00    | 00:00:00   | f
 posix/Antarctica/Macquarie             | AEDT   | 11:00:00   | t
 posix/Antarctica/Casey                 | +11    | 11:00:00   | f
 posix/NZ-CHAT                          | +1345  | 13:45:00   | t
 posix/Universal                        | UTC    | 00:00:00   | f
 posix/MST                              | MST    | -07:00:00  | f
 posix/Jamaica                          | EST    | -05:00:00  | f
 posix/UCT                              | UTC    | 00:00:00   | f
 posix/Factory                          | -00    | 00:00:00   | f
 posix/GB                               | GMT    | 00:00:00   | f
 posix/US/Aleutian                      | HST    | -10:00:00  | f
 posix/US/Hawaii                        | HST    | -10:00:00  | f
 posix/US/Arizona                       | MST    | -07:00:00  | f
 posix/US/Indiana-Starke                | CST    | -06:00:00  | f
 posix/US/Pacific                       | PST    | -08:00:00  | f
 posix/US/Samoa                         | SST    | -11:00:00  | f
 posix/US/Michigan                      | EST    | -05:00:00  | f
 posix/US/Eastern                       | EST    | -05:00:00  | f
 posix/US/Central                       | CST    | -06:00:00  | f
 posix/US/Alaska                        | AKST   | -09:00:00  | f
 posix/US/Mountain                      | MST    | -07:00:00  | f
 posix/US/East-Indiana                  | EST    | -05:00:00  | f
 posix/Indian/Chagos                    | +06    | 06:00:00   | f
 posix/Indian/Comoro                    | EAT    | 03:00:00   | f
 posix/Indian/Maldives                  | +05    | 05:00:00   | f
 posix/Indian/Antananarivo              | EAT    | 03:00:00   | f
 posix/Indian/Christmas                 | +07    | 07:00:00   | f
 posix/Indian/Mauritius                 | +04    | 04:00:00   | f
 posix/Indian/Mayotte                   | EAT    | 03:00:00   | f
 posix/Indian/Cocos                     | +0630  | 06:30:00   | f
 posix/Indian/Reunion                   | +04    | 04:00:00   | f
 posix/Indian/Kerguelen                 | +05    | 05:00:00   | f
 posix/Indian/Mahe                      | +04    | 04:00:00   | f
 posix/Singapore                        | +08    | 08:00:00   | f
 posix/GMT-0                            | GMT    | 00:00:00   | f
 posix/Zulu                             | UTC    | 00:00:00   | f
 posix/Australia/Lord_Howe              | +11    | 11:00:00   | t
 posix/Australia/Broken_Hill            | ACDT   | 10:30:00   | t
 posix/Australia/Adelaide               | ACDT   | 10:30:00   | t
 posix/Australia/Sydney                 | AEDT   | 11:00:00   | t
 posix/Australia/Canberra               | AEDT   | 11:00:00   | t
 posix/Australia/NSW                    | AEDT   | 11:00:00   | t
 posix/Australia/Yancowinna             | ACDT   | 10:30:00   | t
 posix/Australia/LHI                    | +11    | 11:00:00   | t
 posix/Australia/West                   | AWST   | 08:00:00   | f
 posix/Australia/South                  | ACDT   | 10:30:00   | t
 posix/Australia/Melbourne              | AEDT   | 11:00:00   | t
 posix/Australia/Eucla                  | +0845  | 08:45:00   | f
 posix/Australia/Tasmania               | AEDT   | 11:00:00   | t
 posix/Australia/Hobart                 | AEDT   | 11:00:00   | t
 posix/Australia/Currie                 | AEDT   | 11:00:00   | t
 posix/Australia/Perth                  | AWST   | 08:00:00   | f
 posix/Australia/ACT                    | AEDT   | 11:00:00   | t
 posix/Australia/Queensland             | AEST   | 10:00:00   | f
 posix/Australia/North                  | ACST   | 09:30:00   | f
 posix/Australia/Lindeman               | AEST   | 10:00:00   | f
 posix/Australia/Darwin                 | ACST   | 09:30:00   | f
 posix/Australia/Brisbane               | AEST   | 10:00:00   | f
 posix/Australia/Victoria               | AEDT   | 11:00:00   | t
 posix/UTC                              | UTC    | 00:00:00   | f
 posix/Libya                            | EET    | 02:00:00   | f
 posix/Arctic/Longyearbyen              | CET    | 01:00:00   | f
 posix/America/Ciudad_Juarez            | MST    | -07:00:00  | f
 posix/America/Ojinaga                  | CST    | -06:00:00  | f
 posix/America/Godthab                  | -03    | -03:00:00  | f
 posix/America/Fort_Nelson              | MST    | -07:00:00  | f
 posix/America/Paramaribo               | -03    | -03:00:00  | f
 posix/America/Sao_Paulo                | -03    | -03:00:00  | f
 posix/America/Campo_Grande             | -04    | -04:00:00  | f
 posix/America/Bahia                    | -03    | -03:00:00  | f
 posix/America/Detroit                  | EST    | -05:00:00  | f
 posix/America/Winnipeg                 | CST    | -06:00:00  | f
 posix/America/Belem                    | -03    | -03:00:00  | f
 posix/America/Boise                    | MST    | -07:00:00  | f
 posix/America/Araguaina                | -03    | -03:00:00  | f
 posix/America/Belize                   | CST    | -06:00:00  | f
 posix/America/Anguilla                 | AST    | -04:00:00  | f
 posix/America/Marigot                  | AST    | -04:00:00  | f
 posix/America/Yakutat                  | AKST   | -09:00:00  | f
 posix/America/Danmarkshavn             | GMT    | 00:00:00   | f
 posix/America/Indianapolis             | EST    | -05:00:00  | f
 posix/America/Maceio                   | -03    | -03:00:00  | f
 posix/America/Caracas                  | -04    | -04:00:00  | f
 posix/America/Swift_Current            | CST    | -06:00:00  | f
 posix/America/Coral_Harbour            | EST    | -05:00:00  | f
 posix/America/El_Salvador              | CST    | -06:00:00  | f
 posix/America/Argentina/San_Luis       | -03    | -03:00:00  | f
 posix/America/Argentina/La_Rioja       | -03    | -03:00:00  | f
 posix/America/Argentina/Jujuy          | -03    | -03:00:00  | f
 posix/America/Argentina/Mendoza        | -03    | -03:00:00  | f
 posix/America/Argentina/Catamarca      | -03    | -03:00:00  | f
 posix/America/Argentina/Buenos_Aires   | -03    | -03:00:00  | f
 posix/America/Argentina/San_Juan       | -03    | -03:00:00  | f
 posix/America/Argentina/Cordoba        | -03    | -03:00:00  | f
 posix/America/Argentina/Rio_Gallegos   | -03    | -03:00:00  | f
 posix/America/Argentina/ComodRivadavia | -03    | -03:00:00  | f
 posix/America/Argentina/Salta          | -03    | -03:00:00  | f
 posix/America/Argentina/Ushuaia        | -03    | -03:00:00  | f
 posix/America/Argentina/Tucuman        | -03    | -03:00:00  | f
 posix/America/Santa_Isabel             | PST    | -08:00:00  | f
 posix/America/Fort_Wayne               | EST    | -05:00:00  | f
 posix/America/St_Kitts                 | AST    | -04:00:00  | f
 posix/America/Juneau                   | AKST   | -09:00:00  | f
 posix/America/Tegucigalpa              | CST    | -06:00:00  | f
 posix/America/Los_Angeles              | PST    | -08:00:00  | f
 posix/America/St_Lucia                 | AST    | -04:00:00  | f
 posix/America/Atikokan                 | EST    | -05:00:00  | f
 posix/America/La_Paz                   | -04    | -04:00:00  | f
 posix/America/Guyana                   | -04    | -04:00:00  | f
 posix/America/Cayenne                  | -03    | -03:00:00  | f
 posix/America/Metlakatla               | AKST   | -09:00:00  | f
 posix/America/Monterrey                | CST    | -06:00:00  | f
 posix/America/Toronto                  | EST    | -05:00:00  | f
 posix/America/Denver                   | MST    | -07:00:00  | f
 posix/America/Kralendijk               | AST    | -04:00:00  | f
 posix/America/Montreal                 | EST    | -05:00:00  | f
 posix/America/Grand_Turk               | EST    | -05:00:00  | f
 posix/America/Hermosillo               | MST    | -07:00:00  | f
 posix/America/Rankin_Inlet             | CST    | -06:00:00  | f
 posix/America/Miquelon                 | -03    | -03:00:00  | f
 posix/America/Jujuy                    | -03    | -03:00:00  | f
 posix/America/Mendoza                  | -03    | -03:00:00  | f
 posix/America/Guayaquil                | -05    | -05:00:00  | f
 posix/America/Port-au-Prince           | EST    | -05:00:00  | f
 posix/America/Nassau                   | EST    | -05:00:00  | f
 posix/America/Panama                   | EST    | -05:00:00  | f
 posix/America/Regina                   | CST    | -06:00:00  | f
 posix/America/Catamarca                | -03    | -03:00:00  | f
 posix/America/Asuncion                 | -03    | -03:00:00  | t
 posix/America/Iqaluit                  | EST    | -05:00:00  | f
 posix/America/Santo_Domingo            | AST    | -04:00:00  | f
 posix/America/Antigua                  | AST    | -04:00:00  | f
 posix/America/Grenada                  | AST    | -04:00:00  | f
 posix/America/Merida                   | CST    | -06:00:00  | f
 posix/America/Buenos_Aires             | -03    | -03:00:00  | f
 posix/America/Nuuk                     | -03    | -03:00:00  | f
 posix/America/Scoresbysund             | -01    | -01:00:00  | f
 posix/America/Chihuahua                | CST    | -06:00:00  | f
 posix/America/Dominica                 | AST    | -04:00:00  | f
 posix/America/Ensenada                 | PST    | -08:00:00  | f
 posix/America/Blanc-Sablon             | AST    | -04:00:00  | f
 posix/America/Adak                     | HST    | -10:00:00  | f
 posix/America/Vancouver                | PST    | -08:00:00  | f
 posix/America/Yellowknife              | MST    | -07:00:00  | f
 posix/America/Edmonton                 | MST    | -07:00:00  | f
 posix/America/Cancun                   | EST    | -05:00:00  | f
 posix/America/Kentucky/Monticello      | EST    | -05:00:00  | f
 posix/America/Kentucky/Louisville      | EST    | -05:00:00  | f
 posix/America/Thunder_Bay              | EST    | -05:00:00  | f
 posix/America/Thule                    | AST    | -04:00:00  | f
 posix/America/Noronha                  | -02    | -02:00:00  | f
 posix/America/Recife                   | -03    | -03:00:00  | f
 posix/America/Port_of_Spain            | AST    | -04:00:00  | f
 posix/America/Chicago                  | CST    | -06:00:00  | f
 posix/America/Bogota                   | -05    | -05:00:00  | f
 posix/America/Indiana/Indianapolis     | EST    | -05:00:00  | f
 posix/America/Indiana/Winamac          | EST    | -05:00:00  | f
 posix/America/Indiana/Marengo          | EST    | -05:00:00  | f
 posix/America/Indiana/Knox             | CST    | -06:00:00  | f
 posix/America/Indiana/Vincennes        | EST    | -05:00:00  | f
 posix/America/Indiana/Petersburg       | EST    | -05:00:00  | f
 posix/America/Indiana/Tell_City        | CST    | -06:00:00  | f
 posix/America/Indiana/Vevay            | EST    | -05:00:00  | f
 posix/America/St_Johns                 | NST    | -03:30:00  | f
 posix/America/Tijuana                  | PST    | -08:00:00  | f
 posix/America/Cordoba                  | -03    | -03:00:00  | f
 posix/America/Knox_IN                  | CST    | -06:00:00  | f
 posix/America/New_York                 | EST    | -05:00:00  | f
 posix/America/Shiprock                 | MST    | -07:00:00  | f
 posix/America/Cambridge_Bay            | MST    | -07:00:00  | f
 posix/America/Whitehorse               | MST    | -07:00:00  | f
 posix/America/Fortaleza                | -03    | -03:00:00  | f
 posix/America/St_Thomas                | AST    | -04:00:00  | f
 posix/America/Guatemala                | CST    | -06:00:00  | f
 posix/America/Rosario                  | -03    | -03:00:00  | f
 posix/America/Manaus                   | -04    | -04:00:00  | f
 posix/America/Matamoros                | CST    | -06:00:00  | f
 posix/America/Managua                  | CST    | -06:00:00  | f
 posix/America/Guadeloupe               | AST    | -04:00:00  | f
 posix/America/Jamaica                  | EST    | -05:00:00  | f
 posix/America/Barbados                 | AST    | -04:00:00  | f
 posix/America/Dawson                   | MST    | -07:00:00  | f
 posix/America/Mexico_City              | CST    | -06:00:00  | f
 posix/America/Tortola                  | AST    | -04:00:00  | f
 posix/America/Nome                     | AKST   | -09:00:00  | f
 posix/America/Glace_Bay                | AST    | -04:00:00  | f
 posix/America/Eirunepe                 | -05    | -05:00:00  | f
 posix/America/Rio_Branco               | -05    | -05:00:00  | f
 posix/America/St_Barthelemy            | AST    | -04:00:00  | f
 posix/America/Creston                  | MST    | -07:00:00  | f
 posix/America/Nipigon                  | EST    | -05:00:00  | f
 posix/America/Phoenix                  | MST    | -07:00:00  | f
 posix/America/Martinique               | AST    | -04:00:00  | f
 posix/America/Cuiaba                   | -04    | -04:00:00  | f
 posix/America/Mazatlan                 | MST    | -07:00:00  | f
 posix/America/Louisville               | EST    | -05:00:00  | f
 posix/America/Goose_Bay                | AST    | -04:00:00  | f
 posix/America/Menominee                | CST    | -06:00:00  | f
 posix/America/Pangnirtung              | EST    | -05:00:00  | f
 posix/America/Rainy_River              | CST    | -06:00:00  | f
 posix/America/Resolute                 | CST    | -06:00:00  | f
 posix/America/Halifax                  | AST    | -04:00:00  | f
 posix/America/Curacao                  | AST    | -04:00:00  | f
 posix/America/Santarem                 | -03    | -03:00:00  | f
 posix/America/Punta_Arenas             | -03    | -03:00:00  | f
 posix/America/Puerto_Rico              | AST    | -04:00:00  | f
 posix/America/Dawson_Creek             | MST    | -07:00:00  | f
 posix/America/Aruba                    | AST    | -04:00:00  | f
 posix/America/Virgin                   | AST    | -04:00:00  | f
 posix/America/Anchorage                | AKST   | -09:00:00  | f
 posix/America/Sitka                    | AKST   | -09:00:00  | f
 posix/America/North_Dakota/Beulah      | CST    | -06:00:00  | f
 posix/America/North_Dakota/New_Salem   | CST    | -06:00:00  | f
 posix/America/North_Dakota/Center      | CST    | -06:00:00  | f
 posix/America/Montserrat               | AST    | -04:00:00  | f
 posix/America/Boa_Vista                | -04    | -04:00:00  | f
 posix/America/Bahia_Banderas           | CST    | -06:00:00  | f
 posix/America/Montevideo               | -03    | -03:00:00  | f
 posix/America/Costa_Rica               | CST    | -06:00:00  | f
 posix/America/Cayman                   | EST    | -05:00:00  | f
 posix/America/Porto_Velho              | -04    | -04:00:00  | f
 posix/America/Moncton                  | AST    | -04:00:00  | f
 posix/America/Lower_Princes            | AST    | -04:00:00  | f
 posix/America/Havana                   | CST    | -05:00:00  | f
 posix/America/Lima                     | -05    | -05:00:00  | f
 posix/America/Atka                     | HST    | -10:00:00  | f
 posix/America/Porto_Acre               | -05    | -05:00:00  | f
 posix/America/Inuvik                   | MST    | -07:00:00  | f
 posix/America/Santiago                 | -03    | -03:00:00  | t
 posix/America/St_Vincent               | AST    | -04:00:00  | f
 posix/Israel                           | IST    | 02:00:00   | f
 posix/MST7MDT                          | MST    | -07:00:00  | f
 posix/Africa/Accra                     | GMT    | 00:00:00   | f
 posix/Africa/Malabo                    | WAT    | 01:00:00   | f
 posix/Africa/Kigali                    | CAT    | 02:00:00   | f
 posix/Africa/El_Aaiun                  | +01    | 01:00:00   | f
 posix/Africa/Juba                      | CAT    | 02:00:00   | f
 posix/Africa/Abidjan                   | GMT    | 00:00:00   | f
 posix/Africa/Bujumbura                 | CAT    | 02:00:00   | f
 posix/Africa/Lome                      | GMT    | 00:00:00   | f
 posix/Africa/Dakar                     | GMT    | 00:00:00   | f
 posix/Africa/Dar_es_Salaam             | EAT    | 03:00:00   | f
 posix/Africa/Asmera                    | EAT    | 03:00:00   | f
 posix/Africa/Mbabane                   | SAST   | 02:00:00   | f
 posix/Africa/Harare                    | CAT    | 02:00:00   | f
 posix/Africa/Freetown                  | GMT    | 00:00:00   | f
 posix/Africa/Tripoli                   | EET    | 02:00:00   | f
 posix/Africa/Conakry                   | GMT    | 00:00:00   | f
 posix/Africa/Monrovia                  | GMT    | 00:00:00   | f
 posix/Africa/Lagos                     | WAT    | 01:00:00   | f
 posix/Africa/Khartoum                  | CAT    | 02:00:00   | f
 posix/Africa/Casablanca                | +01    | 01:00:00   | f
 posix/Africa/Maseru                    | SAST   | 02:00:00   | f
 posix/Africa/Blantyre                  | CAT    | 02:00:00   | f
 posix/Africa/Cairo                     | EET    | 02:00:00   | f
 posix/Africa/Algiers                   | CET    | 01:00:00   | f
 posix/Africa/Kampala                   | EAT    | 03:00:00   | f
 posix/Africa/Brazzaville               | WAT    | 01:00:00   | f
 posix/Africa/Douala                    | WAT    | 01:00:00   | f
 posix/Africa/Niamey                    | WAT    | 01:00:00   | f
 posix/Africa/Porto-Novo                | WAT    | 01:00:00   | f
 posix/Africa/Timbuktu                  | GMT    | 00:00:00   | f
 posix/Africa/Libreville                | WAT    | 01:00:00   | f
 posix/Africa/Ceuta                     | CET    | 01:00:00   | f
 posix/Africa/Banjul                    | GMT    | 00:00:00   | f
 posix/Africa/Bissau                    | GMT    | 00:00:00   | f
 posix/Africa/Windhoek                  | CAT    | 02:00:00   | f
 posix/Africa/Nouakchott                | GMT    | 00:00:00   | f
 posix/Africa/Maputo                    | CAT    | 02:00:00   | f
 posix/Africa/Lubumbashi                | CAT    | 02:00:00   | f
 posix/Africa/Ndjamena                  | WAT    | 01:00:00   | f
 posix/Africa/Nairobi                   | EAT    | 03:00:00   | f
 posix/Africa/Kinshasa                  | WAT    | 01:00:00   | f
 posix/Africa/Bamako                    | GMT    | 00:00:00   | f
 posix/Africa/Asmara                    | EAT    | 03:00:00   | f
 posix/Africa/Lusaka                    | CAT    | 02:00:00   | f
 posix/Africa/Sao_Tome                  | GMT    | 00:00:00   | f
 posix/Africa/Gaborone                  | CAT    | 02:00:00   | f
 posix/Africa/Djibouti                  | EAT    | 03:00:00   | f
 posix/Africa/Luanda                    | WAT    | 01:00:00   | f
 posix/Africa/Tunis                     | CET    | 01:00:00   | f
 posix/Africa/Addis_Ababa               | EAT    | 03:00:00   | f
 posix/Africa/Ouagadougou               | GMT    | 00:00:00   | f
 posix/Africa/Johannesburg              | SAST   | 02:00:00   | f
 posix/Africa/Bangui                    | WAT    | 01:00:00   | f
 posix/Africa/Mogadishu                 | EAT    | 03:00:00   | f
 posix/Asia/Katmandu                    | +0545  | 05:45:00   | f
 posix/Asia/Aden                        | +03    | 03:00:00   | f
 posix/Asia/Srednekolymsk               | +11    | 11:00:00   | f
 posix/Asia/Tbilisi                     | +04    | 04:00:00   | f
 posix/Asia/Macao                       | CST    | 08:00:00   | f
 posix/Asia/Phnom_Penh                  | +07    | 07:00:00   | f
 posix/Asia/Ujung_Pandang               | WITA   | 08:00:00   | f
 posix/Asia/Kuala_Lumpur                | +08    | 08:00:00   | f
 posix/Asia/Krasnoyarsk                 | +07    | 07:00:00   | f
 posix/Asia/Hovd                        | +07    | 07:00:00   | f
 posix/Asia/Baghdad                     | +03    | 03:00:00   | f
 posix/Asia/Vladivostok                 | +10    | 10:00:00   | f
 posix/Asia/Kuwait                      | +03    | 03:00:00   | f
 posix/Asia/Dili                        | +09    | 09:00:00   | f
 posix/Asia/Tomsk                       | +07    | 07:00:00   | f
 posix/Asia/Dhaka                       | +06    | 06:00:00   | f
 posix/Asia/Qyzylorda                   | +05    | 05:00:00   | f
 posix/Asia/Yerevan                     | +04    | 04:00:00   | f
 posix/Asia/Kabul                       | +0430  | 04:30:00   | f
 posix/Asia/Gaza                        | EET    | 02:00:00   | f
 posix/Asia/Kuching                     | +08    | 08:00:00   | f
 posix/Asia/Yangon                      | +0630  | 06:30:00   | f
 posix/Asia/Amman                       | +03    | 03:00:00   | f
 posix/Asia/Taipei                      | CST    | 08:00:00   | f
 posix/Asia/Kathmandu                   | +0545  | 05:45:00   | f
 posix/Asia/Ulaanbaatar                 | +08    | 08:00:00   | f
 posix/Asia/Almaty                      | +06    | 06:00:00   | f
 posix/Asia/Yekaterinburg               | +05    | 05:00:00   | f
 posix/Asia/Qatar                       | +03    | 03:00:00   | f
 posix/Asia/Barnaul                     | +07    | 07:00:00   | f
 posix/Asia/Anadyr                      | +12    | 12:00:00   | f
 posix/Asia/Makassar                    | WITA   | 08:00:00   | f
 posix/Asia/Istanbul                    | +03    | 03:00:00   | f
 posix/Asia/Rangoon                     | +0630  | 06:30:00   | f
 posix/Asia/Jerusalem                   | IST    | 02:00:00   | f
 posix/Asia/Nicosia                     | EET    | 02:00:00   | f
 posix/Asia/Choibalsan                  | +08    | 08:00:00   | f
 posix/Asia/Famagusta                   | EET    | 02:00:00   | f
 posix/Asia/Atyrau                      | +05    | 05:00:00   | f
 posix/Asia/Karachi                     | PKT    | 05:00:00   | f
 posix/Asia/Riyadh                      | +03    | 03:00:00   | f
 posix/Asia/Muscat                      | +04    | 04:00:00   | f
 posix/Asia/Tashkent                    | +05    | 05:00:00   | f
 posix/Asia/Chungking                   | CST    | 08:00:00   | f
 posix/Asia/Ust-Nera                    | +10    | 10:00:00   | f
 posix/Asia/Hong_Kong                   | HKT    | 08:00:00   | f
 posix/Asia/Bishkek                     | +06    | 06:00:00   | f
 posix/Asia/Samarkand                   | +05    | 05:00:00   | f
 posix/Asia/Dushanbe                    | +05    | 05:00:00   | f
 posix/Asia/Ashgabat                    | +05    | 05:00:00   | f
 posix/Asia/Chongqing                   | CST    | 08:00:00   | f
 posix/Asia/Dubai                       | +04    | 04:00:00   | f
 posix/Asia/Shanghai                    | CST    | 08:00:00   | f
 posix/Asia/Novosibirsk                 | +07    | 07:00:00   | f
 posix/Asia/Chita                       | +09    | 09:00:00   | f
 posix/Asia/Colombo                     | +0530  | 05:30:00   | f
 posix/Asia/Irkutsk                     | +08    | 08:00:00   | f
 posix/Asia/Beirut                      | EET    | 02:00:00   | f
 posix/Asia/Kolkata                     | IST    | 05:30:00   | f
 posix/Asia/Khandyga                    | +09    | 09:00:00   | f
 posix/Asia/Manila                      | PST    | 08:00:00   | f
 posix/Asia/Novokuznetsk                | +07    | 07:00:00   | f
 posix/Asia/Damascus                    | +03    | 03:00:00   | f
 posix/Asia/Singapore                   | +08    | 08:00:00   | f
 posix/Asia/Sakhalin                    | +11    | 11:00:00   | f
 posix/Asia/Hebron                      | EET    | 02:00:00   | f
 posix/Asia/Dacca                       | +06    | 06:00:00   | f
 posix/Asia/Tel_Aviv                    | IST    | 02:00:00   | f
 posix/Asia/Kashgar                     | +06    | 06:00:00   | f
 posix/Asia/Qostanay                    | +06    | 06:00:00   | f
 posix/Asia/Baku                        | +04    | 04:00:00   | f
 posix/Asia/Kamchatka                   | +12    | 12:00:00   | f
 posix/Asia/Aqtau                       | +05    | 05:00:00   | f
 posix/Asia/Yakutsk                     | +09    | 09:00:00   | f
 posix/Asia/Thimphu                     | +06    | 06:00:00   | f
 posix/Asia/Tokyo                       | JST    | 09:00:00   | f
 posix/Asia/Thimbu                      | +06    | 06:00:00   | f
 posix/Asia/Omsk                        | +06    | 06:00:00   | f
 posix/Asia/Bahrain                     | +03    | 03:00:00   | f
 posix/Asia/Jakarta                     | WIB    | 07:00:00   | f
 posix/Asia/Brunei                      | +08    | 08:00:00   | f
 posix/Asia/Bangkok                     | +07    | 07:00:00   | f
 posix/Asia/Calcutta                    | IST    | 05:30:00   | f
 posix/Asia/Urumqi                      | +06    | 06:00:00   | f
 posix/Asia/Pyongyang                   | KST    | 09:00:00   | f
 posix/Asia/Ho_Chi_Minh                 | +07    | 07:00:00   | f
 posix/Asia/Magadan                     | +11    | 11:00:00   | f
 posix/Asia/Jayapura                    | WIT    | 09:00:00   | f
 posix/Asia/Macau                       | CST    | 08:00:00   | f
 posix/Asia/Pontianak                   | WIB    | 07:00:00   | f
 posix/Asia/Ashkhabad                   | +05    | 05:00:00   | f
 posix/Asia/Aqtobe                      | +05    | 05:00:00   | f
 posix/Asia/Oral                        | +05    | 05:00:00   | f
 posix/Asia/Harbin                      | CST    | 08:00:00   | f
 posix/Asia/Ulan_Bator                  | +08    | 08:00:00   | f
 posix/Asia/Seoul                       | KST    | 09:00:00   | f
 posix/Asia/Vientiane                   | +07    | 07:00:00   | f
 posix/Asia/Saigon                      | +07    | 07:00:00   | f
 posix/Asia/Tehran                      | +0330  | 03:30:00   | f
 posix/Hongkong                         | HKT    | 08:00:00   | f
 posix/WET                              | WET    | 00:00:00   | f
 posix/Mexico/BajaSur                   | MST    | -07:00:00  | f
 posix/Mexico/BajaNorte                 | PST    | -08:00:00  | f
 posix/Mexico/General                   | CST    | -06:00:00  | f
 posix/Iran                             | +0330  | 03:30:00   | f
 Mexico/BajaSur                         | MST    | -07:00:00  | f
 Mexico/BajaNorte                       | PST    | -08:00:00  | f
 Mexico/General                         | CST    | -06:00:00  | f
 Iran                                   | +0330  | 03:30:00   | f
(1195 rows)


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

[Max Nikulin]

On 18/01/2023 23:20, Jean Louis wrote:
> Is there any program, software, system, that is really so good with
> time, apart from PostgreSQL database that I know with 1195 defined
> time zones?
...
>                    name                  | abbrev | utc_offset | is_dst
> ----------------------------------------+--------+------------+--------
>   NZ                                     | NZDT   | 13:00:00   | t
>   GB-Eire                                | GMT    | 00:00:00   | f

What conclusion should we make looking at this long table? I am unsure 
concerning difference from content of tzdata package (IANA or Olson DB) 
that is rather standard on Linux. Emacs uses it though libc (API has 
some limitations, but conversion from UTC to local time should be 
accurate). Various programming languages have libraries to use this 
database.

https://www.iana.org/time-zones

I can not say anything concerning Windows besides that I have seen 
tables for mapping of tzids to IANA timezones.

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

[Alexander Adolf]

Daryl Manning <daryl@wakatara.com> writes:

> [...]
> I'd just be excited to have us run through the basic use cases and then see
> some more "tricky" ones. I imagine there are things we'd just have to
> say... too tricky for (eg. flight takes off in one TZ and range allows it
> to land in timezone... stuff like that might be tricky.).
> [...]

This case doesn't seem tricky to me for as long as both time
specifications have time zone information.

For cross-timezone flights, the VCS calendar appointments airlines send
out by email to customers typically have start and end times given in
UTC. The user's calendaring app will convert that to the time zone in
which the OS of the user's laptop currently pretends to be.

Same thing for flights spanning DST changeovers, btw. A UTC
specification is unambiguous in this case, too.

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

[Tim Cross]

Daryl Manning <daryl@wakatara.com> writes:

> I think timezone you're in should be declared globally, surely?  And then defined in the timestamp?
>

Do you mean globally as in at the OS level or globally in org mode. If
the latter, I disagree. The OS has this information and there is no need
for org to repeat it (and possibly hav it wrong). I would go the other
direction and say that the TZ should only be defined in an org file i it
differs from the OS setting.

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

[Ihor Radchenko]

Tim Cross <theophilusx@gmail.com> writes:

> Daryl Manning <daryl@wakatara.com> writes:
>
>> I think timezone you're in should be declared globally, surely?  And then defined in the timestamp?
>>
>
> Do you mean globally as in at the OS level or globally in org mode. If
> the latter, I disagree. The OS has this information and there is no need
> for org to repeat it (and possibly hav it wrong). I would go the other
> direction and say that the TZ should only be defined in an org file i it
> differs from the OS setting.

I am not sure here.

Consider the following situation:

1. Someone lives in Berlin most of the time and has all the business
   activity, including meetings in Berlin.
2. All the timestamps, including scheduled meetings are thus recorded in
   local time - there is not much point specifying that it is
   Europe/Berlin when system time is Europe/Berlin anyway.
3. The meetings are scattered across various Org files.   
4. The same person goes on holiday to a different time zone with no
   plans to do work meetings there. No adjustments to Org settings or
   files are being made.
5. There is a meeting in Berlin time being scheduled shortly after the
   holiday.   
6. Due to emergency (say, flight delay), it becomes impossible to come
   back to Berlin in time. The meeting must be attended online thus.
7. The local computer time zone is automatically set to the local time
   though. And combined with the timestamps being scheduled in "local"
   time (assuming that they will only matter in Berlin), it becomes a
   problem. Note that the computer time zone should be retained to make
   agenda display real meeting times in local time.
8. Solution to that problem is telling Org somehow that all the
   timestamps without time zone specifier must be considered in
   Europe/Berlin, not local time zone. At least, temporarily.
9. The easiest way Org can support such need would be global "default"
   time zone. It will be easier than a need to go through every possible
   Org file on computer and hand-setting the Europe/Berlin there.   

So, I am in favour of allowing Org-global "default" time zone in addition
to setting it on per-file, per-heading, and per-timestamp basis.

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

[Jean Louis]

* Ihor Radchenko <yantar92@posteo.net> [2023-01-16 14:21]:
> In another message, I also mentioned an idea of specifying time zone
> globally or per file. Other suggestion was per-heading specification. In
> addition to time zone being specified directly inside the timestamp.

Of course that is solution. iCalendar export already supports time
zones. It was logical to author or maybe requirement of iCalendar.

And then comes the calculation, there must be way to re-calculate
representation of timestamps:

When there is global variable for Org file about time zone, then:

- every timestamp with time zone, shall be left intact or
re-calculated to diffrent local time zone. Imagine person giving Org
file from Russia to somebody in Florida, or travelling there. That
user or recipient would like to see the actual time, which is time for
him in Florida, but in its representation different from time in
Russia.

- ever timestamp with settings in heading, shall be calculated as
such.

It means there shall be functions which can convert timestamps to the
new time zone, with the option to left unchanged those timestamps who
already have time zone specified, and with option not to be converted.

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

[Ihor Radchenko]

Jean Louis <bugs@gnu.support> writes:

> When there is global variable for Org file about time zone, then:
>
> - every timestamp with time zone, shall be left intact or
> re-calculated to diffrent local time zone. Imagine person giving Org
> file from Russia to somebody in Florida, or travelling there. That
> user or recipient would like to see the actual time, which is time for
> him in Florida, but in its representation different from time in
> Russia.

Sure. I imagine `org-display-custom-times' could handle this.

> - ever timestamp with settings in heading, shall be calculated as
> such.
>
> It means there shall be functions which can convert timestamps to the
> new time zone, with the option to left unchanged those timestamps who
> already have time zone specified, and with option not to be converted.

I am not sure why you need a difference 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

[Jean Louis]

* Ihor Radchenko <yantar92@posteo.net> [2023-01-18 12:35]:
> > It means there shall be functions which can convert timestamps to the
> > new time zone, with the option to left unchanged those timestamps who
> > already have time zone specified, and with option not to be converted.
> 
> I am not sure why you need a difference here.

Today I was writing offers where I specified en_US time format, and
where I send it from EAT time zone, just realizing that people in US
can't understand how did I send the e-mail ahead of time. My
mistake. It is better that I represent it in their time, then they
will know it was night in their city when I was sending it.

Time shall be displayed correctly to the person in that other time
zone, preferrably in his time zone, not mine.

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

[Ihor Radchenko]

Jean Louis <bugs@gnu.support> writes:

> Today I was writing offers where I specified en_US time format, and
> where I send it from EAT time zone, just realizing that people in US
> can't understand how did I send the e-mail ahead of time. My
> mistake. It is better that I represent it in their time, then they
> will know it was night in their city when I was sending it.
>
> Time shall be displayed correctly to the person in that other time
> zone, preferrably in his time zone, not mine.

Now I understand, I think.

So, we should let the user specify time zone to be used for export.
Then, when sending an email, you can export the heading to text/html and
Org will set the target time zone as requested.

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

[Jean Louis]

* Ihor Radchenko <yantar92@posteo.net> [2023-01-19 13:43]:
> So, we should let the user specify time zone to be used for export.
> Then, when sending an email, you can export the heading to text/html and
> Org will set the target time zone as requested.

Exactly.

Follow the iCalendar export option TIMEZONE. Why did author insist on it?

(info "(org) iCalendar Export")

>    The iCalendar export back-end includes ‘SUMMARY’, ‘DESCRIPTION’,
> ‘LOCATION’, ‘TIMEZONE’ and ‘CLASS’ properties from the Org entries when
> exporting.  To force the back-end to inherit the ‘LOCATION’, ‘TIMEZONE’
> and ‘CLASS’ properties, configure the ‘org-use-property-inheritance’
> variable.

When exporting file or not exporting, the recipient may receive the
file and be in different time zone. If file has no time zone property,
then user in different time zone cannot know what time is being talked
about.

That means that function of sending appointments (headings or TODO
tasks) should embed timezone property in such heading. Or the function
that exports Org file shall embed something like #+TIMEZONE: PST in
the Org file, or at least ask user, or allow such exports by
customized functions.

And all stamps like "Created: " in HTML shall get its time zone,
because without it, time remains ambigous, and also in probably 98%
cases wrong. Why display wrong time? If it is for user only, that is
fine, but if HTML is published on web server for others, the time has
significance.

-- 
Jean

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

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

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

[Jean Louis]

* Ihor Radchenko <yantar92@posteo.net> [2023-01-14 16:23]:
> Tim Cross <theophilusx@gmail.com> writes:
> 
> > Consider for example an agenda file where the TODO items have been added
> > while I am here in Australia (currently +11:00 w/ DST). Tomorrow I fly
> > to Europe where I will be working for the next 6 weeks. I need all my
> > TODOs with active timestamps to be updated to Berlin's TZ. How does this
> > work?
> 
> I am not sure what is the problem.
> The timestamps that should stay in local time will be automatically
> updated as your system TZ is updated.

Then Org shall know what was local time! Without being specified in
the time stamp, it has to be specified somewhere, as computer can't
know at which time zone was it specified.

> The timestamps that should be tied to specific time zone will specify
> that required time zone and will thus remain functional.

That is clear.

> > The representation of the timestamps is the easy part. It is the
> > management, display, calculations, etc where the complications
> > arise. From looking at the supported time related functions in Emacs,
> > while most of the key ones do have support for passing in time zone
> > data, there seems little (if any) code to support the lookup and
> > retrieval of time zone data - in particular, ability to lookup time zone
> > data for a specific date, not just a location.
> 
> But why do we need any time zone data? All we need to converting from
> and to internal Emacs' time representation supplying the correct time
> zone to it.

Converting alone shall be easy, but that does not resolve the
problem. 

You need to review practical examples as they are already listed in
this thread by various people.

Time zones are important for people who work with different time
zones, and for those who share headings and Org files on the planet.

They are not important for people who are static in one city, who do
not travel and do not share Org files with others.

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

[Ihor Radchenko]

Jean Louis <bugs@gnu.support> writes:

>> I am not sure what is the problem.
>> The timestamps that should stay in local time will be automatically
>> updated as your system TZ is updated.
>
> Then Org shall know what was local time! Without being specified in
> the time stamp, it has to be specified somewhere, as computer can't
> know at which time zone was it specified.

We need nothing to use current time zone. And we already do it.

System clock knows the current time zone. Emacs has an ability to
determine current time zone. See `current-time-zone'. This works
automatically (and already) because we use `encode-time'.

> You need to review practical examples as they are already listed in
> this thread by various people.

Indeed. This is the whole point of this discussion. Note my replies with
updated ideas. So far, I do not see a need to get some extra information
about time zones though. If you can, please correct me in the relevant
branches of this thread.

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

[Jean Louis]

* Ihor Radchenko <yantar92@posteo.net> [2023-01-16 14:25]:
> Jean Louis <bugs@gnu.support> writes:
> 
> >> I am not sure what is the problem.
> >> The timestamps that should stay in local time will be automatically
> >> updated as your system TZ is updated.
> >
> > Then Org shall know what was local time! Without being specified in
> > the time stamp, it has to be specified somewhere, as computer can't
> > know at which time zone was it specified.
> 
> We need nothing to use current time zone. And we already do it.
> 
> System clock knows the current time zone. Emacs has an ability to
> determine current time zone. See `current-time-zone'. This works
> automatically (and already) because we use `encode-time'.

Then you did not understand the point.

For users who use Org personally, in single place, single time zone,
who do no travel, who do not share headings, tasks, and files
internationally, they really do not need hussle with time zones!

However, when nice strong guy makes an Org file with list of tasks in
Ukraine and send it to nice girl Florida, she will simply think that
at 9 o'clock she has to discuss making visa with her fiance, but
fiance is already pissed off because she did not appear at online
meeting.

Time zones are useful for:

- people who travel from one time zone to other;
- people who share Org files, headings, tasks;

Of course I was doing it since 2016 until some year when I realized
that there are serious human usability related limits. 

But let's review, what would it be, when it would be that Jean works
in Org:

I have switched from Org to Hyperscope in June 2021:

# SELECT hypeoplerelations_datecreated FROM hypeoplerelations WHERE hypeoplerelations_hypeoplereltypes = 2 LIMIT 1;
 hypeoplerelations_datecreated 
-------------------------------
 2021-06-09 10:19:06.19327+03

That was the date when I slowly transitioned from sharing Org tasks to
people, in fact those were Org headings.

Since June 2021, I have shared 6176 time heading, without using Org,
to people all in various countries.

# SELECT count(1) FROM hypeoplerelations WHERE hypeoplerelations_hypeoplereltypes = 2;
 count 
-------
  6176
(1 row)

Time zones are small detail that does matter. 

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

[Ihor Radchenko]

Jean Louis <bugs@gnu.support> writes:

>> >> I am not sure what is the problem.
>> >> The timestamps that should stay in local time will be automatically
>> >> updated as your system TZ is updated.
>> >
>> > Then Org shall know what was local time! Without being specified in
>> > the time stamp, it has to be specified somewhere, as computer can't
>> > know at which time zone was it specified.
>> 
>> We need nothing to use current time zone. And we already do it.
>> 
>> System clock knows the current time zone. Emacs has an ability to
>> determine current time zone. See `current-time-zone'. This works
>> automatically (and already) because we use `encode-time'.
>
> Then you did not understand the point.
>
> For users who use Org personally, in single place, single time zone,
> who do no travel, who do not share headings, tasks, and files
> internationally, they really do not need hussle with time zones!
>
> However, when nice strong guy makes an Org file with list of tasks in
> Ukraine and send it to nice girl Florida, she will simply think that
> at 9 o'clock she has to discuss making visa with her fiance, but
> fiance is already pissed off because she did not appear at online
> meeting.

Sure. Then, a guy from Ukraine can add default timezone to the shared
file/heading. It will then apply to all the timestamps that do not
explicitly specify the time zone in the file/heading contents.

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

[Tom Gillespie]

> In anticipation to add time zones in future, I have added the following
> to the Org timestamp spec (see
> https://orgmode.org/worg/org-syntax.html#Timestamps):
>
> DATE TIME REPEATER-OR-DELAY
>
> TIME (optional)
> An instance of the pattern H:MMREST where H represents a one to two digit number (and can start with 0), and M represents a single digit. REST can contain anything but \n or closing bracket.
>
> Note that REST imply that almost arbitrary suffix can be in TIME without
> braking the existing Org timestamp parsing code.

I'm not sure how I feel about the REST in the grammar, I think it is a
reasonable approach but need to double check. I'm worried that there
can be some nasty interactions with REPEATER-OR-DELAY syntax, but that
may not actually be an issue.

I will note that this doesn't address the issue of syntax for
historical and future dates. For historical dates those almost always
require significant additional metadata to compensate for things like
the julian/gregorian calendar switchover etc. for future dates we may
want to go ahead and specify something beyond YYYY-.

I'm less concerned about the rest of the issues beyond the fact that
adding syntactic support for timezones seems to have opened up
countless usability and bad assumption issues that have been mentioned
elsewhere in the thread.

So, I think the syntax may be ok, but as written I think there can be
quite nasty interactions with REPEATER-OR-DELAY (not to mention what
happens if a delay tries to track across a change in timezones).

Best,
Tom

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

[Ihor Radchenko]

Tom Gillespie <tgbugs@gmail.com> writes:

>> Note that REST imply that almost arbitrary suffix can be in TIME without
>> braking the existing Org timestamp parsing code.
>
> I'm not sure how I feel about the REST in the grammar, I think it is a
> reasonable approach but need to double check. I'm worried that there
> can be some nasty interactions with REPEATER-OR-DELAY syntax, but that
> may not actually be an issue.

The existing code uses `org-ts-regexp-both' and `org-ts-regexp0' for
analysis. + `org-element-timestamp-parser' that is using Elisp logic.

And these requirements are pretty lax. The actual parsing just requires

YYYY-MM-DD [day] XX:XX[-XX:XX][optional string containing anything but "\n]>"]

with repeater and warning located anywhere after the required
date/day/time components.

date, repeater and warning periods do not have to contain " " afterwards
and thus can have arbitrary misc data. This feature is used by
org-habit, attaching things like /3w after the repeater.

We have a lot of forward-compatibility in timestamps :)

> I will note that this doesn't address the issue of syntax for
> historical and future dates. For historical dates those almost always
> require significant additional metadata to compensate for things like
> the julian/gregorian calendar switchover etc. for future dates we may
> want to go ahead and specify something beyond YYYY-.

This is somewhat orthogonal to time zones.

I am not sure if julian/gregorian is handled by system time libraries.
It should, no?

As for years BC, <-0001-...> will be a breaking change. But I do not
think that we need to really worry about this. Not unless we actually
get feature request. What is the practical application?

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

> Tom Gillespie <tgbugs@gmail.com> writes:
>
>
>> I will note that this doesn't address the issue of syntax for
>> historical and future dates. For historical dates those almost always
>> require significant additional metadata to compensate for things like
>> the julian/gregorian calendar switchover etc. for future dates we may
>> want to go ahead and specify something beyond YYYY-.
>
> This is somewhat orthogonal to time zones.
>
> I am not sure if julian/gregorian is handled by system time libraries.
> It should, no?
>
> As for years BC, <-0001-...> will be a breaking change. But I do not
> think that we need to really worry about this. Not unless we actually
> get feature request. What is the practical application?

Given that the stated approach is to leverage off OS facilities in this
area, it probably should also be noted that some OSs don't handle
historical dates, especially BC ones, at all well. For example, some OS
use a 32 bit number to represent the date+time and can really only
handle dates between approx 1900 and 2038 (or around there - cannot
remember specific range). So with respect to timestamps and time related
calculations, we are limited by the capabilities of the least capable
supported OS.

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

[Tom Gillespie]

> > As for years BC, <-0001-...> will be a breaking change. But I do not
> > think that we need to really worry about this. Not unless we actually
> > get feature request. What is the practical application?

Using org as a format for writing about history and being able to
reference dates in the past accurately and have the dates be
first class entities that can be parsed and checked etc.

The example in my head is a history professor who wants to
write about e.g. the collapse of the Roman republic and not
have to come up with their own time keeping system or force
any one who wants to work with referenced dates to do a bunch
of math to translate from a roman time system to a modern one.

> Given that the stated approach is to leverage off OS facilities in this
> area, it probably should also be noted that some OSs don't handle
> historical dates, especially BC ones, at all well. For example, some OS
> use a 32 bit number to represent the date+time and can really only
> handle dates between approx 1900 and 2038 (or around there - cannot
> remember specific range). So with respect to timestamps and time related
> calculations, we are limited by the capabilities of the least capable
> supported OS.

I'm mostly concerned about the syntactic features where org already
supports dates well outside the facilities of various operating systems.
I don't think that it is wise or practical for org-mode code to use
anything other than the os provided time keeping facilities right now,
but it is important to enable people who might want to do so. Org as
a format for documents has a wider range of use cases for dates and
times than Org as a life organizer and planner. At the same time those
wider use cases don't always need as much precision or ux considerations
because I don't think anyone using org right now is going to be early or
late to their meeting at [3023-01-16 Thu 12:00] (regardless of the timezone).
But org does tell me that it will be a Thursday! Best,
Tom

[FR] Allow BC years in timestamps (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Tom Gillespie <tgbugs@gmail.com> writes:

>> > As for years BC, <-0001-...> will be a breaking change. But I do not
>> > think that we need to really worry about this. Not unless we actually
>> > get feature request. What is the practical application?
>
> Using org as a format for writing about history and being able to
> reference dates in the past accurately and have the dates be
> first class entities that can be parsed and checked etc.
>
> The example in my head is a history professor who wants to
> write about e.g. the collapse of the Roman republic and not
> have to come up with their own time keeping system or force
> any one who wants to work with referenced dates to do a bunch
> of math to translate from a roman time system to a modern one.

This is an OK feature request. But it is orthogonal to time zones. Time
zones cannot help with BC years.

To support BC, we may need to change the timestamp format to, for
example, allow negative years. In addition, we might need to update
exporters to handle such scenarios.

Let's discuss BC/AC years in this thread, if there is further interest.

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

[Jean Louis]

* Daryl Manning <daryl@wakatara.com> [2023-01-13 11:59]:
> *Background*
> 
> 1. org-time-stamp-formats TZ currently only affects display and exports
> 2. org-agenda itself is not TZ aware
> 3. Several discussions on this have taken place over time
> 4. Concerns raise included breaking backwards compatibility
> 
> *Proposal*
> 
> 1. org-mode sets an optional variable (org-timezone-aware t) which enables
> TZ
> 2. org-agenda needs a way to determine which timezone it is in
> 3. Once enabled, any timestamp not exhibiting a TZ in it is considered
> "local time" wherever that is (I do not think UTC would work for this)
> 4. org-agenda can calc local based on TZ differences

Totally understandable. 

In my opinion time functions shall be implemented, if they are not, in
Emacs generally, not only Org specific. 

This is good for review as related to PostgreSQL database:

https://wiki.postgresql.org/wiki/Don%27t_Do_This#Don.27t_use_timestamp_.28without_time_zone.29

Analogously it would be best that Org becomes time zone aware.

It would mean that timestamps become time zone aware. Something like this:

<2023-01-15 Sun +1>

When timestamp becomes time zone aware, then as preliminary option it
would be possible to update all the timestamps in an Org file for
personal use.

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

[Max Nikulin]

On 14/01/2023 02:06, Jean Louis wrote:
> This is good for review as related to PostgreSQL database:

I agree that PostgreSQL is an example of good implementation of 
time-related calculations.

> https://wiki.postgresql.org/wiki/Don%27t_Do_This#Don.27t_use_timestamp_.28without_time_zone.29

I do not find this section enlightening in the context of this 
discussion. It is more related to storage formats of DB than to higher 
level aspects suitable for applications.

> It would mean that timestamps become time zone aware. Something like this:
> 
> <2023-01-15 Sun +1>

Welcome to another set of issues.

First of all, you have just date without specific time point. It may 
mean particular calendar day irrelevant to time zone. ICQ had a bug when 
they decide to store birth dates as timestamps. Significant fraction of 
users received automatic greetings on wrong day, a kind of off by one 
error. So dates must stored as dates omitting time and zone.

Let's assume <2023-01-15 Sun 09:00 +1>

It may be suitable for timestamps in the past, but future is more 
tricky. There is no problem if you are going to watch Lunar eclipse. 
However if your plan is to attend a local event there is a chance that 
you will arrive at wrong time. Sometimes offset of timezones is changed 
and it may happen between the moment when you added a scheduled time and 
the moment of the event.

Notice that Org timestamps already associated with a timezone, the one 
is set in libc (system timezone, or the one set for particular process). 
So daylight saving time and administrative time transitions should be 
taken into account. So Org timestamps may be ambiguous (mostly) 1 hour 
per year around backward time transition, e.g. for timezones having DST. 
This case explicitly specifying time offset helps to avoid uncertainty.

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

[Tim Cross]

Max Nikulin <manikulin@gmail.com> writes:

> On 14/01/2023 02:06, Jean Louis wrote:
>> This is good for review as related to PostgreSQL database:
>
> I agree that PostgreSQL is an example of good implementation of time-related calculations.
>
>> https://wiki.postgresql.org/wiki/Don%27t_Do_This#Don.27t_use_timestamp_.28without_time_zone.29
>
> I do not find this section enlightening in the context of this discussion. It is more
> related to storage formats of DB than to higher level aspects suitable for applications.
>
>> It would mean that timestamps become time zone aware. Something like this:
>> <2023-01-15 Sun +1>
>
> Welcome to another set of issues.
>
> First of all, you have just date without specific time point. It may mean particular
> calendar day irrelevant to time zone. ICQ had a bug when they decide to store birth dates
> as timestamps. Significant fraction of users received automatic greetings on wrong day, a
> kind of off by one error. So dates must stored as dates omitting time and zone.
>
> Let's assume <2023-01-15 Sun 09:00 +1>
>
> It may be suitable for timestamps in the past, but future is more tricky. There is no
> problem if you are going to watch Lunar eclipse. However if your plan is to attend a local
> event there is a chance that you will arrive at wrong time. Sometimes offset of timezones
> is changed and it may happen between the moment when you added a scheduled time and the
> moment of the event.
>
> Notice that Org timestamps already associated with a timezone, the one is set in libc
> (system timezone, or the one set for particular process). So daylight saving time and
> administrative time transitions should be taken into account. So Org timestamps may be
> ambiguous (mostly) 1 hour per year around backward time transition, e.g. for timezones
> having DST. This case explicitly specifying time offset helps to avoid uncertainty.

If org was to add TZ capabilities to timestamps, the underlying format
would have to be UTC. My previous post where I suggested there was two
'layers', the underlying storage layer (used for calculations like
duration or comparison etc) and a presentation layer (what the human
sees, which is often in whatever their local TZ is). While overly
simplified, this is basically the approach used by postgres. If org mode
was to adopt TZ support for timestamps, I am quite certain that the only
sane way to do this will be to store the timestamps as UTC. Anything
else will just cause massive complications for anyone who moves between
different timezones as well as complicating calculations which cross
over DST transition points. 

I think most people are aware of the challenges of dealing with daylight
savings and the fact that the transition date+time into and out of DST
can change based on various criteria, including political whims
(e.g. Australia eastern DST transition date was changed in 2000 because
Sydney hosted the Olympics that year).  This means there is also an
historical context when calculating and formatting timestamps - it isn't
as easy as looking up to see if a location has DST and when the
transition date/time is - you have to determine that as of the date of
the timestamp.

THen we have the further complication of calendar changes and different
calendars. For example, many people don't realise that Russia didn't
adopt the Gregorian calendar until 1918. For example, the reference to
Napoleon earlier is more complicated when considered from a Russian
locale.

Daryl mentioned elsewhere in this thread that how hard this feature
would be depends largely on the available libraries for elisp with
respect to working with date/time values. Sadly, the available elisp
libraries are inadequate in this area. While many of the functions can
be called with an optional argument defining time zone information,
there is no library which can retrieve this information in a consistent
manner and which supports historical data lookup e.g. what were the DST
transition dates for NSW Australia in 1970 (trick questions, NSW didn't
adopt DST until 1971). The existing library functions are focused more
on simpler time calculations where time zone information is less
relevant i.e. running timers, timing command execution, comparing file
modification times etc. Sometimes, it is easy to forget that while Elisp
is powerful, it isn't really a general purpose programming language like
C or Rust or even CL and Scheme. It is primarily a programming language
focused  on a specific domain, the editor. While it has some great
libraries  it also has  anumber of areas where it lacks the sort of
sophistication we have grown to expect with more general purpose
languages.

A further complication is that accessing date and time related data is
very system dependent and there is no high level library which abstracts
this so that you  can easily get consistent results across all the
platforms Emacs runs on. Even the underlying data type can vary greatly
(i.e. some platforms use a 64 bit value while others only use a 32 bit one).

I therefore suspect that in order to consider adding this feature to org
it will first be necessary to add a more sophisticated date+time library
to Emacs - probably one which is able to interface more closely with OS
APIs - most likely, a C library with an Elisp API which is able to query
OS native TZ database information and which implements basic time
calculations and conversions between different TZ values. It is likely
that such a library already exists and just needs to be added to
Emacs. However, in addition to finding an existing library, it would of
course also have to be GPLv3 licensed in order to be added to Emacs

Another aspect of this feature request which hasn't yet been considered
is what to do with respect to exporting data. Will we also need some way
to define/set the TZ for exported documents? Are there issues to be
considered with respect to code tangling? 

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

[Russell Adams]

On Sat, Jan 14, 2023 at 08:32:30PM +1100, Tim Cross wrote:
> If org was to add TZ capabilities to timestamps, the underlying format
> would have to be UTC. My previous post where I suggested there was two
> 'layers', the underlying storage layer (used for calculations like
> duration or comparison etc) and a presentation layer (what the human
> sees, which is often in whatever their local TZ is).

One of the key issues is that Org timestamps were supposed to be human
writable and readable.

Computer generated timestamps can easily be long and complex, and
potentially hidden under a presentation layer.

I have yet to see a proposal that really satisfies both use cases.

Writing incomplete timestamps as a human means timestamps in $TZ. Long
computer generated timestamps may prefer UTC or to include timezone
information (ie: ISO 8601 or RFC 3339).

Can't Org also ready diary formatted timestamps? Do those include
timezones? I know they include better repeat information. Maybe we can
build on that?

------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com
                                    https://www.adamsinfoserv.com/

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

[Ihor Radchenko]

Russell Adams <RLAdams@adamsinfoserv.com> writes:

> Can't Org also ready diary formatted timestamps?

We support diary sexps.

> Do those include timezones?

No, AFAIK. sexps may (they are just Elisp functions, anyway).

> I know they include better repeat information. Maybe we can
> build on that?

Is it really better? Apart from sexps, diaries support cron-like
repeaters, but more limited.

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

[Russell Adams]

On Sat, Jan 14, 2023 at 11:35:00AM +0000, Ihor Radchenko wrote:
> Russell Adams <RLAdams@adamsinfoserv.com> writes:
>
> > Can't Org also ready diary formatted timestamps?
>
> We support diary sexps.
>
> > Do those include timezones?
>
> No, AFAIK. sexps may (they are just Elisp functions, anyway).
>
> > I know they include better repeat information. Maybe we can
> > build on that?
>
> Is it really better? Apart from sexps, diaries support cron-like
> repeaters, but more limited.

They have repeat with a end date or max iterations.


Doesn't Emacs Calc have timezone conversion functions natively?

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


------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com
                                    https://www.adamsinfoserv.com/

[FR] Allow end date and max repeat count for timestamps with repeaters (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Russell Adams <RLAdams@adamsinfoserv.com> writes:

>> > I know they include better repeat information. Maybe we can
>> > build on that?
>>
>> Is it really better? Apart from sexps, diaries support cron-like
>> repeaters, but more limited.
>
> They have repeat with a end date or max iterations.

Good point. These two features are also frequently requested by users.
However, I do not see why we cannot implement them within the current
Org timestamp syntax:

1. <2023-01-14 Sat +1w>--<2024-01-14 Sun>
   can be treated as a repeater with end date.

2. <2023-01-14 Sat +1w/5x>
   can be treated as a repeater with limited number of iterations

The above are backwards-compatible with Org timestamp syntax.

Supporting these cases will require:
1. Updating syntax spec
2. Changing `org-auto-repeat-maybe' to decrease +1w/5x to +1w/4x upon
   updating the timestamp and not repeating when the limit has been
   reached.
3. Updating org-agenda to not display timestamps beyond the limit.

-- 
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: [FR] Allow end date and max repeat count for timestamps with repeaters (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Samuel Wales]

On 1/14/23, Ihor Radchenko <yantar92@posteo.net> wrote:
> However, I do not see why we cannot implement them within the current
> Org timestamp syntax:

my concern would be personal code and 3rd-party packages, which might
have their own peculiar parsing.

that parsing might even be of non-org files with org syntax that is
embedded in another syntax.  [like, parsing diffs of org, with
planning line tses and perhaps trying to accommodate various user
settings for org indentation where possible.]

if otoh org provides really good api that can even do that, then i
suppose you could tell those devs to use that api.

also my personal preference is for less new org syntax.  which is one
reason why i like cl-style sexp kw for future features and
subfeatures.  syntax can be hard to look up in the org manual, hard to
remember, etc.  but that's mho.

Re: [FR] Allow end date and max repeat count for timestamps with repeaters (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Samuel Wales <samologist@gmail.com> writes:

> On 1/14/23, Ihor Radchenko <yantar92@posteo.net> wrote:
>> However, I do not see why we cannot implement them within the current
>> Org timestamp syntax:
>
> my concern would be personal code and 3rd-party packages, which might
> have their own peculiar parsing.

I proposed a single slight change in timestamp syntax:

<2023-01-14 Sat +1w/5x>

However, it is almost the same with what we have for habits:

<2023-01-14 Sat +1w/2w>

I do not see how things are going to break even if third-party packages
use some home-grown parsers.

> if otoh org provides really good api that can even do that, then i
> suppose you could tell those devs to use that api.

`org-get-repeat', `org-get-wdays', and `org-element-timestamp-parser'.

> also my personal preference is for less new org syntax.  which is one
> reason why i like cl-style sexp kw for future features and
> subfeatures.  syntax can be hard to look up in the org manual, hard to
> remember, etc.  but that's mho.

My proposal is as little new syntax as I was able to come up with.

-- 
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: [FR] Allow end date and max repeat count for timestamps with repeaters (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Samuel Wales]

On 1/15/23, Ihor Radchenko <yantar92@posteo.net> wrote:
> My proposal is as little new syntax as I was able to come up with.

i kind of like it actually.  :]

but i just wanted to bring up the issue of 1] the possibility of
drawing a line in the sand at some point wrt creeping syntax [even if
not in tses for repeaters], [in principle in tses if tz complexity
turns out to demand more user specification etc.], and 2] 3rd party
and personal code that ... who knows what parsing lurks.  unintended
consequences and all that.

i checked my very old own code and indeed i'm not trying to get the
repeater with strict re character group, but in principle i can
imagine code by others could have.

>
> --
> 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: [FR] Allow end date and max repeat count for timestamps with repeaters (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Samuel Wales]

to be clear, i won't object to that syntax, as i think it is as
intuitive as anything else in tses already, but do have the concerns i
raised in general.


On 1/15/23, Samuel Wales <samologist@gmail.com> wrote:
> On 1/15/23, Ihor Radchenko <yantar92@posteo.net> wrote:
>> My proposal is as little new syntax as I was able to come up with.
>
> i kind of like it actually.  :]
>
> but i just wanted to bring up the issue of 1] the possibility of
> drawing a line in the sand at some point wrt creeping syntax [even if
> not in tses for repeaters], [in principle in tses if tz complexity
> turns out to demand more user specification etc.], and 2] 3rd party
> and personal code that ... who knows what parsing lurks.  unintended
> consequences and all that.
>
> i checked my very old own code and indeed i'm not trying to get the
> repeater with strict re character group, but in principle i can
> imagine code by others could have.
>
>>
>> --
>> 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
>


-- 
The Kafka Pandemic

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

Re: [FR] Allow end date and max repeat count for timestamps with repeaters (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Samuel Wales <samologist@gmail.com> writes:

> but i just wanted to bring up the issue of 1] the possibility of
> drawing a line in the sand at some point wrt creeping syntax [even if
> not in tses for repeaters], [in principle in tses if tz complexity
> turns out to demand more user specification etc.], and 2] 3rd party
> and personal code that ... who knows what parsing lurks.  unintended
> consequences and all that.
>
> i checked my very old own code and indeed i'm not trying to get the
> repeater with strict re character group, but in principle i can
> imagine code by others could have.

Well. I'd say that repeat count has been requested enough to strongly
consider adding it. I guess an alternative could be setting a heading
property to limit the number of repetitions.

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

[Ihor Radchenko]

Russell Adams <RLAdams@adamsinfoserv.com> writes:

> Doesn't Emacs Calc have timezone conversion functions natively?

Calc's time zone calculations are hard coded. We should rather rely on
OS library primitives. They have better chances to get updated as
politics changes in some countries.

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

[Russell Adams]

On Sat, Jan 14, 2023 at 12:19:17PM +0000, Ihor Radchenko wrote:
> Russell Adams <RLAdams@adamsinfoserv.com> writes:
>
> > Doesn't Emacs Calc have timezone conversion functions natively?
>
> Calc's time zone calculations are hard coded. We should rather rely on
> OS library primitives. They have better chances to get updated as
> politics changes in some countries.

I had no idea.

Wouldn't Emacs be updated eventually if timezones change? Doesn't it
use the tzdb?

I'd rather see Org depend on built in Emacs functions than OS.

------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com
                                    https://www.adamsinfoserv.com/

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

[Ihor Radchenko]

Russell Adams <RLAdams@adamsinfoserv.com> writes:

>> Calc's time zone calculations are hard coded. We should rather rely on
>> OS library primitives. They have better chances to get updated as
>> politics changes in some countries.
>
> I had no idea.
>
> Wouldn't Emacs be updated eventually if timezones change? Doesn't it
> use the tzdb?

Emacs uses time.h on Linux. If I understand correctly, time.h should use
tzdb or whatever is called in the particular GNU/Linux distribution.

> I'd rather see Org depend on built in Emacs functions than OS.

That's a question to Emacs developers. AFAIR, Emacs uses system
libraries for time zones because otherwise the maintenance would be
unbearable.

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

[Ihor Radchenko]

Tim Cross <theophilusx@gmail.com> writes:

> Daryl mentioned elsewhere in this thread that how hard this feature
> would be depends largely on the available libraries for elisp with
> respect to working with date/time values. Sadly, the available elisp
> libraries are inadequate in this area. While many of the functions can
> be called with an optional argument defining time zone information,
> there is no library which can retrieve this information in a consistent
> manner and which supports historical data lookup e.g. what were the DST
> transition dates for NSW Australia in 1970 (trick questions, NSW didn't
> adopt DST until 1971). The existing library functions are focused more
> on simpler time calculations where time zone information is less
> relevant i.e. running timers, timing command execution, comparing file
> modification times etc. Sometimes, it is easy to forget that while Elisp
> is powerful, it isn't really a general purpose programming language like
> C or Rust or even CL and Scheme. It is primarily a programming language
> focused  on a specific domain, the editor. While it has some great
> libraries  it also has  anumber of areas where it lacks the sort of
> sophistication we have grown to expect with more general purpose
> languages.

Emacs' own time zone support is relying on external libraries. AFAIU,
historical context should be handled no worse than in the OS.

More precisely, tzlookup from timefns.c relies on time.h and Windows
equivalents. All the heavy lifting is done by core OS libraries.

> A further complication is that accessing date and time related data is
> very system dependent and there is no high level library which abstracts
> this so that you  can easily get consistent results across all the
> platforms Emacs runs on. Even the underlying data type can vary greatly
> (i.e. some platforms use a 64 bit value while others only use a 32 bit one).

This is not the problem we need to worry about. We can use whatever
Emacs provides and rely on future improvements in Emacs where things are
deficient. We should not aim for 100% accurate time zone support. Just
good enough. It's not Org's job to implement the gory details of time
zone support.

-- 
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:
>
>> Daryl mentioned elsewhere in this thread that how hard this feature
>> would be depends largely on the available libraries for elisp with
>> respect to working with date/time values. Sadly, the available elisp
>> libraries are inadequate in this area. While many of the functions can
>> be called with an optional argument defining time zone information,
>> there is no library which can retrieve this information in a consistent
>> manner and which supports historical data lookup e.g. what were the DST
>> transition dates for NSW Australia in 1970 (trick questions, NSW didn't
>> adopt DST until 1971). The existing library functions are focused more
>> on simpler time calculations where time zone information is less
>> relevant i.e. running timers, timing command execution, comparing file
>> modification times etc. Sometimes, it is easy to forget that while Elisp
>> is powerful, it isn't really a general purpose programming language like
>> C or Rust or even CL and Scheme. It is primarily a programming language
>> focused  on a specific domain, the editor. While it has some great
>> libraries  it also has  anumber of areas where it lacks the sort of
>> sophistication we have grown to expect with more general purpose
>> languages.
>
> Emacs' own time zone support is relying on external libraries. AFAIU,
> historical context should be handled no worse than in the OS.
>
> More precisely, tzlookup from timefns.c relies on time.h and Windows
> equivalents. All the heavy lifting is done by core OS libraries.
>
>> A further complication is that accessing date and time related data is
>> very system dependent and there is no high level library which abstracts
>> this so that you  can easily get consistent results across all the
>> platforms Emacs runs on. Even the underlying data type can vary greatly
>> (i.e. some platforms use a 64 bit value while others only use a 32 bit one).
>
> This is not the problem we need to worry about. We can use whatever
> Emacs provides and rely on future improvements in Emacs where things are
> deficient. We should not aim for 100% accurate time zone support. Just
> good enough. It's not Org's job to implement the gory details of time
> zone support.

I guess we will have to disagree here. If org is going to claim to
support time zones, then 100% accurate is IMO essential. As it stands
now, we don't claim TZ support and time calculations are correct on the
basis they are all done relative to current locale. However, once you
add TZ information, if you don't apply it consistently and correctly,
that means the values can no longer be relied upon.

Or to put it in another way - currently, it is well understood where org
timestamps fall down. However, once you add TZ and provide the
expectation TZ data will be respected correctly, all bets are off.

Anyway, I've made my point and will leave it alone now. Ironically, time
will tell us who is right and who isn't.

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

[Ihor Radchenko]

Tim Cross <theophilusx@gmail.com> writes:

>> This is not the problem we need to worry about. We can use whatever
>> Emacs provides and rely on future improvements in Emacs where things are
>> deficient. We should not aim for 100% accurate time zone support. Just
>> good enough. It's not Org's job to implement the gory details of time
>> zone support.
>
> I guess we will have to disagree here. If org is going to claim to
> support time zones, then 100% accurate is IMO essential. As it stands
> now, we don't claim TZ support and time calculations are correct on the
> basis they are all done relative to current locale. However, once you
> add TZ information, if you don't apply it consistently and correctly,
> that means the values can no longer be relied upon.
>
> Or to put it in another way - currently, it is well understood where org
> timestamps fall down. However, once you add TZ and provide the
> expectation TZ data will be respected correctly, all bets are off.

I think I need to clarify.
Emacs currently relies on glibc time zone support on Linux.
I am not sure if glibc is 100% accurate, but it should be good enough.
At least, there is no way we can do better ourselves.

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

[tomas]

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

On Sat, Jan 14, 2023 at 02:38:05PM +0000, Ihor Radchenko wrote:

[...]

> > Or to put it in another way - currently, it is well understood where org
> > timestamps fall down. However, once you add TZ and provide the
> > expectation TZ data will be respected correctly, all bets are off.
> 
> I think I need to clarify.
> Emacs currently relies on glibc time zone support on Linux.
> I am not sure if glibc is 100% accurate, but it should be good enough.
> At least, there is no way we can do better ourselves.

TBH, this is the only way which makes sense. The OS keeps the Olson
database up to date and all applications rely on that. Anything else
would be madness.

Now there's still enough work for the applications to do: presentation,
parsing, disambiguation, if necessary asking the user for help. Someone
mentioned PostgreSQL -- this is a nice example of what can be done beyond
the (comparatively!) boring details of time zone management :-)

Cheers
-- 
t

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

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

[Ihor Radchenko]

<tomas@tuxteam.de> writes:

> Now there's still enough work for the applications to do: presentation,
> parsing, disambiguation, if necessary asking the user for help. Someone
> mentioned PostgreSQL -- this is a nice example of what can be done beyond
> the (comparatively!) boring details of time zone management :-)

Do I understand correctly that PostgreSQL insists on using timestamps
with time zone info in favour or ordinary timestamps? Exactly to avoid
issues with the same timestamp pointing to a different real time from
epoch depending on the current OS time zone setting?

Thinking more about this, I can see how it can be important for
clocking, and similar auto-recorded information. Users may be surprised
to record clocking on some task yesterday just to find the clocking data
in future upon travelling from Singapore to San Fran.

So, when implementing time zones, we may need to take care about adding
the time zone info when auto-inserting timestamps.

In addition, we may provide some mechanism to set the time zone for:
1. Individual files
2. For all files, including possible time zone transitions over time.

What I mean by (2) is when the user travels from, say, Australia to USA,
it could be possible to say: Use Australia/Seattle up to certain time
and then use USA/Austin.

However, the above considerations are just nice-to-haves and should not
be a blocker to a more generic time zone support in Org. Having an
ability to specify time zones manually will already cater needs for a
number of users.

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

[tomas]

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

On Sat, Jan 14, 2023 at 03:05:22PM +0000, Ihor Radchenko wrote:
> <tomas@tuxteam.de> writes:
> 
> > Now there's still enough work for the applications to do: presentation,
> > parsing, disambiguation, if necessary asking the user for help. Someone
> > mentioned PostgreSQL -- this is a nice example of what can be done beyond
> > the (comparatively!) boring details of time zone management :-)
> 
> Do I understand correctly that PostgreSQL insists on using timestamps
> with time zone info in favour or ordinary timestamps? Exactly to avoid
> issues with the same timestamp pointing to a different real time from
> epoch depending on the current OS time zone setting?

It doesn't insist: it offers both data types, but the docs are very clear
on what they prefer.

> Thinking more about this, I can see how it can be important for
> clocking, and similar auto-recorded information. Users may be surprised
> to record clocking on some task yesterday just to find the clocking data
> in future upon travelling from Singapore to San Fran.
> 
> So, when implementing time zones, we may need to take care about adding
> the time zone info when auto-inserting timestamps.
> 
> In addition, we may provide some mechanism to set the time zone for:
> 1. Individual files
> 2. For all files, including possible time zone transitions over time.
> 
> What I mean by (2) is when the user travels from, say, Australia to USA,
> it could be possible to say: Use Australia/Seattle up to certain time
> and then use USA/Austin.
> 
> However, the above considerations are just nice-to-haves and should not
> be a blocker to a more generic time zone support in Org. Having an
> ability to specify time zones manually will already cater needs for a
> number of users.

Definitely. But the time stamp (with time zone) in itself doesn't
carry enough context to actually decide that. It's even not that
easy to wrap one's head around dates that "travel" (the easiest
example would be perhaps: "9:00 show up at work" -- when DST takes
effect, it's still 9:00 whatever the local time is). When you
have appointments with people in totally diverse time zones, perhaps
dates tend to be more fixed wrt UTC.

Cheers
-- 
t

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

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

[Ihor Radchenko]

tomas@tuxteam.de writes:

>> ... Having an
>> ability to specify time zones manually will already cater needs for a
>> number of users.
>
> Definitely. But the time stamp (with time zone) in itself doesn't
> carry enough context to actually decide that. It's even not that
> easy to wrap one's head around dates that "travel" (the easiest
> example would be perhaps: "9:00 show up at work" -- when DST takes
> effect, it's still 9:00 whatever the local time is).

This is basically what we have now - conform to "current" system time
zone. We are not going to remove this timestamp style. Just add an
ability to explicitly specify the timestamps if needed.

> When you have appointments with people in totally diverse time zones,
> perhaps dates tend to be more fixed wrt UTC.

AFAIK, people don't usually bother. As long as you can map from specific
time zone (applying the currently active summer clock time changes) to
something like seconds from epoch, you can always calculate back to you
preferred time zone. Look at https://www.emacswiki.org/emacs/Usergroups.
They say, for example, "Europe/Berlin", which may be either CET or CEST.

In any case, selection of time zone for user timestamps is not something
we need to worry about in Org code. Users are to decide. Org might
assist, but I do not see anything meaningful we can do to help with DST.

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

[tomas]

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

On Sat, Jan 14, 2023 at 05:06:31PM +0000, Ihor Radchenko wrote:
> tomas@tuxteam.de writes:
> 
> >> ... Having an
> >> ability to specify time zones manually will already cater needs for a
> >> number of users.
> >
> > Definitely. But the time stamp (with time zone) in itself doesn't
> > carry enough context to actually decide that [...]

> This is basically what we have now - conform to "current" system time
> zone. We are not going to remove this timestamp style. Just add an
> ability to explicitly specify the timestamps if needed.

IMO that totally makes sense. Most people just use time naively and
aren't around at half-past-three in the night when things happen :)

> > When you have appointments with people in totally diverse time zones,
> > perhaps dates tend to be more fixed wrt UTC.
> 
> AFAIK, people don't usually bother. As long as you can map from specific
> time zone (applying the currently active summer clock time changes) to
> something like seconds from epoch, you can always calculate back to you
> preferred time zone. Look at https://www.emacswiki.org/emacs/Usergroups.
> They say, for example, "Europe/Berlin", which may be either CET or CEST.
> 
> In any case, selection of time zone for user timestamps is not something
> we need to worry about in Org code. Users are to decide. Org might
> assist, but I do not see anything meaningful we can do to help with DST.

What I can imagine being useful (besides allowing timestamps to carry
that extra info) is the possibility to set defaults, perhaps at the
file (even, who knows, at the heading) level. A special attribute
seems pretty adequate, if I'm not missing some monster.

Cheers
-- 
t

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

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

[Jean Louis]

* tomas@tuxteam.de <tomas@tuxteam.de> [2023-01-14 20:16]:
> What I can imagine being useful (besides allowing timestamps to carry
> that extra info) is the possibility to set defaults, perhaps at the
> file (even, who knows, at the heading) level. A special attribute
> seems pretty adequate, if I'm not missing some monster.

So far only supported for iCalendar backend:

(info "(org) iCalendar Export")

Though it should be supported on file level, then any timezone can be
recalculated for representation.

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

Ihor Radchenko <yantar92@posteo.net> writes:

> tomas@tuxteam.de writes:
>
>>> ... Having an
>>> ability to specify time zones manually will already cater needs for a
>>> number of users.
>>
>> Definitely. But the time stamp (with time zone) in itself doesn't
>> carry enough context to actually decide that. It's even not that
>> easy to wrap one's head around dates that "travel" (the easiest
>> example would be perhaps: "9:00 show up at work" -- when DST takes
>> effect, it's still 9:00 whatever the local time is).
>
> This is basically what we have now - conform to "current" system time
> zone. We are not going to remove this timestamp style. Just add an
> ability to explicitly specify the timestamps if needed.
>
>> When you have appointments with people in totally diverse time zones,
>> perhaps dates tend to be more fixed wrt UTC.
>
> AFAIK, people don't usually bother. As long as you can map from specific
> time zone (applying the currently active summer clock time changes) to
> something like seconds from epoch, you can always calculate back to you
> preferred time zone. Look at https://www.emacswiki.org/emacs/Usergroups.
> They say, for example, "Europe/Berlin", which may be either CET or CEST.
>
> In any case, selection of time zone for user timestamps is not something
> we need to worry about in Org code. Users are to decide. Org might
> assist, but I do not see anything meaningful we can do to help with DST.

I think I basically agree with the last statement. However, perhaps we
need to step back and ask ourselves what it is that people do want which
drives this feature request. I doubt it is simply the ability to add TZ
information to timestamps. I suspect the underlying motivation here is
to have org mode actually use this information in a meaningful way,
which essentially means all the complicated stuff I'm concerned about
and which you seem to imply we wouldn't manage anyway.

To put it another way, we need to clarify what people mean when they
request the feature of timestamp support in org-mode datestamps. What
does this actually mean? Is it as simple as just being able to specify
the timezone (seems relatively easy to implement, but doens't really add
much) or is the expectation that once you have time zone information, it
will be used to do things like adjust date+time in agenda based on
change in locale or change in daylight savings status etc.

Clarifying the end goal will likely focus the discussion a lot
more. My interpretation, which could well be too extreme, is that people
want more than just the ability to add TZ info to their timestamps. They
want their agenda to reflect correct meeting/schedule times based on
their current locale, which may have changed since the initial timestamp
was recorded. They want time duration calculations which are able to
handle DS transitions etc, they want their agenda/calendar to adjust in
a similar way to how their Google calendar will adjust based on DS
transitions. 

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

[Ihor Radchenko]

Tim Cross <theophilusx@gmail.com> writes:

>> In any case, selection of time zone for user timestamps is not something
>> we need to worry about in Org code. Users are to decide. Org might
>> assist, but I do not see anything meaningful we can do to help with DST.
>
> I think I basically agree with the last statement. However, perhaps we
> need to step back and ask ourselves what it is that people do want which
> drives this feature request. I doubt it is simply the ability to add TZ
> information to timestamps. I suspect the underlying motivation here is
> to have org mode actually use this information in a meaningful way,
> which essentially means all the complicated stuff I'm concerned about
> and which you seem to imply we wouldn't manage anyway.

I don't imply that. What I am saying is that we first need to decide on
syntax and provide basic support for time zones. It will already be
helpful as I won't need to convert timestamps into local time or think
if I need to convert timestamps ahead of time before a flight to
different time zone.

More things can be implemented once we have the basic support.

> To put it another way, we need to clarify what people mean when they
> request the feature of timestamp support in org-mode datestamps. What
> does this actually mean? Is it as simple as just being able to specify
> the timezone (seems relatively easy to implement, but doens't really add
> much) or is the expectation that once you have time zone information, it
> will be used to do things like adjust date+time in agenda based on
> change in locale or change in daylight savings status etc.

Converting timestamps with time zone to local time is indeed one of the
basic features we need to support.

> Clarifying the end goal will likely focus the discussion a lot
> more. My interpretation, which could well be too extreme, is that people
> want more than just the ability to add TZ info to their timestamps. They
> want their agenda to reflect correct meeting/schedule times based on
> their current locale, which may have changed since the initial timestamp
> was recorded. They want time duration calculations which are able to
> handle DS transitions etc, they want their agenda/calendar to adjust in
> a similar way to how their Google calendar will adjust based on DS
> transitions. 

I do not see any obstacle to having these basic features either. We
already use `encode-time' in time calculations across Org. So, all the
operations on times already use internal time representation. We will
get all the features you named pretty much for free just by supplying
time zone to `encode-time' calls.

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

[Alexander Adolf]

Ihor Radchenko <yantar92@posteo.net> writes:

> [...]
> I don't imply that. What I am saying is that we first need to decide on
> syntax and provide basic support for time zones. It will already be
> helpful as I won't need to convert timestamps into local time or think
> if I need to convert timestamps ahead of time before a flight to
> different time zone.
>
> More things can be implemented once we have the basic support.
> [...]
>
> Converting timestamps with time zone to local time is indeed one of the
> basic features we need to support.
> [...]

I fully concur with Ihor.

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

[Jean Louis]

* Tim Cross <theophilusx@gmail.com> [2023-01-15 01:13]:
> I think I basically agree with the last statement. However, perhaps we
> need to step back and ask ourselves what it is that people do want which
> drives this feature request. I doubt it is simply the ability to add TZ
> information to timestamps. I suspect the underlying motivation here is
> to have org mode actually use this information in a meaningful way,
> which essentially means all the complicated stuff I'm concerned about
> and which you seem to imply we wouldn't manage anyway.

It means for representation and calculations.

Person in East Africa writes task to somebody in Washington, with
deadline with time zone in Croatia, when notary has to sign a document
for somebody in Croatia. Because there is hypothetical timezone
parameter at file, or header level or timestamp level, then user in
Washington can see proper time in his time zone.

Representation should depend on user's local system. But how to know
how to display the time, without having time zone defined in first
place?

It requires global timezone parameter, heading and timestamp based.

Apparently it is confusing and asks for work. Sorry for that. It is
something one had to think ahead of time when dealing with people all
over the world. 

I think that any function reading timestamps should get its "bypass"
to re-calculate timestamp according to specified time zone.

If user Joe in East Africa wrote a meeting appointment with person in
Greek by Greek timezone, and sent that appointment to Washington, USA,
then person in Washington should read the time in his time zone, and
would know when is meeting accurately, in how many hours for him. 

Greek, East African and Washington people would all see different
times, but would meet accurately at same time.

> To put it another way, we need to clarify what people mean when they
> request the feature of timestamp support in org-mode datestamps. What
> does this actually mean? Is it as simple as just being able to specify
> the timezone (seems relatively easy to implement, but doens't really add
> much) or is the expectation that once you have time zone information, it
> will be used to do things like adjust date+time in agenda based on
> change in locale or change in daylight savings status etc.

I am sure that adjustments must come there. 

Practically, Org headings and files are easily shareable. Users in
different time zones could instead plan their own, receive the agenda
planned by other people, they would see it in their own calculated
time zone, while other people watching same agenda, would see it in
their own.

-- 
Jean

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

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

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

[Jean Louis]

* Ihor Radchenko <yantar92@posteo.net> [2023-01-14 20:08]:
> > When you have appointments with people in totally diverse time zones,
> > perhaps dates tend to be more fixed wrt UTC.
> 
> AFAIK, people don't usually bother.

Can't agree to that, we who do bother will simply find different
solutions but Org, like I have developed it for myself or other CRM
systems where all time issues are solved fundamentally on the database
level.

Haven thanks, it is very easy within seconds to find how many people
are affected by time zones, so I have run 

"SELECT DISTINCT get_contacts_name(hyobjects_assignedperson) FROM
hyobjects WHERE hyobjects_assignedperson IS NOT NULL;"

And I got round number of 50 people! 

All our staff members used Org mode before, now not, there is no need
for it, apart from few lines, or generated Org buffers for usage
similar like browsing. And this is only for reasons of having fancier
themes. 

You can't know if people bother if you do not ask. 

Yes, I feel that it is not considerate enough when you say that people
don't usually bother. 

When I expressed my on this mailing list that there are issues, that
was back in time, and I would consider any issue here mentioned ever
once, that "people do bother". 

In media and newspaper business, we know that when there is one
reader's letter, that there are 1000 other people who have the same
opinion. Maybe statistics changed, but you should use that principle
on mailing list and in any community software development. One person
writing on mailing list may mean hundreds affected in background.

I can observe on other development places that people raise issue
before 10 years, before 8 years, until it finally gets solved, and the
package get its boost because it became really useful.

All the people who were direct and indirect users of Org mode since
2016, switched to different system. They are not bothered to learn
about Org, which is useful as it minimizes distraction. Though Org
mode remains useful in work of managers.

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

[Ihor Radchenko]

Jean Louis <bugs@gnu.support> writes:

> * Ihor Radchenko <yantar92@posteo.net> [2023-01-14 20:08]:
>> > When you have appointments with people in totally diverse time zones,
>> > perhaps dates tend to be more fixed wrt UTC.
>> 
>> AFAIK, people don't usually bother.
>
> Can't agree to that, we who do bother will simply find different
> solutions but Org, like I have developed it for myself or other CRM
> systems where all time issues are solved fundamentally on the database
> level.

I think you misunderstood my statement here.

"People don't bother" does not make life easier for us.
I was replying to an assertion that it is common for meeting times to be
expressed in non-ambiguous UTC+XX offsets. I gave an example that it is
not the case - some meetings are, in fact, scheduled in local, tricky
time zones. We have to account for those.

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

tomas@tuxteam.de writes:

> [[PGP Signed Part:Undecided]]
> On Sat, Jan 14, 2023 at 03:05:22PM +0000, Ihor Radchenko wrote:
>> <tomas@tuxteam.de> writes:
>> 
>> > Now there's still enough work for the applications to do: presentation,
>> > parsing, disambiguation, if necessary asking the user for help. Someone
>> > mentioned PostgreSQL -- this is a nice example of what can be done beyond
>> > the (comparatively!) boring details of time zone management :-)
>> 
>> Do I understand correctly that PostgreSQL insists on using timestamps
>> with time zone info in favour or ordinary timestamps? Exactly to avoid
>> issues with the same timestamp pointing to a different real time from
>> epoch depending on the current OS time zone setting?
>
> It doesn't insist: it offers both data types, but the docs are very clear
> on what they prefer.
>

The internal representation of timestamps used by Postgres is ALWAYS
UTC, regardless of whether the field was defined as timestamp or
timestamp with timezone. The only real difference is that if the field
is defined as just timestamp, postgres assumes the data being entered is
in local time and will adjust using the local timezone offset. It will
ignore any tz information in the input. If the field is defined as
timestamp with time zone, it will use the offset defined by the timezone
in the input to determine the UTGC value. When displaying a timestamp,
postgres always uses the local time zone unless you request a different
timezone using the 'at time zone' construct. 

>> Thinking more about this, I can see how it can be important for
>> clocking, and similar auto-recorded information. Users may be surprised
>> to record clocking on some task yesterday just to find the clocking data
>> in future upon travelling from Singapore to San Fran.
>> 
>> So, when implementing time zones, we may need to take care about adding
>> the time zone info when auto-inserting timestamps.
>> 
>> In addition, we may provide some mechanism to set the time zone for:
>> 1. Individual files
>> 2. For all files, including possible time zone transitions over time.
>> 
>> What I mean by (2) is when the user travels from, say, Australia to USA,
>> it could be possible to say: Use Australia/Seattle up to certain time
>> and then use USA/Austin.
>> 
>> However, the above considerations are just nice-to-haves and should not
>> be a blocker to a more generic time zone support in Org. Having an
>> ability to specify time zones manually will already cater needs for a
>> number of users.
>
> Definitely. But the time stamp (with time zone) in itself doesn't
> carry enough context to actually decide that. It's even not that
> easy to wrap one's head around dates that "travel" (the easiest
> example would be perhaps: "9:00 show up at work" -- when DST takes
> effect, it's still 9:00 whatever the local time is). When you
> have appointments with people in totally diverse time zones, perhaps
> dates tend to be more fixed wrt UTC.
>

One thing to keep in mind is that the abbreviated time zone names are
really just abbreviations for time offsets. So AEST is the same as
+1000. However, full timezone names represent complete timezone rules
i.e. Australia/Sydney is not just an offset value, it can tell us (via
the tz database) when daylight savings transitions occur (both for now
and in the past). The abbreviated names lack this information and can
also be ambiguous because some countries use the same abbreviation for
inside and outside daylight savings periods.  

This means that if we were to store timestamps in org files and use the
abbreviated tz name, we cannot handle adjustments due to daylight
savings times because we don't actually know the 'real' timezone of the
timestamp - we only know the tz offset at the point when the timestamp
was created. If we really want a solution which is able to handle
mobility and movement between different timezones and adjust for changes
in offsets due to daylight savings etc, you need to record the true full
timezone name, not the abbreviation. 

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

[Jean Louis]

* Tim Cross <theophilusx@gmail.com> [2023-01-15 00:40]:
> The internal representation of timestamps used by Postgres is ALWAYS
> UTC, regardless of whether the field was defined as timestamp or
> timestamp with timezone.

Right.

> The only real difference is that if the field is defined as just
> timestamp, postgres assumes the data being entered is in local time
> and will adjust using the local timezone offset.

I was never thinking about it because I have never observed it or
maybe I was unable to see it. I don't see it is adjusting
anything. Because time without time zone is just UTC time, so it is
not adjusting, but adding the time.

CREATE TABLE my (timestamp_without timestamp without time zone default
now(), 
                timestamp_with timestamp with time zone default
		now());


\d my
                                Table "public.my"
      Column       |            Type             | Collation | Nullable | Default 
-------------------+-----------------------------+-----------+----------+---------
 timestamp_without | timestamp without time zone |           |          | now()
 timestamp_with    | timestamp with time zone    |           |          | now()

[local] maddox@admin=# insert into my default values;
INSERT 0 1
[local] maddox@admin=# select * from my;
     timestamp_without      |        timestamp_with         
----------------------------+-------------------------------
 2023-01-15 23:07:35.753599 | 2023-01-15 23:07:35.753599+03
(1 row)

What if user comes to UTC time zone by Greenwich and then sets the
time zone with PostgreSQL:

SET TIME ZONE 'UTC';

select * from my;
     timestamp_without      |        timestamp_with         
----------------------------+-------------------------------
 2023-01-15 23:07:35.753599 | 2023-01-15 20:07:35.753599+00
(1 row)

One can see that time stamp with time zone is being adjusted.

Because it is not same time:

select timestamp_with - timestamp_without from my;
 ?column?  
-----------
 -03:00:00

There is 3 hours difference, though the entry in the database was in
the same time and time "looks same" while it is not.

The difference is not that PostgreSQL adjusts something but timestamp
without time zone is treated as UTC and with time zones is treated as
different to UTC, those are different times then even though they may
look apparently same.

> It will ignore any tz information in the input. If the field is
> defined as timestamp with time zone, it will use the offset defined
> by the timezone in the input to determine the UTGC value.

Or no need for offset, as in the above example.

> When displaying a timestamp, postgres always uses the local time
> zone unless you request a different timezone using the 'at time
> zone' construct.

Actualy not, it does not always use local time zone, as for timestamp
without time zone, it does not show any different representation
regardless of local time zone:

set time zone '+4';
SET
[local] maddox@admin=# select * from my;
     timestamp_without      |        timestamp_with         
----------------------------+-------------------------------
 2023-01-15 23:07:35.753599 | 2023-01-16 00:07:35.753599+04

> >> Thinking more about this, I can see how it can be important for
> >> clocking, and similar auto-recorded information. Users may be surprised
> >> to record clocking on some task yesterday just to find the clocking data
> >> in future upon travelling from Singapore to San Fran.

That is so much right.

> >> So, when implementing time zones, we may need to take care about adding
> >> the time zone info when auto-inserting timestamps.

That is good conclusion. It just comes so late in time.

> >> In addition, we may provide some mechanism to set the time zone for:
> >> 1. Individual files
> >> 2. For all files, including possible time zone transitions over
> >> time.

One has system time, but one can work with different system file and
specifying different time zone, so yes, one shall have global options
of the time zone, which should allow settings different than system
time. 

It requires in Org export to understand what is local time zone so
that Org export can set global variable of local time zone, as if it
was not set, so that when Org file is used in different time zone,
that proper time calculation can take place.

Settings shall be available:

- based on operating system time zone;

- which could be rewritten by Org settings for all files;

- which could be rewritten by file setting;

- which could be rewritten by heading property;

- which could be rewritten by timestamp itself;

Then the function reading timestamps should understand it, and later
provide all calculations.

> > Definitely. But the time stamp (with time zone) in itself doesn't
> > carry enough context to actually decide that.

Ha, ha, that is right, as time with time zone in Org context is not
UTC time internally, so that way is very difficult to achieve
accuracy, as it should involve all political changes about time zones
at any time point in past and in future. 

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

[Max Nikulin]

On 14/01/2023 22:05, Ihor Radchenko wrote:
> In addition, we may provide some mechanism to set the time zone for:
> 1. Individual files
> 2. For all files, including possible time zone transitions over time.
> 
> What I mean by (2) is when the user travels from, say, Australia to USA,
> it could be possible to say: Use Australia/Seattle up to certain time
> and then use USA/Austin.

I like this idea.

Having a time handling library supporting custom ad hoc timezones it 
would be possible to create a special zone for such trip. Its time 
offset and naming rules follows locations of the trip. As a result, 
supplying various timezones to agenda generation code it would be 
possible to generate schedule for
- the traveling user with time local to each trip point (custom TZ)
- colleagues and relatives staying at the departure point (original TZ)
- accepting party (destination TZ)

For a timestamp without explicit timezone it may be obtained from
- subtree or file property (single value or list of time intervals 
reflecting history of timezone changes)
- buffer local variable (single TZ or history)
- global org variable (single TZ or history)
- timezone (single value) set inside libc (e.g. initialized from the TZ 
environment or changed by code)
- system timezone.

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

[Max Nikulin]

On 14/01/2023 22:05, Ihor Radchenko wrote:
> <tomas@tuxteam.de> writes:
> 
>> Now there's still enough work for the applications to do: presentation,
>> parsing, disambiguation, if necessary asking the user for help. Someone
>> mentioned PostgreSQL -- this is a nice example of what can be done beyond
>> the (comparatively!) boring details of time zone management :-)
> 
> Do I understand correctly that PostgreSQL insists on using timestamps
> with time zone info in favour or ordinary timestamps? Exactly to avoid
> issues with the same timestamp pointing to a different real time from
> epoch depending on the current OS time zone setting?

My points of what that wiki page tries to say:

PostgreSQL has better support of timezone conversions than some of other 
databases or middleware libraries. That is why taking advantage of the 
postgres feature allows to create more reliable application. The recipe 
is to allow postgres to store timestamps in UTC and to delegate it time 
conversion by specifying "timestamp with time zone" type.

"With time zone" does not mean that original time zone is stored. It is 
converted to UTC from explicitly specified timezone or from the one set 
for client's connection.

Some postgres time related types was added just because they are 
required to pass SQL compliance tests or to allow easier migration from 
other databases. They should be avoided when possible.

I totally agree with the recommendation to use timestamptz for data 
related to something in history: billing, bank transactions, etc.

However it is call to trouble for planned events and schedules. Not 
frequent, so almost untested use cases.

If I remember correctly, another type, timestamp (without tz), may be 
cast on demand to any timezone (stored in another column or passed from 
application). So it may be used obtain correct UTC timestamp after 
update of timezone database.

> Thinking more about this, I can see how it can be important for
> clocking, and similar auto-recorded information. Users may be surprised
> to record clocking on some task yesterday just to find the clocking data
> in future upon travelling from Singapore to San Fran.

In the case of crossing international date line it is certainly an 
issue. Users often crossing of timezone border with several hours time 
difference may need to specify timezone explicitly as well. For others 
timezone change history should be enough to calculate duration of 
clocking intervals from regular local time.

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

[Jean Louis]

* Max Nikulin <manikulin@gmail.com> [2023-01-15 08:05]:
> I totally agree with the recommendation to use timestamptz for data related
> to something in history: billing, bank transactions, etc.
> 
> However it is call to trouble for planned events and schedules. Not
> frequent, so almost untested use cases.
> 
> If I remember correctly, another type, timestamp (without tz), may be cast
> on demand to any timezone (stored in another column or passed from
> application). So it may be used obtain correct UTC timestamp after update of
> timezone database.

It is about representation.

If time is represented as UTC, by user in Brazil, how is somebody in
Russia going to understand when is the meeting?

Call for trouble is when there is UTC time only as that requires users
to calculate themselves the different time zone, instead, computer is
for such calculations there.

When time is specified with time zone, then user in any ther time
zone can see that in his own time zone.

In the context of Org files, that would mean that there must exist
function which would convert time zone timestamps into local time zone
for proper representation.

Only with such functions problems are gone.

Without such function to convert time zones in different time zone,
user will see time zone from Brazil and will run into difficulties.

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

[Ihor Radchenko]

Jean Louis <bugs@gnu.support> writes:

> In the context of Org files, that would mean that there must exist
> function which would convert time zone timestamps into local time zone
> for proper representation.
>
> Only with such functions problems are gone.
>
> Without such function to convert time zones in different time zone,
> user will see time zone from Brazil and will run into difficulties.

This is not a problem. We already have `org-time-stamp-custom-formats'
that will use current time zone.

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

[Max Nikulin]

On 14/01/2023 16:32, Tim Cross wrote:
> 
> If org was to add TZ capabilities to timestamps, the underlying format
> would have to be UTC.
...
> can change based on various criteria, including political whims
> (e.g. Australia eastern DST transition date was changed in 2000 because
> Sydney hosted the Olympics that year).

Due to this particular reason storage format for significant fraction of 
future timestamps (but not always) must not be in UTC

2024-01-14 Sun 21:14:58 ACS (+0930, Australia/Darwin)

is not the same as

2024-01-14 Sun 11:45:58 UTC (+0000, Z)

despite currently it is.

Depending on use case the same particular fields of timestamp may be 
authoritative or derived for user convenience from other data.

UNIX timestamps in seconds in UTC timezone almost unavoidable will be 
used underneath, but operations like "start of next day" require 
non-trivial computations to find if time zone offset changes in between.

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

[Tim Cross]

Max Nikulin <manikulin@gmail.com> writes:

> On 14/01/2023 16:32, Tim Cross wrote:
>> If org was to add TZ capabilities to timestamps, the underlying format
>> would have to be UTC.
> ...
>> can change based on various criteria, including political whims
>> (e.g. Australia eastern DST transition date was changed in 2000 because
>> Sydney hosted the Olympics that year).
>
> Due to this particular reason storage format for significant fraction of future timestamps
> (but not always) must not be in UTC
>
> 2024-01-14 Sun 21:14:58 ACS (+0930, Australia/Darwin)
>
> is not the same as
>
> 2024-01-14 Sun 11:45:58 UTC (+0000, Z)
>
> despite currently it is.
>

I"m sorry, but I don't follow. The UTC time is the only time whihc is
not affected by daylight savings transitions, so is the only stable
metric. All the others are relative to that time but can change based on
things like changes in DST transition dates/times. When DST transitions
occur, time is lost/gained wrt the local time, but real time and UTC
time do not change. So when DST starts here at 2am on the llth it is 5pm
on the 10th UTC. At 2am locally, we jump to 3am, losing an hour, but the
UTC time is still 5pm. The meeting I had scheduled for 10am with friends
form the US was at 0:00 UTC. It is now at 11am local time, but still at
0:00 UTC, however, I will likely fall asleep in it because instead of my
normal 7 hours sleep, I only got six despite going to be and getting up
at the same time.  

> Depending on use case the same particular fields of timestamp may be authoritative or
> derived for user convenience from other data.
>
> UNIX timestamps in seconds in UTC timezone almost unavoidable will be used underneath, but
> operations like "start of next day" require non-trivial computations to find if time zone
> offset changes in between.

Yes, but if the underlying representation is UTC, then all you have to
do is apply local TZ data to get the local time. THis is how postgres
works. You just hav eto ensure the TZ data you get is the TZ data for
that date in that locale. 

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

[Max Nikulin]

On 14/01/2023 20:50, Tim Cross wrote:
> 
> I"m sorry, but I don't follow. The UTC time is the only time whihc is
> not affected by daylight savings transitions, so is the only stable
> metric. All the others are relative to that time but can change based on
> things like changes in DST transition dates/times. When DST transitions
> occur, time is lost/gained wrt the local time, but real time and UTC
> time do not change. So when DST starts here at 2am on the llth it is 5pm
> on the 10th UTC. At 2am locally, we jump to 3am, losing an hour, but the
> UTC time is still 5pm. The meeting I had scheduled for 10am with friends
> form the US was at 0:00 UTC. It is now at 11am local time, but still at
> 0:00 UTC, however, I will likely fall asleep in it because instead of my
> normal 7 hours sleep, I only got six despite going to be and getting up
> at the same time.

Future events may be affected by changes in timezones happened after 
scheduling them. UTC timestamps becomes incorrect in such cases.

Let's assume that a company from Sydney has a weekly meeting on Mondays 
at 15:00 *local* time. Their standard time offset is +10:00

TZ="Australia/Sydney" date --date '2023-07-15 15:00' '+%F %a %T %Z %z'
2023-07-15 Sat 15:00:00 AEST +1000

They decided to invite a person from Singapore (no DST) to join the 
meeting online next year on 2024-01-15 during the period of summer 
(daylight saving) time (+11:00 offset) in Australia:

TZ="Australia/Sydney" date --date '2024-01-15 15:00' '+%F %a %T %Z %z'
2024-01-15 Mon 15:00:00 AEDT +1100

The person in Singapore should schedule the event at

LANG=C TZ=Asia/Singapore date --date 'TZ="Australia/Sydney" 2024-01-15 
15:00' '+%F %a %T %Z %z'
2024-01-15 Mon 12:00:00 +08 +0800

the same moment as UTC timestamp

date --utc --date 'TZ="Australia/Sydney" 2024-01-15 15:00' '+%F %a %T %Z %z'
2024-01-15 Mon 04:00:00 UTC +0000

If Australia were decided to cancel daylight saving time transition then 
for the Singapore partner the meeting would be shifted by 1 hour to

LANG=C TZ=Asia/Singapore date --date '2024-01-15 15:00 +1000' '+%F %a %T 
%Z %z'
2024-01-15 Mon 13:00:00 +08 +0800

LANG=C date --utc --date '2024-01-15 15:00 +1000' '+%F %a %T %Z %z'
2024-01-15 Mon 05:00:00 UTC +0000

If the guest from Singapore or some guy from Australia decided to store 
the appointment in UTC, not as local time, they would expect beginning 
of the meeting at 14:00 (Sydney time) instead of 15:00.

The primary data for this event is

     2024-01-15 15:00 Australia/Sydney

everything else is derived accordingly to current state of timezone 
database and should be recalculated in the case of its change:

- AEDT +1100
- 2024-01-15 Mon 04:00:00 UTC +0000
- 2024-01-15 Mon 12:00:00 +08 +0800 Asia/Singapore

So future events bound to local time must be stored as local time and 
the corresponding local timezone. UTC must be used for global events 
(e.g. an eclipse) or if the negotiation is to fix event time in UTC. UTC 
is not a silver bullet for time computations, it should be used consciously.

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

[Tim Cross]

Max Nikulin <manikulin@gmail.com> writes:

> On 14/01/2023 20:50, Tim Cross wrote:
>> I"m sorry, but I don't follow. The UTC time is the only time whihc is
>> not affected by daylight savings transitions, so is the only stable
>> metric. All the others are relative to that time but can change based on
>> things like changes in DST transition dates/times. When DST transitions
>> occur, time is lost/gained wrt the local time, but real time and UTC
>> time do not change. So when DST starts here at 2am on the llth it is 5pm
>> on the 10th UTC. At 2am locally, we jump to 3am, losing an hour, but the
>> UTC time is still 5pm. The meeting I had scheduled for 10am with friends
>> form the US was at 0:00 UTC. It is now at 11am local time, but still at
>> 0:00 UTC, however, I will likely fall asleep in it because instead of my
>> normal 7 hours sleep, I only got six despite going to be and getting up
>> at the same time.
>
> Future events may be affected by changes in timezones happened after scheduling them. UTC
> timestamps becomes incorrect in such cases.
>
> Let's assume that a company from Sydney has a weekly meeting on Mondays at 15:00 *local*
> time. Their standard time offset is +10:00
>
> TZ="Australia/Sydney" date --date '2023-07-15 15:00' '+%F %a %T %Z %z'
> 2023-07-15 Sat 15:00:00 AEST +1000
>
> They decided to invite a person from Singapore (no DST) to join the meeting online next
> year on 2024-01-15 during the period of summer (daylight saving) time (+11:00 offset) in
> Australia:
>
> TZ="Australia/Sydney" date --date '2024-01-15 15:00' '+%F %a %T %Z %z'
> 2024-01-15 Mon 15:00:00 AEDT +1100
>
> The person in Singapore should schedule the event at
>
> LANG=C TZ=Asia/Singapore date --date 'TZ="Australia/Sydney" 2024-01-15 15:00' '+%F %a %T
> %Z %z'
> 2024-01-15 Mon 12:00:00 +08 +0800
>
> the same moment as UTC timestamp
>
> date --utc --date 'TZ="Australia/Sydney" 2024-01-15 15:00' '+%F %a %T %Z %z'
> 2024-01-15 Mon 04:00:00 UTC +0000
>
> If Australia were decided to cancel daylight saving time transition then for the Singapore
> partner the meeting would be shifted by 1 hour to
>
> LANG=C TZ=Asia/Singapore date --date '2024-01-15 15:00 +1000' '+%F %a %T %Z %z'
> 2024-01-15 Mon 13:00:00 +08 +0800
>
> LANG=C date --utc --date '2024-01-15 15:00 +1000' '+%F %a %T %Z %z'
> 2024-01-15 Mon 05:00:00 UTC +0000
>
> If the guest from Singapore or some guy from Australia decided to store the appointment in
> UTC, not as local time, they would expect beginning of the meeting at 14:00 (Sydney time)
> instead of 15:00.
>
> The primary data for this event is
>
>     2024-01-15 15:00 Australia/Sydney
>
> everything else is derived accordingly to current state of timezone database and should be
> recalculated in the case of its change:
>
> - AEDT +1100
> - 2024-01-15 Mon 04:00:00 UTC +0000
> - 2024-01-15 Mon 12:00:00 +08 +0800 Asia/Singapore
>
> So future events bound to local time must be stored as local time and the corresponding
> local timezone. UTC must be used for global events (e.g. an eclipse) or if the negotiation
> is to fix event time in UTC. UTC is not a silver bullet for time computations, it should
> be used consciously.

OK, I see what your arguing now. However, I disagree on the semantics
here. Really you have the exact same issue in both use cases. Only the
way it is handled is different. For example, I actually do have a
fortnightly meeting with people in the US and my meeting time changes
due to daylight savings transition. The UTC time stays the same, but the
meeting time for me changes twice per year (moving forward/backward an
hour). Likewise, it changes for most of the other people in the meeting
who are in various timzones except for one participant in Brisbane where
they don't have daylight savings time. His meeting time is constant all
year round.

With your semantics, the person in Singapore is the one who has to keep
changing the meeting time while for the Ausies in Sydney, it stays at
15:00 regardless. Worse yet, the Singapore participant has to chnage 4
times per year - when Singapore transitions and when Sydney does.

On the other hand, the downside with my approach is that when local
daylgiht savings transition occurs, all meeting times change, including
those with only local participants, which isn't great either. Again,
this is just some of the issues I'm concerned people are glossing over
when they say it isn't too hard to add TZ support and that we can
leverage off the built-in TZ facilities of Emacs and the OS. The
underlying semantics and model is far mor complex and getting a workable
and user friendly solution which maintains the utility of the existing
timestamps is complicated and hard. The fact you can only really rely on
full timezone names e.g. Australia/Sydney and not abbreviations like
AEST makes it even worse as we run the risk of loosing the compact
format. 

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

[Max Nikulin]

On 15/01/2023 03:30, Tim Cross wrote:
> The UTC time stays the same, but the
> meeting time for me changes twice per year (moving forward/backward an
> hour).

Meeting time remains the same expressed as local time (15:00), but 
alternates between 04:00 and 05:00 UTC. So repeating schedule can not be 
stored as UTC, instead UTC timestamp should be calculated from local 
time for each date. (Even libc can do it while you work with single 
timezone.) It is OK to store in UTC already passed events, but local 
time still may be more compact and user friendly.

Actually I am trying to draw attention to a more tricky case when 
timestamp stored as local time is even more important. Event time is 
bound to local time, and timezone database changed due to new rules for 
this time zone: the government decided to cancel or introduce DST 
transitions or to extend/shorten interval when daylight saving time is 
active. For a timezone without DST time offset may be changed as well.

While timezone database is stable, you can calculate UTC timestamps for 
any moments expressed in local time. When new rules are published some 
future UTC timestamps become invalid. If you know local time, you may 
update UTC timestamps. If you store just UTC timestamp you have a trouble.

Paul Eggert provided an example of updating time transition history, so 
what is authoritative: local time or UTC, applies to the past as well. 
However I do not agree with Paul completely. It is necessary to decide 
for each timestamp, what is the primary data, time offset (so timezone 
identifier should be updated) or local time (so time offset should be 
updated keeping timezone identifier).

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54764#30
Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list
Thu, 14 Apr 2022 15:46:58 -0700
> Again, that depends on the application. It's typically wrong to store an 
> old timestamp in a form like "1950-07-01 00:00 Europe/Lisbon", because 
> there is no standard for what "Europe/Lisbon" means. If you update your 
> copy of TZDB, or interpret such a timestamp on another computer, that 
> can change the interpretation of such a timestamp. In this particular 
> case, a change in TZDB release 2021b altered the interpretation of this 
> old timestamp because we discovered that DST was observed in 1950 in 
> Portugal.
> 
> If you want to keep the TZDB identifier for advice about how to 
> interpret dates relative to a timestamp, that's fine. But you should 
> keep the UT offset in addition to the TZDB identifier, if you want your 
> app to be fully accurate and useful. For example, you should store 
> "1950-07-01 00:00:00 +0000 Europe/Lisbon" for a timestamp generated by 
> TZDB release 2021a, so that when you interpret the timestamp in release 
> 2021b you'll have an idea of what you're dealing with.

So keeping redundant information may be crucial to get warnings that 
some timestamps need to be reviewed.

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

[Tim Cross]

Max Nikulin <manikulin@gmail.com> writes:

> On 15/01/2023 03:30, Tim Cross wrote:
>> The UTC time stays the same, but the
>> meeting time for me changes twice per year (moving forward/backward an
>> hour).
>
> Meeting time remains the same expressed as local time (15:00), but alternates between
> 04:00 and 05:00 UTC. So repeating schedule can not be stored as UTC, instead UTC timestamp
> should be calculated from local time for each date. (Even libc can do it while you work
> with single timezone.) It is OK to store in UTC already passed events, but local time
> still may be more compact and user friendly.
>
> Actually I am trying to draw attention to a more tricky case when timestamp stored as
> local time is even more important. Event time is bound to local time, and timezone
> database changed due to new rules for this time zone: the government decided to cancel or
> introduce DST transitions or to extend/shorten interval when daylight saving time is
> active. For a timezone without DST time offset may be changed as well.
>
> While timezone database is stable, you can calculate UTC timestamps for any moments
> expressed in local time. When new rules are published some future UTC timestamps become
> invalid. If you know local time, you may update UTC timestamps. If you store just UTC
> timestamp you have a trouble.
>
> Paul Eggert provided an example of updating time transition history, so what is
> authoritative: local time or UTC, applies to the past as well. However I do not agree with
> Paul completely. It is necessary to decide for each timestamp, what is the primary data,
> time offset (so timezone identifier should be updated) or local time (so time offset
> should be updated keeping timezone identifier).
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54764#30
> Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list
> Thu, 14 Apr 2022 15:46:58 -0700
>> Again, that depends on the application. It's typically wrong to store an old timestamp
>> in a form like "1950-07-01 00:00 Europe/Lisbon", because there is no standard for what
>> "Europe/Lisbon" means. If you update your copy of TZDB, or interpret such a timestamp on
>> another computer, that can change the interpretation of such a timestamp. In this
>> particular case, a change in TZDB release 2021b altered the interpretation of this old
>> timestamp because we discovered that DST was observed in 1950 in Portugal.
>> If you want to keep the TZDB identifier for advice about how to interpret dates relative
>> to a timestamp, that's fine. But you should keep the UT offset in addition to the TZDB
>> identifier, if you want your app to be fully accurate and useful. For example, you
>> should store "1950-07-01 00:00:00 +0000 Europe/Lisbon" for a timestamp generated by TZDB
>> release 2021a, so that when you interpret the timestamp in release 2021b you'll have an
>> idea of what you're dealing with.
>
> So keeping redundant information may be crucial to get warnings that some timestamps need
> to be reviewed.

WRT future timestamps, we would probably have to take the same approach
as postgres i.e. the timezone rules in force at the time the timestamp
is created are assumed to be 'forever'. While this is not true, it is
really the only solution you can adopt and you just have ot accept that
there is the chance that the rule will change in the future and the
timestamp will then be incorrect.

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

[Jean Louis]

* Tim Cross <theophilusx@gmail.com> [2023-01-15 10:58]:
> WRT future timestamps, we would probably have to take the same
> approach as postgres i.e. the timezone rules in force at the time
> the timestamp is created are assumed to be 'forever'. While this is
> not true, it is really the only solution you can adopt and you just
> have ot accept that there is the chance that the rule will change in
> the future and the timestamp will then be incorrect.

Not sure if that is so. It is about representation. 

Database user in different time zone would see different time in his
time zone, while user in other time zone would see it different. This
makes more sense for people then using UTC, which is confusing for
people and which would imply that people somehow have to convert UTC
to their local time. Isn't it?

Imagine online meeting with 2 people in different time zones, they
share the Org heading with time stamp, but when user opens that Org
heading in Florida, will see different time according to his time
zone, while user in East Africa will see different time. 

Due to correct representation, both users now know when is the meeting
taking place, and they meet in same time.

If they would share UTC time, or any time without time zone
representation, they would get time coordination difficulties.

The type TIMESTAMP WITH TIME ZONE in PostgreSQL is always stored as
UTC and time zone rules are not forever.

The type TIMESTAMP WITH TIME ZONE automatically converts to proper
time zone. 

One could think for Org to simply become able to designate time zone
somewhere, be it generally for Org file or/and specific heading, or/and
specific timestamp. 

Then implement function to transform time to UTC, and then use
libraries or Emacs to transform UTC to designated time zone.

https://www.postgresql.org/docs/15/datatype-datetime.html

For timestamp with time zone, the internally stored value is always in
UTC (Universal Coordinated Time, traditionally known as Greenwich Mean
Time, GMT). An input value that has an explicit time zone specified is
converted to UTC using the appropriate offset for that time zone. If
no time zone is stated in the input string, then it is assumed to be
in the time zone indicated by the system's TimeZone parameter, and is
converted to UTC using the offset for the timezone zone.

When a timestamp with time zone value is output, it is always
converted from UTC to the current timezone zone, and displayed as
local time in that zone. To see the time in another time zone, either
change timezone or use the AT TIME ZONE construct (see Section 9.9.4).

Conversions between timestamp without time zone and timestamp with
time zone normally assume that the timestamp without time zone value
should be taken or given as timezone local time. A different time zone
can be specified for the conversion using AT 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: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Ihor Radchenko]

Jean Louis <bugs@gnu.support> writes:

> One could think for Org to simply become able to designate time zone
> somewhere, be it generally for Org file or/and specific heading, or/and
> specific timestamp. 
>
> Then implement function to transform time to UTC, and then use
> libraries or Emacs to transform UTC to designated time zone.

We already transform timestamps into internal time representation via
`encode-time' (for the most part, at least). It is an equivalent to
transforming to UTC. The internal representation can be later
transformed back via `decode-time' with appropriate target ZONE
parameter.

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

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54764#30
> Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list
> Thu, 14 Apr 2022 15:46:58 -0700
>> If you want to keep the TZDB identifier for advice about how to 
>> interpret dates relative to a timestamp, that's fine. But you should 
>> keep the UT offset in addition to the TZDB identifier, if you want your 
>> app to be fully accurate and useful. For example, you should store 
>> "1950-07-01 00:00:00 +0000 Europe/Lisbon" for a timestamp generated by 
>> TZDB release 2021a, so that when you interpret the timestamp in release 
>> 2021b you'll have an idea of what you're dealing with.
>
> So keeping redundant information may be crucial to get warnings that 
> some timestamps need to be reviewed.

My takeaway from here is that automatically generated timestamps for
past events should better contain redundant information:

"1950-07-01 00:00:00 +0000 Europe/Lisbon"

+0000 is what matters for time calculation while Europe/Lisbon indicates
the actual timezone being implied.

Then, if there is an event of TZ database change, Org might compare
+0000 vs. Europe/Lisbon and display warning if there is discrepancy.

For us, it means that we might potentially reserve 

<1950-07-01 00:00:00+0000@Europe/Lisbon> as a valid timestamp format.
Warning is optional feature we might implement in future.

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

[Jean Louis]

* Max Nikulin <manikulin@gmail.com> [2023-01-14 10:14]:
> Let's assume <2023-01-15 Sun 09:00 +1>
> 
> It may be suitable for timestamps in the past, but future is more tricky.
> There is no problem if you are going to watch Lunar eclipse. However if your
> plan is to attend a local event there is a chance that you will arrive at
> wrong time. Sometimes offset of timezones is changed and it may happen
> between the moment when you added a scheduled time and the moment of the
> event.

Can't follow you.

with "+1" I would say it is time zone.

Basic point is that users shall learn to express themselves by using
time zone.

That may be set as global property, which could be enough for Org file
to be mobile, that Org file may be conclusively understood in any
other time zone of the world when some specific thing happened.

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

[Max Nikulin]

On 14/01/2023 20:08, Jean Louis wrote:
> * Max Nikulin [2023-01-14 10:14]:
>> Let's assume <2023-01-15 Sun 09:00 +1>
>>
>> It may be suitable for timestamps in the past, but future is more tricky.
>> There is no problem if you are going to watch Lunar eclipse. However if your
>> plan is to attend a local event there is a chance that you will arrive at
>> wrong time. Sometimes offset of timezones is changed and it may happen
>> between the moment when you added a scheduled time and the moment of the
>> event.
> 
> Can't follow you.
> 
> with "+1" I would say it is time zone.
> 
> Basic point is that users shall learn to express themselves by using
> time zone.

"+1" is not a timezone, it is current offset shared by several 
timezones. You can not assure that time offset at a particular location 
would not change due to new administrative rules.

E.g. Europe/Berlin is a timezone, but, strictly speaking, is still 
underspecified. Sometimes timezones are split into smaller parts.

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

[Tim Cross]

Max Nikulin <manikulin@gmail.com> writes:

> On 14/01/2023 20:08, Jean Louis wrote:
>> * Max Nikulin [2023-01-14 10:14]:
>>> Let's assume <2023-01-15 Sun 09:00 +1>
>>>
>>> It may be suitable for timestamps in the past, but future is more tricky.
>>> There is no problem if you are going to watch Lunar eclipse. However if your
>>> plan is to attend a local event there is a chance that you will arrive at
>>> wrong time. Sometimes offset of timezones is changed and it may happen
>>> between the moment when you added a scheduled time and the moment of the
>>> event.
>> Can't follow you.
>> with "+1" I would say it is time zone.
>> Basic point is that users shall learn to express themselves by using
>> time zone.
>
> "+1" is not a timezone, it is current offset shared by several timezones. You can not
> assure that time offset at a particular location would not change due to new
> administrative rules.
>
> E.g. Europe/Berlin is a timezone, but, strictly speaking, is still
> underspecified. Sometimes timezones are split into smaller parts.

Yes, this is a problem. We really want a symbolic TZ
specification and we would need 'smarts' i the timestamp generation code
that is able to handle potential offset changes due to daylight savings
transition etc. Even then, the transition time can change between when
the timestamp is set for and when it actually occurs.

Unfortunately, the common abbreviated forms like EST, AEST etc are
inconsistent here. Some places will have a standard and a daylight
savings type i.e. AEST and AEDT, while others will have just AEST. TO
make it worse, two locations with the same time zone offset my use
different versions i.e. Australia/Melbourn is AEST (+10/+11) and
Australia/Sydney is AEST (+10) and AEDT (+11) and Australia/Brisbane is
just AEST (+10). If everywhere which has daylight savings ensured they
used a different abbreviation for daylight saving and non-daylight
saving times, life would be easier, but they don't). Then of course
there are many countries which don't have a symbolic letter abbreviation
i.e. just have e.g -05 as their abbreviated TZ name.

It is this and other related reasons why just relying on Emacs' internal
API for times and dates is not sufficient. The abbreviated times have
ambiguity and the full timezone specification is cumbersome and
ugly. Even worse is that issue won't be shown up as failures - you will
just silently get wrong results.  

If on the other hand all the timestamps were in UTC, you avoid lots of
these issues. However, you would then also require a 'view'
layer/overlay which would take the UTC time, apply whatever the local TZ
is and show that result as the timestamp. THis would avoid things being
out by an hour due to daylight savings transitions and would mean the
user would see timestamps relative to whatever their local time zone is,
regardless of changes in location which has also changed time zones.

The problem with this approach is that now you have lost the 'plain
text' nature of org files. When editing the value, the user would need
to remember the value stored in their org file is UTC, not local
time. Many exporters would also need to be updated to handle conversion
to local time as well.

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

[tomas]

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

On Sun, Jan 15, 2023 at 06:43:19AM +1100, Tim Cross wrote:
> Max Nikulin <manikulin@gmail.com> writes:
> 
> > On 14/01/2023 20:08, Jean Louis wrote:
> >> * Max Nikulin [2023-01-14 10:14]:
> >>> Let's assume <2023-01-15 Sun 09:00 +1>
> >>>
> >>> It may be suitable for timestamps in the past, but future is more tricky.
> >>> There is no problem if you are going to watch Lunar eclipse. However if your
> >>> plan is to attend a local event there is a chance that you will arrive at
> >>> wrong time. Sometimes offset of timezones is changed and it may happen
> >>> between the moment when you added a scheduled time and the moment of the
> >>> event.
> >> Can't follow you.
> >> with "+1" I would say it is time zone.
> >> Basic point is that users shall learn to express themselves by using
> >> time zone.
> >
> > "+1" is not a timezone, it is current offset shared by several timezones. You can not
> > assure that time offset at a particular location would not change due to new
> > administrative rules.
> >
> > E.g. Europe/Berlin is a timezone, but, strictly speaking, is still
> > underspecified. Sometimes timezones are split into smaller parts.
> 
> Yes, this is a problem. We really want a symbolic TZ
> specification and we would need 'smarts' i the timestamp generation code
> that is able to handle potential offset changes due to daylight savings
> transition etc. Even then, the transition time can change between when
> the timestamp is set for and when it actually occurs.

Having wrangled that (outside Emacs) for a while, I politely disagree.

If it's the past we are talking about, the offset is most of the time
the right thing (we know best at timestamp creation time). When it's
the future /and/ we are talking about local time, then the symbolic
time zone makes more sense (e.g. we meet in Lviv next Monday at 3pm,
whatever 3pm is in that timezone).

I think we need (optionally) both. Well knowing that some dates with
some symbolic time zones are ambiguous.

For a log file (past times), for example, I would insist in having the
offset (actually I'd try to talk people into having UTC, but have failed
at times with that).

Cheers
-- 
t

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

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

[Ihor Radchenko]

Tim Cross <theophilusx@gmail.com> writes:

> Unfortunately, the common abbreviated forms like EST, AEST etc are
> inconsistent here. Some places will have a standard and a daylight
> savings type i.e. AEST and AEDT, while others will have just AEST. TO
> make it worse, two locations with the same time zone offset my use
> different versions i.e. Australia/Melbourn is AEST (+10/+11) and
> Australia/Sydney is AEST (+10) and AEDT (+11) and Australia/Brisbane is
> just AEST (+10). If everywhere which has daylight savings ensured they
> used a different abbreviation for daylight saving and non-daylight
> saving times, life would be easier, but they don't). Then of course
> there are many countries which don't have a symbolic letter abbreviation
> i.e. just have e.g -05 as their abbreviated TZ name.
>
> It is this and other related reasons why just relying on Emacs' internal
> API for times and dates is not sufficient. The abbreviated times have
> ambiguity and the full timezone specification is cumbersome and
> ugly. Even worse is that issue won't be shown up as failures - you will
> just silently get wrong results.  

So, basically we may need a way to (1) identify ambiguous TZ
specifications; (2) signal to user about potential issues.

Note that these are also optional features we may implement any time
once we have basic timezone support.

For (2) we may use something similar to `world-clock' - display user
timestamp at point for different time zones. Maybe via eldoc.

-- 
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:
>
>> Unfortunately, the common abbreviated forms like EST, AEST etc are
>> inconsistent here. Some places will have a standard and a daylight
>> savings type i.e. AEST and AEDT, while others will have just AEST. TO
>> make it worse, two locations with the same time zone offset my use
>> different versions i.e. Australia/Melbourn is AEST (+10/+11) and
>> Australia/Sydney is AEST (+10) and AEDT (+11) and Australia/Brisbane is
>> just AEST (+10). If everywhere which has daylight savings ensured they
>> used a different abbreviation for daylight saving and non-daylight
>> saving times, life would be easier, but they don't). Then of course
>> there are many countries which don't have a symbolic letter abbreviation
>> i.e. just have e.g -05 as their abbreviated TZ name.
>>
>> It is this and other related reasons why just relying on Emacs' internal
>> API for times and dates is not sufficient. The abbreviated times have
>> ambiguity and the full timezone specification is cumbersome and
>> ugly. Even worse is that issue won't be shown up as failures - you will
>> just silently get wrong results.  
>
> So, basically we may need a way to (1) identify ambiguous TZ
> specifications; (2) signal to user about potential issues.
>
> Note that these are also optional features we may implement any time
> once we have basic timezone support.
>
> For (2) we may use something similar to `world-clock' - display user
> timestamp at point for different time zones. Maybe via eldoc.


If the timestamp only contains the abbreviated name e.g. AEST, then
there is no automatic way to disambiguate - best we could
do is issue a warning. The abbreviated TZ name, unlike the full TZ name,
is really just a shorthand for the time offset from UTC at a specific
point in time. The full TZ name on the other hand states not only the
UTC offset, but also the TZ rules (and with things like the IANA TZ
database, the specific TZ rules in place at the point in time that
timestamp represents). This is essentially Max's main point - if
timestamps for the future have the full TZ name, then we can manage
things like changes in TZ database rules which occur after creation of
the timestamp or adjusting timestamps (for scheduled tasks) based on
changes in location etc). This would not be possible with abbreviated TZ
or just UTC offsets.

As an example, I'm in Australia/Brisbane TZ and I create a timestamp. If
it only has the AEST TZ info, when I travel to Australia/Melbourne org
would not be able to identify I'm in a TZ with an offset of +1100 rather
than +1000 because both use AEST (for NSW it likely would work as NSW
uses AEDT during daylight savings time). However, if the TZ was full
name i.e. Australian/Brisbane, then it does know and can adjust because
my local TZ has changed to Australia/Melbourne. 

So I guess the timestamp format and the code which manages them will
need the ability to use the full TZ name and not just the abbreviated
form (and I guess an option to allow the user to select). In fact, we
probably need a way to select between abbreviated/full dynamically as
well as you might use the different TZ types as a way to flag which
timestamps you want to adjust due to TZ changes (either in TZ db or in
user location) and those you don't want changed.

I also note a comment from an earlier thread regarding timestamps and
historical changes in tz info. I don't think this is an issue.  As far
as I know, past TZ rules/information rarely, if ever, change. It is only
with respect to future dates it is a problem and I doubt there is much
that can be done. For example Postgres recognises that a future
timestamp may become incorrect due to changes in TZ rules post creation
of the timestamp, but they specifically state they don't handle that
situation and that their model has an implicit assumption that the TZ
rules associated with a TZ don't change. In other words, from their
perspectrive, you would have to have a different process which monitors
TZ database information and when it changes, examine your db of
timestamps for ones which have been affected and adjust accordingly
(assuming it matters enough of course). I think org could eventually
reach a middle ground - if a future timestamp has the full tz name, then
changes can be applied, but if not they cannot and leave it to the user
to decide which is used. 

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

[Tom Gillespie]

> So I guess the timestamp format and the code which manages them will
> need the ability to use the full TZ name and not just the abbreviated
> form (and I guess an option to allow the user to select). In fact, we
> probably need a way to select between abbreviated/full dynamically as
> well as you might use the different TZ types as a way to flag which
> timestamps you want to adjust due to TZ changes (either in TZ db or in
> user location) and those you don't want changed.

I think the only sane way to do this is to require timezone abbreviations
/expansions to be defined in the file itself and never in an init.el there is
simply too much ambiguity and if the information is lost we are out of luck.

Of course then the question comes whether we can use something like
#+tzinfo: US/Central CT
#+tzoff: CST -06:00
#+tzoff: CDT -05:00
I don't think it is wise to allow users to map #+tzinfo: US/Central CST
because that will produce surprising and results when US/Central
changes to DST. Ugh, what a mess.

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

[Ihor Radchenko]

Tom Gillespie <tgbugs@gmail.com> writes:

>> So I guess the timestamp format and the code which manages them will
>> need the ability to use the full TZ name and not just the abbreviated
>> form (and I guess an option to allow the user to select). In fact, we
>> probably need a way to select between abbreviated/full dynamically as
>> well as you might use the different TZ types as a way to flag which
>> timestamps you want to adjust due to TZ changes (either in TZ db or in
>> user location) and those you don't want changed.
>
> I think the only sane way to do this is to require timezone abbreviations
> /expansions to be defined in the file itself and never in an init.el there is
> simply too much ambiguity and if the information is lost we are out of luck.

I strongly disagree. I'd prefer to allow only internationally recognized
time zone format. Let's not make life harder for Org file parsers.

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

[Tom Gillespie]

> I strongly disagree. I'd prefer to allow only internationally recognized
> time zone format. Let's not make life harder for Org file parsers.

So offsets and tz database names but no time zone abbreviations?

That seems reasonable since there isn't a sane way to handle the
timezone with dst vs abbreviation for an offset, so better to force
only US/Central aka America/Chicago and then -06:00 and -05:00
if users want CST/CDT to avoid any ambiguity?

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

[Ihor Radchenko]

Tom Gillespie <tgbugs@gmail.com> writes:

>> I strongly disagree. I'd prefer to allow only internationally recognized
>> time zone format. Let's not make life harder for Org file parsers.
>
> So offsets and tz database names but no time zone abbreviations?
>
> That seems reasonable since there isn't a sane way to handle the
> timezone with dst vs abbreviation for an offset, so better to force
> only US/Central aka America/Chicago and then -06:00 and -05:00
> if users want CST/CDT to avoid any ambiguity?

No. Let's allow anything that can be understood by `encode-time' (or TZ
variable in other words). And also recommend using America/Chicago-like
and direct offsets in the manual. Abbreviations should be supported, but
not advised.

We may also later provide a linter to warn about ambiguous abbreviations
and times.

Basically, there is literally no way we avoid ambiguous timestamps, yet
keeping the required flexibility. No matter what we try. The best we can
do is support everything, recommend more reliable practices in the
manual, and warn about possible problems.

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

[Ihor Radchenko]

Tim Cross <theophilusx@gmail.com> writes:

> If the timestamp only contains the abbreviated name e.g. AEST, then
> there is no automatic way to disambiguate - best we could
> do is issue a warning. The abbreviated TZ name, unlike the full TZ name,
> is really just a shorthand for the time offset from UTC at a specific
> point in time. The full TZ name on the other hand states not only the
> UTC offset, but also the TZ rules (and with things like the IANA TZ
> database, the specific TZ rules in place at the point in time that
> timestamp represents). This is essentially Max's main point - if
> timestamps for the future have the full TZ name, then we can manage
> things like changes in TZ database rules which occur after creation of
> the timestamp or adjusting timestamps (for scheduled tasks) based on
> changes in location etc). This would not be possible with abbreviated TZ
> or just UTC offsets.

Sure. That's what I proposed by

<2023-01-16 Mon 12:00@Australia/Melbourne>

But we may as well allow UTC offsets there

<2023-01-16 Mon 12:00+0200>

whichever users prefer to use in their use case.

Both the variants may be preferred depending on the purpose. The first
is good when we need to conform to local time, including all the
possible changes in TZ rules. The second is good when we, say, want to
schedule something "102000 _actual_ hours from the beginning of the
experiment; don't care about what government may decide about
winter/summer time in future"

> So I guess the timestamp format and the code which manages them will
> need the ability to use the full TZ name and not just the abbreviated
> form (and I guess an option to allow the user to select). In fact, we
> probably need a way to select between abbreviated/full dynamically as
> well as you might use the different TZ types as a way to flag which
> timestamps you want to adjust due to TZ changes (either in TZ db or in
> user location) and those you don't want changed.

Sure. We should get it for free because both GMT+8 and Asia/Singapore
are the valid TZ values. Both supported by Emacs' `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: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Jean Louis]

* Tim Cross <theophilusx@gmail.com> [2023-01-14 23:25]:
> Yes, this is a problem. We really want a symbolic TZ
> specification and we would need 'smarts' i the timestamp generation code
> that is able to handle potential offset changes due to daylight savings
> transition etc. Even then, the transition time can change between when
> the timestamp is set for and when it actually occurs.

As PostgreSQL type TIMESTAMP WITH TIME ZONE is stored with underlying
UTC time, so should be Org times also be calculated with underlying
UTC times.

And in that case I just assume that operating system libraries ar
handling problem you have stated.

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

[Max Nikulin]

On 16/01/2023 02:14, Jean Louis wrote:
> 
> As PostgreSQL type TIMESTAMP WITH TIME ZONE is stored with underlying
> UTC time, so should be Org times also be calculated with underlying
> UTC times.

Org currently can properly handle the following case:

Let's assume that current date is 2022-07-01. A user living in Mexico 
City schedules a local event at 2023-07-01 16:00 (local time, 
America/Mexico_City time zone). That day the region had DST active, so
current time at the moment of appointment creation has the form 
2022-07-01 16:00:00 CDT -0500.

Since that date it was decided to cancel DST transitions, so currently 
(2023-01-16) planned event time is not CDT -0500 but

TZ=America/Mexico_City date -d '2023-07-01 16:00' '+%F %T %Z %z'
2023-07-01 16:00:00 CST -0600

Agenda in Org has no problem as soon as tzdata is up to date.

As a PosgreSQL expert, could you, please, explain how to handle it in 
Postgres?

1. Downgrade tzdata to 2022e version or older, restart Postgres
2. Create a suitable table
3. Store "2023-07-01 16:00" America/Mexico_City timestamp using column 
types you find appropriate for such case
4. Update tzdata to 2022f version or newer, restart Postgres
5. Check that the event is still scheduled at 16:00 in Mexico City

I am interested in the table schema, insert and select commands.

To check timezone data you may use

     zdump  -v America/Mexico_City

Feel free to take another example of tzdata change instead of
https://github.com/eggert/tz/commit/2050724fa1144bacb0d35c7cd9b862da858406c4
that I found it in /usr/share/doc/tzdata/changelog.Debian.gz

I do not want a regression in Org due to a feature that is intended to 
improve timestamp handling. I see the point in the Postgres wiki 
recommendations, but I see their limitations as well. I do not feel that 
time offset and absence of DST can be considered as a settled state for 
the timezone I live in.

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

[Jean Louis]

* Max Nikulin <manikulin@gmail.com> [2023-01-14 19:59]:
> On 14/01/2023 20:08, Jean Louis wrote:
> > * Max Nikulin [2023-01-14 10:14]:
> > > Let's assume <2023-01-15 Sun 09:00 +1>
> > > 
> > > It may be suitable for timestamps in the past, but future is more tricky.
> > > There is no problem if you are going to watch Lunar eclipse. However if your
> > > plan is to attend a local event there is a chance that you will arrive at
> > > wrong time. Sometimes offset of timezones is changed and it may happen
> > > between the moment when you added a scheduled time and the moment of the
> > > event.
> > 
> > Can't follow you.
> > 
> > with "+1" I would say it is time zone.
> > 
> > Basic point is that users shall learn to express themselves by using
> > time zone.
> 
> "+1" is not a timezone, it is current offset shared by several timezones.
> You can not assure that time offset at a particular location would not
> change due to new administrative rules.

Fine, that was example to indicat time zone. I don't really use Org
for timestamps since quite some time, as every time stamp on my side
must be stored in database.

My Org usage is with generated read-only buffers these days. It is
good for representation and sometimes conversion to other files.

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

[Samuel Wales]

sounds complex.  but if timestamp syntax is to be changed, my personal
"like a broken record" view is that possibly extensible syntax could
be used, depending on the number of places ts parsing is done
currently.

i.e. on whether current ts parsing is intermingled in core org code
with ts semantics and scattered all over org.  although, i suspect a
lot o that woul dneed changing if you wanted to iplement tz anyway.

org has kept deveoping new syntax; es was designed to stop that being
necessary.  i prefer less proliferation.  es allows a maximal amount
of flexibility using the same code for handling every aspect of it.
it is sexp data.

thus if favorable and tz is still desirable perhaps those who want to
use timezones would use es for tses, and a :tz keyword.  if desired
the org buffer can look like today's tses with whatever tz cookie
syntax you want.  it would not need any parsing.  it would be
analogous to links not showing their brackets/url.  the cookie would
be for presentation only so need only be a line or two of code.

still, adding tz semantics to all of org's features and packages and
personal code for those who want it sounds complex.


On 1/13/23, Daryl Manning <daryl@wakatara.com> wrote:
> Following on from thread at
> https://www.reddit.com/r/orgmode/comments/zrppqw/
>
> [First off, I just wanted to say thank you to everyone that works on
> org-mode. It is a wonder.]
>
> While I realize a few kicks at this can may have been taken, I wanted to
> (re-)propose Timezone support in org-mode. The world is much less local
> these days and we're all more remote and coordinating globally these days.
>
> *Background*
>
> 1. org-time-stamp-formats TZ currently only affects display and exports
> 2. org-agenda itself is not TZ aware
> 3. Several discussions on this have taken place over time
> 4. Concerns raise included breaking backwards compatibility
>
> *Proposal*
>
> 1. org-mode sets an optional variable (org-timezone-aware t) which enables
> TZ
> 2. org-agenda needs a way to determine which timezone it is in
> 3. Once enabled, any timestamp not exhibiting a TZ in it is considered
> "local time" wherever that is (I do not think UTC would work for this)
> 4. org-agenda can calc local based on TZ differences
>
> I understand this is by no means trivial and quite gnarly with DST and such
> to figure out but I do believe libs exists to deal with that heavy lifting.
> Currently, it does feel like a hole in org-mode as a 21st century organizer
> (disclaimer: digital nomading so might feel it more keenly). Also, just
> interested in making org-mode a more awesome tool for everybody.
>
> I'd love an understanding of the alluded to reservations raised in the
> reddit thread and in the mailing list threads mentioned that the format
> change might break things (I was unsure if that was referring to say, how
> time ranges were handled, or how say date ranges got dealt with (for
> example, say a flight from Singapore to Vancouver which takes off in one
> time zone and lands in another - something that is often in my cal.).
>
> thanks!
> Daryl.
>


-- 
The Kafka Pandemic

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

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

[Tom Gillespie]

Without wading too far into this at the moment,
timezones are an extremely tricky problem with
a whole bunch of design considerations. I am
reproducing the heading comment from laundry's
timestamp.rkt in its entirety here. Best!
Tom

https://github.com/tgbugs/laundry/blob/master/laundry/grammar/timestamp.rkt

; the org spec is currently silent on how org will handle dates beyond
; 0000 and 9999, the relevant standards for expanded representations
; are ISO 8601-1:2019,5.2.2.3 and ISO 8601-2:2019,8.4.3. The problem
; with expanded representations is that they require all parties to
; agree ahead of time how wide the year is and prefix with + and
; leading zeros, I am not sure that this is as robust as we would like
; 0000-01-01 is january first of the year zero, -0001-01-01 is jan
; first of the year 1BCE, and +10000-01-01 for jan 1 of 10000CE 5
; digits must be prefixed by the plus sign, the standard is not
; entirely clear, but I think that we could do PLUS digits HYPHEN
; or DIGIT-4 HYPHEN and everything would work out

; on a separate but related note, org timestamps are always in local
; time and do not currently support timezones, which is a problem

; further absurdities that are related to the timezone issue: the
; date/time implementation as a text format completely fails if
; authoring on another planet

; given my objective to ensure that org documents can be interpreted
; without having to stick stupid things like #+planet: mars in the
; header or risk your earthling readers getting incorrect dates --- I
; suggest that org switch to storing all dates and times in earth zulu
; time or with an offset as it stands, the timezone setting of the
; computer drafting the document must be known to determine what day
; it was etc. users could still draft using <2020-12-16> but C-c C-c
; would add the correct offset? actually this is tricky, because there
; are two cases, one where the location is clear, "napoleon on [1812-01-01]"
; and the other where it is not, the issue is that a single date refers
; to as many different time intervals as there are timezones and without
; knowing the timezone you don't know the date, similar issue if we were
; to try to convert to sols
; https://www.eecis.udel.edu/~mills/missions.html
; https://www.eecis.udel.edu/~mills/ipin.html
; https://en.wikipedia.org/wiki/Timekeeping_on_Mars
; HOWEVER having applied a bit more brain power to the problem, let's
; just assume that clock synchonization will happen between earth and
; mars so that the unix epoch could be synchronized between the frames
; probably with multiple reference stations in free fall and/or in deep
; space to account for gravitaitonal differences etc. so actually the
; only issue would be a practical notational one, or a UI one, since we
; can use timestamp with timezone or just straight epoc for this to work
; earth vs martian year/day is a much harder issue
; the org spec is currently silent on how org will handle dates beyond

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

[tomas]

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

On Sat, Jan 14, 2023 at 12:51:31AM -0500, Tom Gillespie wrote:
> Without wading too far into this at the moment,
> timezones are an extremely tricky problem with
> a whole bunch of design considerations. I am
> reproducing the heading comment from laundry's
> timestamp.rkt in its entirety here. Best!
> Tom
> 
> https://github.com/tgbugs/laundry/blob/master/laundry/grammar/timestamp.rkt

[...]

> ; are two cases, one where the location is clear, "napoleon on [1812-01-01]"
> ; and the other where it is not, the issue is that a single date refers

Where location also includes time, sometimes (think DSTs). IMO, a timezone
is nice for added context, but meaningless without a concrete offset wrt
some agreed upon base (UTC, here on Earth, for example). Unless you use
clearly different shorthands (e.g. CST for Central Standard Time [1]
and CDT for Central Daylight Time).

The nice cherry on top of that is that this context info is sometimes
relevant and sometimes not. A regular appointment ("brush teeth") may
want to be seen relative to the current time zone (so it "moves" when
I travel from Berlin to New York), another ("Jitsi meeting with my
colleagues in Delhi, Dar-Es-Salam and Denpasar") might not.

I warmly recommend the Wikipedia page [2] on that topic.

An interesting problem :)

Cheers

[1] Eh. Nevermind that it also can mean Cuba Standard Time or China
   Standard Time.
[2] https://en.wikipedia.org/wiki/Time_zone

-- 
t

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

Org mode timestamps on the Moon ;] (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Tom Gillespie <tgbugs@gmail.com> writes:

> ; given my objective to ensure that org documents can be interpreted
> ; without having to stick stupid things like #+planet: mars in the
> ; header or risk your earthling readers getting incorrect dates --- I
> ; suggest that org switch to storing all dates and times in earth zulu
> ; time ...

https://www.nature.com/articles/d41586-023-00185-z

"The coming decade will see a resurgence in lunar exploration —
including dozens of missions and plans to establish permanent bases on
the Moon. The endeavours pose myriad challenges. Among them is a subtle,
but fundamental, question that metrologists worldwide are working to
answer: what time is it on the Moon?"

...

"It’s not obvious what form a universal lunar time would take. Clocks on
Earth and the Moon naturally tick at different speeds, because of the
differing gravitational fields of the two bodies"

...

"Decisions must be made soon,... If an official lunar time is not
established, space agencies and private companies will come up with
their own solutions" (and Org too?)

...

"Moon missions will also need an official lunar time to cooperate and
communicate, says Hahn. “All this has to trace to one kind of a time
reference, otherwise you have chaos and things do not work together.”"

...

"The Moon’s gravitational pull is weaker than Earth’s, meaning that, to
an observer on Earth, a lunar clock would run faster than an Earth one.
Gramling estimates that a lunar clock would gain about 56 microseconds
over 24 hours" (how will it affect Org's timestamps? should we do
anything about it?)

"...a clock’s speed would also subtly change depending on its position
on the lunar surface, because of the Moon’s rotation" (oh, dear...)

...

“The idea is to produce a Solar System internet,” says Gramling. “And
the first part would be at the Moon.” 

-- 
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: Org mode timestamps on the Moon ;]

[Fraga, Eric]

On Thursday, 26 Jan 2023 at 15:24, Ihor Radchenko wrote:
> "The Moon’s gravitational pull is weaker than Earth’s, meaning that, to
> an observer on Earth, a lunar clock would run faster than an Earth one.
> Gramling estimates that a lunar clock would gain about 56 microseconds
> over 24 hours" (how will it affect Org's timestamps? should we do
> anything about it?)

Well, it would take a little over 120 years for this difference to affect an org time stamp (given resolution to the minute as used by org)...

I love what I'm learning about time zones etc. in this discussion thread!

-- 
: Eric S Fraga, with org release_9.6.1-199-g7ad779 in Emacs 30.0.50

Re: Org mode timestamps on the Moon ;]

[Thomas S. Dye]

Aloha Eric,

"Fraga, Eric" <e.fraga@ucl.ac.uk> writes:

> On Thursday, 26 Jan 2023 at 15:24, Ihor Radchenko wrote:
>> "The Moon’s gravitational pull is weaker than Earth’s, meaning 
>> that, to
>> an observer on Earth, a lunar clock would run faster than an 
>> Earth one.
>> Gramling estimates that a lunar clock would gain about 56 
>> microseconds
>> over 24 hours" (how will it affect Org's timestamps? should we 
>> do
>> anything about it?)
>
> Well, it would take a little over 120 years for this difference 
> to affect an org time stamp (given resolution to the minute as 
> used by org)...
>
> I love what I'm learning about time zones etc. in this 
> discussion thread!

Then I can recommend Carlo Rovelli's The Order of Time.

All the best,
Tom

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

Re: Org mode timestamps on the Moon ;] (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Tom Gillespie]

Oh boy. In short, I think we can only hope they come up with
LTC and we already have a syntactic space to say whether
our reference seconds are TAI/UTC/LTC/MTC/JTC etc. And
being the privileged squats that we are if the time system is
left out then it means UTC. The friendly thing to do would be
to always include the time system code in our timestamps,
but I don't think those have standard reference codes yet?

> would gain about 56 microseconds over 24 hours

And here I was naively hoping to avoid having to deal with
relativistic effects. That would seem to be a pretty serious
issue, but my assumption further down that comment is
hopefully what they will do. Specifically:

> let's just assume that clock synchonization will happen between earth and
> mars so that the unix epoch could be synchronized between the frames

The only generalized solution is to record the full location
(see intro to http://naggum.no/lugm-time.html which I'm surprised
hasn't been linked in this thread yet, but was linked on the same
topic back in 2011 it seems) and let people sort out how to translate
that local time from that reference frame in that particular gravity well.

I don't think we want to force users to start embedding their gps
coordinates, their current acceleration, etc. along with their
timestamp. But it turns out that the unix epoch is only standard
at 9.8m/s^2. So ... minutes should be ok right?

Joking aside. Clocks run faster on the moon, slower on the ISS,
so either clocks are synchronized back to earth seconds, or
they use some alternate standard reference time.

My expectation is that there will be some time keeping standard
that will ensure uniformity and that what we will want to capture
is whose seconds they are using to keep track of time, because
unix epoch on the moon has a different integer value than on
earth, and is likely off by multiple seconds.

I guess as long as the moon can participate in earth NTP it will
be ok? Otherwise I suspect that the NTP network standard for
the celestial body will be what we want to go with/record. I think
that will fit in the opening you have created for this in the syntax.

So instead of UTC it would be LTC (lunar coordinated time).
If you're getting logs from servers on the moon knowing that the
system clock was running on LTC and not UTC will be critical.

Some future engineer: "Leaving earth was a mistake."

Re: Org mode timestamps on the Moon ; ] (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Greg Minshall]

Tom,

> The only generalized solution is to record the full location (see
> intro to http://naggum.no/lugm-time.html which I'm surprised hasn't
> been linked in this thread yet, ...

very nice -- thanks for the pointer!

cheers, Greg

Re: Org mode timestamps on the Moon ;] (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Tom Gillespie <tgbugs@gmail.com> writes:

> Oh boy. In short, I think we can only hope they come up with
> LTC and we already have a syntactic space to say whether
> our reference seconds are TAI/UTC/LTC/MTC/JTC etc. And
> being the privileged squats that we are if the time system is
> left out then it means UTC. The friendly thing to do would be
> to always include the time system code in our timestamps,
> but I don't think those have standard reference codes yet?

I cannot see anything in
https://en.wikipedia.org/wiki/List_of_tz_database_time_zones

So, just UTC. If we want to support more, it will have to be done
manually. 

> I don't think we want to force users to start embedding their gps
> coordinates, their current acceleration, etc. along with their
> timestamp. But it turns out that the unix epoch is only standard
> at 9.8m/s^2. So ... minutes should be ok right?

> Joking aside. Clocks run faster on the moon, slower on the ISS,
> so either clocks are synchronized back to earth seconds, or
> they use some alternate standard reference time.

I am afraid that calculating "real" time inside a given reference system
is impossible now. Time from epoch in Greenwich when you are looking
from inside Greenwich and time from epoch in Greenwich when you are
looking from inside ISS are two different time intervals. And what about
time from epoch in ISS when looking from Greenwich?

And then we also synchronize time with UTC now. But time since epoch in
UTC when looking from UTC and time from epoch in UTC when looking from
different elevation are different times :)

Further, what does it mean to have a meeting scheduled for
<2023-01-30 Mon 14:00 @Europe/Berlin>--<2023-01-30 Mon 20:00 @Asia/Singapore>
What is the reference frame? Europe/Berlin gravitation well?
Asia/Singapore well? Local well?

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

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