[BUG] Emacs-29.0.60: (setopt org-babel-load-languages ...) may cause warnings

[gerard . vermeulen]

Hi,

I have been replacing to calls to =custom-set-variables= with calls to 
the safer

=setopt= (new in Emacs-29.0.60) and I discovered that calling
src_emacs-lisp{(setopt org-babel-load-languages '((eshell t) (emacs-lisp 
t)))}
raises a warning because =eshell= is missing from the 
=org-babel-load-languages=
=defcustom=.  The code below shows that this =defcustom= is quit out of 
sync with

the rest of the code base:

#+header: :wrap "src emacs-lisp :results silent :tangle no"
#+begin_src emacs-lisp :exports both :results value pp :exports both
(defun all-org-babel-execute-fns ()
  "Find `ob-LANGUAGE' files in Org defining 
`org-babel-execute:LANGUAGE'.


Return a list of items where the filename is the `car' of each item and 
the

`cdr' of each item lists the `org-babel-execute:LANGUAGE' functions."
  (let* ((dir (file-name-parent-directory (locate-library "org")))
 (names (directory-files dir t (rx "ob-" (+ print)  ".el" 
eos

(cl-loop for name in names
 for found = (has-org-babel-execute-fn name)
 when found collect found)))

(defun has-org-babel-execute-fn (name)
  (let* ((buffer (find-file-noselect name))
 (base (file-name-base (buffer-file-name buffer)))
 (regexp (rx "defun" (+ blank) "org-babel-execute:" (group (+ 
graphic

 (matches))
(save-match-data
  (save-excursion
(with-current-buffer buffer
  (save-restriction
(widen)
(goto-char 1)
(while (re-search-forward regexp nil t 1)
  (push (match-string-no-properties 1) matches))
(when matches
  `(,base ,@matches

(all-org-babel-execute-fns)
#+end_src

#+RESULTS:
#+begin_src emacs-lisp :results silent :tangle no
(("ob-C" "C" "D" "C++" "cpp")
 ("ob-R" "R")
 ("ob-awk" "awk")
 ("ob-calc" "calc")
 ("ob-clojure" "clojurescript" "clojure")
 ("ob-css" "css")
 ("ob-ditaa" "ditaa")
 ("ob-dot" "dot")
 ("ob-emacs-lisp" "emacs-lisp")
 ("ob-eshell" "eshell")
 ("ob-forth" "forth")
 ("ob-fortran" "fortran")
 ("ob-gnuplot" "gnuplot")
 ("ob-groovy" "groovy")
 ("ob-haskell" "haskell")
 ("ob-java" "java")
 ("ob-js" "js")
 ("ob-julia" "julia")
 ("ob-latex" "latex")
 ("ob-lilypond" "lilypond")
 ("ob-lisp" "lisp")
 ("ob-lua" "lua")
 ("ob-makefile" "makefile")
 ("ob-maxima" "maxima")
 ("ob-ocaml" "ocaml")
 ("ob-octave" "octave" "matlab")
 ("ob-org" "org")
 ("ob-perl" "perl")
 ("ob-plantuml" "plantuml")
 ("ob-processing" "processing")
 ("ob-python" "python")
 ("ob-ruby" "ruby")
 ("ob-sass" "sass")
 ("ob-scheme" "scheme")
 ("ob-screen" "screen")
 ("ob-sed" "sed")
 ("ob-shell" "shell")
 ("ob-sql" "sql")
 ("ob-sqlite" "sqlite"))
#+end_src

The attached patch synchronizes the =defcustom= with the rest of the
code base, groups languages by org-babel file, and uses camel-case to
spell languages (the new fashion).

Best regards -- Gerard


fix-org-babel-load-languages.patch
Description: Binary data

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

[Jean Louis]

Dear Heinz,

Thanks, let me see.

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

Yes, that is good our mutual understanding.

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

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

Before representing time with the UTC offset:
-

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

After representing time with the UTC offset:


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

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

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

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

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

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

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

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

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

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

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

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

We can say it is approximate what they mean.

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

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

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

-- 
Jean

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

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

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

[Jean Louis]

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

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

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

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

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

My intention is of course not what you stated. 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: Firefox permission dialog and org-protocol

[Samuel Wales]

unable to follow this but it sounds like a big deal and i am glad that
you are looking into it.  thanks.

[my use case fwiw:
1] it is disruptive for me having org-capture not work [i do not alwys use kb].
2] x-wide capture using emacsclient would presumably not contain the
page title in firefox.
3] if automatic reliable confirmation if possible results as a side
effect of this work, great.
4] oh do i ever want advanced spookfox!
please ignore all of this just want to say thanks.]


On 1/29/23, Max Nikulin  wrote:
> On 29/01/2023 20:50, Ihor Radchenko wrote:
>> Max Nikulin writes:
>>> On 26/01/2023 01:01, Ihor Radchenko wrote:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1678994
>>>
>>> Bug 1678994 "website permission to open special links in external
>>> applications not configurable"
> ...
>> It appears to be a newer version of Firefox.
>> I originally got to know about the problem from
>> https://old.reddit.com/r/emacs/comments/10jr2up/orgprotocol_permissions_on_firefox/
>
> Likely the person uses a bookmarklet to initiate capture. This case
> JavaScript snippet is executed in the context of the current web site,
> so it is necessary to confirm permission for each site. I would
> recommend to install an add-on for org-protocol instead. It would be
> enough to confirm once that *this extension* is allowed to launch
> external application through a custom scheme URI.
>
> An additional advantage is that if some site were had a malicious
> org-protocol link hidden by some attractive description then browser
> would ask user even if some pages on the same site were captured earlier.
>
> I faced a similar issue 3 years ago when "always allow" checkbox just
> disappeared from chromium popup.
>
> The popup with permission request appeared because some version of zoom
> allowed unsolicited video call. They decided that a dialog in the app
> before switching on camera would be annoying to users. Users already
> confirmed their intention in the Safari dialog. So other browser had to
> add this popup as well. The intention is to avoid joining a video call
> accidentally while being naked.
>
> https://infosecwriteups.com/zoom-zero-day-4-million-webcams-maybe-an-rce-just-get-them-to-visit-your-website-ac75c83f4ef5?gi=2ed4ab044837
> Jonathan Leitschuh. Zoom Zero Day: 4+ Million Webcams & maybe an RCE?
> Just get them to visit your website! 2019-07-08
>
> To summarize, I believe that a browser extension is a safer way to use
> org-protocol. With a native messaging helper application it is even
> possible to avoid desktop-wide org-protocol configuration and to call
> emacsclient directly by the add-on but not through links on non-trusted
> web sites.
>
> P.S. Actually launching an application from an add-on is not really
> reliable as well. The following issue has links to some other bugs. Not
> to mention that external scheme URI is a shoot and forget approach with
> hardly possible error detection. (A native host application may check
> emacsclient exit code.)
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1745931
> External scheme handler configured to "Always ask" can not be launched
> from add-on background page.
>
>
>
>
>


-- 
The Kafka Pandemic

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

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

[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: Inline markup: How does org identify nested code/verbatim?

[Tom Gillespie]

In short, you cannot nest code in verbatim or verbatim in code
because they are both terminal (end of the line for nesting).
In fact you can't nest anything inside them by their very nature.

Anything inside of them cannot have special functionality, even
escape codes don't play well in that part of the grammar.

There is no way around this because you cannot nest inside
things that are by definition terminal. However, from your
examples it seems that you can get the effect you are looking
for using ~is~ =verbatim= ~in code~.

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

[Tim Cross]

Jean Louis  writes:

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

Jean,

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

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

I will not be engaging with you further.

Re: org-crypt fails if default key is expired while non-default key is to be used

[Karl Voit]

Hi Ihor,

* Ihor Radchenko  wrote:
> Karl Voit  writes:
>
>>> What is the return value of
>>>
>>> (epg-list-keys (epg-make-context nil t t) org-crypt-key)
>>>
>>> ?
>>>
>>> Does it show the right key?
>>
>> It shows:
>>
>> (#s(epg-key ultimate
>> (#s(epg-sub-key ultimate ... nil 1 4096 "ABC12345" 1515327255 
>> nil "...ABC12345")
>>#s(epg-sub-key ultimate ... nil 1 4096 "FFF" 1515327255 
>> nil "."))
>> (#s(epg-user-id ultimate "Karl Voit (Internal key for orgmode) 
>> " nil
>>
>> ... with ABC12345 being the correct key for org-crypt and FFF being my
>> default OpenPGP key.
>
> Ok. What about
>
> (let ((context (epg-make-context nil t t)))
>   (epg-decrypt-string context (epg-encrypt-string context "test" 
> (epg-list-keys context org-crypt-key
>

It asks me for the passphrase of the orgmode key (the correct one)
and prints out "test".

-- 
get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode:
   > get Memacs from https://github.com/novoid/Memacs <
Personal Information Management > http://Karl-Voit.at/tags/pim/
Emacs-related > http://Karl-Voit.at/tags/emacs/

Re: [POLL] Use compat.el in Org? (was: Useful package? Compat.el)

[Daniel Mendler]

On 1/30/23 20:40, Greg Minshall wrote:
> i see, yes.  i'm just thinking that, for a given release CUR (like i
> know anything about org-mode release procedures!)  we would use whatever
> has been available in compat.el since release CUR-n (for whatever n we
> use -- 2?), and supplement that, in org-compat.el, with whatever other
> compatibility features *we* (org-mode) need to support releases [CUR-n
> .. CUR].
> 
> (and, presumably, contribute whatever might be appropriate from
> org-compat.el to compat.el, so we can prune it out from org-compat.el at
> some future point in time.)

Sounds good. But note that Compat will at some point have sufficient
coverage of the existing APIs, such that Org may not miss anything. From
then on new additions will only be made at the time of a new Emacs
release. The current Compat already supports many Emacs 29 APIs, which
is in time for the upcoming pretest. Compat won't add any APIs which are
still part of the unstable development master branch (before the branch
cut and feature freeze), which reduces the need for coordination.

If you are missing something right now, and want to introduce and use a
new backported function, e.g., something new from Emacs 29, instead of
going via the org-compat indirection, you could also make an addition
directly to Compat, a Compat release can be prepared a short while
after, and then you start using the new function in the Org development
version.

Daniel

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

[Jean Louis]

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

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

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

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

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

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

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

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

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

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

I do believe that Org developers will make right decisions.

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

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

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

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

Excercise:

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

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

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

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

What do you think, is that information true?

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

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

Or programmer needs to know information about time zones?

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

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

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

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

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

-- 
Jean

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

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

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

[Jean Louis]

* 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

[Jean Louis]

Dear Thomas,

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

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

So let me gently try explaining it with different words.

> UTC offset exists without time zone.

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

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

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

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

> UTC is absolute time

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

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

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

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

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

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

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

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

Look at this nice map with time zones and UTC offsets:
https://qz.com/wp-content/uploads/2015/03/map.jpg?quality=80=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

[Jean Louis]

* 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: [POLL] Use compat.el in Org? (was: Useful package? Compat.el)

[Greg Minshall]

Ihor,

> >> 1. If compat.el happens to lack support of some function, we will need
> >>to contribute to compat.el directly and synchronize Org releases with
> >>compat.el releases.
> >
> > would a separate "org-compat.el" (in addition to compat.el) somehow
> > solve this?  (i worry about the synch'ing.)
> 
> That's what we already do.
> Using compat.el means that we can remove some of the functions from
> org-compat.el and instead rely on compat.el where the same functions are
> maintained more carefully.

i see, yes.  i'm just thinking that, for a given release CUR (like i
know anything about org-mode release procedures!)  we would use whatever
has been available in compat.el since release CUR-n (for whatever n we
use -- 2?), and supplement that, in org-compat.el, with whatever other
compatibility features *we* (org-mode) need to support releases [CUR-n
.. CUR].

(and, presumably, contribute whatever might be appropriate from
org-compat.el to compat.el, so we can prune it out from org-compat.el at
some future point in time.)

i'm *only* thinking of trying to de-couple org-mode development from
that of compat.el, in the mindset that "less cross-dependencies" ==
"less complication".  if that makes sense.

cheers, Greg

Re: [POLL] Use compat.el in Org? (was: Useful package? Compat.el)

[Ihor Radchenko]

Greg Minshall  writes:

>> 1. If compat.el happens to lack support of some function, we will need
>>to contribute to compat.el directly and synchronize Org releases with
>>compat.el releases.
>
> would a separate "org-compat.el" (in addition to compat.el) somehow
> solve this?  (i worry about the synch'ing.)

That's what we already do.
Using compat.el means that we can remove some of the functions from
org-compat.el and instead rely on compat.el where the same functions are
maintained more carefully.

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

Re: Patch for worg org-tools

[Ihor Radchenko]

Jakob Schöttl  writes:

> I got a patch for
>
> https://orgmode.org/worg/org-tools/index.html
>
> Does someone with access wants to apply it?

Thanks for the patch, but I am unable to apply it.
May you follow https://orgmode.org/worg/org-contribute.html#org045e318 ?

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

Re: diary-anniversary doesn'work om Mac osx 12.6.3

[Ihor Radchenko]

Renato Pontefice  writes:

> * Anniversaries
> %%(diary-anniversary 1948 01 30) Arthur's birthday (%d years old)
>
> %%(diary-anniversary 2023-01-30) Arthur's birthday (%d years old)
>
>  <2023-01-30 Mon 15:53>
> Just this. The last line is made by C-u-c .
> To display the way my date are setted
>
> If I press C a a
> Emacs compose the agenda (as in the attached file, but without the entry of 
> Arthur birthday

I tried the above and can hear error being signalled:

Bad sexp at line 4 in /tmp/bug.org: (let ((entry Arthur's birthday (%d years 
old)) (date '(1 30 2023))) (diary-anniversary 2023-01-30))
Bad sexp at line 4 in /tmp/bug.org: (let ((entry Arthur's birthday (%d years 
old)) (date '(1 31 2023))) (diary-anniversary 2023-01-30))
Bad sexp at line 4 in /tmp/bug.org: (let ((entry Arthur's birthday (%d years 
old)) (date '(2 1 2023))) (diary-anniversary 2023-01-30))
Bad sexp at line 4 in /tmp/bug.org: (let ((entry Arthur's birthday (%d years 
old)) (date '(2 2 2023))) (diary-anniversary 2023-01-30))
Bad sexp at line 4 in /tmp/bug.org: (let ((entry Arthur's birthday (%d years 
old)) (date '(2 3 2023))) (diary-anniversary 2023-01-30))
Bad sexp at line 4 in /tmp/bug.org: (let ((entry Arthur's birthday (%d years 
old)) (date '(2 4 2023))) (diary-anniversary 2023-01-30))
Bad sexp at line 4 in /tmp/bug.org: (let ((entry Arthur's birthday (%d years 
old)) (date '(2 5 2023))) (diary-anniversary 2023-01-30))

Your diary entries have wrong format.

If you do  f diary-anniversary , you will see

(diary-anniversary MONTH DAY  YEAR MARK)

So, the correct entries will be

%%(diary-anniversary 01 30 1948) Arthur's birthday (%d years old)

%%(diary-anniversary 01 30 2023) Arthur's birthday (%d years old)

org-anniversary uses more conventional year-month-day order:

%%(org-anniversary 1948 01 30) Arthur's birthday (%d years old)

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

Re: [BUG] ob-shell doesn't evaluate last line on Windows (cmd/cmdproxy) [9.6.1 ( @ c:/Users/Osher/AppData/Roaming/.emacs.d/elpa/org-9.6.1/)]

[Matt]

Pushed the change to `org-babel-eval'.

Re: [BUG] ob-sql sql-connection-alist

[Daniel Kraus]

Hi!

Andreas Gerler  writes:

> I added the missing changelog entry.

Thanks.
I installed the patch.

(I'll also answer to your dbconnection engine mail soon.
Just very busy atm)

Thanks,
  Daniel

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

[Greg Minshall]

Ihor, makes sense.  that we probably need to *display* imprecision
doesn't mean we need to accept/parse it.

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

[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

[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: diary-anniversary doesn'work om Mac osx 12.6.3

[Gautier Ponsinet]

Hello Renato,

Renato Pontefice  :
> * Anniversaries
> %%(diary-anniversary 1948 01 30) Arthur's birthday (%d years old)
>
> %%(diary-anniversary 2023-01-30) Arthur's birthday (%d years old)
>
>  <2023-01-30 Mon 15:53>
> Just this. The last line is made by C-u-c .
> To display the way my date are setted
>
> If I press C a a
> Emacs compose the agenda (as in the attached file, but without the entry of 
> Arthur birthday

Have you tried 'org-anniversary' instead of 'diary-anniversary'?

All the best,
Gautier.

[BUG] org-manual: Using bookmarklet for org-capture is no longer reliable (was: Firefox permission dialog and org-protocol)

[Ihor Radchenko]

Max Nikulin  writes:

 To summarize, I believe that a browser extension is a safer way to use 
> org-protocol. With a native messaging helper application it is even 
> possible to avoid desktop-wide org-protocol configuration and to call 
> emacsclient directly by the add-on but not through links on non-trusted 
> web sites.

This is bad news.

17.16.2 The ‘capture’ protocol section of Org manual recommends

   To use this feature, add a bookmark with an arbitrary name, e.g.,
‘Org: capture’, and enter this as ‘Location’:

 javascript:location.href='org-protocol://capture?' +
   new URLSearchParams({
 template: 'x', url: window.location.href,
 title: document.title, body: window.getSelection()});

With the annoying Firefox dialogue, things get very annoying.
Even though I do understand the motivation of devs.
But they broke bookmarklets :'(

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

Re: diary-anniversary doesn'work om Mac osx 12.6.3

[Renato Pontefice]

* Anniversaries
%%(diary-anniversary 1948 01 30) Arthur's birthday (%d years old)

%%(diary-anniversary 2023-01-30) Arthur's birthday (%d years old)

 <2023-01-30 Mon 15:53>
Just this. The last line is made by C-u-c .
To display the way my date are setted

If I press C a a
Emacs compose the agenda (as in the attached file, but without the entry of 
Arthur birthday

> Il giorno 30 gen 2023, alle ore 14:46, Ihor Radchenko  
> ha scritto:
> 
> Renato Pontefice  writes:
> 
>> I try to perform this simple line of emacs manual (this is the perfect page 
>> of the manual where I took this: where I took this: "31.13.10 Sexp Entries 
>> and the Fancy Diary Display”). Because trying to learn emacs I would try as 
>> many entry possibile as I could (I know I can obtain that in a different 
>> way).
>> 
>> But on my Mac OS X platform I cannot obtain the right result.
>> I’ve tried with:
>> - emacs ver 26.2; 28.3; 28.3 (via terminal “emacs -Q” and via GUI With or 
>> without a init.el file
> 
>> ... And finally, I’ve installed a VM, running Debian 11 and try it running 
>> emacs by terminal and typing ORG-AGENDA ret a
>> I obtain the agenda with the correct entry.
>> 
>> So I’m wondering:
>> Maybe Mac osx does not contain the right (elisp?) code to obtain that?
> 
> Could you please detail what exactly you tried? How did you use
> diary-anniversary? What did you put into diary file? Or did you use
> diary sexp style timestamp? Did you enable org-agenda-include-diary?
> 
> -- 
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 

Re: Inline markup: How does org identify nested code/verbatim?

[Ihor Radchenko]

 writes:

> The point is myself I'm able to identify code or verbatim with regex
> including three catch groups for the content before, between and
> after the inline markers.
>
> for verbatim: "(^|[ .,;:\-?!({\"'])=(.*?)=([ .,;:\-?!)}\"']|$)"
> for code: "(^|[ .,;:\-?!({\"'])~(.*?)~([ .,;:\-?!)}\"']|$)"
>  
> But they don't work together. In the example above I need to use the
> verbatim regex first to make it right. 

See https://orgmode.org/worg/org-syntax.html#Emphasis_Markers
Note that Org is not context-free. Within Org AST elements that can
contain objects, the first match "wins":
1. Org looks at a text and searches the first matching object regexp
2. Everything before the match is considered plain-text
3. Everything inside the match is considered the matched object and then
   parsed recursively
4. go to (1)   

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

Re: Supporting non-free SQL clients in ob-sql (was: [PATCH] ob-sql: Add support for Athena)

[Ihor Radchenko]

Richard Stallman  writes:

>   > However, I gues the point remains, sql.el and ob-sql.el support a number
>   > of non-free RDMS
>
> Can someone post a verified list of which of them are non-free?
> Someone posted a list of a few, which I cannot find now in my saved
> inboxes, but I think it included oracle, mysql, vertica? and a fourth
> one else (what was it?).
>
> Does sql.el handle any other nonfree ones aside from those?

Note that we are talking about sql.el and also about ob-sql.el, which
are different libraries.

ob-sql.el supports the following non-free SQL implementations:
- mssql (https://en.wikipedia.org/wiki/Microsoft_SQL_Server)
- Oracle (https://en.wikipedia.org/wiki/Oracle_Database)
- Vertica (https://en.wikipedia.org/wiki/Vertica)
- saphana (https://en.wikipedia.org/wiki/SAP_HANA)

sql.el supports the following non-free SQL implementations:
- Oracle (https://en.wikipedia.org/wiki/Oracle_Database)
- SOLID SQL (https://en.wikipedia.org/wiki/SolidDB)
- Sybase (acquired by SAP, see sapphana; https://en.wikipedia.org/wiki/Sybase)
- Informix (https://en.wikipedia.org/wiki/IBM_Informix)
- Ingress (https://en.wikipedia.org/wiki/Ingres_(database))
- mssql (https://en.wikipedia.org/wiki/Microsoft_SQL_Server)
- Interbase (https://en.wikipedia.org/wiki/InterBase)
- DB2 (https://en.wikipedia.org/wiki/IBM_Db2)
- linter (https://en.wikipedia.org/wiki/Linter_SQL_RDBMS)
- Vertica (https://en.wikipedia.org/wiki/Vertica)

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

Patch for worg org-tools

[Jakob Schöttl]

Hi all,

I got a patch for

https://orgmode.org/worg/org-tools/index.html

Does someone with access wants to apply it?

- Jakob


diff --git a/org-tools/index.org b/org-tools/index.org
index eec65e77..44c2fe3c 100644
--- a/org-tools/index.org
+++ b/org-tools/index.org
@@ -19,6 +19,7 @@ This page lists external tools useful for handling Org 
files.
 | Name    | Language    | Author | 
Annoncement/info  |

 
|-+-+---+---|
 | [[https://github.com/200ok-ch/org-parser][org-parser]]  | 
JavaScript/Java/Clojure/BNF | 200ok | 
[[https://200ok.ch/project/org-parser.html][homepage]]  |
+| [[https://github.com/tecosaur/Org.jl][Org.jl]]  | 
Julia   | tecosaur  | 
[[https://github.com/tecosaur/Org.jl][homepage]]  |
 | [[https://github.com/mashdot/orgile][Orgile]]  | 
PHP | 
[[https://github.com/mashdot][mashdot]]   | 
[[http://toshine.org/etc/orgile-emacs-org-mode-file-html-parser-php-publishing-tool/][this 
blog entry]]   |
 | [[https://bitbucket.org/joebo/pico-org/src][pico-org]]    | 
PicoLisp    | Joe Bogner    | 
[[http://thread.gmane.org/gmane.lisp.picolisp.general/3679][Message]] |
 | [[http://common-lisp.net/project/cl-org-mode/][cl-org-mode]] | 
Common Lisp | |   |

Re: [BUG] ob-shell doesn't evaluate last line on Windows (cmd/cmdproxy) [9.6.1 ( @ c:/Users/Osher/AppData/Roaming/.emacs.d/elpa/org-9.6.1/)]

[Ihor Radchenko]

Matt  writes:

>   On Thu, 26 Jan 2023 04:51:19 -0500  Ihor Radchenko  wrote --- 
>
>  > This will add a newline to "cmdproxy.exe" command -> "cmdproxy.exe\n".
>  > You should instead look into `org-babel--write-temp-buffer-input-file'.
>
> I made the change in `org-babel--shell-command-on-region' based on your 
> recommendation in https://list.orgmode.org/orgmode/87bkmttv2h.fsf@localhost/
>
> I'd be happy to put it in `org-babel--write-temp-buffer-input-file'.  
> Unfortunately, I don't understand why you suggest the change be made there.  
> Wouldn't it make more sense to insert the newline into the temp buffer that 
> `org-babel--write-temp-buffer-input-file' writes from? 

I just thought that it is the most logical place to add trailing
newline. `org-babel--write-temp-buffer-input-file' deletes the buffer
contents anyway, so modification will not cause any undesired side
effects.

> ;; 99.999% sure this isn't what you meant
>  (defun org-babel--write-temp-buffer-input-file (input-file)
>"Write the contents of the current temp buffer into INPUT-FILE."
>(let ((start (point-min))
>  (end (point-max)))
>  (goto-char start)
>  (push-mark (point) 'nomsg)
>  (write-region start end input-file)
> +(with-temp-buffer
> +  (insert "\n")
> +  (write-region (point-min) (point-max) input-file))
>  (delete-region start end)
>  (exchange-point-and-mark)))

I meant inserting newline in current buffer at the beginning.

> AFAICT, `org-babel--write-temp-buffer-input-file' is only called by 
> `org-babel--shell-command-on-region' and that's only ever called by 
> `org-babel-eval'.  That's where the query (the block source) is inserted into 
> a temp buffer.  Maybe something like this?
>
> modified   lisp/ob-eval.el
> @@ -64,7 +64,7 @@ Writes QUERY into a temp-buffer that is processed with
>(let ((error-buffer (get-buffer-create " *Org-Babel Error*")) exit-code)
>  (with-current-buffer error-buffer (erase-buffer))
>  (with-temp-buffer
> -  (insert query "\n")
> +  (insert (concat query "\n"))

The original is just (insert query).
(insert query "\n") is also ok.

I don't have strong preference here.

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

Re: org-crypt fails if default key is expired while non-default key is to be used

[Ihor Radchenko]

Karl Voit  writes:

>> What is the return value of
>>
>> (epg-list-keys (epg-make-context nil t t) org-crypt-key)
>>
>> ?
>>
>> Does it show the right key?
>
> It shows:
>
> (#s(epg-key ultimate
> (#s(epg-sub-key ultimate ... nil 1 4096 "ABC12345" 1515327255 nil 
> "...ABC12345")
>#s(epg-sub-key ultimate ... nil 1 4096 "FFF" 1515327255 
> nil "."))
> (#s(epg-user-id ultimate "Karl Voit (Internal key for orgmode) 
> " nil
>
> ... with ABC12345 being the correct key for org-crypt and FFF being my
> default OpenPGP key.

Ok. What about

(let ((context (epg-make-context nil t t)))
  (epg-decrypt-string context (epg-encrypt-string context "test" (epg-list-keys 
context org-crypt-key

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

Re: diary-anniversary doesn'work om Mac osx 12.6.3

[Ihor Radchenko]

Renato Pontefice  writes:

> I try to perform this simple line of emacs manual (this is the perfect page 
> of the manual where I took this: where I took this: "31.13.10 Sexp Entries 
> and the Fancy Diary Display”). Because trying to learn emacs I would try as 
> many entry possibile as I could (I know I can obtain that in a different way).
>
> But on my Mac OS X platform I cannot obtain the right result.
> I’ve tried with:
> - emacs ver 26.2; 28.3; 28.3 (via terminal “emacs -Q” and via GUI With or 
> without a init.el file

>  ... And finally, I’ve installed a VM, running Debian 11 and try it running 
> emacs by terminal and typing ORG-AGENDA ret a
> I obtain the agenda with the correct entry.
>
> So I’m wondering:
> Maybe Mac osx does not contain the right (elisp?) code to obtain that?

Could you please detail what exactly you tried? How did you use
diary-anniversary? What did you put into diary file? Or did you use
diary sexp style timestamp? Did you enable org-agenda-include-diary?

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

Maintenance status of individual Org libraries

[Ihor Radchenko]

Dear all,

I have gone through the maintainers of individual Org files and,
especially after Nicolas went missing from the list, the situation is
rather dire.

The following libraries have no maintainer or author active on the list:

ob-comint, ob-core, ob-css, ob-ditaa, ob.el, ob-emacs-lisp,
ob-eval, ob-exp, ob-forth, ob-fortran, ob-js, ob-latex, ob-lilypond,
ob-lob, ob-lua, ob-matlab, ob-ocaml, ob-octave, ob-org, ob-per,
ob-plantuml, ob-ref, ob-R, ob-ruby, ob-sass, ob-sed, ob-table,
ob-tangle, oc-basic, oc-biblatex, oc-bibtex, oc.el, oc-natbib, ol-bbdb,
ol-docview, ol-doi, ol.el, ol-eshell, ol-info, ol-irc, ol-mhe, ol-rmail,
org-agenda, org-archive, org-capture, org-clock, org-colview, org-compat
(maintenance would be useful, especially wrt compat.el), org-ctags,
org-datetree, org-duration, org-element (I can), org-entities,
org-faces, org-feed, org-footnote, org-goto, org-id, org-indent,
org-keys, org-lint, org-macro, org-macs, org-mobile, org-mouse, org-num,
org-refile, org-table, org-tempo, org-timer, ox-ascii, ox-beamer, ox.el,
ox-icalendar, ox-man, ox-md, ox-odt, ox-org, ox-publish, ox-texinfo

83/127 (~65%) of the libraries do not have someone familiar with their
code.

Should we try to make a call for maintenance at least for some of these
libraries?

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

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: Org mode timestamps on the Moon ;] (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ihor Radchenko]

Tom Gillespie  writes:

> Oh boy. In short, I think we can only hope they come up with
> LTC and we already have a syntactic space to say whether
> our reference seconds are TAI/UTC/LTC/MTC/JTC etc. And
> being the privileged squats that we are if the time system is
> left out then it means UTC. The friendly thing to do would be
> to always include the time system code in our timestamps,
> but I don't think those have standard reference codes yet?

I cannot see anything in
https://en.wikipedia.org/wiki/List_of_tz_database_time_zones

So, just UTC. If we want to support more, it will have to be done
manually. 

> I don't think we want to force users to start embedding their gps
> coordinates, their current acceleration, etc. along with their
> timestamp. But it turns out that the unix epoch is only standard
> at 9.8m/s^2. So ... minutes should be ok right?

> Joking aside. Clocks run faster on the moon, slower on the ISS,
> so either clocks are synchronized back to earth seconds, or
> they use some alternate standard reference time.

I am afraid that calculating "real" time inside a given reference system
is impossible now. Time from epoch in Greenwich when you are looking
from inside Greenwich and time from epoch in Greenwich when you are
looking from inside ISS are two different time intervals. And what about
time from epoch in ISS when looking from Greenwich?

And then we also synchronize time with UTC now. But time since epoch in
UTC when looking from UTC and time from epoch in UTC when looking from
different elevation are different times :)

Further, what does it mean to have a meeting scheduled for
<2023-01-30 Mon 14:00 @Europe/Berlin>--<2023-01-30 Mon 20:00 @Asia/Singapore>
What is the reference frame? Europe/Berlin gravitation well?
Asia/Singapore well? Local well?

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

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

[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: [POLL] Use compat.el in Org? (was: Useful package? Compat.el)

[Greg Minshall]

Ihor,

> Cons:
> 
> 1. If compat.el happens to lack support of some function, we will need
>to contribute to compat.el directly and synchronize Org releases with
>compat.el releases.

would a separate "org-compat.el" (in addition to compat.el) somehow
solve this?  (i worry about the synch'ing.)

cheers, Greg

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

[Greg Minshall]

Ihor, Sterling, et al.,

just a thought/reminder.  there are "semantics" and "encoding".  a spec
like ISO-8601 specifies both.  the important thing for org-mode is to
use an encoding that

1. is easily parsable/understandable by the mere mortal

2. allows expression of all the semantics of the underlying spec/specs
   (be that ISO-8601, this new IETF spec, the Library of Congress spec,
   etc.)

3. and, importantly, is designed to *try* to follow updates to the
   underlying spec/specs (which will inevitably happen)

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

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

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

cheers, Greg

Re: Org mode timestamps on the Moon ; ] (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Greg Minshall]

Tom,

> The only generalized solution is to record the full location (see
> intro to http://naggum.no/lugm-time.html which I'm surprised hasn't
> been linked in this thread yet, ...

very nice -- thanks for the pointer!

cheers, Greg

Re: [PATCH] org-element-cache-map: Fix handling of continue-from

[Ihor Radchenko]

Matthieu Caneill  writes:

> I'm hit by the following bug in `org-element-cache-map'. When I use
> `tags' or `tags-todo' in an agenda, with the option
> `(org-tags-match-list-sublevels nil)', all sub-elements of a matching
> item are correctly skipped except the last one.
>
> It can be reproduced with the following org file:
> ...

Thanks for reporting!
Fixed, on bugfix. Now, also covered by tests.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=c340e799f

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