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

[Jean Louis]

* AW  [2023-01-22 21:49]:
> Isn't this rather important? How many users of orgmode get TODOs via E-Mail 
> and need an efficient way to come back from the TODO to its origin?

Absolutely!

There are many uses apart from tasks, there are attachments. 

Legally is better not to delete attachment from e-mail to keep it as
evidence, and references to document in the e-mail are useful.

It seem as a "forgotten" and lacking feauture in many software.

From:

TECHNOLOGY TEMPLATE PROJECT OHS Framework :
https://www.dougengelbart.org/content/view/110/460/

 Dynamic knowledge capture, integration, management

Automated capture,  indexing and cross-referencing,  integrated email,
journal/library,  intelligence collections;  utilities for  repository
management

Sadly software designers do not follow successful principles, they
tend to follow personal or individual demands, and we get some use of
it, though we could do so much more for people.

- automated capture is missing in many software programs, as programs
  are tool centric, made to be "better" among competition, instead of
  integrating with competition.
  
  Example is Evince PDF viewer which does not have capture system. At
  least it has referencing system by page and query. While XPdf
  program has possibility to capture and reference in the same
  time. 
  
  Many PDF viewers don't have system to capture page number, query,
  some have annotations usable only from inside of the tool, without
  providing integration to other applications.
 
So it is with E-mail clients, they tend to be self-centric, not
providing information in usable way to other applications. Would they
do, there would be no such external tools like `mu' and `notmuch` for
indexing, as any information would be already indexed and re-usable by
other software (competition).

In Emacs we have that option to remember position of a cursor in some
specific file by customizing `save-place' option. That is miniscule
example of automatic capture of piece of information such as location
of a cursor, and with automatic referencing to that piece of
information so that user get to that portion of the file or text where
user was in last session. I think it should be by default. And so many
text editors do not have that basic feature.

It is good to keep filing feature requests to various software authors
that they start implementing note capturing features.

-- 
Jean

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

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

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

[Jean Louis]

* Richard Stallman  [2023-01-23 07:25]:

>   > > Because we already support Orcale, SAP Hana, MSSql and Vertico for 
> example.
> 
> Would someone please tell me more concretely what kind of "support"
> this is?

You can find interactive support in `sql' library, functions such as:

M-x sql-oracle 

which supports proprietary Oracle Database:
https://en.wikipedia.org/wiki/Oracle_Database

or 

M-x sql-ms

which description says:

sql-ms is an autoloaded interactive byte-compiled Lisp function in
‘sql.el’.

(sql-ms  BUFFER)

Run osql by Microsoft as an inferior process.

> Which GNU package supports them, and how?

Emacs, sql package

> Are they nonfree programs, or are they SaaSS?

They are proprietary programs that may be also SaaSS.


--
Jean

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

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

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

[Jean Louis]

* Thomas S. Dye  [2023-01-22 20:36]:
> > After all, for a person in Berlin [2023-01-22 Sun 08:29@+1100] may
> > tell more than [2023-01-22 Sun 08:29@Australia/Sydney].
> 
> I'm not sure to follow this.  IIUC, the timestamp with offset refers to
> absolute time, whereas the timestamp with the Australia/Sydney timezone
> refers to a region of space/time whose relation to absolute time is fixed
> for any moment, but potentially variable over time.

I understand above that it is easier understandable when reading
[2023-01-22 Sun 08:29@+1100] as it is assumed by poster (I guess Max)
that user will understand that there is +11 hours ahead.

That is assumption by poster. I do not find it easier.

As when user sees 08:29 that user will think of time in Berlin, of
time which is not in UTC, and not time in UTC plus 11 hours.

What is easier is what is generally accepted in any type of software
worldwide, just represent it in local time zone.

Difference between offset time and time with time zone is that time
zone includes rules of daylight savings and other anomalies.

-- 
Jean

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

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

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Because we already support Orcale, SAP Hana, MSSql and Vertico for 
example.

Would someone please tell me more concretely what kind of "support"
this is?  Which GNU package supports them, and how?  Also, what kind
of things are those?  Are they nonfree programs, or are they SaaSS?
Some of them I recognize as nonfree programs, but some names I don't
recognize at all.

There are situations where it is acceptable for a GNU package to
support its use together with certain nonfree programs.  Mainly when
the nonfree program so well known that this support mainly encourage
people who already use that nonfree program to start using the GNU
package with it, and is unlikely to do the converse.

See the GNU Maintainers Guide for more details.

However, use with a SaaSS system (service as a software substitute) is
a different issue (though it has much in common).  I'd like to think
about it and ask advisors for advice.  These details can help me start
to think about it.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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]

  On Fri, 20 Jan 2023 04:27:18 -0500  Ihor Radchenko  wrote --- 
 > I think `org-babel--shell-command-on-region' will be more appropriate.
 > Because similar issues might appear when attempting to evaluate other
 > code blocks on Windows, where `shell-file-name' is set to cmdproxy.exe.
 > 
 > It will also be useful to leave a comment in the code explaining why we
 > need this newline.

Works for me.  

How should I update bugfix to match main?  Since we're considering this a bug, 
I figured I'd do this on bugfix.  I notice, however, that bugfix doesn't have 
the latest updates to test-ob-shell.  When I rebase main onto bugfix I get a 
ton of conflicts.  If I instead merge main into bugfix, that shows many merge 
commits with bugfix.  Since I don't see any "Merge with 'bugfix'" commits on 
bugfix currently, I assume that's not the way to do it.

Re: [DISCUSSION] Should we deprecate python-mode.el (alternative to built-in python.el) support in ob-python?

[Jack Kamm]

Ihor Radchenko  writes:

> Marked for future removal in ob-python.el.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=21741a469

Thanks Ihor.

Not sure if it's too early for this, but I've prepared a patch to remove
the support for python-mode.el, attached.

Also, to help any python-mode users with the transition, I ported the
code to support python-mode to an external package here:

https://gitlab.com/jackkamm/ob-python-mode-mode

As always, feedback is welcome, either on this patch or the external
package.

Best,
Jack

>From 44bdfbbd9858f4190e4404467fa61b8a3f445347 Mon Sep 17 00:00:00 2001
From: Jack Kamm 
Date: Sat, 21 Jan 2023 08:24:41 -0800
Subject: [PATCH] ob-python: Remove python-mode.el support

* lisp/ob-python.el (org-babel-python-mode): Remove customization
variable.
(org-babel-python-initiate-session-by-key): Remove code to support
python-mode.el.
(org-babel-python-send-string): Renamed from
org-babel-python--send-string, turning it into a public function to
accommodate ob-python-mode-mode which advises this function. Also,
remove some code for python-mode.el
(org-babel-python-evaluate-session): Update calls to renamed function
org-babel-python-send-string.
---
 etc/ORG-NEWS  | 10 ++
 lisp/ob-python.el | 88 +--
 2 files changed, 34 insertions(+), 64 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 3ef76ec1a..ad7bd6604 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -12,6 +12,16 @@ See the end of the file for license conditions.
 Please send Org bug reports to mailto:emacs-orgmode@gnu.org.
 
 * Version 9.7 (not released yet)
+** Important announcements and breaking changes
+*** =python-mode.el (MELPA)= support in =ob-python.el= is removed
+
+=python-mode.el= support has been removed from =ob-python.el=. The
+related customization =org-babel-python-mode= has also been removed.
+
+If you still want to use python-mode with ob-python, you might
+consider [[https://gitlab.com/jackkamm/ob-python-mode-mode][ob-python-mode-mode]], where the code to support python-mode
+has been ported to.
+
 ** New options
 *** New options for the "csl" citation export processor's LaTeX output
 
diff --git a/lisp/ob-python.el b/lisp/ob-python.el
index 39fe5c28d..f19440e00 100644
--- a/lisp/ob-python.el
+++ b/lisp/ob-python.el
@@ -36,10 +36,6 @@ (require 'ob)
 (require 'org-macs)
 (require 'python)
 
-(declare-function py-shell "ext:python-mode" ( args))
-(declare-function py-choose-shell "ext:python-mode" ( shell))
-(declare-function py-shell-send-string "ext:python-mode" (strg  process))
-
 (defvar org-babel-tangle-lang-exts)
 (add-to-list 'org-babel-tangle-lang-exts '("python" . "py"))
 
@@ -52,16 +48,6 @@ (defcustom org-babel-python-command "python"
   :group 'org-babel
   :type 'string)
 
-;; FIXME: Remove third-party `python-mode' package support in the next release.
-(defcustom org-babel-python-mode
-  (if (featurep 'python-mode) 'python-mode 'python)
-  "Preferred python mode for use in running python interactively.
-This will typically be either `python' or `python-mode'."
-  :group 'org-babel
-  :version "24.4"
-  :package-version '(Org . "8.0")
-  :type 'symbol)
-
 (defcustom org-babel-python-hline-to "None"
   "Replace hlines in incoming tables with this when translating to python."
   :group 'org-babel
@@ -183,7 +169,6 @@ (defun org-babel-python-without-earmuffs (session)
 	(substring name 1 (- (length name) 1))
   name)))
 
-(defvar py-which-bufname)
 (defvar python-shell-buffer-name)
 (defvar-local org-babel-python--initialized nil
   "Flag used to mark that python session has been initialized.")
@@ -197,47 +182,25 @@ (defun org-babel-python-initiate-session-by-key ( session)
 	   (cmd (if (member system-type '(cygwin windows-nt ms-dos))
 		(concat org-babel-python-command " -i")
 		  org-babel-python-command)))
-  (cond
-   ((eq 'python org-babel-python-mode) ; python.el
-	(unless py-buffer
-	  (setq py-buffer (org-babel-python-with-earmuffs session)))
-	(let ((python-shell-buffer-name
-	   (org-babel-python-without-earmuffs py-buffer)))
-	  (run-python cmd)
-  (with-current-buffer py-buffer
-(add-hook
- 'python-shell-first-prompt-hook
- (lambda ()
-   (setq-local org-babel-python--initialized t)
-   (message "I am running!!!"))
- nil 'local
-   ((and (eq 'python-mode org-babel-python-mode)
-	 (fboundp 'py-shell)) ; python-mode.el
-	(require 'python-mode)
-	;; Make sure that py-which-bufname is initialized, as otherwise
-	;; it will be overwritten the first time a Python buffer is
-	;; created.
-	(py-choose-shell)
-	;; `py-shell' creates a buffer whose name is the value of
-	;; `py-which-bufname' with '*'s at the beginning and end
-	(let* ((bufname (if (and py-buffer (buffer-live-p py-buffer))
-			(replace-regexp-in-string ;; zap surrounding *
-			 "^\\*\\([^*]+\\)\\*$" "\\1" py-buffer)
-			  (concat 

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

[Edgar Lux]

January 22, 2023 at 12:15:14 PM CET Ihor Radchenko  
wrote:Edgar Lux  writes:
> Note that we have https://orgmode.org/manual/Citation-export-processors.html
> Of course, the "Citations" section of the manual is not yet complete.
> More examples and details will be welcome.

Yes, indeed

> > #+cite_export: biblatex "bibstyle=numeric-comp,sorting=none, 
> > hyperref=true,backref=true,url=true,backend=biber,natbib=true"
>
> The general design is
> #+cite_export: NAME BIBLIOGRAPHY-STYLE CITATION-STYLE
> ... removed content ...
> I am not sure how your idea fits the above.

The general design only allows two options (and their values) to be passed to 
=biblatex= (in the =#+cite_export:= line): =bibstyle= and =citestyle=. However, 
=biblatex= can take many more options. Currently (correct me if I am wrong), 
the two alternatives to pass more options is to use a 
=org-cite-biblatex-options= or a line like this

#+begin_src org
  ,#+LaTeX_HEADER: \usepackage[bibstyle=numeric-comp,sorting=none, 
hyperref=true,backref=true,url=true,backend=biber,natbib=true]{biblatex}
#+end_src

> Also, note that `org-cite-biblatex--package-options' combines INITIAL
> option list from the \usepackage declaration already present with
> options dictated by STYLE.

Precisely.

> However, only certain options are considered.
> After applying your patch, things may be broken in this area.

One of the attachments showed what I considered to be all possible cases: the 
new string (containing =style==; it could be either =bibstyle==, =citestyle==. 
It is similar to the case which allows for ="bibstyle/citestyle"=, as 
documented on line 34 of =oc-biblatex.el=). Currently (these could, hopefully, 
also be used for the documentation), if somebody uses

1. case
   #+begin_src org
 #+cite_export: biblatex "how/much"
   #+end_src

   the result is
   #+begin_src latex
 \usepackage[bibstyle=how,citestyle=much]{biblatex}
   #+end_src

2. case
   #+begin_src org
 #+cite_export: biblatex "how" "much"
   #+end_src

   the result is
   #+begin_src latex
 \usepackage[style=how]{biblatex}
   #+end_src

3. case
   #+begin_src org
 #+cite_export: biblatex "how,opt=true"
   #+end_src

   the result is
   #+begin_src latex
 \usepackage[style=how,opt=true]{biblatex}
   #+end_src

4. case
   #+begin_src org
 #+cite_export: biblatex "how/much,hack=true"
   #+end_src

   the result is
   #+begin_src latex
 \usepackage[bibstyle=how,citestyle=much,hack=true]{biblatex}
   #+end_src

5. case
   #+begin_src org
 #+cite_export: biblatex "citestyle=corner/much"
   #+end_src

   the result is
   #+begin_src latex
 \usepackage[bibstyle=citestyle=corner,citestyle=much]{biblatex}
   #+end_src

6. case
   #+begin_src org
 #+cite_export: biblatex "citestyle=corner/much,opt=true"
   #+end_src

   the result is
   #+begin_src latex
 \usepackage[bibstyle=citestyle=corner,citestyle=much,opt=true]{biblatex}
   #+end_src

7. case
   #+begin_src org
 #+cite_export: biblatex "bibstyle=corner"
   #+end_src

   the result is
   #+begin_src latex
 \usepackage[style=bibstyle=corner]{biblatex}
   #+end_src

8. case
   #+begin_src org
 #+cite_export: biblatex "bibstyle=corner/much"
   #+end_src

   the result is
   #+begin_src latex
 \usepackage[bibstyle=bibstyle=corner,citestyle=much]{biblatex}
   #+end_src

9. case
   #+begin_src org
 #+cite_export: biblatex "[bibstyle=corner/much]"
   #+end_src

   the result is
   #+begin_src latex
 \usepackage[bibstyle=[bibstyle=corner,citestyle=much]]{biblatex}
   #+end_src

10. case (note that this can be combined with all the above)
#+begin_src emacs-lisp
  (setq org-cite-biblatex-options "nulloption=true")
#+end_src

#+begin_src org
  #+cite_export: biblatex "how/much"
#+end_src

the result is
#+begin_src latex
  \usepackage[nulloption=true,bibstyle=how,citestyle=much]{biblatex}
#+end_src

whether some of these are broken is up for discussion. The suggested patch adds 
one conditional case, which searches for ="syle="=, takes away the brackets and 
turns the above cases into:

1. case
   #+begin_src org
 #+cite_export: biblatex "how/much"
   #+end_src

   same result as above

2. case
   #+begin_src org
 #+cite_export: biblatex "how" "much"
   #+end_src

   same result as above

3. case
   #+begin_src org
 #+cite_export: biblatex "how,opt=true"
   #+end_src

   same result as above

4. case
   #+begin_src org
 #+cite_export: biblatex "how/much,hack=true"
   #+end_src

   same result as above

5. case
   #+begin_src org
 #+cite_export: biblatex "citestyle=corner/much"
   #+end_src

   the result is
   #+begin_src latex
 \usepackage[citestyle=corner,citestyle=much]{biblatex}
   #+end_src

6. case
   #+begin_src org
 #+cite_export: biblatex "citestyle=corner/much,opt=true"
   #+end_src

   the result is
   #+begin_src latex
 \usepackage[citestyle=corner,citestyle=much,opt=true]{biblatex}
   #+end_src

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

[Edgar Lux]

January 22, 2023 at 12:36:32 PM CET "András Simonyi"  
wrote:Dear All,

> There is also the customizable variable `org-cite-biblatex-options' to
> pass additional options,

That is very useful, indeed (I didn't know how to use it). Hopefully the e-mail 
which I just sent helps with the documentation.

> which could be used with #bind+ if document-specific options are needed.

Just in case, I think that you meant #+bind: . However, it didn't work for me 
(I'm blaming myself). I added this in line 16 of my 324-lines file

#+bind: org-cite-biblatex-options "opt=true"

but the =opt=true= value is not shown next to =\usepackage{biblatex}= when I 
export. I do have =org-export-allow-bind-keywords= set to =t=

> best wishes,
> András

you too!


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

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

[AW]

Am Sonntag, 22. Januar 2023, 09:32:34 CET schrieb Ihor Radchenko:
> Max Nikulin  writes:
> > 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
> 
> My notmuch allows me to click on the above link from inside the email.
> As for Org links, [[notmuch:id:3218434.44cspzl...@linux.fritz.box]]
> works the same via ol-notmuch.
> 

Works, great, one thing solved. Thank you!

> We could support mid: is the corresponding url schema existed and
> supported by various OSes.

Isn't this rather important? How many users of orgmode get TODOs via E-Mail 
and need an efficient way to come back from the TODO to its origin?

-- 
Regards,

Alexander

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

[Karl Voit]

Hi,

I think I've found a bug with org-crypt:

Org mode version 9.5.5 (release_9.5.5 @
/home/vk/src/external_compilations/emacs/lisp/org/)

GNU Emacs 28.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.33,
cairo version 1.16.0) of 2023-01-09


SUMMARY:

org-crypt fails to encrypt when org-encrypt-entry is set to a
different key than the default openpgp key and the default key is
expired.


BACKGROUND:

My setup involves an openpgp-key which is specifically used for
org-crypt. This key is not my default key A1234567 which I'm using
for encrypting and singing emails and such.

org-crypt-key is set to this secondary key, let's call it
org-openpgp-key. So the org-crypt setup is correct in that sense
that org-mode should not care about other keys than my
org-openpgp-key.

However, I've had the situation where the default openpgp key
expired on a machine. Please note that my org-openpgp-key did not
expire.

When I invoked org-decrypt-entry, decrypting works like always. Then
I modified something in this heading which is tagged with :crypt:.
On saving that buffer, org-crypt issues an error message:

| Error: (error "GPG error: \"Encrypt failed\", \"Unusable public key:
| A1234567; Exit\"")

This A1234567 key is my default key and not the org-openpgp-key.

org-encrypt-entry is causing this error at:

|   ;; Text and key have to be identical, otherwise we
|   ;; re-crypt.
|   (if (and (equal crypt-key key)
|(string= checksum (sha1 contents)))
|   (get-text-property 0 'org-crypt-text contents)
| (epg-encrypt-string epg-context contents crypt-key)))

After fixing the expiry date of A1234567, org-crypt was working
properly, using the correct org-openpgp-key again.

I do think this is wrong behavior: when the default key is expired
but a specific secondary key is used, encryption should be possible.

-- 
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: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode)

[Thomas S. Dye]

Aloha Max,

Max Nikulin  writes:

Thomas, notice that I resumed a postponed earlier part of 
discussion related to
timestamps in the past. Offset from UTC is almost always well 
defined this case.


My perception is that discussing timestamps in future, we came 
to agreement with

Tom that timestamps can be specified with timezone <2024-02-22
08:29@Australia/Sydney>, in UTC <2024-02-21
21:29@UTC>, or in local timezone <2024-02-22 08:29>

Now I had a hope to convince at least some participants that 
explicit time
offset may be used interchangeably with UTC. It is applicable to 
timestamps in
the past and to future timestamps when the person who created 
appointment
respects remote participants, so decided to rule out DST and fix 
absolute time.


Agreed, offset relative to UTC is absolute time.



On 22/01/2023 13:17, Thomas S. Dye wrote:

UTC is not a timezone.  It is absolute time.


I do not see any point to consider UTC too special.

It is independent of the legislative tampering (DST, etc.) that 
makes timezones difficult to work with.


Both timestamps [2023-01-21 Sat 21:29@UTC] and [2023-01-22 Sun 
08:29@+1100]
specify absolute time. "+1100" means 11 hours, not particular 
location. Do you

have an example of a case where I am wrong?


No, not if +1100 is relative to UTC.

I use the term "time zone" as a set of rules how to calculate 
offset at
particular time moment. UTC is a degenerate case of fixed zero 
offset. 
In this sense "+11:00" is not a timezone, it is time offset. 
Several time zones
(as set of rules) may have such offset at some specific time 
moments including

"Etc/GMT-11" that is a timezone.

This confuses me.  Calculating offset relative to a timezone, such 
as HST, refers to space/time and yields an event.  Calculating 
offset relative to UTC does not refer to space/time and yields 
absolute time.  IMO, using "time zone", which typically refers to 
a region of space/time, to refer to a set of rules that might 
yield absolute time invites the confusion Ramsey was hoping to 
avoid.


A side note. In my opinion, *by default* timestamps should be 
created in

local
time with no offset or timezone. There are should be some 
preferences to

enable
absolute timestamps and a function to fix offsets or timezone 
identifiers for
existing timestamp when the user realizes that they become 
necessary (e.g.

before a trip).

I don't think there should be a default.


Unfortunately hard choice of default value or behavior is 
unavoidable during
development of software. Consider a user who just have installed 
Org. Till it is
explicitly configured, perhaps it is better to add e.g. clocking 
entries without
offset or timezone assuming local time. It should be possible to 
change it

later.

Is there some way for Org to identify when it is likely that user 
has not specified time zone?  If so, a query might be useful.


So I do not see any advantages of UTC in comparison to time 
offset specific

to
particular time zone, usually user's local one. My vote is 
[2023-01-22 Sun
08:29@+1100] and not [2023-01-21 Sat 21:29@UTC] (of course, 
only in cases

when
identifiers like Australia/Sydney do not matter) with a 
configuration option

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

is a requirement of occurrences.


I consider the case when offset is already known because it is a 
time moment in
the past. Besides rare corner cases offset can be considered as 
a part of
authoritative data. Timestamps like [2023-01-22 Sun 08:29@+1100] 
can be

unambiguously mapped to UTC.

Yes, if +1100 is relative to UTC.  If not, then it assumes a 
timezone library that correctly includes the past time.


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

around the globe.


For timestamp in the past offsets simplifies calculation of 
duration. Offsets
may be used to fix absolute time before changing location when 
time zone was

omitted. Perhaps I will add more in another part of this thread.

After all, for a person in Berlin [2023-01-22 Sun 08:29@+1100] 
may tell more

than [2023-01-22 Sun 08:29@Australia/Sydney].


I'm not sure to follow this.  IIUC, the timestamp with offset 
refers to absolute time, whereas the timestamp with the 

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

[Thomas S. Dye]

Aloha Max,

Max Nikulin  writes:


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

Aloha Max,

Max Nikulin  writes:


On 21/01/2023 07:37, Thomas S. Dye wrote:

1) Occurrence, where the timestamp includes UTC;
2) Event relative to user, where the timestamp does not 
include UTC

or a
time zone; and 3)
Event not relative to user, where the timestamp includes 
the

relevant time
zone.


I'm curious to find out how the distinction between past and 
future

makes a difference.


For timestamps in the past "absolute" time is almost always 
known, so
beside timezone identifiers like Australia/Sydney it is possible 
to use
UTC or fixed offset 2023-01-21 Sat 05:55:54 -1000. If a 
timestamp in
future is bound to specific timezone then its identifier must be 
used
since the government may change time offset. Of course there are 
cases
when UTC or timestamps with fixed offsets are used as well: e.g. 
Lunar

eclipse or participants with multiple locations are expected.


Yes, of course!

FYI, lunar eclipse was Ramsey's example of an occurrence, which 
has to do with changes in the relations of things at a time.




So it is "feature" of some timestamps in future that attempt to 
store

them in UTC may lead to their invalidation later.


Yes, these are events, which are relative to a timezone, either 
implicit or explicit.





As to format for storage timestamps in Org files, particular
timestamps may have
or not explicitly specified timezones, but it is unrelated to 
these 3

cases.


I'm curious to learn the classification unrelated to these 
three cases

used to determine when to store UTC and timezone.

...
From my point of view these, 3 cases might be relevant to 
date-time

picker UI,
but not for storage format. While parsing, interpretation of 
each

timestamp
without explicit timezone depends on preferences chosen at 
higher scope.


I'm curious what these preferences are, or might be.


Is the following timestamp is in user local timezone or in UTC?

<2023-02-01 Wed 15:00>

If features like the following is implemented then it will not 
be in

local time zone:
- file-local

   #+TIMEZONE: UTC
   or

   #+TIMEZONE: Australia/Sydney
- subtree-local

   * H1
   :PROPERTIES:
   :TIMEZONE: Australia/Sydney
   :END:

So looking at such timestamp it would be hard to choose 
particular case

from the set you proposed.

This might be a feature, not a bug.  A timestamp that does not 
indicate absolute time (UTC or fixed offset) and does not include 
a timezone relies on the timezone set by user.  So user changes 
timezone preference during trips and these timestamps become 
relative to user's local time.


A timestamp with absolute time or with a timezone would ignore 
user's timezone preference.


Of course it leads to tricky cases when some timestamp is copied 
to a
scope with another time zone. It requires some yank handler and 
text
properties. When timezone is added to a subtree, perhaps, all 
timestamps

inside may need to be changed from implicit timezone.

Perhaps the solution here is to consider this a feature, not a 
bug.  When displaying an event timestamp, the timezone should 
always be indicated.  For an event relative to user, this would be 
the preference currently in scope.  For an event not relative to 
user, the timezone will be part of the timestamp.



For storage format I would use another types
- explicit/implicit time zone
Yes, explicit for events not relative to user, implicit for events 
relative to user.


- Specific timezone/fixed offset. UTC and Etc/GMT-11 zones are 
identical

to + and +1100 offsets accordingly.


Here, absolute time is best, either UTC or fixed offset from UTC 
(don't underestimate legislators' folly changing timezones).


For UI it is better to choose some terms to make the manual and 
UI

dialogues more clear.


Agreed, though I don't have suggestions atm.

I am not a native English speaker and terms "event", 
"occurrence" sounds
confusing for me. E.g. a conference is an event. A regular 
meeting (even
when scheduled in another time zone) or "brush teeth" are more 
close to
occurrence. As soon as you have to split "event" category into 2 
parts
perhaps it is better to pick 3 different names. I may ask for 
fourth
that is absolute, but not UTC, but I would prefer to not insist 
on

namely UTC and use fixed offset instead.

Yes, UTC and fixed offset (from UTC) are two ways of specifying 
absolute time.  Neither one refers to a timezone.



For UI it is meaningful to name
- default time zone for this scope (with a hint if it is 
currently

system-wide, file-local, or specific to subtree), so no explicit
timezone will be set.
- absolute (UTC or fixed offset) preferred for global event
- bound to location (e.g. Australia/Sydney)
- ad-hoc timezone that follows user in their trips (close to 
Ramsey's

"occurrence").


I think the first and last can be considered identical (see 
above).


Also note that ad-hoc timezone is an event because it specifies a 
timezone, which is a 

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

[Max Nikulin]

On 22/01/2023 19:14, Max Nikulin wrote:
- ad-hoc timezone that follows user in their trips (close to Ramsey's 
"occurrence").


Sorry, it should be "event", not "occurrence". It was not intentional 
demonstration of my confusion.

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

[Max Nikulin]

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

Aloha Max,

Max Nikulin  writes:


On 21/01/2023 07:37, Thomas S. Dye wrote:

1) Occurrence, where the timestamp includes UTC;
2) Event relative to user, where the timestamp does not include UTC 
or a

time zone; and 3)
Event not relative to user, where the timestamp includes the 
relevant time

zone.


I'm curious to find out how the distinction between past and future 
makes a difference.


For timestamps in the past "absolute" time is almost always known, so 
beside timezone identifiers like Australia/Sydney it is possible to use 
UTC or fixed offset 2023-01-21 Sat 05:55:54 -1000. If a timestamp in 
future is bound to specific timezone then its identifier must be used 
since the government may change time offset. Of course there are cases 
when UTC or timestamps with fixed offsets are used as well: e.g. Lunar 
eclipse or participants with multiple locations are expected.


So it is "feature" of some timestamps in future that attempt to store 
them in UTC may lead to their invalidation later.


As to format for storage timestamps in Org files, particular 
timestamps may have
or not explicitly specified timezones, but it is unrelated to these 3 
cases.


I'm curious to learn the classification unrelated to these three cases 
used to determine when to store UTC and timezone.

...
From my point of view these, 3 cases might be relevant to date-time 
picker UI,
but not for storage format. While parsing, interpretation of each 
timestamp

without explicit timezone depends on preferences chosen at higher scope.


I'm curious what these preferences are, or might be.


Is the following timestamp is in user local timezone or in UTC?

<2023-02-01 Wed 15:00>

If features like the following is implemented then it will not be in 
local time zone:

- file-local
  #+TIMEZONE: UTC
  or
  #+TIMEZONE: Australia/Sydney
- subtree-local
  * H1
  :PROPERTIES:
  :TIMEZONE: Australia/Sydney
  :END:

So looking at such timestamp it would be hard to choose particular case 
from the set you proposed.


Of course it leads to tricky cases when some timestamp is copied to a 
scope with another time zone. It requires some yank handler and text 
properties. When timezone is added to a subtree, perhaps, all timestamps

inside may need to be changed from implicit timezone.

For storage format I would use another types
- explicit/implicit time zone
- Specific timezone/fixed offset. UTC and Etc/GMT-11 zones are identical 
to + and +1100 offsets accordingly.


For UI it is better to choose some terms to make the manual and UI 
dialogues more clear.


I am not a native English speaker and terms "event", "occurrence" sounds 
confusing for me. E.g. a conference is an event. A regular meeting (even 
when scheduled in another time zone) or "brush teeth" are more close to 
occurrence. As soon as you have to split "event" category into 2 parts 
perhaps it is better to pick 3 different names. I may ask for fourth 
that is absolute, but not UTC, but I would prefer to not insist on 
namely UTC and use fixed offset instead.


For UI it is meaningful to name
- default time zone for this scope (with a hint if it is currently 
system-wide, file-local, or specific to subtree), so no explicit 
timezone will be set.

- absolute (UTC or fixed offset) preferred for global event
- bound to location (e.g. Australia/Sydney)
- ad-hoc timezone that follows user in their trips (close to Ramsey's 
"occurrence").


The problem is to push users to timezone identifiers for future 
timestamps associated with some location. Offsets must be discouraged 
this case, but encouraged for on-line meetings. For past timestamps 
particular choice is less important. That is why I separated future/past 
timestamps.


Agreed.  The boss needs to inform you what her local time will be for 
the meeting by sending you a timestamp with a time zone. Ideally, Org 
would know how to associate the timestamp with a recurring item stored 
locally.


Unsure it it may be implemented reliably.

Nowadays, I am frequently asked by applications to give permission for 
using my location.  When I give it, the application reports back with my 
local postal code, etc.  I'm assuming Org can use location to determine 
my current timezone.


libc has a concept of timezone. I think, it should be the primary 
source. It is initialized on application startup (roughly) from 
system-wide settings, may be overridden by TZ environment and changed 
later by setting another value of TZ. The problem is that identifier 
like "Australia/Sydney" is considered implementation specific and is not 
directly accessible from the code, it is sealed inside the library. 
Another issue is that I do not know if Emacs is able to receive 
notifications on change of system-wide timezone.


Web-application may request time zone settings from the browser:
new Intl.DateTimeFormat().resolvedOptions().timeZone

Android devices may have outdated and incomplete zoneinfo database. This 

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

[Ihor Radchenko]

Max Nikulin  writes:

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

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

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

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

[Ihor Radchenko]

Tim Ruffing  writes:

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

Thanks for reporting!
May you try the attached patch?

I am, however, still concerned about how `org-read-date' is handling
`org-extend-today-until'.

If we have something like

* This is test
SCHEDULED: <2023-01-28 Sat>

Then, M-: (setq org-extend-today-until 20)
Then, C-c C-s on the heading above

What will happen if one tries to do "." or +1 or ++1. I find the current
behavior rather disorienting. Could someone check what we promise in the
Org manual, `org-read-date' docstring, `org-extend-today-until'
docstring, and what actually happens in practice?

>From 998f2f9b93f5727942fa0e53567288ebcf544764 Mon Sep 17 00:00:00 2001
Message-Id: <998f2f9b93f5727942fa0e53567288ebcf544764.1674387603.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Sun, 22 Jan 2023 14:37:47 +0300
Subject: [PATCH] org-read-date: Do not consider `org-extend-today-until' with
 default time

* lisp/org.el (org-read-date): When DEFAULT-TIME time provided, prefer
it even when `org-extend-today-until' dictates -1 day shift.  We
should only consider `org-extend-today-until' for actual today times,
not for future dates, where is becomes confusing.

Reported-by: Tim Ruffing 
Link: https://orgmode.org/list/3489c1917ad4be0625ea5f0b2c1b0f2b72ea39e9.ca...@timruffing.de
---
 lisp/org.el | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index 0e6a3da0a..f4cc7b4be 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -13695,7 +13695,11 @@ (defun org-read-date ( with-time to-time from-string prompt
 	 (calendar-view-holidays-initially-flag nil)
 	 ans (org-ans0 "") org-ans1 org-ans2 final cal-frame)
 ;; Rationalize `org-def' and `org-defdecode', if required.
-(when (< (nth 2 org-defdecode) org-extend-today-until)
+;; Only consider `org-extend-today-until' when explicit reference
+;; time is not given.
+(when (and (not default-time)
+   (not org-overriding-default-time)
+   (< (nth 2 org-defdecode) org-extend-today-until))
   (setf (nth 2 org-defdecode) -1)
   (setf (nth 1 org-defdecode) 59)
   (setq org-def (org-encode-time org-defdecode))
-- 
2.39.1


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

[András Simonyi]

Dear All,

On Sun, 22 Jan 2023 at 12:15, Ihor Radchenko  wrote:

> Also, note that `org-cite-biblatex--package-options' combines INITIAL
> option list from the \usepackage declaration already present with
> options dictated by STYLE. However, only certain options are considered.
> After applying your patch, things may be broken in this area.

There is also the customizable variable `org-cite-biblatex-options' to
pass additional options,
which could be used with #bind+ if document-specific options are needed.

best wishes,
András

> P.S. Could you please send patches as plain text? They are easier to
> view then.
>
> --
> 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 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:

Note that we have https://orgmode.org/manual/Citation-export-processors.html
Of course, the "Citations" section of the manual is not yet complete.
More examples and details will be welcome.

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

The general design is
#+cite_export: NAME BIBLIOGRAPHY-STYLE CITATION-STYLE

There, NAME is the name of a registered citation processor providing export
functionality, as a symbol.  BIBLIOGRAPHY-STYLE (respectively CITATION-STYLE)
is the desired default style to use when printing a bibliography (respectively
exporting a citation), as a string or nil.  Both BIBLIOGRAPHY-STYLE and
CITATION-STYLE are optional.  NAME is mandatory.

I am not sure how your idea fits the above.

Also, note that `org-cite-biblatex--package-options' combines INITIAL
option list from the \usepackage declaration already present with
options dictated by STYLE. However, only certain options are considered.
After applying your patch, things may be broken in this area.

P.S. Could you please send patches as plain text? They are easier to
view then.

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

[Bastien Guerry]

Hi,

Ihor Radchenko  writes:

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

I cannot find any entry with "Gerler" as a name, or with the email
"ba...@bundesbrandschatzamt.de".

Andreas, can you write me in private with a copy of the signed FSF
copyright assignment?  We can sort this out with the FSF copyright
clerk.

Thanks,

-- 
 Bastien

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

[Max Nikulin]

On 22/01/2023 15:32, Ihor Radchenko wrote:

Max Nikulin writes:

My notmuch allows me to click on the above link from inside the email.
As for Org links, [[notmuch:id:3218434.44cspzl...@linux.fritz.box]]
works the same via ol-notmuch.

We could support mid: is the corresponding url schema existed and
supported by various OSes.


Does emacs support query to desktop environment if specific URI schema 
is supported? Anyway it will increase load time. Instead list of types 
for `browse-url' may be converted into a user option, currently it is 
hard coded:


(dolist (scheme '("ftp" "http" "https" "mailto" "news"))
  (org-link-set-parameters scheme
   :follow
   (lambda (url arg)
 (browse-url (concat scheme ":" url) arg

Currently I use

(with-eval-after-load 'ol
  (org-link-set-parameters
   "mid"
   :follow (lambda (url  arg)
 (browse-url (concat "mid:" url) arg

See Org FAQ https://orgmode.org/worg/org-faq.html#org1d563f2 "Can I 
create links to Thunderbirds emails?"


I suppose, notmuch may provide a function for "mid:" associatiopn in 
`browse-url-handler' and a .desktop file similar to


http://git.savannah.gnu.org/cgit/emacs.git/tree/etc/emacsclient-mail.desktop

for handling mid: links from other applications.

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

[Jean Louis]

* Ihor Radchenko  [2023-01-22 11:34]:
> We could support mid: is the corresponding url schema existed and
> supported by various OSes.

Instead of supporting hard coded `mid:` in Org, you better support
generally anything that users may define with variable
`browse-url-handlers` and `browse-url-default-handlers` or
`thing-at-point-uri-schemes', that way you need not need to hard code
it in Org, let it be handled on Emacs level.

Hide browse-url-handlers: 
'(("gemini:" . elpher-go)
  ("gopher:" . elpher-handler-go)
  ("about:" . hyperscope-about)
  ("mid:" . mutt-by-message-id)
  ("hyperscope:" . hyperscope-go)
  ("e2dk://" . amule-handler))

Unless it already works that way.

But on my side it opens up GUI widget telling me "No match, create
heading" -- which is wrong.

If I however, turn on M-x goto-address-mode then about:hyperscope and
mid:123 starts working automatically, it is handled by user's choice.


List of URI Schemes:
https://en.wikipedia.org/wiki/List_of_URI_schemes


--
Jean

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

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

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

[Max Nikulin]

Thomas, notice that I resumed a postponed earlier part of discussion 
related to timestamps in the past. Offset from UTC is almost always well 
defined this case.


My perception is that discussing timestamps in future, we came to 
agreement with Tom that timestamps can be specified with timezone 
<2024-02-22 08:29@Australia/Sydney>, in UTC <2024-02-21

21:29@UTC>, or in local timezone <2024-02-22 08:29>

Now I had a hope to convince at least some participants that explicit 
time offset may be used interchangeably with UTC. It is applicable to 
timestamps in the past and to future timestamps when the person who 
created appointment respects remote participants, so decided to rule out 
DST and fix absolute time.


On 22/01/2023 13:17, Thomas S. Dye wrote:


UTC is not a timezone.  It is absolute time.


I do not see any point to consider UTC too special.

Both timestamps [2023-01-21 Sat 21:29@UTC] and [2023-01-22 Sun 
08:29@+1100] specify absolute time. "+1100" means 11 hours, not 
particular location. Do you have an example of a case where I am wrong?


I use the term "time zone" as a set of rules how to calculate offset at 
particular time moment. UTC is a degenerate case of fixed zero offset. 
In this sense "+11:00" is not a timezone, it is time offset. Several 
time zones (as set of rules) may have such offset at some specific time 
moments including "Etc/GMT-11" that is a timezone.


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

before a trip).


I don't think there should be a default.


Unfortunately hard choice of default value or behavior is unavoidable 
during development of software. Consider a user who just have installed 
Org. Till it is explicitly configured, perhaps it is better to add e.g. 
clocking entries without offset or timezone assuming local time. It 
should be possible to change it later.


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

with timezone used fix offsets in stored timestamps.


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


I consider the case when offset is already known because it is a time 
moment in the past. Besides rare corner cases offset can be considered 
as a part of authoritative data. Timestamps like [2023-01-22 Sun 
08:29@+1100] can be unambiguously mapped to UTC.


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


For timestamp in the past offsets simplifies calculation of duration. 
Offsets may be used to fix absolute time before changing location when 
time zone was omitted. Perhaps I will add more in another part of this 
thread.


After all, for a person in Berlin [2023-01-22 Sun 08:29@+1100] may tell 
more than [2023-01-22 Sun 08:29@Australia/Sydney].

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

[Ihor Radchenko]

Max Nikulin  writes:

> 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

My notmuch allows me to click on the above link from inside the email.
As for Org links, [[notmuch:id:3218434.44cspzl...@linux.fritz.box]]
works the same via ol-notmuch.

We could support mid: is the corresponding url schema existed and
supported by various OSes.

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

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

[Tim Cross]

Max Nikulin  writes:

> On 22/01/2023 04:29, Tim Cross wrote:
>> Max Nikulin writes:
>>> - UTC is a recommendation for planning when participants are scattered over 
>>> multiple
>>>   timezones.
>>> - You admit that some timestamps in your files may be specified as time 
>>> zone identifier +
>>>   local time relative to this zone.
>>> - In both cases you may configure overlays to use local timezone or another 
>>> one whatever
>>>   you currently find convenient.
>>> - Time chooser offers several time zone options.
>> That seems to be in-line with what I was arguing, so yes, would agree.
>
> Great. At this stage my goal is to convince people that local time and UTC 
> for future
> timestamps are not enough for real life use cases. Arbitrary timezone may be 
> crucial to
> arrive at proper time despite it matters in rare cases. My concern is mostly 
> storage
> format, timestamp syntax in Org files.
>
> On 21/01/2023 06:38, Tim Cross wrote:
 I would also argue UTC is good for 'traditional' timestamps which record
 a specific point in time and for situations where you want accurate
 calculations of time durations.
>
> Let's consider the following timestamp
>
> [2023-01-22 Sun 08:29@+1100]
>
> "@" is unimportant here, I take it from Ihor's examples. This timestamp is 
> from the
> "Date:" header of your message. It is not UTC, but in my opinion it is 
> equally precise
> (disregarding seconds) to a UTC timestamp.
>
> Would you prefer to have timestamps in your files in such form or as
>
> [2023-01-21 Sat 21:29Z] ([2023-01-21 Sat 21:29@UTC], [2023-01-21 Sat 
> 21:29@+00:00], etc)?
>
> Maybe [@1674336588] (seconds since epoch)?
>

It really depends on what the timestamp is for as to what my preference
would be.  For example, timestamp for an email message is likely best as
your initial example or date with remote senders TZ. Timestamp for a log
record I would probably want  or one of the
variants because the most common way I use those types of timestamp is
in diagnosing problems and comparing revords from various locations
where I don't care about the local time where the record was generated,
but with when it occurred in relation to other log recores.  

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

I would argue that all depends on how you use the information. My org
files are consumed by me (reading) and by scripts, elisp and other
programs. 

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

Guess I agree, but this is such a rare/small use case, I really don't
consider it terribly relevant. While I do share data relating to
projects I work on with others, I am the only one who uses org mode and
I suspect I'm the only one who uses Emacs. Sharing org mode files simply
isn't a use case I need to worry about and sharing timestamp data from
those files is rare as well - if I do need to, they will likely be
processed into some other more standard format anyway. 

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

Again, depends on the use case and how you use the data. 

> A side note. In my opinion, *by default* timestamps should be created in 
> local time with
> no offset or timezone. There are should be some preferences to enable 
> absolute timestamps
> and a function to fix offsets or timezone identifiers for existing timestamp 
> when the user
> realizes that they become necessary (e.g. before a trip).
>
> So I do not see any advantages of UTC in comparison to time offset specific 
> to particular
> time zone, usually user's local one. My vote is [2023-01-22 Sun 08:29@+1100] 
> and not
> [2023-01-21 Sat 21:29@UTC] (of course, only in cases when identifiers like
> Australia/Sydney do not matter) with a configuration option with timezone 
> used fix offsets
> in stored timestamps.

My preference is for a timestamp syntax which lets the user select the
format they want and not attempt to restrict it more than that. Provided
you can specify timestamp with and without TZ information and you
support full and abbreviated time zone names as well as UTC, I don't
think it mattters - let the user choose what suits them best. I
definitely have use cases where timestamp in UTC is the most convenient
format. 

My default would be without time zones, but enable easy adding of
timezones when needed e.g. by calling the function with