Timestamp and timestamp range definitions

[Ilya Chernyshov]

Hello

What's a type of timestamp <2022-10-15 Sat 10:00-13:00>?


From org-manual:


the definition for a timestamp is:

A timestamp is a specification of a date (possibly with a time or 
a range of times) in a
special format, either '<2003-09-16 Tue>' or '<2003-09-16 Tue 
09:39>'

or ‘<2003-09-16 Tue 12:00-12:30>'

Also, the definition for timestamp range is:

Two timestamps connected by '--' denote a range. The headline is 
shown on
the first and last day of the range, and on any dates that are 
displayed and fall

in the range. Here is an example:
,* Meeting in Amsterdam
<2004-08-23 Mon>--<2004-08-26 Thu>

But, according to tests in test-org-element.el such a timestamp is
considered a timerange [added in commit cb32494e2]:

(should
  (eq 'active-range
  (org-test-with-temp-text "<2012-03-29 Thu 7:30-16:40>"
 (org-element-property :type (org-element-context)

So, we either should change the behavior of
(org-element-timestamp-parser) or update the definitions of 
timestamp

and timestamp range in org-manual. What do you think?
--
Best,
Ilya

Re: [RFC] If you use Org 9.6, please share the output of M-x org-element-cache-hash-show-statistics

[orzodk]

Ihor Radchenko  writes:

> Hi,
>
> I would like to assess the efficiency of one of search optimizations used
> in org-element.el [1]
>
> The statistics about efficiency is collected by Org, but obviously not
> shared without your consent.
>
> If you are ok with sharing the statistics, and you are running Emacs
> session for at least few hours (using Org mode, obviously), please reply
> sharing the output of
>  M-x org-element-cache-hash-show-statistics 
>  M-x emacs-uptime 
>
> [1] Pugh [Information Processing Letters] (1990) Slow optimally balanced
>  search strategies vs. cached fast uniformly balanced search strategies.
>  http://dx.doi.org/10.1016/0020-0190(90)90130-P

20.43% of cache searches hashed, 29.71% non-hashable.

2 days, 5 hours, 49 minutes, 48 seconds

GNU Emacs 29.0.60 (build 1, aarch64-apple-darwin22.2.0, NS
appkit-2299.30 Version 13.1 (Build 22C65)) of 2023-02-08

Org mode version 9.6.1 (9.6.1-g02ae90 @
/Users/o/.emacs.d/straight/build/org/)

Re: [PATCH] Async evaluation in ob-shell

[Matt]

  On Sat, 11 Feb 2023 06:44:56 -0500  Ihor Radchenko  wrote --- 
 > 1. You should provide all the docstrings.
 > 2. I generally feel that separate async and separate session code are
 >either duplicating the same code or edge cases considered by session
 >code may popup in async code unexpectedly.

Excellent points.  Thank you.

As part of the commit, I want to include tests.

How to test an async block is non-obvious.  The initial evaluation returns a 
uuid which returns immediately and can be checked using a regex:

(defconst test-ob-shell/uuid-regex
  
"[0-9a-fA-F]\\{8\\}\\b-[0-9a-fA-F]\\{4\\}\\b-[0-9a-fA-F]\\{4\\}\\b-[0-9a-fA-F]\\{4\\}\\b-[0-9a-fA-F]\\{12\\}")

Technically, this is a ob-comint aspect and may be more rightly included in 
(the currently non-existant) tests for that module.

Checking the final result from the callback is trickier.   The following works, 
but requires advice (which could potentially persist beyond the test) and a 
delay (which slows testing overall and whose duration likely depends on the 
hardware the test runs on).  Without the delay, I could not get the callback to 
execute within the test.  It would execute when running manually in an Org 
buffer, however.  I'm not sure why. 

(ert-deftest test-ob-shell/session-async-evaluation ()
  (let ((session-name "test-ob-shell/session-async-evaluation")
(kill-buffer-query-functions nil)
result)
;; perform check after the callback executes which looks for the
;; expected result
(advice-add
 'ob-shell-async-chunk-callback
 :filter-return
 (lambda ( r)
   (let ((result (car r)))
 (if (not (string= result "1\n2\n"))
 (ert-fail (format "Expected 1\n2\n: %s" result)))
 result))
 `((name . ,session-name)))
;; always remove the advice, regardless of test outcome
(unwind-protect
(org-test-with-temp-text
(concat "#+begin_src sh :session " session-name " :async t
echo 1
echo 2
#+end_src")
  ;; execute the block; delay momentarily so that the callback
  ;; executes
  (setq result (org-trim (org-babel-execute-src-block)))
  (if (should
   (and
;; if the block runs...
(string-match
 test-ob-shell/uuid-regex
 result)
;; ...and the callback executes without fail
(not (sleep-for 0.1
  ;; clean up buffer on success
  (kill-buffer session-name)))
  (advice-remove 'ob-shell-async-chunk-callback session-name

This works for me using the last patch.

Thoughts?

Re: [PATCH] Async evaluation in ob-shell

[Matt]

  On Sat, 11 Feb 2023 15:56:00 -0500wrote --- 
 > org-babel-comint-async-filter is capable of taking a similar approach,
 > and reading/writing to tempfile.

There is some precedence in ob-shell for this.  Currently, the cmdline, stdin, 
and shebang headers use temp files.  It may be that implementing async versions 
of these could use this part of the async API.  However, cmdline, stdin, and 
shebang each use a temporary shell process rather than a dedicated comint, even 
when the :session header is present.  The async implementation requires a 
comint buffer.

 > I believe this approach would be
 > generally more robust, but the major weakness is that it would break if
 > you SSH'd to a remote host in the middle of the session.

Good point.

 > There was an interesting patch to ob-shell that was never applied, that
 > took the approach of wrapping the code block in a bash function before
 > executing; I think it might be a promising approach:
 > 
 > https://lists.gnu.org/archive/html/emacs-orgmode/2020-02/msg00923.html
 
This is interesting.  Thanks for sharing!  Instead of writing to a temp file, 
it could use a here document.  Here documents, AFAIK, are POSIX portable, 
although function definitions aren't.  Of course, if we're considering Windows 
cmd (as we did in a recent bug report), there are all sorts of problems: batch 
syntax (executed from a file) is different than CLI syntax, functions will 
implemented using labels (I'm not sure how robust that is), and no here 
documents.  A comint would probably be best for the Windows use-case.

ahab@pequod ~$ guix shell dash
ahab@pequod ~ [env]$ dash <<- EOF 
my_function() { echo "hello, world!"; echo "the end"; }
my_function;
EOF
hello, world!
the end

ahab@pequod ~$ guix shell fish
ahab@pequod ~ [env]$ fish <<- EOF
> function my_function
>   echo "hello, world!"
>   echo "the end"
> end
> my_function
> EOF
hello, world!
the end

 > By the way, I took a look at ob-shell for the first time in awhile, and
 > noticed that ob-shell now forces the prompt to be like:
 > 
 > org_babel_sh_prompt>
 > 
 > Which I think makes cleaning up the prompt markers a lot more
 > robust. But it is a bit ugly, and also seems to break working with shell
 > sessions started outside of Babel with M-x shell.

Is this something you consider a bug?

Re: Problem with let/cl-letf binding stuff with org-capture

[Ihor Radchenko]

Arthur Miller  writes:

> And for the last time: I am not using this version of read-string, I don't 
> need
> it myself; it was just me thinking how to implement something after reading a
> blog post. Anyway, thanks for the input, it was valuable to me.

Note that Emacs 29 has `read-string-from-buffer'.
 
-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Problem with let/cl-letf binding stuff with org-capture

[Arthur Miller]

Bruno Barbier  writes:

> Hi Arthur,
>
> Arthur Miller  writes:
>
>> Bruno Barbier  writes:
>>
>> ...  but I feel a
>> bit of passive aggressivity here, for no good reason tbh.
>
> I'm just trying to help, giving some valid or invalid advices.  I'm
> sorry that what I wrote, and how I wrote it, made you feel that way.

It is ok, I just don't want us to go into social media discussion style where
there is more important to assert own ego then to come into some insight.

>>>
>>> Yes, let binding is fundamental. But I think it's the first time I see
>>> 'cl-letf' with the 'symbol-function' place.
>>
>> https://nullprogram.com/blog/2017/10/27/
>> https://endlessparentheses.com/understanding-letf-and-how-it-replaces-flet.html
>> https://stackoverflow.com/questions/39550578/in-emacs-what-is-the-difference-between-cl-flet-and-cl-letf
>>
>
> Thanks for these links. I like cl-flet and cl-labels :-)

They are good for introducing *new* bindings, not so for overriding locally.

 but I am not sure if I can do anything here without introducing at-least an
 extra keymap, to not install into the org-capture-mode-map, so I can as 
 well
 create a minor mode, but at this point it is not much different than
 re-invinting the read-string, so I'll terminate my experiment here :).
>>>
>>> You can replace the buffer keymap with a keymap that only contain your 
>>> custom
>>> keys, and inherits everything else from org-capture-mode-map.
>>
>> Isn't that what I wrote: introducing an extra keymap?
>> Of course I can solve the problem differently, but that was not what question
>> was about :).
>
> Right. Even when inheriting from the old keymap, it's still building a
> new keymap.  Sorry :-)
>
>
>> Well, I definitely understand you, and agree that overwriting function for
>> everyone and everything is not the best idea, but unfortunately bindings 
>> work as
>> they do in Emacs. I would prefer to have a local binding, with cl-flet, but 
>> this
>> does not work in Emacs:
>>
>> (defun my-read-string (prompt)
>>   (let ((delta 20 )
>> (minibuffer-mode-map org-mode-map))
>> (window-resize (minibuffer-window) delta)
>> (cl-flet ((org-ctrl-c-ctrl-c ()
>> (interactive)
>> (let ((s (buffer-string)))
>>   (exit-minibuffer) s))
>>   (minibuffer-mode () #'org-mode)
>>   (minibuffer-complete-and-exit () #'org-return)
>>   (org-kill-note-or-show-branches () #'keyboard-escape-quit))
>>   (read-string (concat "# Press C-c C-c to continue, C-c C-k to 
>> cancel\n# "
>>   prompt "\n\n")
>
> Yes. cl-flet looks safe to me :-)
>
>>
>> Hooks serve a different purpose. Advice can serve same purpose with exactly
>> same side effect, and some other limitations. With some care, let-binding is
>> still more "local" then advice. With other words, I agree with you about the
>> problems, but not with dogmatic approach that it should never be done, and
>> that hooks and advices are the replacement.
>
> Sorry if my words sounding dogmatic.
> Else, I agree too :-)
>
>
>>>
 I am very interested to hear more on the topic, since I would definitely 
 like to
 learn more about different techniques.
>>>
>>> Variables are designed to be overriden (let bounds). Functions are not
>>
>> I have never heard before that functions are not designed to be overriden. I
>> think of them as two slots in a symbol structure; let creates bindings for 
>> value
>> slot, and flet for function slot. Functions are just objects or data as any
>> other value in lisp.
>>
>>> (as there is only one binding at any given time).
>>
>> Yes, unfortunately, in Emacs it is so;
>
> ok. We do really agree then :-)
>
>
>> but I don't think it should be > :).
>
> ... oh no ! ;-)
>
>
>>
>> There is an interesting package by Nick Ferrier
>>
>> https://github.com/nicferrier/emacs-noflet
>
>> but it does not seem to work, at least not for me.
>
> It's almost like a temporary advice ;-)
>
>
> About your use case, if what you need is asynchronous editing, maybe the
> with-editor package will be of interest to you:
> https://github.com/magit/with-editor/blob/main/lisp/with-editor.el
> 
> It allows sub-processes to call Emacs for editing tasks. It's used by
> magit. It's easy enough to reuse. I've attached my attempt at it if
> you're interested.
>
> best,
>
> Bruno
>
> (cl-defun my-edit-async (finish  mode buffer-name setup cancel)
>   "Open a buffer, let the user edit its content.
> Return the editing buffer.  Call FINISH in the editing buffer if
> the user validates his edit (C-c C-c).  When CANCEL is non-nil,
> call CANCEL in the editing buffer if the user cancels his
> edit (C-c C-k). When done, delete the buffer and its content.
>
> When MODE is non-nil, use it as the major-mode.  When BUFFER-NAME
> is non-nil, use it to generate a new unique name of the editing buffer.
> When SETUP is non-nil, call it in the edit buffer to setup the
> buffer before starting 

[PATCH] Allow customizing commands affected by `org-fold-catch-invisible-edits' (was: Should we extend org-catch-invisible-edits to more interactive commands? (was: Catching invisible edits: problem u

[Ihor Radchenko]

alain.coch...@unistra.fr writes:

> Ihor Radchenko writes on Sat 11 Feb 2023 18:22:
>
>  > We can indeed at such warning, but it will probably be not very
>  > helpful.
>
> I don't understand this.  And isn't it better to have a more accurate
> manual anyway?

Sure. But I want to implement more generic feature.
See the attached patch.

> Also, this is another instance where 'C-h v' with the cursor on
> 'org-fold-catch-invisible-edits' does not offer it right away in the
> minibuffer.  I am surprised since it does so in 9.5 (with
> 'org-catch-invisible-edit').

The variable has been moved to a different file.
C-h v not working is an Emacs bug.

>From 653005e1b383b4c7ad9086fc0b7e40d262dab744 Mon Sep 17 00:00:00 2001
Message-Id: <653005e1b383b4c7ad9086fc0b7e40d262dab744.1676215378.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Sun, 12 Feb 2023 18:13:36 +0300
Subject: [PATCH] org-fold: Allow customizing commands where invisible edits
 are checked

* lisp/org-fold.el (org-fold-catch-invisible-edits-commands): New
custom option.
(org-fold-catch-invisible-edits): Mention the new custom option in the
docstring.
(org-fold-check-before-invisible-edit-maybe): New function checking
if edits are safe for `this-command'.
(org-fold--advice-edit-commands): New function advising the functions
with `org-fold-check-before-invisible-edit-maybe'.
* lisp/org.el (org-mode): Advice functions on Org startup.
(org-self-insert-command):
(org-delete-backward-char):
(org-delete-char):
(org-meta-return): Do not call `org-fold-check-before-invisible-edit'
and rely on the new advise mechanism instead.
* etc/ORG-NEWS (Commands affected by ~org-fold-catch-invisible-edits~
can now be customized): Announce the change.
* doc/org-manual.org (Catching invisible edits): Mention new
customization.
---
 doc/org-manual.org | 12 +---
 etc/ORG-NEWS   | 12 
 lisp/org-fold.el   | 45 -
 lisp/org.el|  6 ++
 4 files changed, 67 insertions(+), 8 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 2d38cf76c..2b836a026 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -622,11 +622,17 @@ *** Catching invisible edits
 #+cindex: edits, catching invisible
 
 #+vindex: org-fold-catch-invisible-edits
+#+vindex: org-fold-catch-invisible-edits-commands
 Sometimes you may inadvertently edit an invisible part of the buffer
 and be confused on what has been edited and how to undo the mistake.
-Setting ~org-fold-catch-invisible-edits~ to non-~nil~ helps preventing
-this.  See the docstring of this option on how Org should catch
-invisible edits and process them.
+By default, Org prevents such edits for a limited set of user
+commands.  Users can control which commands are affected by
+customizing ~org-fold-catch-invisible-edits-commands~.
+
+The strategy used to decide if a given edit is dangerous is controlled
+by ~org-fold-catch-invisible-edits~.  See the docstring of this option
+on the available strategies.  Set the option to ~nil~ to disable
+catching invisible edits completely.
 
 ** Motion
 :PROPERTIES:
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 87ecd77cd..b85c46758 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -24,6 +24,18 @@ consider [[https://gitlab.com/jackkamm/ob-python-mode-mode][ob-python-mode-mode]
 has been ported to.
 
 ** New and changed options
+*** Commands affected by ~org-fold-catch-invisible-edits~ can now be customized
+
+New user option ~org-fold-catch-invisible-edits-commands~ controls
+which commands trigger checking for invisible edits.
+
+The full list of affected commands is:
+- ~org-self-insert-command~
+- ~org-delete-backward-char~
+- ~org-delete-char~
+- ~org-meta-return~
+- ~org-return~ (not checked in earlier Org versions)
+
 *** New escape in ~org-beamer-environments-extra~ for labels in Beamer export
 The escape =%l= in ~org-beamer-environments-extra~ inserts the label
 obtained from ~org-beamer--get-label~.  This is added to the default
diff --git a/lisp/org-fold.el b/lisp/org-fold.el
index 1b7ca22b0..3d86eb802 100644
--- a/lisp/org-fold.el
+++ b/lisp/org-fold.el
@@ -189,7 +189,10 @@ (defcustom org-fold-catch-invisible-edits 'smart
  Never delete a previously invisible character or add in the
  middle or right after an invisible region.  Basically, this
  allows insertion and backward-delete right before ellipses.
- FIXME: maybe in this case we should not even show?"
+ FIXME: maybe in this case we should not even show?
+
+This variable only affects commands listed in
+`org-fold-catch-invisible-edits-commands'."
   :group 'org-edit-structure
   :version "24.1"
   :type '(choice
@@ -199,6 +202,33 @@ (defcustom org-fold-catch-invisible-edits 'smart
 	  (const :tag "Show invisible part and do the edit" show)
 	  (const :tag "Be smart and do the right thing" smart)))
 
+(defcustom org-fold-catch-invisible-edits-commands
+  ;; We do not 

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[tomas]

On Sun, Feb 12, 2023 at 12:33:40PM +0300, Jean Louis wrote:
> * Ihor Radchenko  [2023-02-10 13:48]:
> > Jean Louis  writes:
> > 
> > > If you start adding in Org "fixed" time with UTC offset, that is a new
> > > type of timestamp, as it is not common in world.
> > 
> > It is how ISO8601 defines offsets.
> 
> - did you say you wish to represent time with UTC time zone by using
>   UTC offset?
> 
> - and I said, UTC time is always without offset, and if any is
>   represented then it must be +00
> 
> - and now you say that ISO8601 defines offsets... sorry, you are
>   confusing me and readers.

It is not about "the offset OF UTC". It is about "the offset
RELATIVE TO UTC".

Sorry for raising my voice :-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Ypo]

Could it be reasonable to collect the hypothetical cases where relative 
timestamps would be used?

So, alternatives and solutions could be evaluated more easily.
For example:


| External Input  | User's 
input | Org output | 
Agenda output (local time) | Org time storing |


|-+--+++--|
| Meeting at 09:37:54, 28 February 2023, in Foz do Iguaçu | [2023-02-28 
ma. 09:37 @UTC-3]    | [2023-02-28 ma. 09:37 @UTC-3]  | 
[2023-02-28 ma. 13:37] | 20230228T12:37:54,68 |
| Same case as above  | [2023-02-28 
ma. 09:37 @timezone] | [2023-02-28 ma. 09:37 @UTC-3,timezone] | 
[2023-02-28 ma. 13:37] | 20230228T12:37:54,68 |
| Party at my home, tomorrow  | [2023-02-13 
lu. 14:15]   | [2023-02-13 lu. 14:15 @UTC+1,timezone] | 
[2023-02-13 lu. 14:15] | 20230213T13:15:54,68 |



- I didn't expect this: it is more difficult for me to find the 
timezone, and to write it in the correct format, than to find the UTC 
offset.


- Maybe org output should always show the time zone, since for calculations

- Should convert show every timestamp timezone, so we know local 
timezone is correct?


- Sorry for the table format, I don't know how to export it from orgmode 
to thunderbird's mail editor.







* Max Nikulin  [2023-02-11 07:47]:
>/On 10/02/2023 10:29, Jean Louis wrote:/
>/> 2030-02-09 12:00 -08 @UTC -- this time CANNOT be said to be "fixed/
>/> UTC"/
>//
>/I do not see any reason why obviously invalid timestamp draws so much/
>/attention./
>//
>/Resolution may be rather concise: behavior is *undefined* since field 
values/
>/are mutually inconsistent. Perhaps implementation may prefer to treat 
it as/
>/2030-02-09T12:00:00-0800 discarding UTC as time zone specifier. 
`org-lint'/

>/should issue a warning requesting a user action./

Thank you!

I have demonstrated that Etar application from F-Droid would disregard
what is invalid and basically only enter valid time. Same for Google
calendar, it would disregard invalid timestamp (even though not
represented as above), and it would enter only valid one. PostgreSQL
will "silently" ignore what does not belong to it.

One can search for "silent" here:
https://www.postgresql.org/docs/current/datatype-datetime.html

>/Could you explain what is wrong with the following (without timezone)?/
>//
>/2030-02-09 12:00 -0800/
>//
>/I consider it as an unambiguous equivalent of 2030-02-09T20:00:00Z 
that is a/

>/UTC timestamp./

That is not same case as Ihor, when he designated it as

2030-02-09 12:00 -0800 @UTC
because there are no offsets @UTC time zone.

In this different case you wish to say that it is:

time of 2030-02-09 12:00 -0800 whereby -0800 is UTC offset from floating time
2030-02-09 12:00, and one can derive UTC time.

That is totally alright as representation of time. That is how past
timestamps are represented in local time.

Why not -- you can use it for future.

I find it less useful for exchange purposes, almost useless, but you
can do. Because if you store time as UTC, you can always see local
time anywhere in the world. But if programmers wish to do that to Org,
okay fine.

It is different time type representation, that does not exist in ISO
8601, but why not, you can include it in Org.

You just be sure that you put a "tag" or such representation that
users will know what is it, even from plain text.

>/The format with explicit offset may be convenient for a person/
>/living in an area that *likely* will have -08:00 offset and who/
>/would like to watch some astronomical event such as lunar eclipse/
>/and who had a plan to connect to some telescope on the opposite side/
>/of the globe. Event time will not change if local time changed. Both/
>/variants 2030-02-09T12:00:00-0800 and 2030-02-09T20:00:00Z may be/
>/presented as "2030-02-09 12:00" to users./

And now you speak of presentation. But then why store it with
2030-02-09T12:00:00-0800 when you can store it as 2030-02-09T20:00:00Z
and have representation be same "2030-02-09 12:00" to users.

So that is only addition to programmer.

Remember that not even databases store the time like that. It is
either UTC time, or date, time, and some time zone stored separately.

>/If timezone offset is changed both variants will converted to/
>/"13:00" or "11:00" depending on sign of change./

Correct. I understand you want to say that representation of time for
that UTC time zone will be modified depnding of change, and that is
correct.

>/So the format with offset is human friendly because it gives a hint/
>/concerning *probable* value of local time still remaining *precise*/
>/in respect to UTC./

This 

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Jean Louis]

* Max Nikulin  [2023-02-11 07:47]:
> On 10/02/2023 10:29, Jean Louis wrote:
> > 2030-02-09 12:00 -08 @UTC -- this time CANNOT be said to be "fixed
> > UTC"
> 
> I do not see any reason why obviously invalid timestamp draws so much
> attention.
> 
> Resolution may be rather concise: behavior is *undefined* since field values
> are mutually inconsistent. Perhaps implementation may prefer to treat it as
> 2030-02-09T12:00:00-0800 discarding UTC as time zone specifier. `org-lint'
> should issue a warning requesting a user action.

Thank you!

I have demonstrated that Etar application from F-Droid would disregard
what is invalid and basically only enter valid time. Same for Google
calendar, it would disregard invalid timestamp (even though not
represented as above), and it would enter only valid one. PostgreSQL
will "silently" ignore what does not belong to it.

One can search for "silent" here:
https://www.postgresql.org/docs/current/datatype-datetime.html

> Could you explain what is wrong with the following (without timezone)?
> 
> 2030-02-09 12:00 -0800
> 
> I consider it as an unambiguous equivalent of 2030-02-09T20:00:00Z that is a
> UTC timestamp.

That is not same case as Ihor, when he designated it as 

2030-02-09 12:00 -0800 @UTC
because there are no offsets @UTC time zone.

In this different case you wish to say that it is:

time of 2030-02-09 12:00 -0800 whereby -0800 is UTC offset from floating time
2030-02-09 12:00, and one can derive UTC time.

That is totally alright as representation of time. That is how past
timestamps are represented in local time.

Why not -- you can use it for future.

I find it less useful for exchange purposes, almost useless, but you
can do. Because if you store time as UTC, you can always see local
time anywhere in the world. But if programmers wish to do that to Org,
okay fine.

It is different time type representation, that does not exist in ISO
8601, but why not, you can include it in Org.

You just be sure that you put a "tag" or such representation that
users will know what is it, even from plain text.

> The format with explicit offset may be convenient for a person
> living in an area that *likely* will have -08:00 offset and who
> would like to watch some astronomical event such as lunar eclipse
> and who had a plan to connect to some telescope on the opposite side
> of the globe. Event time will not change if local time changed. Both
> variants 2030-02-09T12:00:00-0800 and 2030-02-09T20:00:00Z may be
> presented as "2030-02-09 12:00" to users.

And now you speak of presentation. But then why store it with
2030-02-09T12:00:00-0800 when you can store it as 2030-02-09T20:00:00Z
and have representation be same "2030-02-09 12:00" to users.

So that is only addition to programmer.

Remember that not even databases store the time like that. It is
either UTC time, or date, time, and some time zone stored separately.

> If timezone offset is changed both variants will converted to
> "13:00" or "11:00" depending on sign of change.

Correct. I understand you want to say that representation of time for
that UTC time zone will be modified depnding of change, and that is
correct.

> So the format with offset is human friendly because it gives a hint
> concerning *probable* value of local time still remaining *precise*
> in respect to UTC.

This representation of time is human friendly:
2030-02-09 12:00 -0800 and that is the way how I daily see my
timestamps, like this: 2023-02-12 12:59:52.839773+03
which does not differ much from that one.

However, my timestamp is only represented with +03 UTC offset. It is
not stored with UTC offset.

Storing values is not equal to representing values.

- In other software values are not stored as "UTC time that has
  offset"

- It is stored as "UTC time"

- Offset is calculated from time zone and represented to user.

Of course you need not follow what other software does.

Though I think you need rather exact designation for users to
unmistakably can understand what you mean with it:

- Right now when I press C-c . I get: <2023-02-12 Sun>

- C-u C-c . and I get <2023-02-12 Sun 13:03>

- Then I can think you (developers) will invent something like:
  <2023-02-12 Sun 13:03 @Europe/Berlin> (whereby one has to avoid
  invalid time stamps), which is UTC time: 2023-02-12 12:03:00

- Then I can think you would invent time stamp which you proposed,
  something like: <2023-02-12 12:00 -08:00> which in this case cannot
  have day representation, as one cannot know which day is that,
  right?

  And in this case that timestamp would mean it is 20:00 o'clock UTC
  time.

  And which can be replaced with <2023-02-12 20:00 @UTC>

  I am just not sure if that will be enough human friendly to say:
  <2023-02-12 12:00 -08:00> to people, as there is no designation that
  it is UTC time, and one cannot use "@UTC" as that would be wrong.

  Maybe designation is not necessary?
  
When we consider how good calendars work, they will always ask user
for the 

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Jean Louis]

* Ihor Radchenko  [2023-02-10 13:48]:
> Jean Louis  writes:
> 
> > If you start adding in Org "fixed" time with UTC offset, that is a new
> > type of timestamp, as it is not common in world.
> 
> It is how ISO8601 defines offsets.

- did you say you wish to represent time with UTC time zone by using
  UTC offset?

- and I said, UTC time is always without offset, and if any is
  represented then it must be +00

- and now you say that ISO8601 defines offsets... sorry, you are
  confusing me and readers.

Please see here:
https://en.wikipedia.org/wiki/ISO_8601

on right side, there is representation of UTC time:
Date and time in UTC
2023-02-12T06:45:15+00:00
2023-02-12T06:45:15Z
20230212T064515Z

Do you see? There is no offset larger or smaller than zero.

We were discussing of a time stamp at @UTC time zone with offset!

That type of a timestamp does not exist.

What exists with positive or negative offset is timestamp with time
zone other but UTC.

But not with UTC.

If you do introduce positive or negative offsets at UTC time zone, you
are introducing something new in Org. It is not necessarily bad, but
IMHO you will create more confusion, for no good reason.

> > Here is suggestion:
> > ---
> >
> > 1. Convert local time timestamp to UTC
> > 2. Add 10024 hours
> > 3. Provide timestamp in UTC
> 
> This will involve converting time, which is prone to errors. I still
> think that sometimes it is more convenient for human to use familiar
> time zone and fix the offset for future.

Your answer is not related any more to @UTC time you were mentioning
as now you are using "familiar time zone". I said, there is no offset
representation with UTC time but +00. But it can be with other time
zones.

However, when you say "fix the offset for future" that does not
work. If you do specify time zone, you are fixing it by time zone, and
not by UTC offset, because it is less likely that the time zone
definition changes, but UTC offset can change easier.

The UTC offset is property of the time zone. The future time zone
definition will know what is it's UTC offset.

You can introduce something new in Org and say "This is fixed UTC
offset in time zone @ABC" but that way you are confusing yourself and
future programmer and users, as it does not comply to already accepted
international standards.

iCalendar proposes different way of representation of time in future,haw
that is, it could be UTC time in future, or it could be date, time and
time zone. Using UTC offset for future is redundant, as in present
time when you are writing future time stamp, you cannot know the
future UTC offset.

> > Also look at this reference:
> > https://icalendar.org/iCalendar-RFC-5545/3-3-5-date-time.html
> >i
> > ,
> > | The form of date and time with UTC offset MUST NOT be used. For
> > | example, the following is not valid for a DATE-TIME value:
> > | 
> > |  19980119T23-0800   ;Invalid time format
> > `
> 
> > As with the above format, author would maybe think it is alright, but
> > in general it is confusing. If author wish to specify UTC time, then
> > no offset shall be used.
> 
> icalendar is _not_ the only time spec around. We can take it into
> account, but I do not see any reason to follow it blindly.

How about finding reasons why iCalendar specifies it that way?

And then deciding if those reasons, not specification literally,
should be followed?

> Reading the linked RFC spec, I did note that the motivation for the time
> format used in calendar is mainly scheduling meetings for people
> residing in different time zones.

And I think that is what we are talking about, about conclusive time
representation in cases where Org users need it. If meeting or not,
that is something for users to decide.

Important is only to define the types of time stamps, and then let
users use it.

Goal is to improve Org timestamps so that Org get feature of
conclusive time representation.

That means to me, that inconclusive, like floating timestamps can be
left how they are, only new are added.

For past time representation is best using UTC timestamp, as such can
easily be converted to local time. But how? Using overlays? Or
updating time stamps in buffer? Or using updated local time timestamps
in exports?

There is that time stamp for future, if it should not be floating or
non-conclusive, then you use date, time and time zone.

You insist on "fixing UTC time offset for time zone", but I do not
understand that reasoning, as it is contradictory to time zone
database use per se.

> I can see how the icalendar format is reasonable within that
> specific purpose. I cannot see why Org timestamps should be limited
> to meetings.

"Meeting" is not for Org to specify, that is for user to specify what
it is.

It need not be meeting, any future representation is quite different
from past.

Past timestamps are more conclusive, than future.

Past time zone databases already exists, TZ database is rarely updated
with past time zones, 

Re: Problem with let/cl-letf binding stuff with org-capture

[Bruno Barbier]

Hi Arthur,

Arthur Miller  writes:

> Bruno Barbier  writes:
>
> ...  but I feel a
> bit of passive aggressivity here, for no good reason tbh.

I'm just trying to help, giving some valid or invalid advices.  I'm
sorry that what I wrote, and how I wrote it, made you feel that way.

>>
>> Yes, let binding is fundamental. But I think it's the first time I see
>> 'cl-letf' with the 'symbol-function' place.
>
> https://nullprogram.com/blog/2017/10/27/
> https://endlessparentheses.com/understanding-letf-and-how-it-replaces-flet.html
> https://stackoverflow.com/questions/39550578/in-emacs-what-is-the-difference-between-cl-flet-and-cl-letf
>

Thanks for these links. I like cl-flet and cl-labels :-)


>>> but I am not sure if I can do anything here without introducing at-least an
>>> extra keymap, to not install into the org-capture-mode-map, so I can as well
>>> create a minor mode, but at this point it is not much different than
>>> re-invinting the read-string, so I'll terminate my experiment here :).
>>
>> You can replace the buffer keymap with a keymap that only contain your custom
>> keys, and inherits everything else from org-capture-mode-map.
>
> Isn't that what I wrote: introducing an extra keymap?
> Of course I can solve the problem differently, but that was not what question
> was about :).

Right. Even when inheriting from the old keymap, it's still building a
new keymap.  Sorry :-)


> Well, I definitely understand you, and agree that overwriting function for
> everyone and everything is not the best idea, but unfortunately bindings work 
> as
> they do in Emacs. I would prefer to have a local binding, with cl-flet, but 
> this
> does not work in Emacs:
>
> (defun my-read-string (prompt)
>   (let ((delta 20 )
> (minibuffer-mode-map org-mode-map))
> (window-resize (minibuffer-window) delta)
> (cl-flet ((org-ctrl-c-ctrl-c ()
> (interactive)
> (let ((s (buffer-string)))
>   (exit-minibuffer) s))
>   (minibuffer-mode () #'org-mode)
>   (minibuffer-complete-and-exit () #'org-return)
>   (org-kill-note-or-show-branches () #'keyboard-escape-quit))
>   (read-string (concat "# Press C-c C-c to continue, C-c C-k to cancel\n# 
> "
>   prompt "\n\n")

Yes. cl-flet looks safe to me :-)

>
> Hooks serve a different purpose. Advice can serve same purpose with exactly
> same side effect, and some other limitations. With some care, let-binding is
> still more "local" then advice. With other words, I agree with you about the
> problems, but not with dogmatic approach that it should never be done, and
> that hooks and advices are the replacement.

Sorry if my words sounding dogmatic.
Else, I agree too :-)


>>
>>> I am very interested to hear more on the topic, since I would definitely 
>>> like to
>>> learn more about different techniques.
>>
>> Variables are designed to be overriden (let bounds). Functions are not
>
> I have never heard before that functions are not designed to be overriden. I
> think of them as two slots in a symbol structure; let creates bindings for 
> value
> slot, and flet for function slot. Functions are just objects or data as any
> other value in lisp.
>
>> (as there is only one binding at any given time).
>
> Yes, unfortunately, in Emacs it is so;

ok. We do really agree then :-)


> but I don't think it should be > :).

... oh no ! ;-)


>
> There is an interesting package by Nick Ferrier
>
> https://github.com/nicferrier/emacs-noflet

> but it does not seem to work, at least not for me.

It's almost like a temporary advice ;-)


About your use case, if what you need is asynchronous editing, maybe the
with-editor package will be of interest to you:
https://github.com/magit/with-editor/blob/main/lisp/with-editor.el

It allows sub-processes to call Emacs for editing tasks. It's used by
magit. It's easy enough to reuse. I've attached my attempt at it if
you're interested.

best,

Bruno

(cl-defun my-edit-async (finish  mode buffer-name setup cancel)
  "Open a buffer, let the user edit its content.
Return the editing buffer.  Call FINISH in the editing buffer if
the user validates his edit (C-c C-c).  When CANCEL is non-nil,
call CANCEL in the editing buffer if the user cancels his
edit (C-c C-k). When done, delete the buffer and its content.

When MODE is non-nil, use it as the major-mode.  When BUFFER-NAME
is non-nil, use it to generate a new unique name of the editing buffer.
When SETUP is non-nil, call it in the edit buffer to setup the
buffer before starting the edit."
  (unless buffer-name (setq buffer-name "@Async edit"))
  (let ((buf (generate-new-buffer buffer-name)))
(with-current-buffer buf
  (when mode (funcall mode))
  (when setup
(funcall setup))
  (with-editor-mode 1)
  (setq with-editor-previous-winconf
(current-window-configuration))
  (add-hook 'with-editor-pre-finish-hook
(lambda ()