Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Jean Louis]

* AW  [2023-01-22 00:33]:
> Workflow: E-Mails with a question comes in, I open a TODO heading in
> an orgmode file regarding the question.
> 
> Now, I'd like to add a link to the E-Mail under this TODO heading in the 
> orgmode file. I've seen the manual page about external links, https://
> orgmode.org/manual/External-Links.html 

I am using Mutt: https://mutt.org which must be in your
distribution. 

There is way how to automatically capture Message-ID and put it
outside of the Mutt, though I did not yet implement it.

However, if I wish to open specific e-mail I point to the Maildir, or
maybe Mbox or other type,

Maildir: /home/data1/protected/Maildir/to...@tuxteam.de
Message-ID: Y0mt4/g+dlklu...@tuxteam.de

Then I use this function:

(defun hyperscope-mutt-view-by-message-id (link argument)
  "Opens email by message ID by using mutt"
  (let* ((folder link)
 (message-id (replace-regexp-in-string "=" "=" argument))
 (push (format "push '=i %s'" message-id)))
(call-process "xterm" nil nil nil "-e" "mutt" "-f" folder "-e" push)))

Where by function must receive LINK and ARGUMENT, whereby ARGUMENT
means Message-ID string.

xterm is called, mutt launched for FOLDER which is same as LINK, and
"-e" specify a command to be executed after initialization, which is
in this case "push "'=i Y0mt4/g+dlklu...@tuxteam.de'"

And I get to see that specific e-mail that was hyperlinked.

You may implement this in org by creating elisp: type of links easy. You could 
call this function different:

(defalias 'my-message-id 'hyperscope-mutt-view-by-message-id)

(my-message-id LINK ARGUMENT)

Opens email by message ID by using mutt

[[elisp:(my-message-id "/home/data1/protected/Maildir/to...@tuxteam.de" 
"Y0mt4/g+dlklu...@tuxteam.de")][Link to my message]]

And after clicking on the above Org hyperlink I can see it works well. 

KMail does not work on my side, so you can see which command line
options are available to find message by Message-ID.

In Thunderbird you may use this plugin:

Copy Message ID :: Add-ons for Thunderbird:
https://addons.thunderbird.net/en-us/thunderbird/addon/copy-message-id/

as to get quickly Message-ID.

The way to open up in Thunderbird is:

./thunderbird mid:PUT-HERE-YOUR-MESSAGE-ID

Here is easier way to insert Message-ID hyperlinks:

(defun rcd-org-link-message-id-by-elisp ()
  (interactive)
  (let* ((my-selection (gui-selection-value))
 (functions '("(my-message-id \"%s\" \"%s\")" 
"(message-id-by-thunderbird \"%s\")"))
 (function (completing-read "Choose function for Message-ID: " 
functions nil t))
 (name (read-string "Name of link: "))
 (folder (read-string "Enter mail folder if any or RET for nothing: "))
 (message-id (read-string "Enter Message-ID: " my-selection)))
(insert "[[elisp:" (format function folder message-id) "][" name "]]")))

1. Copy Message ID in memory, but you also need to know Mail folder, depending 
of function

2. M-x rcd-org-link-message-id-by-elisp and answer questions

3. [[elisp:(my-message-id "my mail folder" "my message ID")][my name]]

> I'm on Linux, KDE as GUI, distro Tumbleweed by openSUSE. The E-mail
> software is kmail. Unfortunately, there is no way to get the path to
> an individual E- mail out of kmail, which I could simply use to put
> it into my orgmode file as a link.  So I installed notmuchmail and
> the emacs package notmuch.el.

It requires indexing and wastes time. If you use Mutt, it will open up
Message-ID e-mails in breeze. You may invoke external HTML viewers or
external program to see e-mails in different way. I know it is double
work.

Peculiar ways to make Evolution work are explained by Karl Voit:

Moving from Thunderbird to Evolution for Emails and Calendar:
https://karl-voit.at/2021/06/01/Thunderbird-to-Evolution/

Feature request: getting a message-id link from email + CLI option to open 
email via message-id (#1508) · Issues · GNOME / evolution · GitLab:
https://gitlab.gnome.org/GNOME/evolution/-/issues/1508

> By notmuch-search I can find an individual E-mail. In the E-Mail
> buffer I type c I , which copies the message-ID of that E-Mail into
> the keyring.  Instead of a link I paste the message-ID into my
> orgmode file. If I'd like to read the E-Mail again, I can use
> notmuch-search: id:  to find the E- Mail again.  I know,
> this is not a really efficient way. Probably you are not surprised
> to read my question: How can I have a link in an orgmode file to an
> E-Mail using either a feature of kmail oder notmuch ?  Regards,

We tried to solve this problem for Mutt here, since 3 years already:

Feature proposal: provide possibility to link directly to a message (#172) · 
Issues · Mutt Project / mutt · GitLab:
https://gitlab.com/muttmua/mutt/-/issues/172

Of course, one can see that both in Gnome and Mutt society, people
hardly understand use cases of capturing hyperlinks to messages.

Capturing of e-mails attributes is more of a problem that creating
hyperlinks in 

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

[Thomas S. Dye]

Aloha Max,

Max Nikulin  writes:


Let's consider the following timestamp

[2023-01-22 Sun 08:29@+1100]

"@" is unimportant here, I take it from Ihor's examples. This 
timestamp is from
the "Date:" header of your message. It is not UTC, but in my 
opinion it is

equally precise (disregarding seconds) to a UTC timestamp.

Would you prefer to have timestamps in your files in such form 
or as


[2023-01-21 Sat 21:29Z] ([2023-01-21 Sat 21:29@UTC], [2023-01-21 
Sat

21:29@+00:00], etc)?

Maybe [@1674336588] (seconds since epoch)?

I consider storage format as a part of Org UI, so I believe that 
[2023-01-22 Sun
08:29@+1100] with offset of the usual time zone is more 
convenient than
[2023-01-21 Sat 21:29@+]. Overlays may present your local 
time in both

cases, but raw value with usual offset is easier to comprehend.

When a file is shared by a group of people spread across the 
globe, they are
free to use UTC or another fixed timezone or do not care at all 
concerning

particular offset, it just should present.


UTC is not a timezone.  It is absolute time.

Postgres has a reason to insist on UTC since timestamps are 
stored in binary
format as microseconds since epoch. It is important for 
performance and there is
no room to specify offset. Org has to parse timestamps from 
strings anyway, so

it is better to use format more convenient for humans.


Agreed.

A side note. In my opinion, *by default* timestamps should be 
created in local
time with no offset or timezone. There are should be some 
preferences to enable
absolute timestamps and a function to fix offsets or timezone 
identifiers for
existing timestamp when the user realizes that they become 
necessary (e.g.

before a trip).


I don't think there should be a default.  If I'm correct that 
occurrences, events relative to user, and events not relative to 
user exhaustively classify the possibilities, then Org should 
insist that timestamps conform to one of these three 
possibilities.  If the classification is complete, then there is 
no need for a catch-all default.


So I do not see any advantages of UTC in comparison to time 
offset specific to
particular time zone, usually user's local one. My vote is 
[2023-01-22 Sun
08:29@+1100] and not [2023-01-21 Sat 21:29@UTC] (of course, only 
in cases when
identifiers like Australia/Sydney do not matter) with a 
configuration option

with timezone used fix offsets in stored timestamps.


The disadvantage of time offset specific to a particular timezone 
is that the timezone offset wrt UTC can change arbitrarily. This 
is a potential problem if the arbitrary change takes place between 
the creation of the timestamp and the happening it identifies.  In 
contrast, UTC is guaranteed not to change.  It is not a timezone, 
it is absolute time, a pure continuum.  It is a requirement of 
occurrences.


I'm not sure offset is necessary for events, given that offset can 
change arbitrarily.  WDYT?  It seems to me that once an event has 
been tied to a particular time in a particular time zone that 
Org's job is to take into account changes to that timezone, such 
as DST and arbitrary legislation.  These changes in the event's 
timezone need to be propagated through the schedule for each user, 
so it is possible to synchronize local timestamps around the 
globe.


All the best,
Tom

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

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

[Max Nikulin]

On 22/01/2023 04:29, Tim Cross wrote:

Max Nikulin writes:

- UTC is a recommendation for planning when participants are scattered over 
multiple
  timezones.
- You admit that some timestamps in your files may be specified as time zone 
identifier +
  local time relative to this zone.
- In both cases you may configure overlays to use local timezone or another one 
whatever
  you currently find convenient.
- Time chooser offers several time zone options.


That seems to be in-line with what I was arguing, so yes, would agree.


Great. At this stage my goal is to convince people that local time and 
UTC for future timestamps are not enough for real life use cases. 
Arbitrary timezone may be crucial to arrive at proper time despite it 
matters in rare cases. My concern is mostly storage format, timestamp 
syntax in Org files.


On 21/01/2023 06:38, Tim Cross wrote:

I would also argue UTC is good for 'traditional' timestamps which record
a specific point in time and for situations where you want accurate
calculations of time durations.


Let's consider the following timestamp

[2023-01-22 Sun 08:29@+1100]

"@" is unimportant here, I take it from Ihor's examples. This timestamp 
is from the "Date:" header of your message. It is not UTC, but in my 
opinion it is equally precise (disregarding seconds) to a UTC timestamp.


Would you prefer to have timestamps in your files in such form or as

[2023-01-21 Sat 21:29Z] ([2023-01-21 Sat 21:29@UTC], [2023-01-21 Sat 
21:29@+00:00], etc)?


Maybe [@1674336588] (seconds since epoch)?

I consider storage format as a part of Org UI, so I believe that 
[2023-01-22 Sun 08:29@+1100] with offset of the usual time zone is more 
convenient than [2023-01-21 Sat 21:29@+]. Overlays may present your 
local time in both cases, but raw value with usual offset is easier to 
comprehend.


When a file is shared by a group of people spread across the globe, they 
are free to use UTC or another fixed timezone or do not care at all 
concerning particular offset, it just should present.


Postgres has a reason to insist on UTC since timestamps are stored in 
binary format as microseconds since epoch. It is important for 
performance and there is no room to specify offset. Org has to parse 
timestamps from strings anyway, so it is better to use format more 
convenient for humans.


A side note. In my opinion, *by default* timestamps should be created in 
local time with no offset or timezone. There are should be some 
preferences to enable absolute timestamps and a function to fix offsets 
or timezone identifiers for existing timestamp when the user realizes 
that they become necessary (e.g. before a trip).


So I do not see any advantages of UTC in comparison to time offset 
specific to particular time zone, usually user's local one. My vote is 
[2023-01-22 Sun 08:29@+1100] and not [2023-01-21 Sat 21:29@UTC] (of 
course, only in cases when identifiers like Australia/Sydney do not 
matter) with a configuration option with timezone used fix offsets in 
stored timestamps.

[ot] git corruption in personal repo --- leave it alone?

[Samuel Wales]

investigating the insane diff [intermingled entries] thread i found
correpted commuits using git log.  for example,

* entry
asdfadsf
asdfasdf
 entry
this entry's qwerqwerqwer
qwerqwerqwer
previous entry's qwerqwerqewr

in other words, a task inside text of another tasks and not even
adjusted subevels.  as a user i would not create that most liekly.
most likely is intra-hunk operations in an old version of magit not
worth reporting.  but never mind that.

i was just curious if you were me, would you just leae he corrupted
commits, or is there a compelling reason to use ineractive rebase edit
and fix the commits and then maybe teh later commits will be less
insane or maybe there will be slme kind of message that will tell me
more that might be useful.  or not.  idk.


-- 
The Kafka Pandemic

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

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Max Nikulin]

On 22/01/2023 04:32, AW wrote:


How can I have a link in an orgmode file to an E-Mail using either a feature of
kmail oder notmuch ?


I am not a kmail user, but out of curiosity I spent a couple of minutes 
trying to find some way to link messages. The only result is some old 
blog post suggesting to create links to files (it seems storage format 
is maildir).


So it seems the only way to get it possible in future is to file a 
feature request to implement "mid:" URI schema


RFC 2392 - Content-ID and Message-ID Uniform Resource Locators. 1998
https://tools.ietf.org/html/rfc2392

I was surprised that "mid:" had been reserved many years ago by

Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource 
Locators (URL)", RFC 1738, December 1994


E.g. thunderbird implemented such feature relatively recently and it 
allows me to have links like


AW to emacs-orgmode. Link from orgmode file to E-Mail (using kmail or 
notmuch) Sat, 21 Jan 2023 22:32:47 +0100. 
mid:3218434.44cspzl...@linux.fritz.box


in my Org files.

Re: Patch for \usepackage[ ... natbib = true ...]{...biblatex} with org-cite

[Edgar Lux]

For the very silly reason that I was not aware of it >.< . Thank you, Ihor. 

For the uninformed: evaluate this as a lisp expression (require 'oc-biblatex) . 
Also, you can use either  #+LaTeX_HEADER: \usepackage... (like shown in this 
thread) or style options with #+cite_export: biblatex (read the documentation 
for oc-biblatex.el). I tested like this (and with the \usepackage line too):

#+cite_export: biblatex
#+bibliography: your_file.bib

This:

#+cite_export: biblatex "bibstyle=numeric-comp,sorting=none, 
hyperref=true,backref=true,url=true,backend=biber,natbib=true"

will create

\usepackage[style=bibstyle=numeric-comp,sorting=none, 
hyperref=true,backref=true,url=true,backend=biber,natbib=true]{biblatex}

(note the style=bibstyle=)

I would suggest that the org-info pages mention (require 'oc-biblatex) and show 
an example of  how one can use extra options (with the #+latex_header as well). 
Further, may be it would be better to allow something like this:

#+cite_export: biblatex "bibstyle=numeric-comp,sorting=none, 
hyperref=true,backref=true,url=true,backend=biber,natbib=true"
#+bibliography: your_file.bib

For which one can use the appended patch, which may break other things, of 
course :P . The gain is control over biblatex options without resorting to 
#+latex_header: \usepackage[...]{biblatex}

Cheers! Thanks.

January 21, 2023 at 9:37:18 AM CET Ihor Radchenko  
wrote:Edgar Lux  writes:

I now looked at the patch and I have one general question. What you
don't just use oc-biblatex in the above?


-- 
Sent with https://mailfence.com  
Secure and private email


oc-biblatex.patch.gz
Description: File Attachment: oc-biblatex.patch.gz


oc-biblatex-postpatch-tests.txt.gz
Description: File Attachment: oc-biblatex-postpatch-tests.txt.gz

Re: New face: org-agenda-calendar-timerange

[Gautier Ponsinet]

Ihor Radchenko  writes:
> Added to the contributor list:
> https://git.sr.ht/~bzg/worg/commit/b8096c5a
>
[ 4 more citation lines. Click/Enter to show. ]
> Now, I can apply the patch.
> Applied, onto main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a0a30d7b6
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=cb73633e2

> Done.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a7e910646

Great! Thanks Ihor & Bastien!

All the best,
Gautier.

Re: Link from orgmode file to E-Mail (using kmail or notmuch)

[Gautier Ponsinet]

Hello Alexander,

AW :
> How can I have a link in an orgmode file to an E-Mail using either a feature 
> of 
> kmail oder notmuch ?

The package "ol-notmuch" implements links to notmuch messages and "searches":
https://git.sr.ht/~tarsius/ol-notmuch .

There might be other solution, for notmuch or kmail, which I am not
aware of. I hope it helps you.

All the best,
Gautier.

Re: Help with a workflow to export plantuml diagrams

[Ypo]

Thanks, Ihor

I can't make it to work by now, but that could be a path to the correct 
workflow.


Best regards :-)


El 17/01/2023 a las 14:28, Ihor Radchenko escribió:

Ypo  writes:


Could be the headlines exported in a faster way?

Could be possible to avoid the duplication of information? (To create
the diagram directly from the headlines, without yanking a copy of them).

You can use noweb reference syntax.

#+name: collect-headings
#+begin_src emacs-lisp :results silent
;; Collect all the headings in current buffer.
(concat
  "* Top\n"
  (mapconcat
   #'identity
   (org-map-entries
'(concat "*"
 (buffer-substring-no-properties
  (line-beginning-position) (line-end-position
   "\n"))
#+end_src

#+begin_src plantuml :noweb yes :file my-diagram.png
@startwbs
<>
@endwbs
#+end_src

Link from orgmode file to E-Mail (using kmail or notmuch)

[AW]

Hi!

Workflow: E-Mails with a question comes in, I open a TODO heading in an orgmode 
file regarding the question.

Now, I'd like to add a link to the E-Mail under this TODO heading in the 
orgmode file. I've seen the manual page about external links, https://
orgmode.org/manual/External-Links.html 

I'm on Linux, KDE as GUI, distro Tumbleweed by openSUSE. The E-mail software 
is kmail. Unfortunately, there is no way to get the path to an individual E-
mail out of kmail, which I could simply use to put it into my orgmode file as a 
link.

So I installed notmuchmail and the emacs package notmuch.el. Works. By 
notmuch-search I can find an individual E-mail. In the E-Mail buffer I type
c I , which copies the message-ID of that E-Mail into the keyring. 

Instead of a link I paste the message-ID into my orgmode file. If I'd like to 
read the E-Mail again, I can use notmuch-search: id:  to find the E-
Mail again.

I know, this is not a really efficient way. Probably you are not surprised to 
read my question:

How can I have a link in an orgmode file to an E-Mail using either a feature of 
kmail oder notmuch ?

Regards,

Alexander

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

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

[BUG] Date prompt suggests yesterday when changing timestamp with org-extend-today-until set [9.6]

[Tim Ruffing]

Hi,

Assume org-extend-today-until is set to an integer greater 0, say 3.
When I change a timestamp without date such as <2023-01-20> (e.g, when
rescheduling), the prompt defaults to a day earlier, i.e., to "2023-01-
19" in this case. The same happens with <2023-01-20 01:00> which is
still before 3am. 
 
That's very confusing, in particular in the case when the old timestamp
only has a date but no time. But even when the old timestamp has has a
time, org should never suggest yesterday. I think a good rule of thumb
here is that if the user just presses Enter without having typed
anything at the prompt, the timestamp shouldn't change at all.

The bug happens because org-read-date tries to take into account the
value of org-extend-today-until but it should probably do this when the
default time suggested to the user is taken from the current wallclock
time, not when it's taken from an existing timestamp. 

A similar issue when capturing has been reported and fixed here:
https://lists.gnu.org/archive/html/emacs-orgmode/2019-06/msg00056.html

(Please include me in CC for now, I haven't subscribed to mailing
list.) 

Best,
Tim


PS: Thanks for org-mode. It has my changed my life.

[BUG] org-clock-in opens buffers for all agenda files

[Tom Gillespie]

I just tried to clock in to a task for the first time
in ... a while, and was immediately accosted with
hundreds of buffers being opened.

This seems to be because org-clock-in somehow
calls org-agenda or org-agenda-prepare or something
similar, however I cannot find the call site.

Is there a way to disable this so that clocking does not
destroy my emacs buffer state by starting org-agenda?

Thanks!
Tom

Re: [BUG] org-clock-in opens buffers for all agenda files

[Tom Gillespie]

> This is because Org is checking if you have any dangling clocks present.

Seems like a reasonable default.

> See org-clock-auto-clock-resolution

Perfect solution for my case. Thanks!

Re: [BUG] org-clock-in opens buffers for all agenda files

[Ihor Radchenko]

Tom Gillespie  writes:

> I just tried to clock in to a task for the first time
> in ... a while, and was immediately accosted with
> hundreds of buffers being opened.

This is because Org is checking if you have any dangling clocks present.

>
> Is there a way to disable this so that clocking does not
> destroy my emacs buffer state by starting org-agenda?

See org-clock-auto-clock-resolution

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

[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

[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

[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

[Jean Louis]

* 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

[Jean Louis]

* 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

[Jean Louis]

* 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

[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

[Jean Louis]

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

ob-sql dbconnection engine

[Andreas Gerler]

Hi!

as I am still learning more elisp it took me some try and error but I can use 
the sql-product now within dbconnection.
Using :engine still works as well.
Still wondering if there is a more elegant way for the if clause.



ob-sql.el.diff
Description: Binary data


so long…

Andreas Gerler

—

http://www.bundesbrandschatzamt.de/~baron



signature.asc
Description: Message signed with OpenPGP

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

[Andreas Gerler]

The copyright assignment was in April 2017.
gnu.org #1203873 if that helps.

> On 21. Jan 2023, at 09:48, Ihor Radchenko  wrote:
> 
> Daniel Kraus  writes:
> 
>> @Ihor, since this is the first patch I install from another contributor,
>> is there anything I should look out for?
> 
>> E.g. does this need a TINYCHANGE entry or something?
> 
> 1. General checks for tests passing and sanity of the patches
> 2. Ensuring copyright status, when total contributed nuber of LOC is
>   around 15
> 
> See https://orgmode.org/worg/org-maintenance.html and
> https://www.gnu.org/prep/maintain/
> 
> Also, make sure that you are familiar with general contribution
> guidelines listed at https://orgmode.org/worg/org-contribute.html
> 
>> Or do you have already copyright assignments filled out, Andreas and
>> then it's not necessary?
>> Can I see somewhere who I need to ask for copyright assignments or not?
> 
> We list all (well, most of) the past contributors and their copyright
> assignment status at https://orgmode.org/worg/contributors.html
> 
> I also have a small hook for my Emacs mail client that automatically
> checks the contributor status and number of contributed LOCs for Org
> mailing list:
> https://github.com/yantar92/emacs-config/blob/master/config.org#detect-fsf-contribution-status-of-sender-for-org-ml
> 
> Bastien has access to official FSF records. We need to ask him when
> copyright assignment status cannot be determined from the Org
> contributors page.
> 
> In this case, Andreas is not listed on
> https://orgmode.org/worg/contributors.html
> I also cannot find anything relevant in the mailing list archives.
> (well, there is
> https://orgmode.org/list/b664b5e8-b6a8-4b20-b0cb-f6149c720...@bundesbrandschatzamt.de,
> but I do not see any confirmation of the copyright assignment status).
> 
> Bastien, could you please confirm the copyright status of Andreas Gerler?
> 
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
> 



so long…
Andreas Gerler
—

http://www.bundesbrandschatzamt.de/~baron



signature.asc
Description: Message signed with OpenPGP

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

[Max Nikulin]

On 21/01/2023 16:21, Ihor Radchenko wrote:


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

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

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


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

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


On 21/01/2023 16:21, Ihor Radchenko wrote:

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


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



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


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

Re: [PATCH] Support building Org from shallow clone [9.6.1 (release_9.6.1-137-gecb62e @ /home/n/.emacs.d/elpaca/builds/org/)]

[Ihor Radchenko]

No Wayman  writes:

> Why not use ORGVERSION here? Is the metadata in org.el's version 
> header not updated when a commit is tagged as a release?

ORGVERSION can be ahead of the last released version.

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

Re: [PATCH] org-datetree.el: Allow datetrees with TODO, priority, tags

[Ihor Radchenko]

Ilya Chernyshov  writes:

> Since the last patch, I've made the following changes, thanks to 
> your
> recommendations in Matrix chat: ...

Thanks!
Applied, onto main. After resolving merge conflicts.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=005c9ae74

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

"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: [BUG] ob-sql sql-connection-alist

[Ihor Radchenko]

Daniel Kraus  writes:

> @Ihor, since this is the first patch I install from another contributor,
> is there anything I should look out for?

> E.g. does this need a TINYCHANGE entry or something?

1. General checks for tests passing and sanity of the patches
2. Ensuring copyright status, when total contributed nuber of LOC is
   around 15

See https://orgmode.org/worg/org-maintenance.html and
https://www.gnu.org/prep/maintain/   

Also, make sure that you are familiar with general contribution
guidelines listed at https://orgmode.org/worg/org-contribute.html

> Or do you have already copyright assignments filled out, Andreas and
> then it's not necessary?
> Can I see somewhere who I need to ask for copyright assignments or not?

We list all (well, most of) the past contributors and their copyright
assignment status at https://orgmode.org/worg/contributors.html

I also have a small hook for my Emacs mail client that automatically
checks the contributor status and number of contributed LOCs for Org
mailing list:
https://github.com/yantar92/emacs-config/blob/master/config.org#detect-fsf-contribution-status-of-sender-for-org-ml

Bastien has access to official FSF records. We need to ask him when
copyright assignment status cannot be determined from the Org
contributors page.

In this case, Andreas is not listed on
https://orgmode.org/worg/contributors.html
I also cannot find anything relevant in the mailing list archives.
(well, there is
https://orgmode.org/list/b664b5e8-b6a8-4b20-b0cb-f6149c720...@bundesbrandschatzamt.de,
but I do not see any confirmation of the copyright assignment status).

Bastien, could you please confirm the copyright status of Andreas Gerler?

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

Re: Patch for \usepackage[ ... natbib = true ...]{...biblatex} with org-cite

[Ihor Radchenko]

Edgar Lux  writes:

> I send the attached patch for your consideration. It allows to use biber for 
> bibliographies. I tested it with this:
>
> (require 'oc-natbib)
>
> #+cite_export: natbib
> #+LaTeX_HEADER: \usepackage[style=numeric-comp,sorting=none, 
> hyperref=true,backref=true,url=true,backend=biber,natbib=true]{biblatex}
> #+LaTeX_HEADER: \addbibresource{../../Sources/sources.bib}

I now looked at the patch and I have one general question. What you
don't just use oc-biblatex in the above?

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

Re: New face: org-agenda-calendar-timerange

[Ihor Radchenko]

Ihor Radchenko  writes:

> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a0a30d7b6
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=cb73633e2
> ...
> Done.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a7e910646

Sorry, messed up the commit hashes.
Should be:

https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=22dea8557
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=84ead47d3

https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=f2320a2cc

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

Re: New face: org-agenda-calendar-timerange

[Ihor Radchenko]

Bastien Guerry  writes:

> Ihor Radchenko  writes:
>
>> Now, just waiting for confirmation from Bastien about your copyright
>> status records.
>
> Yes, I confirme Gautier's FSF copyright record is in order.

Added to the contributor list:
https://git.sr.ht/~bzg/worg/commit/b8096c5a

Now, I can apply the patch.
Applied, onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a0a30d7b6
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=cb73633e2

>> I am inclined to revert your commit because the original bug report was
>> trying to make Org use timestamp format, Org does not really
>> recognize.
>
> Yes, please do. Thanks!

Done.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a7e910646

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