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

[Tim Cross]

Jean Louis  writes:

> * Tim Cross  [2023-01-19 00:31]:
>> The problem is with meeting 2 and the assumption there is a definitive
>> timezone for the meeting.
>> 
>> Consider this scenario. I have a meeting with two other people. We are
>> all in different timezone. What is the timezone of the meeting?
>
> Org in this state can't handle such things.
>
> A person in any timezone shall be able to see that time in his local
> time zone if we speak of distant meetings, and in case of face to face
> meetings, that person shall have computer aid to show him the meeting
> time in any time zone that user is located, during travel and upon
> arrival to face to face meeting. 
>
> User is supposed to be assisted by computer. And not to assist to
> computer, or to get troubles from computer.
>
> - Time zone shall be more or less recognizable by city and country. 
>
> - User addresses in the address book shall be part of every computer system
>
> - It is natural and common sense to know addresses of people one wants
>   to meet
>
> - By using location of person one wants to meet, computer has got
>   enough information for representation of the time zone
>
> - By sharing appointment record to user in other time zone, that user
>   would see it in his time zone, or by choice in original time zone of
>   the meeting place
>
> A record of time, shall have two attributes, the UTC time and the time
> zone to be displayed. By using system time zone setting, Org file time
> zone settings, heading time zone settings or time stamp time zone
> setting, any export of Org shall contain (by user's option) the
> desired representation of time stamps.
>
> Function of sharing of meetings shall ask local user:
>
> - is user in different time zone? 
>
> And then by choice of the user's location, the time representation
> shall be prepared in such way that both parties understand each other.
>
> That is really not in the sphere of Org where there is not even a
> decent address book available.
>
> Just re-write the time by hand for your friend at other part of the
> world, write the timestamp in his time zone and your time zone, and
> problem solved.
>
> It is supposed to be text. It is not God.

You completely misunderstood the specific issue being discussed. You
clearly have not been following this specific point being discussed and
your long reply just confuses matters rather than helps.

This issue is in dealing with the meeting time when the local timezone
changes due to daylight savings time and the fact you have two different
requirements

1. For meeting where all people are in the same timezone, a transition
in/out of daylight savings changes nothing. The meeting time stays the same

2. For meetings wiht people from different time zones, when daylight
savings transition occurs, the timestamp needs to be changed.  Nothing
needs to happen for the people in other time zones - it isn't their
problem and their meeting time is not affected.

Ihor['s suggested solution was to just use the TZ of the 'meeting', but
that is ambiguous. A meeting doesn't have a time zone and picking just
one of the recipients doens't help as now you just have the issues of
their daylight savings transitions etc.

The 'solution' is to record this meeting in UTC tz. However, to make
this 'workable' for most people, the interface for managing timestamps
needs to make this easy.

For example, I would probablyh want an interface where by default, my
timestamps have no TZ data, but if I call the command to add a timestamp
with the universal argument, it will add a default tz and allow me to
easily change it to a different one.

My default 'no tz data' choice is best for me because I don't travel
much and am rarely in different time zones. Therefore, tz data not
needed and the smaller and easier to read/edit timestamps are
preferred. If on the other hand I was someone who travelled a lot, then
I would want the default to be to add full time zone information to
timestamps (though, I would probably want an overlay or similar to
display the timestamps in a more concise format converted to current
tz).

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

[Thomas S. Dye]

Aloha all,

Jean Louis  writes:


* Tim Cross  [2023-01-19 00:31]:
The problem is with meeting 2 and the assumption there is a 
definitive

timezone for the meeting.

Consider this scenario. I have a meeting with two other people. 
We are

all in different timezone. What is the timezone of the meeting?


Meetings are occurrences, which require absolute time, which has 
no timezones.  Org should record occurrences with timestamps in 
UTC, possibly translating from the user's local time.




Org in this state can't handle such things.


Org can do the useful thing: translate the UTC timestamp into 
local time and report both UTC and local time.  User will be able 
quickly to determine if local time is incorrect for some reason, 
such as DST or travel.


Storing timestamps in UTC solves the interval problem Ihor raised. 
Intervals always make sense in absolute time.  Moving them to 
event time leads to the insanity Ihor mentioned.


hth,
Tom



A person in any timezone shall be able to see that time in his 
local
time zone if we speak of distant meetings, and in case of face 
to face
meetings, that person shall have computer aid to show him the 
meeting
time in any time zone that user is located, during travel and 
upon
arrival to face to face meeting. 

User is supposed to be assisted by computer. And not to assist 
to

computer, or to get troubles from computer.

- Time zone shall be more or less recognizable by city and 
country. 

- User addresses in the address book shall be part of every 
computer system


- It is natural and common sense to know addresses of people one 
wants

  to meet

- By using location of person one wants to meet, computer has 
got

  enough information for representation of the time zone

- By sharing appointment record to user in other time zone, that 
user
  would see it in his time zone, or by choice in original time 
  zone of

  the meeting place

A record of time, shall have two attributes, the UTC time and 
the time
zone to be displayed. By using system time zone setting, Org 
file time
zone settings, heading time zone settings or time stamp time 
zone

setting, any export of Org shall contain (by user's option) the
desired representation of time stamps.

Function of sharing of meetings shall ask local user:

- is user in different time zone? 

And then by choice of the user's location, the time 
representation
shall be prepared in such way that both parties understand each 
other.


That is really not in the sphere of Org where there is not even 
a

decent address book available.

Just re-write the time by hand for your friend at other part of 
the
world, write the timestamp in his time zone and your time zone, 
and

problem solved.

It is supposed to be text. It is not God.



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

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

[Jean Louis]

* Tim Cross  [2023-01-19 00:31]:
> The problem is with meeting 2 and the assumption there is a definitive
> timezone for the meeting.
> 
> Consider this scenario. I have a meeting with two other people. We are
> all in different timezone. What is the timezone of the meeting?

Org in this state can't handle such things.

A person in any timezone shall be able to see that time in his local
time zone if we speak of distant meetings, and in case of face to face
meetings, that person shall have computer aid to show him the meeting
time in any time zone that user is located, during travel and upon
arrival to face to face meeting. 

User is supposed to be assisted by computer. And not to assist to
computer, or to get troubles from computer.

- Time zone shall be more or less recognizable by city and country. 

- User addresses in the address book shall be part of every computer system

- It is natural and common sense to know addresses of people one wants
  to meet

- By using location of person one wants to meet, computer has got
  enough information for representation of the time zone

- By sharing appointment record to user in other time zone, that user
  would see it in his time zone, or by choice in original time zone of
  the meeting place

A record of time, shall have two attributes, the UTC time and the time
zone to be displayed. By using system time zone setting, Org file time
zone settings, heading time zone settings or time stamp time zone
setting, any export of Org shall contain (by user's option) the
desired representation of time stamps.

Function of sharing of meetings shall ask local user:

- is user in different time zone? 

And then by choice of the user's location, the time representation
shall be prepared in such way that both parties understand each other.

That is really not in the sphere of Org where there is not even a
decent address book available.

Just re-write the time by hand for your friend at other part of the
world, write the timestamp in his time zone and your time zone, and
problem solved.

It is supposed to be text. It is not God.

--
Jean

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

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

org-sort no ts

[Samuel Wales]

with org-sort, by analogy with org-agenda-sort-notime-is-late, is it
possible to sort T, i.e. by ts with most recent first, with entries
that have no ts at the bottom?

-- 
The Kafka Pandemic

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

Re: One of my Org files hangs Emacs

[Richard Kim]

Ihor Radchenko  writes:

> Marcin Borkowski  writes:
>
>> so I have a bunch of Org files, most of them pretty big (over 1
>> megabyte), and one of them repeatedly causes my Emacsa to hang.
>> Sometimes a plain `C-g' helps, sometimes I need to kill the Emacs
>> process.  How do I even begin to find out what happens?  Any hints?
>
> 1. Set debug-on-quit to t and study the backtrace you get after C-g
> 2. Set debug-on-error to t, send SIGUSR2 signal to Emacs and study the 
> backtrace
> 3. Run emacs -Q only loading the Org version you use and try to
>reproduce. If you can, this is a bug in Org. If you can't, bisect
>your config to identify the cause (there is a helper bug-hunter
>package to assist; it can be used for manual reproduction as well)

I would suggest disabling "org persist" which has caused so much grief for me.

(setq org-element-cache-persistent nil)

Prior to me adding above line, I would get mysterious hangs, and all
kinds of frequent errors.  I tried debug-on-quit and debug-on-error, but
this "org persist" thing was impossible to debug.

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

[No Wayman]

No Wayman  writes:


The attached patch should take care of that.


Sorry. Had trailing whitespace in that version. 
Attached here without trailing whitespace.


>From 85990610ca7572f5a6ff7604d957efdf00747094 Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Mon, 16 Jan 2023 14:00:41 -0500
Subject: [PATCH] * mk/targets.mk (GITVERSION): support shallow repo clones

If Org is being built from a shallow clone, tags are not locally available.
Query the upstream remote via git ls-remote and parse the output.
Note this will result in a "n/a" indicator in org-version where the
number of commits since the last tag is usually present.
e.g. "release_9.6.1-n/a-gabc123"
---
 mk/targets.mk | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/mk/targets.mk b/mk/targets.mk
index 4435daa9..be79a127 100644
--- a/mk/targets.mk
+++ b/mk/targets.mk
@@ -14,7 +14,20 @@ ifneq ($(wildcard .git),)
   # Use the org.el header.
   ORGVERSION := $(patsubst %-dev,%,$(shell $(BATCH) --eval "(require 'lisp-mnt)" \
 --visit lisp/org.el --eval '(princ (lm-header "version"))'))
-  GITVERSION ?= $(shell git describe --match release\* --abbrev=6 HEAD)
+  ifneq ($(wildcard .git/shallow),)
+REMOTETAGS := $(strip $(shell git ls-remote --tags 2>/dev/null | tail -n 1))
+COMMIT := $(shell git rev-parse --short=6 HEAD)
+TAG:= $(lastword $(REMOTETAGS))
+ifneq ($(TAG),)
+  TAGPREFIX  := $(subst refs/tags/,,$(TAG))
+  GITVERSION ?= $(subst ^{},-n/a-g$(COMMIT), $(TAGPREFIX))
+else
+  GITVERSION ?= $(ORGVERSION)-n/a-g$(COMMIT)
+endif
+  else
+GITVERSION ?= $(shell git describe --match release\* --abbrev=6 HEAD)
+  endif
+  GITVERSION ?= N/A
   GITSTATUS  ?= $(shell git status -uno --porcelain)
 else
  -include mk/version.mk
-- 
2.39.0

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

[No Wayman]

Ihor Radchenko  writes:


No Wayman  writes:


Ihor Radchenko  writes:

What we should not have is "make autoloads" failing without 
internet.


The attached patch should take care of that.
If the ls-remote errors, GITVERSION will be set to N/A as when 
it 
is generally unavailable. 


I just tried your patch running make without internet. I got the
following Org version:

Subject: [BUG] test [9.6.1 ( @ /tmp/org-mode/lisp/)]

As you can see, the last commit number is not listed even though 
I can

see it via git log.



The attached patch should take care of that.

>From 872ba4bf04313692758bcb3d8622c16bbd407101 Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Mon, 16 Jan 2023 14:00:41 -0500
Subject: [PATCH] * mk/targets.mk (GITVERSION): support shallow repo clones

If Org is being built from a shallow clone, tags are not locally available.
Query the upstream remote via git ls-remote and parse the output.
Note this will result in a "n/a" indicator in org-version where the
number of commits since the last tag is usually present.
e.g. "release_9.6.1-n/a-gabc123"
---
 mk/targets.mk | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/mk/targets.mk b/mk/targets.mk
index 4435daa9..ca6d8c42 100644
--- a/mk/targets.mk
+++ b/mk/targets.mk
@@ -14,7 +14,20 @@ ifneq ($(wildcard .git),)
   # Use the org.el header.
   ORGVERSION := $(patsubst %-dev,%,$(shell $(BATCH) --eval "(require 'lisp-mnt)" \
 --visit lisp/org.el --eval '(princ (lm-header "version"))'))
-  GITVERSION ?= $(shell git describe --match release\* --abbrev=6 HEAD)
+  ifneq ($(wildcard .git/shallow),)
+REMOTETAGS := $(strip $(shell git ls-remote --tags 2>/dev/null | tail -n 1))
+COMMIT := $(shell git rev-parse --short=6 HEAD)
+TAG:= $(lastword $(REMOTETAGS))
+ifneq ($(TAG),)
+  TAGPREFIX  := $(subst refs/tags/,,$(TAG))
+  GITVERSION ?= $(subst ^{},-n/a-g$(COMMIT), $(TAGPREFIX)) 
+else
+  GITVERSION ?= $(ORGVERSION)-n/a-g$(COMMIT)
+endif
+  else
+GITVERSION ?= $(shell git describe --match release\* --abbrev=6 HEAD)
+  endif
+  GITVERSION ?= N/A
   GITSTATUS  ?= $(shell git status -uno --porcelain)
 else
  -include mk/version.mk
-- 
2.39.0

Re: [PATCH][oc-csl] Improve reference parsing

[András Simonyi]

Dear All,

apologies for replying that late. If I understand the situation
correctly, we could handle the question of allowing macros in
citations independently of the handling of other constructs, because
macros are resolved before processing citations, so they have no
effect on the input of Citeproc-el.  In light of this, maybe there
could be a separate patch for just allowing macros?

As for the question of other elements, I proposed the custom
backend-based approach because CSL has its own rich-text markup (which
is actually not simply a subset of Org's, for example, it contains
small-caps, which is not in Org), and, consequently, Citeproc-el has
its own internal rich-text representations (ASTs), on which it
performs the operations that are prescribed by the various CSL styles.
When the rich text citation/bibliography is finalized, it can be
"serialized" or "formatted" (analogously to Org's exporting a parse
tree) using one of the Citeproc formatters, e.g. into LaTeX, HTML or
Org. As the prefix, suffix and the locator also need to be operated on
by the processor (concatenated to other rich text elements etc.,),
they also have to be parsed into CIteproc el's internal rich-text
representations. Since this is a given, the only question is in what
format should they be passed, and the simple HTML-like standard which
is already supported by Citeproc-el (see
https://www.zotero.org/support/kb/rich_text_bibliography) seems to be
the simplest solution.

Ihor Radchenko  wrote:
> Could you please explain in more details why CSL require special
> export of the prefix/suffix? What will happen if we simply pass the Org
> markup verbatim?

Since Citeproc-el assumes that all formatting in the prefix/suffix is
in the HTML-like markup mentioned above, any Org markup would be
treated as plain text which should be preserved as is, and not
interpreted as formatting, so, for example, when an Org document with
underlined text in a citation prefix were exported to LaTeX then the
Citeproc LaTeX formatter would escape the underscore characters ("\_")
to preserve them in the output and the citation would be inserted in
this form into the resulting LaTeX document.

> I am asking because org-cite-csl-render-citation uses
> org-cite-parse-objects so, unless citeproc does something terrible with
> the original Org syntax, we can re-parse the output string and export
> appropriately according to the current export backend.

See above, unfortunately, this wouldn't work, at least not in a
general and safe way.

best wishes,
András


On Sun, 15 Jan 2023 at 09:56, Ihor Radchenko  wrote:
>
> M. ‘quintus’ Gülker  writes:
>
> > I probably have not much to contribute to this rather technical thread,
> > but Ihor has redirected me here two times for my citation formatting
> > questions[1][2]. So I would like to ask if there is something I can do to
> > accelerate its inclusion into org so that I can start using macros in
> > citations?
>
> András is the author of citeproc.el. I am not sure who else would be in
> position to help us to move this forward.
>
> My understanding of CSL is non-existing. I can only tell that
> citeproc.el has its own implementation of citation export
> (`citeproc-render-citations'), which expects some limited kind of html
> as input. I am hoping that we can somehow work around limited markup
> support of citeproc's implementation and instead leverage ox.el to do
> the job. Otherwise, we will keep stumbling upon citeproc.el limitations
> when exporting bibliography items.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 

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

[Tim Cross]

Ihor Radchenko  writes:

> Jean Louis  writes:
>
>> ...
>> Should be part of C library to observe those things.
>
> Sure. My previous proposals are all relying on `encode-time' which uses
> time.h from system libraries and utilizing TZDB that is taking care
> about all this insanity.
>
> We, however, might need to be careful about applying date increments. In
> `org-read-date' and `org-timestamp-change', which are implemented in
> Elisp without considering these complexities. (maybe also other
> functions; these are just the ones I can think about)
>
> What should we do when:
>
> 1. It is close to DST transition 2:59 -> 2:00 -> 2:01 -> ... -> 2:59 -> 3:00
>and the users asks to create a timestamp +1h from now
>or, worse, a timestamp +1h from now in a different time zone
>
> 2. A user asks +1w date shift and the time zone has a 1-day jump during DST?
>what about +7d? +1d?
>
> 3. What will be +1d 2:30am timestamp refer to when there DST transition
>as in (1)?

Yep, these are exactly the sorts of issues I was worried about wrt
adding time zone support. Challenge here is I'm not sure there is one
right answer. It will depend on individual use cases. I guess the best
we can do is select what seems to be the most 'sane' approach and
document th elimitations (and possibly how to work around them). The key
is likely to avoid user surprise. Limitations are often better accepted
when flagged up front and when 'discovered' later.

Initially, my thoughts on the 3 above are "I have no clue what the sane
default is" - all options seem to have equal pros and cons. Guess the
best we can do is go with the simplest solution and 'suck it and see". 

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

[Tim Cross]

Ihor Radchenko  writes:

> Tim Cross  writes:
>
>>> Does it sound good enough?
>>
>> No, I'm afraid not. How does org distinguish between meeting 1 and
>> meeting 2? IN meeting one, when the timezone transitions in/out of
>> daylight savings, nothing needs to change, but in meeting 2, when this
>> occurs, the meeting needs to be re-sechduled so that it keeps the same
>> offset relative to UTC.
>> Some mechanism is needed so that the user can
>> identify timestamps like those fo rmeeting 1 from those for meeting
>> 2. My idea was to have meeting 1 type timestamps without TZ info and
>> meeting 2 require fully qualified TZ info. However, while this would
>> probably work, I don't like it because it isn't explicit and would be
>> prone to errors.
>
> I still don't understand.
>
> In Org, you will have a default time zone that will be used to build the
> agenda.
>
> In meeting 1, you set the time zone to your local zone
> In meeting 2, you set the time zone to the time zone where the meeting
> is scheduled.
>
> The, both the meetings will be first converted to the default time zone
> and appear in your agenda adjusted as required.

The problem is with meeting 2 and the assumption there is a definitive
timezone for the meeting.

Consider this scenario. I have a meeting with two other people. We are
all in different timezone. What is the timezone of the meeting?

Thinking more about it, in this situation, you probably just need to set the 
meeting time to UTC
and that would work. However, we would want some easy way to set this
when creating the timestamp (and that could be all that is needed - a
good enhancement to the interface to make it easy to set the timezone)
and good control over how values are displayed in the agenda and org
files (i.e. I imagine you might want a default where they are all shown
in your local time, but similar to working with links, the ability to
display the 'raw' version for editing and other purposes).

As yuou mentioned in another thread, it is likely many of these
scenarios can be adequately managed with good TZ support. It will be
critical that we also have a good UI for setting/adding TZ
information. Then, as you pointed out elsewhere, we will just need good
documentation/tutorials as some of these workflows are not terribly
intuitive and people find this stuff confusing. 

Re: Question about deadline/schedule events date text property

[Daniel Fleischer]

Ihor Radchenko [2023-01-18 Wed 13:23]  wrote:

> Note that `org-fix-agenda-info' converts the 'date property back to some
> other format... (yes, that's kind of crazy)

Thanks, that could be useful. 

--
Daniel Fleischer

Re: Org-cite (oc-csl) tip: Filtering bibliography for language

[András Simonyi]

Dear All,

first of all, sorry for replying that late.

On Tue, 20 Dec 2022 at 11:46, Christian Moe  wrote:
> Arbitrary sexps would give us more flexibility. Alternately, one could
> achieve more or less the same by letting :filter collect any additional
> arguments and pass them as  to the user's predicate function,
> something like:
>
>   #+PRINT_BIBLIOGRAPHY: :filter bibitem-lang-p nb nn no :type article

I like this proposal a lot -- it seems to strike a good balance with
regard to safety and flexibility.
I'll try to make the required changes on the citeproc-el side and then
propose a patch here.

> Alternatively, I think there is a case for adding a user-friendly
> :language property to the print_bibliography keyword. On my bookshelf it
> vies with primary/secondary sources as the most common criterion for
> separate bibliographies.

> I was going to say that this is the only extension I can think of that
> is needed beside :(not)(csl)type and :(not)keyword, but of course people
> are sooner or later going to want easy-to-use properties to filter by
> author, publication date ranges, and probably other criteria I cannot
> think of right now, so it's a strategic decision for the maintainer(s)
> if you want to go that way. :-)

this is also a useful suggestion, although with the added difficulty
of having to support both
bib(la)tex and csl-json, which use, I think, different sets of language codes.

best wishes,
András

> Yours,
> Christian

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

[Jean Louis]

Just leave it out and let Org be single user, single time zone system.

You can't make the impossible. It is not database for sensitive work.

Let it be text.

If they want to convert to their time zone, let them do the home work.

If they don't want to use Org for timestamps, like me, let them be.

-- 
Jean

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

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

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

[Jean Louis]

* Ihor Radchenko  [2023-01-18 13:01]:
> Max Nikulin  writes:
> 
> > ... I am unsure concerning Windows, it may have an option of quite 
> > similar variant. That is why I am not sure to which degree Org should be 
> > liberal in respect to various time zones.
> 
> May we just support whatever TZ supports (POSIX)?

Yes, not too much. It is impossible.

I would say this way, if user does not like Org task management
without time zones, go and find other one without Org. Simple.

Org does not have foundation where you can even think of complexities
discussed here.

-- 
Jean

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

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

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

[Jean Louis]

* Max Nikulin  [2023-01-17 20:31]:
> On 17/01/2023 02:07, Ihor Radchenko wrote:
> > https://www.youtube.com/watch?v=-5wpm-gesOY gives various examples.
> 
> More links:
> - https://stackoverflow.com/tags/timezone/info
> - 
> https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time
>   Falsehoods programmers believe about time

Seems overwhelming to satisfy all requirement.

Is there any program, software, system, that is really so good with
time, apart from PostgreSQL database that I know with 1195 defined
time zones?

SELECT
name,
abbrev,
utc_offset,
is_dst
FROM pg_timezone_names;

  name  | abbrev | utc_offset | is_dst 
+++
 NZ | NZDT   | 13:00:00   | t
 GB-Eire| GMT| 00:00:00   | f
 Canada/Yukon   | MST| -07:00:00  | f
 Canada/Atlantic| AST| -04:00:00  | f
 Canada/Pacific | PST| -08:00:00  | f
 Canada/Eastern | EST| -05:00:00  | f
 Canada/Central | CST| -06:00:00  | f
 Canada/Saskatchewan| CST| -06:00:00  | f
 Canada/Newfoundland| NST| -03:30:00  | f
 Canada/Mountain| MST| -07:00:00  | f
 Japan  | JST| 09:00:00   | f
 Kwajalein  | +12| 12:00:00   | f
 Egypt  | EET| 02:00:00   | f
 Poland | CET| 01:00:00   | f
 Turkey | +03| 03:00:00   | f
 CET| CET| 01:00:00   | f
 Brazil/DeNoronha   | -02| -02:00:00  | f
 Brazil/East| -03| -03:00:00  | f
 Brazil/West| -04| -04:00:00  | f
 Brazil/Acre| -05| -05:00:00  | f
 Chile/Continental  | -03| -03:00:00  | t
 Chile/EasterIsland | -05| -05:00:00  | t
 EST5EDT| EST| -05:00:00  | f
 Atlantic/Jan_Mayen | CET| 01:00:00   | f
 Atlantic/Cape_Verde| -01| -01:00:00  | f
 Atlantic/South_Georgia | -02| -02:00:00  | f
 Atlantic/Faroe | WET| 00:00:00   | f
 Atlantic/St_Helena | GMT| 00:00:00   | f
 Atlantic/Azores| -01| -01:00:00  | f
 Atlantic/Madeira   | WET| 00:00:00   | f
 Atlantic/Stanley   | -03| -03:00:00  | f
 Atlantic/Bermuda   | AST| -04:00:00  | f
 Atlantic/Canary| WET| 00:00:00   | f
 Atlantic/Reykjavik | GMT| 00:00:00   | f
 Atlantic/Faeroe| WET| 00:00:00   | f
 Iceland| GMT| 00:00:00   | f
 GMT0   | GMT| 00:00:00   | f
 EST| EST| -05:00:00  | f
 PRC| CST| 08:00:00   | f
 Cuba   | CST| -05:00:00  | f
 Eire   | GMT| 00:00:00   | t
 HST| HST| -10:00:00  | f
 GMT| GMT| 00:00:00   | f
 Greenwich  | GMT| 00:00:00   | f
 CST6CDT| CST| -06:00:00  | f
 W-SU   | MSK| 03:00:00   | f
 GMT+0  | GMT| 00:00:00   | f
 EET| EET| 02:00:00   | f
 Etc/GMT-2  | +02| 02:00:00   | f
 Etc/GMT-13 | +13| 13:00:00   | f
 Etc/GMT+2  | -02| -02:00:00  | f
 Etc/GMT+7  | -07| -07:00:00  | f
 Etc/GMT-12 | +12| 12:00:00   | f
 Etc/GMT-5  | +05| 05:00:00   | f
 Etc/GMT-11 | +11| 11:00:00   | f
 Etc/GMT0   | GMT| 00:00:00   | f
 Etc/GMT+6  | -06| -06:00:00  | f
 Etc/GMT| GMT| 00:00:00   | f
 Etc/Greenwich  | GMT| 00:00:00   | f
 Etc/GMT+0  | GMT| 00:00:00   | f
 Etc/GMT+4  | -04| -04:00:00  | f
 Etc/GMT-6  | +06| 06:00:00   | f
 Etc/GMT+11 | -11| -11:00:00  | f
 Etc/GMT+8  | -08| -08:00:00  | 

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

[Jean Louis]

* Ihor Radchenko  [2023-01-18 12:35]:
> > It means there shall be functions which can convert timestamps to the
> > new time zone, with the option to left unchanged those timestamps who
> > already have time zone specified, and with option not to be converted.
> 
> I am not sure why you need a difference here.

Today I was writing offers where I specified en_US time format, and
where I send it from EAT time zone, just realizing that people in US
can't understand how did I send the e-mail ahead of time. My
mistake. It is better that I represent it in their time, then they
will know it was night in their city when I was sending it.

Time shall be displayed correctly to the person in that other time
zone, preferrably in his time zone, not mine.

-- 
Jean

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

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

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

[Jean Louis]

* Ihor Radchenko  [2023-01-18 12:29]:
> What should we do when:
> 
> 1. It is close to DST transition 2:59 -> 2:00 -> 2:01 -> ... -> 2:59 -> 3:00
>and the users asks to create a timestamp +1h from now
>or, worse, a timestamp +1h from now in a different time zone

I still understand that it should be job of underlying system
functions. Org is only invoking addition by using system time:

>From Org timestamp with time zone one has to use system functions, to
add, or deduct time, then again to Org time representation.

> 2. A user asks +1w date shift and the time zone has a 1-day jump during DST?
>what about +7d? +1d?

That is all for system functions to know. Is not good on the higher
level (of Org) to start deciding about international issues that shall
be recorded in C libraries somewhere, time zone databases, etc


-- 
Jean

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

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

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

[Jean Louis]

* Ihor Radchenko  [2023-01-17 22:51]:
> Some good news is that all the above edge cases would equally affect the
> current Org's timestamp handling code. Yet, we have no bug reports in
> this area. I'd even go further and say that we should not try hard to
> make things 100% accurate: (1) it will waste a lot of resources; (2)
> users dealing with these edge cases are likely already accustomed to
> most programs not handling things correctly for their special time zone
> situations.

Org shall not handle that, only conversion between Emacs Lisp and
system functions.

Any maintenance shall be done on underlying level of system functions.

-- 
Jean

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

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

Re: One of my Org files hangs Emacs

[Ihor Radchenko]

Marcin Borkowski  writes:

> so I have a bunch of Org files, most of them pretty big (over 1
> megabyte), and one of them repeatedly causes my Emacsa to hang.
> Sometimes a plain `C-g' helps, sometimes I need to kill the Emacs
> process.  How do I even begin to find out what happens?  Any hints?

1. Set debug-on-quit to t and study the backtrace you get after C-g
2. Set debug-on-error to t, send SIGUSR2 signal to Emacs and study the backtrace
3. Run emacs -Q only loading the Org version you use and try to
   reproduce. If you can, this is a bug in Org. If you can't, bisect
   your config to identify the cause (there is a helper bug-hunter
   package to assist; it can be used for manual reproduction as well)

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

One of my Org files hangs Emacs

[Marcin Borkowski]

Hi fellow Orgers,

so I have a bunch of Org files, most of them pretty big (over 1
megabyte), and one of them repeatedly causes my Emacsa to hang.
Sometimes a plain `C-g' helps, sometimes I need to kill the Emacs
process.  How do I even begin to find out what happens?  Any hints?

TIA,

-- 
Marcin Borkowski
http://mbork.pl

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

[Max Nikulin]

On 17/01/2023 16:45, Tim Cross wrote:

Ihor Radchenko  writes:


Tim Cross  writes:


It also seems that the solution will need some mechanism (possibly on a
per time stamp basis) for the user to specify what should happen when
either the time zone has a daylight savings transition, when the
timezone rules change or when the user's 'default' time zone changes
because they have changed locations.


Could you please elaborate here?


I have some meetings scheduled in my org files which show up in the
agenda.

Meeting 1 is a reoccurring meeting which happens every 2 weeks.
When we
transition into/out of daylight savings time, I don't want the timestamp
to change. THe meeting will remain at 3pm.


You specify time zone (globally, for the file, for the subtree, or for 
the particular timestamp) using IANA ID (e.g. Australia/Canberra)


TZ=Australia/Canberra date -d "15:00" '+%F %a %T %z %Z'
2023-01-19 Thu 15:00:00 +1100 AEDT

TZ=Australia/Canberra date -d "+6 month 15:00" '+%F %a %T %z %Z'
2023-07-19 Wed 15:00:00 +1000 AEST


Meeting 2. This is also a reoccuring meeting. However, this meeting is
with people from a number of idfferent time zones. When my timezone
moves into or out of daylight savings time, I need the meeting time to
be updated - moved forward/back 1 hour.


You either specify time offset or a timezone with fixed offset

TZ=Australia/Canberra date -d "09:00 +0500" '+%F %a %T %z %Z'
2023-01-19 Thu 15:00:00 +1100 AEDT

TZ=Australia/Canberra date -d "+6month 09:00 +0500" '+%F %a %T %z %Z'
2023-07-19 Wed 14:00:00 +1000 AEST

TZ=Australia/Canberra date -d 'TZ="Etc/GMT-5" 09:00' '+%F %a %T %z %Z'
2023-01-18 Wed 15:00:00 +1100 AEDT

TZ=Australia/Canberra date -d 'TZ="Etc/GMT-5" +6month 09:00' '+%F %a %T 
%z %Z'

2023-07-18 Tue 14:00:00 +1000 AEST


Next week, I'm travelling to a different city for work and will be in a
different timezone. I need all my meetings to be adjusted except for
those I've already booked that are in the timezone I willl be in while
I'm away.


You specify that you original time zone e.g. Australia/Canberra, since 
2023-01-25 15:00 +0100 Europe/Berlin should be used and that agenda 
should be presented in either the "time zome" following you, or some 
fixed one (Australia/Canberra, Europe/Berlin, or Asia/Singapore)

Re: Observation of hysteresis in a GNU libc time conversion function

[Max Nikulin]

On 18/01/2023 16:54, Ihor Radchenko wrote:


This is problematic. You are putting MINUTES out of normal range. 


 (Isn't it really broken?)
https://www.gnu.org/software/libc/manual/html_node/Broken_002ddown-Time.html


 It uses the values of the other components to determine the calendar
time; it’s permissible for these components to have unnormalized values
outside their normal ranges.

Re: Observation of hysteresis in a GNU libc time conversion function

[Max Nikulin]

On 18/01/2023 16:54, Ihor Radchenko wrote:

Max Nikulin writes:


   (dt '(-90 -60 -31 -30 -29 -15 0 15 29 30 31 60 90))


This is problematic. You are putting MINUTES out of normal range.


Actually after some experiments and surprising results I figured out 
what really happens. I modified your example to get the value that you 
was likely expecting:


(let* ((tz "Europe/Berlin")
   (t1 (encode-time `(0 1 3 29 10 2023 nil -1 ,tz)))
   ;; !!! Try to comment out the line below
   (_ (encode-time `(0 59 1 29 10 2023 nil -1 ,tz)))
   (t2 (encode-time `(0 59 2 29 10 2023 nil -1 ,tz
  (list
   (format-time-string "%F %T %z %Z" t1 tz)
   (format-time-string "%F %T %z %Z" t2 tz)
   (time-subtract t1 t2)))
("2023-10-29 03:01:00 +0100 CET" "2023-10-29 02:59:00 +0200 CEST" 3720)

No negative minutes were involved.

I decided that hysteresis example is more funny.

Frankly speaking, I just forgot that I may use (make-decoded-time 
:minute -40) and `decoded-time-add' since I was not limited by Emacs-26 
support.


`encode-time' docstring for Emacs-26 has the following statement:


Out-of-range values for SECOND, MINUTE, HOUR, DAY, or MONTH are allowed;
for example, a DAY of 0 means the day preceding the given month.


So I do not think it affects anything. I decided to ask GNU libc developers
https://inbox.sourceware.org/libc-alpha/tq93sc$p3$1...@ciao.gmane.io/T/#u
"mktime result may depend on previous calls"


Looking at
https://codecogs.com/library/computing/c/time.h/ctime.php?alias=mktime,
out-of-range minutes are not documented.


Looks like a compilation of unspecified sources. The following is 
similar to ctime(3) man page


  if structure members are outside their valid
  interval,  they will be normalized (so that, for example,
  40 October is changed into 9 November);

My reading is that out of range values for other "members" are allowed 
as well. However it may be tricky.



Also, see
https://stackoverflow.com/questions/20104531/weird-mktime-logic-with-negative-seconds


My expectation is that ±1 day (or month) should preserve local time 
hours (e.g. 11:00 CET -> 11:00 CEST) if such moment of time exists. ±24 
hours, ±24*60 minutes, ±24*3600 seconds across DST change should cause 
appropriate shift of hours (e.g. 11:00 -> 12:00 is possible).


Moreover "out of range" month day 0 is the only way to specify last 
month day to get


 Jan, 31 <- 1 month -> Feb, 28 (or 29) <- 1 month -> Mar, 31

arithmetic.

However it is hardly implementation specific and GNU date(1) CLI 
utility, PostgreSQL, PHP timelib, JavaScript Date objects behave 
differently.


I still do not think it affects my example though.

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

[gautier]

The tables in my last message were not send correctly.
Please find attached a org file containing the tables.
So, the current situation is the following:

| Type of entry  | 
Face  | Use `org-agenda-timerange-leaders' |
|+---+|
| simple date: <2023-01-01 Sun>  | 
org-agenda-calendar-event | no |
| simple date with hour range: <2023-01-01 Sun 10:00-15:00>  | 
org-agenda-calendar-event | no |
| timerange (same day): <2023-01-01 Sun 10:00>--<2023-01-01 Sun 15:00>   | 
default   | yes|
| timerange (different days): <2023-01-01 Sun 10:00>--<2023-01-18 Wed 15:00> | 
default   | yes|
||  
 ||

and you say it would be better like this:

| Type of entry  | 
Face  | Use `org-agenda-timerange-leaders' |
|+---+|
| simple date: <2023-01-01 Sun>  | 
org-agenda-calendar-event | no |
| simple date with hour range: <2023-01-01 Sun 10:00-15:00>  | 
org-agenda-calendar-event | yes|
| timerange (same day): <2023-01-01 Sun 10:00>--<2023-01-01 Sun 15:00>   | 
org-agenda-calendar-event | yes|
| timerange (different days): <2023-01-01 Sun 10:00>--<2023-01-18 Wed 15:00> | 
new face (org-agenda-calendar-daterange?) | yes|

Is that correct?

Re: Make org-paste-subtree more predictable and useful

[Philipp Kiefer]

Thanks for addressing my concern, Ihor.

So I can force same-level yank by navigating to the beginning of the 
current headline before calling org-paste-subtree, I see. However, I 
still do not see a way to force it to paste one level below the current 
headline, i. e. to add the trees on the clipboard as child-subtrees or 
the current heading.


My best bet currently is probably to create a blank child heading, add 
some text (there seems to be a glitch turning the blank heading into an 
empty line when pasting with point on the blank dummy heading when it 
has no text), go back to the beginning of the line, then paste the 
subtrees at the level of the dummy heading, navigate back to the dummy 
heading and delete it. I'd really rather not have to do all that to 
achieve my simple goal of pasting subtrees at child level.


As for the claim that the current procedure "makes sure that the subtree 
remains an independent subtree and does not swallow low level entries.", 
either I don't understand it or it isn't true. If I have a level 2 
heading below which is a level 5 heading and I paste subtrees with point 
on the level 2 heading, the level 5 heading is subsumed under the last 
subtree yanked from the clipboard in all cases.


Best,

Philipp

On 18.01.2023 09:04, Ihor Radchenko wrote:

Philipp Kiefer  writes:


Unfortunately, org-paste-subtree currently attempts to "modify the level of
the subtree to make sure the tree fits in nicely at the yank position"
[from Org Manual].
...
My suggestion would be to make a fundamental change to how the command
works, prioritizing definite A) or B) type results over the current vague
"the tree fits in nicely" approach. IMHO the default should be to yank at
the same level as the focused heading. Then, if the C-u 0 numeric prefix
(which currently produces an error message) were used to yank at one level
below that (as subheadings of the focused heading), the functionality of
the other numeric prefixes to set the yank level could be preserved.

AFAIU, `org-paste-subtree' already does what you want for the most part.
See the function docstring:

 Paste the clipboard as a subtree, with modification of headline level.
 
 The entire subtree is promoted or demoted in order to match a new headline

 level.
 
 If the cursor is at the beginning of a headline, the same level as

 that headline is used to paste the tree.
 
 If not, the new level is derived from the *visible* headings

 before and after the insertion point, and taken to be the inferior headline
 level of the two.  So if the previous visible heading is level 3 and the
 next is level 4 (or vice versa), level 4 will be used for insertion.
 This makes sure that the subtree remains an independent subtree and does
 not swallow low level entries.

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

[gautier]

Ihor Radchenko  writes:


<2023-01-01 Sun 10:00>--<2023-01-01 Sun 15:00>
and
<2023-01-01 Sun 10:00-15:00>

are equivalent.

I'd say that it will make sense to apply `org-agenda-calendar-event'
face and `org-agenda-timerange-leaders' to <2023-01-01 Sun 10:00-15:00>
as well. What do you think about this approach?


So, the current situation is the following:

| Type of entry  
| Face  | Use `org-agenda-timerange-leaders' |

|+---+|
| simple date: <2023-01-01 Sun>  
| org-agenda-calendar-event | no |
| simple date with hour range: <2023-01-01 Sun 10:00-15:00>  
| org-agenda-calendar-event | no |
| timerange (same day): <2023-01-01 Sun 10:00>--<2023-01-01 Sun 15:00>   
| default   | yes|
| timerange (different days): <2023-01-01 Sun 10:00>--<2023-01-18 Wed 
15:00> | default   | yes
|


and you say it would be better like this:

| Type of entry  
| Face  | Use 
`org-agenda-timerange-leaders' |

|+---+|
| simple date: <2023-01-01 Sun>  
| org-agenda-calendar-event | no 
|
| simple date with hour range: <2023-01-01 Sun 10:00-15:00>  
| org-agenda-calendar-event | yes
|
| timerange (same day): <2023-01-01 Sun 10:00>--<2023-01-01 Sun 15:00>   
| org-agenda-calendar-event | yes
|
| timerange (different days): <2023-01-01 Sun 10:00>--<2023-01-18 Wed 
15:00> | new face (org-agenda-calendar-daterange?) | yes 
   |


Is that correct?

This would be nice. However, this requires more complexes changes. I
don't know if I am capable of preparing such a patch, but I can give it
a try.

By the way, the entries "simple date with hour range" and "timerange (on
the same day)" are also presented differently in the agenda view, the
first ones look like:
  agenda: 10:00-15:00 Test simple date with hour range
while the second ones look like:
  agenda: 10:00 ┄ Test timerange (on the same day)

Should this change as well?

org-habit and hourly repeats

[Felipe Balbi]

Hi,

I'm trying to start using `org-habit' but I noticed that hourly repeats
are not properly parsed by `org-habit-duration-to-days', however that's
a valid use case --- e.g. drinking water, medicine schedule,
physiotherapy sessions during the day, periodically practicing a new
language. For example, here's an easy TODO item that reproduces the
problem:

8<  cut here 

* TODO Foo
  SCHEDULED: <2023-01-18 Wed 11:00 .+8h>
  :PROPERTIES:
  :STYLE:habit
  :END:

8<  cut here 

It appears that a simple solution would be modify
`org-habit-duration-to-days' to accept the `h' suffix and set it to a
fraction of a day, something like:

8<  cut here 

(defun org-habit-duration-to-days (ts)
  (if (string-match "\\([0-9]+\\)\\([hdwmy]\\)" ts)
  ;; lead time is specified.
  (floor (* (string-to-number (match-string 1 ts))
(cdr (assoc (match-string 2 ts)
'(("h" . 0.042) ("d" . 1)
  ("w" . 7) ("m" . 30.4)
  ("y" . 365.25))
(error "Invalid duration string: %s" ts)))

8<  cut here 

Would something like this be an acceptable solution?

-- 
balbi

Re: Question about deadline/schedule events date text property

[Ihor Radchenko]

Daniel Fleischer  writes:

> Hi, I'm working on an unrelated project that collects events from agenda
> buffers. I noticed the following: when you have a series of a repeating
> events, scheduled events have a date text property of the form
> (1 9 2023) date matches the instance date
>
> while deadline events have
> 738529 which repeats for all instances

I guess that the corresponding code is in `org-agenda-get-deadlines':

  'date (if upcoming? date deadline)

> Is this intentional? Why don't they have the same format/behavior? 

No idea. org-agenda is old and fragile. I would not dare to touch it
unless absolutely needed.

Note that `org-fix-agenda-info' converts the 'date property back to some
other format... (yes, that's kind of crazy)

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

Re: Thoughts on this ob language generator

[Ihor Radchenko]

George Mauer  writes:

> I had a need the other day to execute some typescript in an org document.
> Now I know that there's an ob-typescript package but that doesn't quite
> work the way I want and expects typescript to be installed globally (which
> runs into a variety of versioning issues).
>
> There is a better option available with the `npx` program (installed
> alongside `npm`) which can install a package along with its dependencies
> into a temporary sandbox and run its binaries.
>
> I rewrote the typescript babel plugin to do this and then realized that
> there was relatively little in it beyond variable and function names that
> was typescript-specific. The exact same process can be used for anything
> that has an interpreter up on npm. Coffeescript, mermaidjs, all sorts of
> things.
>
> So I made a macro. I'm interested what people here think:
> https://github.com/togakangaroo/create-ob-npx

I'd say that the problem you are trying to solve is similar to what
ob-shell.el does. And it does it similarly, modulo common shell syntax.

More generally, generic backends like ob-shell or what you are proposing
are a subset of "take the code block, save it to file, and pass the file
to be executed by a CLI command".

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

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

[Ihor Radchenko]

Tim Cross  writes:

>> Does it sound good enough?
>
> No, I'm afraid not. How does org distinguish between meeting 1 and
> meeting 2? IN meeting one, when the timezone transitions in/out of
> daylight savings, nothing needs to change, but in meeting 2, when this
> occurs, the meeting needs to be re-sechduled so that it keeps the same
> offset relative to UTC.
> Some mechanism is needed so that the user can
> identify timestamps like those fo rmeeting 1 from those for meeting
> 2. My idea was to have meeting 1 type timestamps without TZ info and
> meeting 2 require fully qualified TZ info. However, while this would
> probably work, I don't like it because it isn't explicit and would be
> prone to errors.

I still don't understand.

In Org, you will have a default time zone that will be used to build the
agenda.

In meeting 1, you set the time zone to your local zone
In meeting 2, you set the time zone to the time zone where the meeting
is scheduled.

The, both the meetings will be first converted to the default time zone
and appear in your agenda adjusted as required.

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

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

[Tim Cross]

Ihor Radchenko  writes:

> Tim Cross  writes:
>
>>> Could you please elaborate here?
>>
>> I have some meetings scheduled in my org files which show up in the
>> agenda.
>>
>> Meeting 1 is a reoccurring meeting which happens every 2 weeks. All of
>> the people in that meting are in the same timezone as I'm in. When we
>> transition into/out of daylight savings time, I don't want the timestamp
>> to change. THe meeting will remain at 3pm.
>
> Specifying the timezone should be good enough.
> Not specifying will put you at a risk if you travel (you default OS
> timezone will likely change).
>
>> Meeting 2. This is also a reoccuring meeting. However, this meeting is
>> with people from a number of idfferent time zones. When my timezone
>> moves into or out of daylight savings time, I need the meeting time to
>> be updated - moved forward/back 1 hour.
>
> Again, you can just specify the right timezone and let Org translate it
> to local one when calculating agenda.
>
>> Next week, I'm travelling to a different city for work and will be in a
>> different timezone. I need all my meetings to be adjusted except for
>> those I've already booked that are in the timezone I willl be in while
>> I'm away.
>
> If you don't specify the timezone for both old and new meetings, there
> will be no easy way to deal with this. What you may have to do is: (1)
> indicate explicit timezone for the meetings in the new place (there will
> probably be less of them compared to all other meetings); (2) tell Org
> to use your old time zone as default - it will make the previously
> scheduled meetings without timezone info use the right time zone.
>
>> Finally, I have a few timestamps I use to track some projects and
>> progress on various tasks as well as reports showing actual and
>> estimated effort comparisons as well as managing billing/invoicing. The
>> actual timestamp times are less important than the calculation of
>> durations etc. When durations do cross daylight savings transition
>> points, it is critical that additonal hours are not accidentally
>> added/removed from the duration calculation. Mistakes here could result
>> in me loosing revenue or over charging clients.
>
> For the past timestamps, you can either: (1) make Org put UTC offsets
> when recording clock data; (2) use the idea we discussed about multiple
> default time zones where you can specify different time zones at
> different periods of time (before after travel).
>
> Does it sound good enough?

No, I'm afraid not. How does org distinguish between meeting 1 and
meeting 2? IN meeting one, when the timezone transitions in/out of
daylight savings, nothing needs to change, but in meeting 2, when this
occurs, the meeting needs to be re-sechduled so that it keeps the same
offset relative to UTC. Some mechanism is needed so that the user can
identify timestamps like those fo rmeeting 1 from those for meeting
2. My idea was to have meeting 1 type timestamps without TZ info and
meeting 2 require fully qualified TZ info. However, while this would
probably work, I don't like it because it isn't explicit and would be
prone to errors.

Note that the above is a real scenario - I have to deal with this type
of problem frequently. The other types can, in general, be handled
through judicious use of TZ settings.

Re: org-todo-keywords and task sequence

[Ihor Radchenko]

David Masterson  writes:

>> Ambiguous is: consider a task IN-PROCESS and you press S-left. Should
>> Org go to TODO or to WAIT? Org will choose one, but there are no defined
>> rules.
>
> Ah.  Could Org offer a choice of TODO or WAIT (a la Ido style)?

If you need that choice, just use C-c C-t. I do not think that we need
to complicate S-left/right that much.

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

Re: org-todo-keywords and task sequence

[Ihor Radchenko]

David Masterson  writes:

> What I've been saying is that, except for simple sequences, cycling will
> get you into trouble with notes as a lazy person (aren't we all?) may
> cycle thru something unintended.

As any other Org feature, this one is useful for some people. And not
useful for others. You don't have to use it.

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

Re: .org.bak files are in Org mode -- intended?

[Ihor Radchenko]

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

> I have noticed by chance that files with the .org.bak extension are in
> Org mode by default.
>
> If one does not pay attention, it can lead to mistakes.
>
> If it is really intended, why not mention it in the manual? (In 1.3,
> where it is said that "Files with the ‘.org’ extension use Org mode by
> default.")
>
> Are there other similar cases?

Any backup file is opened as if the file name did not contain the backup
suffix:

`auto-mode-alist' contains:

 ("\\.~?[0-9]+\\.[0-9][-.0-9]*~?\\'" nil t)
 ("\\.\\(?:orig\\|in\\|[bB][aA][kK]\\)\\'" nil t)

meaning "if file name matches, strip the match and try determining major
mode again"

> Also, the names of files generated upon export, although making sense,
> cannot be anticipated: while 'foo.org' is latex exported as 'foo.tex'
> (as said in the manual), 'foo.org.bak' becomes 'foo.org.tex'.

I guess we could fix this.
Though, I'd prefer if Emacs provided basic functionality to strip backup
suffix: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=60929

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

Re: .org.bak files are in Org mode -- intended?

[General discussions about Org-mode.]

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

> I have noticed by chance that files with the .org.bak extension are in
> Org mode by default.
>
> If one does not pay attention, it can lead to mistakes.
>
> If it is really intended, why not mention it in the manual? (In 1.3,
> where it is said that "Files with the ‘.org’ extension use Org mode by
> default.")
>
> Are there other similar cases?
>
> Also, the names of files generated upon export, although making sense,
> cannot be anticipated: while 'foo.org' is latex exported as 'foo.tex'
> (as said in the manual), 'foo.org.bak' becomes 'foo.org.tex'.

I believe this is not org-specific.  Opening "1.txt.bak" makes the
buffer use `text-mode'.

Best,


RY

Re: [PATCH 0/4] Structure editing when region is active

[Ihor Radchenko]

Samuel Wales  writes:

> maybe my comment is too unrelated to the patch, but it just seemed
> worth raising in the context.  to me it feels wrong to have a
> non-linline-task child entry whose heading is star-indented more
> levels than needed to denote a child entry.
>
> in my own case, it suggests corruption, because i would not
> deliberately create that.  i have encountered it.  similarly if
> org-odd-levels-only is non-nil and there is an even star heading.  i
> have encountered it.  confusing to track down.
>
> i was merely asking if there was anything in e.g. main or syntax
> documents etc. that refers to or enforces this.

I have seen some checks in the code to ensure not breaking structure.
They may not be ideal, indeed. Hard to say much without a reproducer.

> as for active region or transient mark, to me, they are supposed to be
> transient, unlike, for example, agenda restriction lock, and thus, for
> example, having to c-g or so to get rid of a highlighted region feels
> like a bug.
>
> there might be exceptions where you pretty much always want to run a
> command more than once with the region remaining active, perhaps such
> as a rectange opening type of command, but to me the patch commands do
> not apply there.

The patch is mostly aiming at M-arrow commands.
I feel like M-arrow are issued repeatedly quite often.
We may also provide a defcustom. Though I will be in favour of keeping
"do not deactivate selection" as the default of such defcustom.

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

.org.bak files are in Org mode -- intended?

[Alain . Cochard]

I have noticed by chance that files with the .org.bak extension are in
Org mode by default.

If one does not pay attention, it can lead to mistakes.

If it is really intended, why not mention it in the manual? (In 1.3,
where it is said that "Files with the ‘.org’ extension use Org mode by
default.")

Are there other similar cases?

Also, the names of files generated upon export, although making sense,
cannot be anticipated: while 'foo.org' is latex exported as 'foo.tex'
(as said in the manual), 'foo.org.bak' becomes 'foo.org.tex'.


-- 
EOST (École et Observatoire des Sciences de la Terre) 
ITE (Institut Terre & Environnement) | alain.coch...@unistra.fr
5 rue René Descartes   [bureau 110]  | Phone: +33 (0)3 68 85 50 44 
F-67084 Strasbourg Cedex, France | [ slot available for rent ]

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

[Ihor Radchenko]

gaut...@gautierponsinet.xyz writes:

> Currently, the entries with a time range of the form
> <2022-12-22 Thu 10:00-12:00>
> use the face 'org-agenda-calendar-event'.
> While the entries with time ranges of the form
> <2022-12-22 Thu>--<2023-01-01 Sun>, or
> <2022-12-22 Thu 12:00>--<2023-01-01 Sun 10:00>, or even
> <2023-01-01 Sun 10:00>--<2023-01-01 Sun 15:00>
> use the default face.

So, the current situation is already not consistent.

<2023-01-01 Sun 10:00>--<2023-01-01 Sun 15:00>
and
<2023-01-01 Sun 10:00-15:00>

are equivalent.

I'd say that it will make sense to apply `org-agenda-calendar-event'
face and `org-agenda-timerange-leaders' to <2023-01-01 Sun 10:00-15:00>
as well. What do you think about this approach?

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

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

[Ihor Radchenko]

Max Nikulin  writes:

> ... I am unsure concerning Windows, it may have an option of quite 
> similar variant. That is why I am not sure to which degree Org should be 
> liberal in respect to various time zones.

May we just support whatever TZ supports (POSIX)?

I was also thinking about ISO 8601, but it interferes with time ranges
(4:00-8:00 may be both "from 2am to 8am" and "4am UTC-08"). Though other
ISO 8601 variants like 4:00-0800 might work.

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

Re: Observation of hysteresis in a GNU libc time conversion function

[Ihor Radchenko]

Max Nikulin  writes:

>  (dt '(-90 -60 -31 -30 -29 -15 0 15 29 30 31 60 90))

This is problematic. You are putting MINUTES out of normal range.
Looking at
https://codecogs.com/library/computing/c/time.h/ctime.php?alias=mktime,
out-of-range minutes are not documented.

Also, see
https://stackoverflow.com/questions/20104531/weird-mktime-logic-with-negative-seconds

Using out-of-range time fields is not advised.

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

Re: [BUG] Many babel-stable-nnn fodlers created in folders with org files (instead of in /tmp) [9.6.1 ( @ /home/bhrgunatha/.emacs.d/elpa/org-9.6.1/)]

[bhrgunatha]

It works for me!

Thank you for fixing this and so quickly too! It's much appreciated.

bhrgunatha


On 18/01/2023 17:07, bhrgunatha wrote:

On 18/01/2023 16:02, Ihor Radchenko wrote:

bhrgunatha  writes:


Open emacs.
Open some .org file with src blocks in some folder /some.org
Notice a new folder called babel-stable-nnn (some randome 3 digit
number) appears in the folder containing the .org file.

I think these should be created in my /tmp/ folder, not the folder
containing the .org file.

Sometimes they ARE created in my /tmp/ folder.

Thanks for reporting!

Could you open one of the folders where babel-stable-nnn directories are
present and then run M-: (temporary-file-directory) ?
Is the printed output "/tmp"? Something else?


Thanks for responding Ihor.

Opening e.g. "/mnt/data/src/learning/zig/zig_notes.org"
In the buffer visiting zig_notes.org:
M-: (temporary-file-directory) -
"/mnt/data/src/learning/zig/"
The variable though:
temporary-file-directory -
"/tmp/"

Looking at that function and from the same buffer I also checked:
default-directory -
"/mnt/data/src/learning/zig/"
mounted-file-systems -
"^\\(?:/\\(?:afs/\\|m\\(?:edia/\\|nt\\)\\|\\(?:ne\\|tmp_mn\\)t/\\)\\)"
(find-file-name-handler default-directory 'temporary-file-directory) -
0

I wondered about a buffer not visiting a file. In my default *scratch* 
buffer I get:

(temporary-file-directory) -
"/tmp/"
temporary-file-directory -
"/tmp/"
mounted-file-systems -
"^\\(?:/\\(?:afs/\\|m\\(?:edia/\\|nt\\)\\|\\(?:ne\\|tmp_mn\\)t/\\)\\)"
(find-file-name-handler default-directory 'temporary-file-directory) -
nil

The same in some *help* buffer though _except_:
(temporary-file-directory) -
"/mnt/data/src/learning/zig/"

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

[Ihor Radchenko]

Jean Louis  writes:

>> >> I am not sure what is the problem.
>> >> The timestamps that should stay in local time will be automatically
>> >> updated as your system TZ is updated.
>> >
>> > Then Org shall know what was local time! Without being specified in
>> > the time stamp, it has to be specified somewhere, as computer can't
>> > know at which time zone was it specified.
>> 
>> We need nothing to use current time zone. And we already do it.
>> 
>> System clock knows the current time zone. Emacs has an ability to
>> determine current time zone. See `current-time-zone'. This works
>> automatically (and already) because we use `encode-time'.
>
> Then you did not understand the point.
>
> For users who use Org personally, in single place, single time zone,
> who do no travel, who do not share headings, tasks, and files
> internationally, they really do not need hussle with time zones!
>
> However, when nice strong guy makes an Org file with list of tasks in
> Ukraine and send it to nice girl Florida, she will simply think that
> at 9 o'clock she has to discuss making visa with her fiance, but
> fiance is already pissed off because she did not appear at online
> meeting.

Sure. Then, a guy from Ukraine can add default timezone to the shared
file/heading. It will then apply to all the timestamps that do not
explicitly specify the time zone in the file/heading contents.

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

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

[Ihor Radchenko]

Jean Louis  writes:

> When there is global variable for Org file about time zone, then:
>
> - every timestamp with time zone, shall be left intact or
> re-calculated to diffrent local time zone. Imagine person giving Org
> file from Russia to somebody in Florida, or travelling there. That
> user or recipient would like to see the actual time, which is time for
> him in Florida, but in its representation different from time in
> Russia.

Sure. I imagine `org-display-custom-times' could handle this.

> - ever timestamp with settings in heading, shall be calculated as
> such.
>
> It means there shall be functions which can convert timestamps to the
> new time zone, with the option to left unchanged those timestamps who
> already have time zone specified, and with option not to be converted.

I am not sure why you need a difference here.

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

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

[Ihor Radchenko]

Jean Louis  writes:

> ...
> Should be part of C library to observe those things.

Sure. My previous proposals are all relying on `encode-time' which uses
time.h from system libraries and utilizing TZDB that is taking care
about all this insanity.

We, however, might need to be careful about applying date increments. In
`org-read-date' and `org-timestamp-change', which are implemented in
Elisp without considering these complexities. (maybe also other
functions; these are just the ones I can think about)

What should we do when:

1. It is close to DST transition 2:59 -> 2:00 -> 2:01 -> ... -> 2:59 -> 3:00
   and the users asks to create a timestamp +1h from now
   or, worse, a timestamp +1h from now in a different time zone

2. A user asks +1w date shift and the time zone has a 1-day jump during DST?
   what about +7d? +1d?

3. What will be +1d 2:30am timestamp refer to when there DST transition
   as in (1)?


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

Re: [BUG] Many babel-stable-nnn fodlers created in folders with org files (instead of in /tmp) [9.6.1 ( @ /home/bhrgunatha/.emacs.d/elpa/org-9.6.1/)]

[Ihor Radchenko]

bhrgunatha  writes:

>> Could you open one of the folders where babel-stable-nnn directories are
>> present and then run M-: (temporary-file-directory) ?
>> Is the printed output "/tmp"? Something else?
>>
> Opening e.g. "/mnt/data/src/learning/zig/zig_notes.org"
> In the buffer visiting zig_notes.org:
> M-: (temporary-file-directory) -
> "/mnt/data/src/learning/zig/"
> The variable though:
> temporary-file-directory -
> "/tmp/"

Thanks!
Then, I see what happens.
Fixed, on bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=cbb288eaa

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

Re: [BUG] org-agenda: definition is void: org-element--cache-active-p

[Simon Tournier]

Hi,

On Wed, 18 Jan 2023 at 09:53, Ihor Radchenko  wrote:

> Fixed, on bugfix.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5d9c9c27c

Cool!  Thank you for the quick fix.

Cheers,
simon

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

[Ihor Radchenko]

Tim Cross  writes:

>> Could you please elaborate here?
>
> I have some meetings scheduled in my org files which show up in the
> agenda.
>
> Meeting 1 is a reoccurring meeting which happens every 2 weeks. All of
> the people in that meting are in the same timezone as I'm in. When we
> transition into/out of daylight savings time, I don't want the timestamp
> to change. THe meeting will remain at 3pm.

Specifying the timezone should be good enough.
Not specifying will put you at a risk if you travel (you default OS
timezone will likely change).

> Meeting 2. This is also a reoccuring meeting. However, this meeting is
> with people from a number of idfferent time zones. When my timezone
> moves into or out of daylight savings time, I need the meeting time to
> be updated - moved forward/back 1 hour.

Again, you can just specify the right timezone and let Org translate it
to local one when calculating agenda.

> Next week, I'm travelling to a different city for work and will be in a
> different timezone. I need all my meetings to be adjusted except for
> those I've already booked that are in the timezone I willl be in while
> I'm away.

If you don't specify the timezone for both old and new meetings, there
will be no easy way to deal with this. What you may have to do is: (1)
indicate explicit timezone for the meetings in the new place (there will
probably be less of them compared to all other meetings); (2) tell Org
to use your old time zone as default - it will make the previously
scheduled meetings without timezone info use the right time zone.

> Finally, I have a few timestamps I use to track some projects and
> progress on various tasks as well as reports showing actual and
> estimated effort comparisons as well as managing billing/invoicing. The
> actual timestamp times are less important than the calculation of
> durations etc. When durations do cross daylight savings transition
> points, it is critical that additonal hours are not accidentally
> added/removed from the duration calculation. Mistakes here could result
> in me loosing revenue or over charging clients.

For the past timestamps, you can either: (1) make Org put UTC offsets
when recording clock data; (2) use the idea we discussed about multiple
default time zones where you can specify different time zones at
different periods of time (before after travel).

Does it sound good enough?

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

Re: [BUG] Many babel-stable-nnn fodlers created in folders with org files (instead of in /tmp) [9.6.1 ( @ /home/bhrgunatha/.emacs.d/elpa/org-9.6.1/)]

[bhrgunatha]

On 18/01/2023 16:02, Ihor Radchenko wrote:

bhrgunatha  writes:


Open emacs.
Open some .org file with src blocks in some folder /some.org
Notice a new folder called babel-stable-nnn (some randome 3 digit
number) appears in the folder containing the .org file.

I think these should be created in my /tmp/ folder, not the folder
containing the .org file.

Sometimes they ARE created in my /tmp/ folder.

Thanks for reporting!

Could you open one of the folders where babel-stable-nnn directories are
present and then run M-: (temporary-file-directory) ?
Is the printed output "/tmp"? Something else?


Thanks for responding Ihor.

Opening e.g. "/mnt/data/src/learning/zig/zig_notes.org"
In the buffer visiting zig_notes.org:
M-: (temporary-file-directory) -
"/mnt/data/src/learning/zig/"
The variable though:
temporary-file-directory -
"/tmp/"

Looking at that function and from the same buffer I also checked:
default-directory -
"/mnt/data/src/learning/zig/"
mounted-file-systems -
"^\\(?:/\\(?:afs/\\|m\\(?:edia/\\|nt\\)\\|\\(?:ne\\|tmp_mn\\)t/\\)\\)"
(find-file-name-handler default-directory 'temporary-file-directory) -
0

I wondered about a buffer not visiting a file. In my default *scratch* 
buffer I get:

(temporary-file-directory) -
"/tmp/"
temporary-file-directory -
"/tmp/"
mounted-file-systems -
"^\\(?:/\\(?:afs/\\|m\\(?:edia/\\|nt\\)\\|\\(?:ne\\|tmp_mn\\)t/\\)\\)"
(find-file-name-handler default-directory 'temporary-file-directory) -
nil

The same in some *help* buffer though _except_:
(temporary-file-directory) -
"/mnt/data/src/learning/zig/"

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

[Ihor Radchenko]

Matt  writes:

> (process-file
>   "cmdproxy.exe"   ; 
> shell-file-name
>   "/path/to/temp/containing/block/source"  ; input-file
>   (t "/tmp/babel jTCHe/ob-error-yHOivA"); output destination (like 
> call-process's DESTINATION)
>   nil ; 
> display
>  "-c"; 
> args
>   "cmdproxy.exe"   ; args

> Thoughts?

If running cmdproxy.exe /c cmdproxy.exe /path/to/input is not wrong, the
problem is on Emacs side.

Osher, could you try putting your example script into a file and running
the command line directly? What will it output?

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

Re: [BUG] org-agenda: definition is void: org-element--cache-active-p

[Ihor Radchenko]

zimoun  writes:

> Obviously, loading org-element fixes the issue:
>
> $ emacs -q -l config.el --eval "(require 'org-element)" -f org-agenda
>
> Therefore, maybe the addition of such requirement in org-agenda.el could
> be enough?

Thanks for reporting!
Loading should be good enough (and does not cause circular dependency
issue).

Fixed, on bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5d9c9c27c

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

Re: [BUG] Org-export does not updates figure path when using recursive includes [9.6 (9.6-??-bed47b4 @ /home/gpetrini/.emacs.d/.local/straight/build-28.2/org/)]

[Ihor Radchenko]

Gabriel Petrini da Silveira  writes:

> *Expected behaviour*: Using recursinve includes generates a PDF file
>  with the respective figures.
>
> *Actual behaviour:* Figure only appears when not using recursive includes.

Thanks for reporting!
Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=0e5de0ff6

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

Re: Make org-paste-subtree more predictable and useful

[Ihor Radchenko]

Philipp Kiefer  writes:

> Unfortunately, org-paste-subtree currently attempts to "modify the level of
> the subtree to make sure the tree fits in nicely at the yank position"
> [from Org Manual].
> ...
> My suggestion would be to make a fundamental change to how the command
> works, prioritizing definite A) or B) type results over the current vague
> "the tree fits in nicely" approach. IMHO the default should be to yank at
> the same level as the focused heading. Then, if the C-u 0 numeric prefix
> (which currently produces an error message) were used to yank at one level
> below that (as subheadings of the focused heading), the functionality of
> the other numeric prefixes to set the yank level could be preserved.

AFAIU, `org-paste-subtree' already does what you want for the most part.
See the function docstring:

Paste the clipboard as a subtree, with modification of headline level.

The entire subtree is promoted or demoted in order to match a new headline
level.

If the cursor is at the beginning of a headline, the same level as
that headline is used to paste the tree.

If not, the new level is derived from the *visible* headings
before and after the insertion point, and taken to be the inferior headline
level of the two.  So if the previous visible heading is level 3 and the
next is level 4 (or vice versa), level 4 will be used for insertion.
This makes sure that the subtree remains an independent subtree and does
not swallow low level entries.

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

Re: [BUG] Many babel-stable-nnn fodlers created in folders with org files (instead of in /tmp) [9.6.1 ( @ /home/bhrgunatha/.emacs.d/elpa/org-9.6.1/)]

[Ihor Radchenko]

bhrgunatha  writes:

> Open emacs.
> Open some .org file with src blocks in some folder /some.org
> Notice a new folder called babel-stable-nnn (some randome 3 digit
> number) appears in the folder containing the .org file.
>
> I think these should be created in my /tmp/ folder, not the folder
> containing the .org file.
>
> Sometimes they ARE created in my /tmp/ folder.

Thanks for reporting!

Could you open one of the folders where babel-stable-nnn directories are
present and then run M-: (temporary-file-directory) ?
Is the printed output "/tmp"? Something else?

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