Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode)

[Tim Cross]

"Thomas S. Dye"  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)

[Thomas S. Dye]

Aloha Max,

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

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)

[Jean Louis]

* Max Nikulin  [2023-01-24 20:12]:
> On 22/01/2023 14:48, Tim Cross wrote:
> > Timestamp for a log
> > record I would probably want  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)

[Jean Louis]

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

[Tim Cross]

Max Nikulin  writes:

> On 22/01/2023 14:48, Tim Cross wrote:
>> Timestamp for a log
>> record I would probably want  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: 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  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)

[Thomas S. Dye]

Aloha Ihor,

Ihor Radchenko  writes:


"Thomas S. Dye"  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:


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

±hh:mm
±hhmm
±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)

[Ihor Radchenko]

"Thomas S. Dye"  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:

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

±hh:mm
±hhmm
±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 .
Support Org development at ,
or support my work at 

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)

[Thomas S. Dye]

Aloha Max,

Max Nikulin  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 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 Jean Louis,
Jean Louis  writes:


* Thomas S. Dye  [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)

[Jean Louis]

* Thomas S. Dye  [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 Max,

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

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)

[Tim Cross]

Max Nikulin  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  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@+]. 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 

Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode)

[Thomas S. Dye]

Aloha Max,

Max Nikulin  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@+]. 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]

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