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

Dear Heinz,

Thanks, let me see.

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

Yes, that is good our mutual understanding.

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

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

Before representing time with the UTC offset:
-

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

After representing time with the UTC offset:


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

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

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

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

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

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

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

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

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

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

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

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

We can say it is approximate what they mean.

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

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

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

-- 
Jean

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

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

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

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

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

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

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

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

My intention is of course not what you stated. 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- While Chinese user was in restaurant at 16 o'clock and waiting for
  appointment at 17 o'clock, because he

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

2023-01-30 Thread Thomas S. Dye


Aloha Jean Louis,

Jean Louis  writes:


Dear Thomas,

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


To solve problem it is important to first define it. And when 
there
are developers reading it, I wish to provide best possible 
references

for the sake of people using Org mode.

So let me gently try explaining it with different words.


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

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

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

2023-01-30 Thread Tim Cross

Jean Louis  writes:

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

Jean,

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

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

I will not be engaging with you further.

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

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

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

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

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

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

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

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

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

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

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

I do believe that Org developers will make right decisions.

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

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

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

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

Excercise:

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

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

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

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

What do you think, is that information true?

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

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

Or programmer needs to know information about time zones?

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

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

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

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

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

-- 
Jean

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

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

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

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

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

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

2023-01-30 Thread 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

2023-01-30 Thread Ihor Radchenko

Greg Minshall  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 .
Support Org development at ,
or support my work at

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

2023-01-30 Thread 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

2023-01-30 Thread Ihor Radchenko

Sterling Hooten  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 .
Support Org development at ,
or support my work at

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

2023-01-30 Thread Ihor Radchenko

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

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

2023-01-30 Thread 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

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

2023-01-29 Thread Tim Cross

Jean Louis  writes:

> * Tim Cross  [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

2023-01-29 Thread Ihor Radchenko

Daryl Manning  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 .
Support Org development at ,
or support my work at

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

2023-01-28 Thread Daryl Manning

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

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

2023-01-28 Thread Thomas S. Dye




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

2023-01-28 Thread 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

2023-01-28 Thread Jean Louis

* Tim Cross  [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 +1 being the same
> as AEST and both being abbreviations for Australia/Sydney outside of
> daylight savings periods. I

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

2023-01-27 Thread Max Nikulin

Sterling, thank you very much for the list of references. I was not
aware of EDTF activity or the proposal for JavaScript.

I do not mind to have better precision for timestamps. Minutes are too
coarse. However I would consider with low priority.

I would prefer to postpone some discussions now. At the current moment
just be aware than one more person may have another opinion. Redundant
fields are useful for humans, in addition, they allow to detect
inconsistency. Date and time format with spaces are more friendly to
humans as well. "T" hampers readability. So I feel some kind of internal
conflict trying to achieve following standards, backward compatibility,
and human readability simultaneously. I am unsure what is the proper
solution.

The following is what I consider as more serious issues:

On 27/01/2023 13:06, Sterling Hooten wrote:

Duration (object)
as a quantity characterizing a time interval. These can be
written in different formats.

Interval, duration, elapsed time are tricky. I do not have preferences
whose definitions we should follow. Just an example: (info "(libc) Time
Basics") https://www.gnu.org/software/libc/manual/html_node/Time-Basics.html

Notice that 1 day does not necessary means 24 hours. Depending on
starting day (e.g. before DST) other relations may be used, either 23 or
25 hours (usually). It is still 1 day. The way to specify interval
should be chosen depending on application.

Another case is January, 31 + 1 month. It actually may mean last day of
January, so expected result may be February, 28 or 29. This case
February, 28 + 1 month (the same interval) is March, 31.

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.

"System time" is often used in the sense of hardware clock and
originated from the times when DOS or Windows required local time.

Time Zone
A place/region.

Do you consider e.g. Etc/GMT-8 or UTC itself as a time zone?

Floating time
A wall time value without time zone or offset information. E.g.,
2023-01-24 or 6:45pm.

A potential source of confusion with timestamp in seconds since epoch as
a floating point number, see `float-time'. (info "(elisp) Time of Day")
https://www.gnu.org/software/emacs/manual/html_node/elisp/Time-of-Day.html#index-float_002dtime

Org must first support
fixed/absolute time instead of just floating time.

Am I wright "in addition" is applicable here in the place of "instead"?

• Design and implement the time zone aware calendar system This is a
separate project.

Will not such decision ruin "every Wednesday at 3:00 PM" at the moment
of DST transition? I would vote that IANA DB should be used for
calculations despite I have not seen a library with perfect API. Though
libc with some tricks may allow to do most of tasks. (Even in presence
of limitations such as unavailable identifier of system time zone.) This
is the main point of my disagreement. If real time zones are not
implemented from the beginning then the will be never supported, so the
whole bunch of code will be requiring throwing away while keeping
support of some formats to read old files.

• We are able to defer to experts and 35 years of knowledge rather
than debate among ourselves

Experts may generate enough pain such as requirement to not support IANA
timezone DB as it was in EcmaScript 5 (Chrome followed it, but in
Firefox conversion between local time worked correctly).

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

2023-01-27 Thread Tim Cross

Jean Louis  writes:

> * Sterling Hooten  [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 +1 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

2023-01-27 Thread Tim Cross

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

2023-01-27 Thread Jean Louis

* Sterling Hooten  [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

2023-01-27 Thread Jean Louis

* Sterling Hooten  [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

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

2023-01-27 Thread Ihor Radchenko

Sterling Hooten  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 .
Support Org development at ,
or support my work at

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

2023-01-27 Thread Sterling Hooten

Thanks for the quick feedback!

> On 2023-01-27, at 08:09, Ihor Radchenko  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

2023-01-27 Thread 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  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 .
Support Org development at ,
or support my work at

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

2023-01-26 Thread Daryl Manning

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

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

2023-01-26 Thread 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., [-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

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

2023-01-22 Thread Thomas S. Dye


Aloha Max,

Max Nikulin  writes:


On 21/01/2023 22:55, Thomas S. Dye wrote:

Aloha Max,

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

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

2023-01-22 Thread 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

2023-01-22 Thread Max Nikulin


On 21/01/2023 22:55, Thomas S. Dye wrote:

Aloha Max,

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

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

2023-01-22 Thread Ihor Radchenko

Max Nikulin  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 .
Support Org development at ,
or support my work at

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

2023-01-21 Thread Tim Cross

Max Nikulin  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: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

2023-01-21 Thread Thomas S. Dye

Aloha Jean Louis,

Jean Louis  writes:

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

2023-01-21 Thread Thomas S. Dye


Aloha Jean Louis,

Jean Louis  writes:


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

2023-01-21 Thread Thomas S. Dye


Aloha Max,

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

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

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

* Alexander Adolf  [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

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

2023-01-21 Thread Ihor Radchenko

Jean Louis  writes:

> * Ihor Radchenko  [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 .
Support Org development at ,
or support my work at

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

* Ihor Radchenko  [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

2023-01-21 Thread 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

2023-01-21 Thread Ihor Radchenko

"Fraga, Eric"  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 .
Support Org development at ,
or support my work at

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


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


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

2023-01-20 Thread Thomas S. Dye


Aloha Tim,

Tim Cross  writes:


"Thomas S. Dye"  writes:


Aloha Max,

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

"Thomas S. Dye"  writes:

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

Max Nikulin  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  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  OR > and for meetings where there are participants from
different time zones, use . 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

Daryl Manning  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  wrote:
>
>  Ihor Radchenko  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 .
>  Support Org development at ,
>  or support my work at 

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

2023-01-20 Thread Thomas S. Dye


Aloha Max,

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


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

2023-01-20 Thread Thomas S. Dye


Aloha Max,

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


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


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

2023-01-20 Thread Daryl Manning

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

> Daryl Manning  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 .
> Support Org development at ,
> or support my work at 
>

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

2023-01-20 Thread Alexander Adolf

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

"Fraga, Eric"  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 .
Support Org development at ,
or support my work at

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

2023-01-20 Thread 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

Daryl Manning  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 .
Support Org development at ,
or support my work at

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

2023-01-20 Thread Daryl Manning

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

> Ihor Radchenko  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 .
> Support Org development at ,
> or support my work at 
>

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

Ihor Radchenko  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 .
Support Org development at ,
or support my work at

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

Tim Cross  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 .
Support Org development at ,
or support my work at

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

2023-01-20 Thread 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

"Thomas S. Dye"  writes:

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

2023-01-19 Thread 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


Aloha Max,

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


Aloha Tim,

Tim Cross  writes:


"Thomas S. Dye"  writes:


Aloha Tim,

Tim Cross  writes:


"Thomas S. Dye"  writes:


Aloha Tim,


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


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

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

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

2023-01-19 Thread 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

"Thomas S. Dye"  writes:

> Aloha Tim,
>
> Tim Cross  writes:
>
>> "Thomas S. Dye"  writes:
>>
>>> Aloha Tim,
>>>
 UTC is a time zone - just one where offset is +
>>>
>>> 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


Aloha Tim,

Tim Cross  writes:


"Thomas S. Dye"  writes:


Aloha Tim,


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


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

"Thomas S. Dye"  writes:

> Aloha Tim,
>
>> UTC is a time zone - just one where offset is +
>
> 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


Aloha Tim,


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


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

Jean Louis  writes:

> * Tim Cross  [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.

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

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

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

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

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

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

2023-01-19 Thread Robert Horn



Ihor Radchenko  writes:

> Robert Horn  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, "+1 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
rjhorn...@gmail.com

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


Aloha Jean Louis,

Jean Louis  writes:


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

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

2023-01-19 Thread Jean Louis

* Tim Cross  [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=16358

> 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

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

2023-01-19 Thread Jean Louis

* Ihor Radchenko  [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

2023-01-19 Thread Jean Louis

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

2023-01-19 Thread Ihor Radchenko

Jean Louis  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 .
Support Org development at ,
or support my work at

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

2023-01-19 Thread Ihor Radchenko

Tim Cross  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 .
Support Org development at ,
or support my work at

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

2023-01-19 Thread Ihor Radchenko

Tim Cross  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 .
Support Org development at ,
or support my work at

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

2023-01-18 Thread Tim Cross

Jean Louis  writes:

> * Tim Cross  [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

2023-01-18 Thread Thomas S. Dye


Aloha all,

Jean Louis  writes:


* Tim Cross  [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

* Tim Cross  [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

2023-01-18 Thread Tim Cross

Ihor Radchenko  writes:

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

2023-01-18 Thread Tim Cross

Ihor Radchenko  writes:

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

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

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  [2023-01-18 13:01]:
> Max Nikulin  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/

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