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

[Max Nikulin]

On 20/01/2023 12:39, Tim Cross wrote:


No, I disagree with that statement. That is old thinking based when
meetings meant face to face meetings. Only meeting which have a specific
location can have a time zone and even then, it isn't really the
meetings time zone, but instead the time zone of the participants at the
meeting.


Tim, I am trying to say that any meeting either face to face or on-line 
may be associated with arbitrary primary timezone. Even when all 
participants are in Sydney they may decide to fix time in Darwin. It is 
strange, but it is possible. UTC is just one of time zones that may be 
convenient for on-line meeting despite no participant really use it. 
Local timezone is usually preferred for purely face to face meetings. 
You are not realizing that is decision since it is not verbalized. 
Consider timezone as something unrelated to location but just a set of 
rules how time offset in respect to epoch evolves in time.


UI might offer you to choose time in your timezone and to select another 
timezone for storage. For your convenience it still may be presented to 
you in your local timezone even it is stored in UTC or some other one.

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

[Thomas S. Dye]

Aloha Max,

Max Nikulin  writes:


On 20/01/2023 03:09, Tim Cross wrote:
To reiterate for the last time, there are 2 clear and different 
use

cases for timestamps associated with meetings.
1. A meeting timestamp for a meeting where all the participants 
are in

the same time zone.
...> 2. A meeting timestamp for a meeting where all the 
participants are in

different time zones


Tim, every scheduled meeting event is associated with some 
particular time zone,

often implicitly. So it is single use case.

It is up to participants to negotiate which timezone is the 
primary one for each
event. It is matter of people communication, not technical 
issue.


First Monday 15:00 is (almost) equally precise for
- Australia/Canberra having DST
- Australia/Darwin where currently no DST
- +1000 (the highest chance of improper use unfortunately)
- UTC

Aside from time transition intervals, it is possible to take any 
of this variant
and to present time local for other participant across the 
globe.


Storage timezone may differ from the current user preference 
which time zone

should be used to display timestamp or to export it.

The problem arises when several participants believe that their 
timezones are
primary ones and they do not sync their schedules through a 
shared file or a DB
entry. An application can not solve this problem, but it might 
try to help to
identify it. Some efforts are necessary from user side. 
Timestamp should contain
list of timezones of other participants and cached local time. 
In such case an
application may warn users that local time values become 
inconsistent due to DST
transitions or due to update of time zone database. Unsure to 
what degree it

should be implemented in Org.

So
- It is participants fault if a meeting is not associated with 
particular

 timezone
- Having a fair time handling library, it does not matter what 
time zone is used

 to schedule the meeting.


Or, one can recognize that the meeting is an occurrence that 
requires absolute time and a timestamp with UTC.  Each participant 
will resolve UTC to the local time where they happen to be when 
the meeting takes place.  The user might toggle between UTC and 
the local time translation using overlays, like pretty entities. 
This avoids the problem of negotiating a timezone caused by 
forcing an occurrence to be represented as an event relative to a 
fictitious space/time.


hth,
Tom

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

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

[Thomas S. Dye]

Aloha Tim,

Tim Cross  writes:


"Thomas S. Dye"  writes:


Aloha Tim,

Tim Cross  writes:


"Thomas S. Dye"  writes:


Aloha Tim,


UTC is a time zone - just one where offset is +


UTC is absolute time.  It lacks the spatial component that 
defines a time zone.




Really? I would have thought the prime meridian was the 
spacial
component for UTC? I thought the full long time zone name was 
Etc/UTC

and UTC as the abbreviation.

Regardless, in all the libraries I've used, you can use 
Etc/UTC or UTC
in exactly the same way you would use something like 
Australia/Sydney or
AEST. So perhaps, from a pedantic standpoint, it is not a time 
zone, but
for all intent and purpose in this discussion, I feel that 
point is

irrelevant.


Agreed.  It does seem irrelevant for time zone libraries.

Nevertheless, from the Org perspective it might not be.  An 
occurrence, which marks
changes in the nature or relations of things at a time, 
requires absolute time.  Meetings,
which involve a change in relation among participants, are 
occurrences.  IMO, this
indicates Org should give occurrences a UTC timestamp, then 
translate that for each of the
participants using their local time zone.  The insane interval 
problems that Ihor brought
up are moot in absolute time.  A single timestamp serves a 
meeting regardless of whether
the participants are all in one time zone or spread around the 
globe.


An occurrence contrasts with an event, which is tied to the 
user's space/time.  Time here
is relative to the user.  IMO, this means that Org should give 
events a timestamp without
reference to either absolute time or a particular time zone, 
like the one it uses now.




Just checking if I understand. I think we are coming from the 
same

position and with the same conclusion.


Thanks!

In the situation where the meeting involves people from 
different time
zones, the time of the meeting as reported by org needs to be 
adjusted
after a daylight savings transition so that the time maintains 
the same

relative to UTC. i.e. meeting time reported in local time goes
forward/backward 1 hour depending on the daylight savings 
transition
(in/out). I guess this is what you call an occurrence? 

When all participants in a meeting are in the same time zone, 
you do not
want the time changed as the result of the daylight savings 
transition.

This is what you call an event?


Every meeting is an occurrence because it involves changes in 
relations of things at time; in this case meeting participants 
relate to one another via Jitsi, regardless of whether they are 
all in one time zone or spread over the globe.


An event's time is relative to the user's location, or space/time. 
So, the example I gave earlier "Brush teeth before bed" set to 
10:00 PM, which works whether I am home in Honolulu or enjoying 
the hustle and bustle of Manhattan, is a simple event.  It happens 
at that time in the timezone I happen to inhabit at the moment, 
because I intend to go to sleep shortly after 10:00 PM regardless 
of where I am.




So, using your terminology, what we now need is convenience 
functions
for setting an occurrence timestamp and an event timestamp. I'm 
not sure
if occurrence/event are the best terms, but I cannot think of 
better
ones. Just slightly concerned people will have trouble grasping 
the
difference and undersanding why some meetings are an occurrence 
while
others are an event. FOr the user, they are just meetings.


Yes, both meetings are occurrences.

I agree that the terms take some getting used to.  I got them from 
Frank Ramsey, who seemed to be happy with event, but not so happy 
with occurrence.


The difference is this: Will the happening being scheduled involve 
other people, who will share the Org timestamp, or will it take 
place at the same absolute time, regardless of where you are when 
it happens?  If so, then the timestamp should be stored as UTC (it 
is an occurrence that requires absolute time).


Or, is it something you want to do at a time, regardless of where 
you are.  If so, then the usual Org timestamp without UTC is what 
should be stored (it is an event that requires time local to the 
user).


In the case of a meeting, where the one who calls the meeting 
sends an Org file with a meeting agenda and a UTC timestamp to 
each of the participants, Org will translate the UTC timestamp 
into local time for each participant.  Similarly, when you are 
traveling, Org will translate the UTC timestamp to the timezone 
you happen to inhabit.  Here, I'm assuming that the timezone 
machinery is capable of determining local time relative to UTC.


hth,
Tom

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

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

[Tim Cross]

Max Nikulin  writes:

> On 20/01/2023 03:09, Tim Cross wrote:
>> To reiterate for the last time, there are 2 clear and different use
>> cases for timestamps associated with meetings.
>> 1. A meeting timestamp for a meeting where all the participants are in
>> the same time zone.
> ...> 2. A meeting timestamp for a meeting where all the participants are in
>> different time zones
>
> Tim, every scheduled meeting event is associated with some particular time 
> zone, often
> implicitly. So it is single use case.
>

No, I disagree with that statement. That is old thinking based when
meetings meant face to face meetings. Only meeting which have a specific
location can have a time zone and even then, it isn't really the
meetings time zone, but instead the time zone of the participants at the
meeting.

Meetings without a specific location do not have time zones, implicit or
otherwise. If you have an on-line meeting with 5 people from 5 different
time zones, there is no time zone which takes precedence and cna be
thought of as the meeting time zone. You could decide to do that if you
wanted, but it doesn't achieve anything useful. 

> It is up to participants to negotiate which timezone is the primary one for 
> each event. It
> is matter of people communication, not technical issue.
>

The issue I'm talking about has nothing to do with the other
participants of the meeting. It is irrelevant to them when my time zone
changes due to daylight savings.

> First Monday 15:00 is (almost) equally precise for
> - Australia/Canberra having DST
> - Australia/Darwin where currently no DST
> - +1000 (the highest chance of improper use unfortunately)
> - UTC
>

That is a bad example and is wrong. Australia/Canberra and
Australia/Darwin are different timezones regardless. Darwin is +930 and
Canberra is +1000 (+1100 with DS). So Monday 15;00 in Darwin will be at
15:30 in Canberra outside DS time and 16:30 during DS time.

> Aside from time transition intervals, it is possible to take any of this 
> variant and to
> present time local for other participant across the globe.
>
> Storage timezone may differ from the current user preference which time zone 
> should be
> used to display timestamp or to export it.
>
> The problem arises when several participants believe that their timezones are 
> primary ones
> and they do not sync their schedules through a shared file or a DB entry. An 
> application
> can not solve this problem, but it might try to help to identify it. Some 
> efforts are
> necessary from user side. Timestamp should contain list of timezones of other 
> participants
> and cached local time. In such case an application may warn users that local 
> time values
> become inconsistent due to DST transitions or due to update of time zone 
> database. Unsure
> to what degree it should be implemented in Org.
>

and this is not the issue I'm trying to solve here. At no time did I
reference booking meetings or scheduling meetings with others. This has
nothing to do with eh use case I was outlining. 

> So
> - It is participants fault if a meeting is not associated with particular 
> timezone
> - Having a fair time handling library, it does not matter what time zone is 
> used to
>  schedule the meeting.

OK, I just give up.

I don't understand why my very simple point seems so hard for anyone to
grasp and why everyone seems so focused on the booking and scheduling of
meetings with outhers. This was never in the scope of the very simple
issue I want solved. 

All I want is for org to tell me when my meeting is. I don't care about
other people's time zones or when the meeting is for them, I don't care
who books the meeting and I don't care whether someone feels the meeting
has a time zone or not because it is all totally irrelevant for my use
case.

This is very very simple and doesn't need to be over thought.

I have two reoccurring meetings.

Meeting 1. All of the people for this meeting are in my time zone. When
daylight savings transitions occur, there is no impact. THis is how org
timestamps work now. Nothing is required.

Meeting 2. This meeting has 5 participants. They are all in different
time zones. When daylight savings time transitions occur in my timezone,
I need the time stamp to report an adjusted time based on the change
(either forward or back 1 hour). Currently, org cannot manage this and
my meeting time is out by one hour for 6 months of the year. 

How is this handled by org?

My suggested solution, which I feel is quite simple is to simply use a
timestamp with a UTC or Etc/UTC value for the time zone for meetings
with participants from different time zones and where the time of the
meeting must remain constant with respect to UTC. Assuming that once org
timestamps handling has been updated to display timestamps according to
the local time zone, the issue with the second meeting example is
solved. Thats it, done.

You might sayh this isn't a technical issue, but it can obviously be
solved adopting a 

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

[Matt]

  On Thu, 19 Jan 2023 11:28:09 -0500  Osher Jacob  wrote --- 
 
 > If we're insistent on passing the input through the command line arguments, 
 > I can think of two ways to go about this, but both seem undesirable

They're good ideas and, I agree, aren't ideal.  

 >  I think it could be enough to make sure the input ends with a newline, in 
 > which case it could be done the way I proposed in the first message, that is 
 > changing:(t (org-babel-eval shell-file-name (org-trim body))
 > to(t (org-babel-eval shell-file-name (concat (org-trim body) "\n"))

Your original proposal was reasonable and looks even more so now. 
 
 > I think as long as this change doesn't break the code in non-Windows 
 > operating systems (How would we go about verifying this?), it would be 
 > preferable due to its simplicity and minimality.

Agreed, I like its simplicity.  Tests are a first step and they all pass with 
your suggested change.

 > If for any other reason you would rather not change the 
 > org-babel-sh-evaluate, and would like to implement a separate function for 
 > Windows, that's also a viable option.I am willing to try and go down that 
 > path, although I'm not a very experienced lisper.
 > Do any of these options sound like they could work well?

I agree, putting in the newline is simple and it would be easy enough to create 
a separate path for Windows/cmd if it were a problem.

I wonder if it might make sense to move where the trimming happens so that the 
body passed into `org-babel-sh-evaluate' is ready to go and we could handle the 
cmd case separately and earlier (by inserting the newline there)?

I appreciate you taking the time to explore and for being open to what feels 
like me over-thinking it :)

I'll be away from the keyboard for a few days and I look forward to getting 
this wrapped up for you.  Meanwhile, I'm curious if Ihor or others have advice.

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

[General discussions about Org-mode.]

Ruijie Yu  writes:
> [...]
> The patch applies cleanly on current main branch (52f29d4da), and all
> tests from `make test` passed.  However, I don't see any effects on a
> test org buffer (see attached) -- in particular, I don't see the
> `org-agenda-calendar-daterange' face being shown anywhere on the buffer.
> According to `C-u C-x =' (`what-cursor-position'), all three date ranges
> use `org-date' face.
>
> $ git am this.patch
> $ make test
> $ emacs -Q -L lisp -l org agenda.org
> (type `C-u C-x =' on each date range to see `org-date')
>
> Thoughts?  Will do the same on the original main branch to ensure I
> didn't misunderstand something.

Took another look at the previous mails and at the variable name, and I
realized that this change is for things under org-agenda, in which case
all three types of ranges are under their respective, correct faces.

Best,


RY

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

[General discussions about Org-mode.]

gaut...@gautierponsinet.xyz writes:

> Please find attached a patch containing two commits.
>
> [...]
>
> It seems to me that this should be done by creating repeating tasks
> rather than an entry with a timerange, because suppose I want to put
> in my agenda an event spanning on several days including the precise
> hours at which it starts and ends but which starts and ends on the
> same hour, for example an entry with the following timerange:
>
> <2023-01-19 jeu. 12:00>--<2023-01-26 jeu. 12:00> .

Slight tangent, it seems that this time range has French abbreviations,
is there any resource I can take a look to find recognized abbreviations
for each language that I am interested in?


> In this case, it makes no sense to print the time "12:00" everyday in
> the range. I would expect the agenda to show the event on each days it
> is, the time at which the event starts on the first day, and the time
> at which the event ends on the last day. Does that make sense?

I agree, this is what I am used to with other calendar programs for
displaying multi-day events.  For the in-between days, maybe these
events should be shown as full-day events?

> All the best,
> Gautier.

> From e3feebdf3596645d28d66c1baf6296bcaedf1f42 Mon Sep 17 00:00:00 2001
> From: Gautier Ponsinet 
> Date: Thu, 19 Jan 2023 21:34:37 +0100
> Subject: [PATCH 1/2] org-agenda: Apply the face `org-agenda-calendar-event'
>
> * list/org-agenda.el (org-agenda-get-blocks): Apply the face
>   `org-agenda-calendar-event' to entries with a time range within a
>   single day.
> ---
>  lisp/org-agenda.el | 13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
> index d983a0916..4f29f3eb6 100644
> --- a/lisp/org-agenda.el
> +++ b/lisp/org-agenda.el
> [...]
> @@ -7109,6 +7108,9 @@ scheduled items with an hour specification like 
> [h]h:mm."
> (setq donep (member todo-state org-done-keywords))
> (when (and donep org-agenda-skip-timestamp-if-done)
>   (throw :skip t))
> +  (setq face (if (= d1 d2)
> + 'org-agenda-calendar-event
> +   nil))
> (setq marker (org-agenda-new-marker (point))
>   category (org-get-category))
>(setq effort (save-match-data (or (get-text-property (point) 
> 'effort)
> [...]
> --
> 2.39.1

I see an (if cond then nil) construct.   Not that it matters for the
entire patch, since the else case is updated in the second commit, but I
want to use this opportunity to fulfill my longstanding curiosity on
lisp styles.  For cases where the "else" branch is nil, I have seen the
following three types of constructs:

1. (if cond then nil) -- like this commit
2. (and cond then) -- what I have heard people prefer and have started to adopt
3. (if cond then) -- I found this construct in various patches and source files

Do people prefer one over the other two, and why?

> From 5dc50a84ab6adc1765eaf5bf3cf3c670df69f355 Mon Sep 17 00:00:00 2001
> From: Gautier Ponsinet 
> Date: Thu, 19 Jan 2023 22:18:12 +0100
> Subject: [PATCH 2/2] Define the face `org-agenda-calendar-daterange'
> [...]
> --
> 2.39.1

The patch applies cleanly on current main branch (52f29d4da), and all
tests from `make test` passed.  However, I don't see any effects on a
test org buffer (see attached) -- in particular, I don't see the
`org-agenda-calendar-daterange' face being shown anywhere on the buffer.
According to `C-u C-x =' (`what-cursor-position'), all three date ranges
use `org-date' face.

$ git am this.patch
$ make test
$ emacs -Q -L lisp -l org agenda.org
(type `C-u C-x =' on each date range to see `org-date')

* Multi-Day Range <2023-01-20 Fri 13:00>--<2023-01-23 Mon 13:00>
description

* Same-Day Multi-Stamp Range <2023-01-21 Sat 13:00>-<2023-01-21 Sat 15:00>
description

* Same-Day Single-Stamp Range <2023-01-21 Sat 13:00-15:00>
description


Thoughts?  Will do the same on the original main branch to ensure I
didn't misunderstand something.

Best,


RY

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

[Max Nikulin]

On 20/01/2023 03:09, Tim Cross wrote:

To reiterate for the last time, there are 2 clear and different use
cases for timestamps associated with meetings.

1. A meeting timestamp for a meeting where all the participants are in
the same time zone.

...> 2. A meeting timestamp for a meeting where all the participants are in

different time zones


Tim, every scheduled meeting event is associated with some particular 
time zone, often implicitly. So it is single use case.


It is up to participants to negotiate which timezone is the primary one 
for each event. It is matter of people communication, not technical issue.


First Monday 15:00 is (almost) equally precise for
- Australia/Canberra having DST
- Australia/Darwin where currently no DST
- +1000 (the highest chance of improper use unfortunately)
- UTC

Aside from time transition intervals, it is possible to take any of this 
variant and to present time local for other participant across the globe.


Storage timezone may differ from the current user preference which time 
zone should be used to display timestamp or to export it.


The problem arises when several participants believe that their 
timezones are primary ones and they do not sync their schedules through 
a shared file or a DB entry. An application can not solve this problem, 
but it might try to help to identify it. Some efforts are necessary from 
user side. Timestamp should contain list of timezones of other 
participants and cached local time. In such case an application may warn 
users that local time values become inconsistent due to DST transitions 
or due to update of time zone database. Unsure to what degree it should 
be implemented in Org.


So
- It is participants fault if a meeting is not associated with 
particular timezone
- Having a fair time handling library, it does not matter what time zone 
is used to schedule the meeting.

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

[Tim Cross]

"Thomas S. Dye"  writes:

> Aloha Tim,
>
> Tim Cross  writes:
>
>> "Thomas S. Dye"  writes:
>>
>>> Aloha Tim,
>>>
 UTC is a time zone - just one where offset is +
>>>
>>> UTC is absolute time.  It lacks the spatial component that defines a time 
>>> zone.
>>>
>>
>> Really? I would have thought the prime meridian was the spacial
>> component for UTC? I thought the full long time zone name was Etc/UTC
>> and UTC as the abbreviation.
>>
>> Regardless, in all the libraries I've used, you can use Etc/UTC or UTC
>> in exactly the same way you would use something like Australia/Sydney or
>> AEST. So perhaps, from a pedantic standpoint, it is not a time zone, but
>> for all intent and purpose in this discussion, I feel that point is
>> irrelevant.
>
> Agreed.  It does seem irrelevant for time zone libraries.
>
> Nevertheless, from the Org perspective it might not be.  An occurrence, which 
> marks
> changes in the nature or relations of things at a time, requires absolute 
> time.  Meetings,
> which involve a change in relation among participants, are occurrences.  IMO, 
> this
> indicates Org should give occurrences a UTC timestamp, then translate that 
> for each of the
> participants using their local time zone.  The insane interval problems that 
> Ihor brought
> up are moot in absolute time.  A single timestamp serves a meeting regardless 
> of whether
> the participants are all in one time zone or spread around the globe.
>
> An occurrence contrasts with an event, which is tied to the user's 
> space/time.  Time here
> is relative to the user.  IMO, this means that Org should give events a 
> timestamp without
> reference to either absolute time or a particular time zone, like the one it 
> uses now.
>

Just checking if I understand. I think we are coming from the same
position and with the same conclusion.

In the situation where the meeting involves people from different time
zones, the time of the meeting as reported by org needs to be adjusted
after a daylight savings transition so that the time maintains the same
relative to UTC. i.e. meeting time reported in local time goes
forward/backward 1 hour depending on the daylight savings transition
(in/out). I guess this is what you call an occurrence? 

When all participants in a meeting are in the same time zone, you do not
want the time changed as the result of the daylight savings transition.
This is what you call an event?

So, using your terminology, what we now need is convenience functions
for setting an occurrence timestamp and an event timestamp. I'm not sure
if occurrence/event are the best terms, but I cannot think of better
ones. Just slightly concerned people will have trouble grasping the
difference and undersanding why some meetings are an occurrence while
others are an event. FOr the user, they are just meetings.

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:


No Wayman  writes:


The attached patch should take care of that.


Thanks!

I played a bit more with the patch and noticed that remote tag 
lookup is

not performed prior to _any_ make command.
For example, there is a noticeable delay on my network when 
running

something as simple as make clean.

Maybe it would be better to download the tags instead of running
ls-remote every time? I also imagine that ls-remote might pull 
newer

tags compared to the actual clone.

An alternative could be postponing git ls-remote call to when 
the actual

targets using GITVERSION are being called.


Feel free to take this the patch as a base to do whatever you 
please with it.
I've run out of free time to iterate on it. 

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

[Thomas S. Dye]

Aloha Tim,

Tim Cross  writes:


"Thomas S. Dye"  writes:


Aloha Tim,


UTC is a time zone - just one where offset is +


UTC is absolute time.  It lacks the spatial component that 
defines a time zone.




Really? I would have thought the prime meridian was the spacial
component for UTC? I thought the full long time zone name was 
Etc/UTC

and UTC as the abbreviation.

Regardless, in all the libraries I've used, you can use Etc/UTC 
or UTC
in exactly the same way you would use something like 
Australia/Sydney or
AEST. So perhaps, from a pedantic standpoint, it is not a time 
zone, but
for all intent and purpose in this discussion, I feel that point 
is

irrelevant.


Agreed.  It does seem irrelevant for time zone libraries.

Nevertheless, from the Org perspective it might not be.  An 
occurrence, which marks changes in the nature or relations of 
things at a time, requires absolute time.  Meetings, which involve 
a change in relation among participants, are occurrences.  IMO, 
this indicates Org should give occurrences a UTC timestamp, then 
translate that for each of the participants using their local time 
zone.  The insane interval problems that Ihor brought up are moot 
in absolute time.  A single timestamp serves a meeting regardless 
of whether the participants are all in one time zone or spread 
around the globe.


An occurrence contrasts with an event, which is tied to the user's 
space/time.  Time here is relative to the user.  IMO, this means 
that Org should give events a timestamp without reference to 
either absolute time or a particular time zone, like the one it 
uses now.


hth,
Tom

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

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

[Tim Cross]

"Thomas S. Dye"  writes:

> Aloha Tim,
>
>> UTC is a time zone - just one where offset is +
>
> UTC is absolute time.  It lacks the spatial component that defines a time 
> zone.
>

Really? I would have thought the prime meridian was the spacial
component for UTC? I thought the full long time zone name was Etc/UTC
and UTC as the abbreviation.

Regardless, in all the libraries I've used, you can use Etc/UTC or UTC
in exactly the same way you would use something like Australia/Sydney or
AEST. So perhaps, from a pedantic standpoint, it is not a time zone, but
for all intent and purpose in this discussion, I feel that point is
irrelevant.

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

[Thomas S. Dye]

Aloha Tim,


UTC is a time zone - just one where offset is +


UTC is absolute time.  It lacks the spatial component that defines 
a time zone.


hth,
Tom

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

[FEATURE REQUEST] Make org-copy-subtree and org-cut-subtree work on an active region

[Philipp Kiefer]

When calling either org-copy-subtree or org-cut-subtree, check if there 
is an active region that starts on a headline and contains at least one 
more headline of the same level. If so, copy / cut all the subtrees 
touched by the region. This saves the user having to count the subtrees 
he / she wants to operate on in order to use the number as a prefix 
argument for the command. This change  would make the process easier and 
provide visual feedback.


Optionally require that the active region fully encloses two or more 
headlines and nothing else, i. e. that it begins at the start of one 
headline and terminates at the end of another headline.


Thanks.

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

[gautier]

Please find attached a patch containing two commits.
The first one applies the face `org-agenda-calendar-event' to entries
with a time range within a single day.
The second one defines the new face `org-agenda-calendar-daterange'
and applies it to entries with a time range on several days. (The
second commit assumes the first one is already applied.)

Since I am still learning elisp and this is my first contribution, it
would be very nice if someone could double check the patch, and any
feedback would be very welcome.

I will look into the other points we have discussed so far later on.

By the way, while trying to understand the code I have discovered the
commit "cb19f5c94e3dc94da78169ec675d5bd07af34427" by Bastien which I
don't really understand. The commit message says, talking about
entries with a timerange:
"* lisp/org-agenda.el (org-agenda-get-blocks): When both dates are of
the same value, assume this is a time to display for each date in the
range."

It seems to me that this should be done by creating repeating tasks
rather than an entry with a timerange, because suppose I want to put
in my agenda an event spanning on several days including the precise
hours at which it starts and ends but which starts and ends on the
same hour, for example an entry with the following timerange:

<2023-01-19 jeu. 12:00>--<2023-01-26 jeu. 12:00> .

In this case, it makes no sense to print the time "12:00" everyday in
the range. I would expect the agenda to show the event on each days it
is, the time at which the event starts on the first day, and the time
at which the event ends on the last day. Does that make sense?

All the best,
Gautier.
From e3feebdf3596645d28d66c1baf6296bcaedf1f42 Mon Sep 17 00:00:00 2001
From: Gautier Ponsinet 
Date: Thu, 19 Jan 2023 21:34:37 +0100
Subject: [PATCH 1/2] org-agenda: Apply the face `org-agenda-calendar-event'

* list/org-agenda.el (org-agenda-get-blocks): Apply the face
  `org-agenda-calendar-event' to entries with a time range within a
  single day.
---
 lisp/org-agenda.el | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index d983a0916..4f29f3eb6 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -7059,8 +7059,7 @@ scheduled items with an hour specification like [h]h:mm."
 (defun org-agenda-get-blocks ()
   "Return the date-range information for agenda display."
   (with-no-warnings (defvar date))
-  (let* ((props (list 'face nil
-		  'org-not-done-regexp org-not-done-regexp
+  (let* ((props (list 'org-not-done-regexp org-not-done-regexp
 		  'org-todo-regexp org-todo-regexp
 		  'org-complex-heading-regexp org-complex-heading-regexp
 		  'mouse-face 'highlight
@@ -7069,9 +7068,9 @@ scheduled items with an hour specification like [h]h:mm."
 			  (abbreviate-file-name buffer-file-name
 	 (regexp org-tr-regexp)
 	 (d0 (calendar-absolute-from-gregorian date))
-	 marker hdmarker ee txt d1 d2 s1 s2 category
-	 level todo-state tags pos head donep inherited-tags
- effort effort-minutes)
+ face marker hdmarker ee txt d1 d2 s1 s2 category level
+	 todo-state tags pos head donep inherited-tags effort
+	 effort-minutes)
 (goto-char (point-min))
 (while (re-search-forward regexp nil t)
   (catch :skip
@@ -7109,6 +7108,9 @@ scheduled items with an hour specification like [h]h:mm."
 	  (setq donep (member todo-state org-done-keywords))
 	  (when (and donep org-agenda-skip-timestamp-if-done)
 		(throw :skip t))
+  (setq face (if (= d1 d2)
+ 'org-agenda-calendar-event
+   nil))
 	  (setq marker (org-agenda-new-marker (point))
 		category (org-get-category))
   (setq effort (save-match-data (or (get-text-property (point) 'effort)
@@ -7160,6 +7162,7 @@ scheduled items with an hour specification like [h]h:mm."
 	(concat "<" end-time ">")
 			 remove-re
 	  (org-add-props txt props
+'face face
 		'org-marker marker 'org-hd-marker hdmarker
 		'type "block" 'date date
 		'level level
-- 
2.39.1


From 5dc50a84ab6adc1765eaf5bf3cf3c670df69f355 Mon Sep 17 00:00:00 2001
From: Gautier Ponsinet 
Date: Thu, 19 Jan 2023 22:18:12 +0100
Subject: [PATCH 2/2] Define the face `org-agenda-calendar-daterange'

* etc/ORG-NEWS: Announce the introduction of the new face
  `org-agenda-calendar-daterange'.
* lisp/org-faces.el: Define the face `org-agenda-calendar-daterange'.
* lisp/org-agenda.el (org-agenda-get-blocks): Apply the face
  `org-agenda-calendar-daterange' to entries with a date range.
---
 etc/ORG-NEWS   | 5 +
 lisp/org-agenda.el | 2 +-
 lisp/org-faces.el  | 4 
 3 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index c5d9bdf6e..613b32408 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -55,6 +55,11 @@ document header:
 ,#+LATEX_HEADER: 

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

[Tim Cross]

Jean Louis  writes:

> * Tim Cross  [2023-01-19 10:48]:
>> 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
>
> I do not use Org for time stamps. I am using PostgreSQL.

Then your input here is not terribly relevant IMO.


> My time
> stamps show correctly (hopefully) as I rely on the design of that
> software. I may be very wrong. Though as user I want simple thing, to
> record time, and that time has to be displayed in my time zone, and I
> want to have functions which will provide for example accounting
> statement in the time zone of the recipient in Washington, USA. As
> simple as that.
>

Completely irrelevant to the point being discussed. Yet again, you are
just pushing your beliefs and pet peeves without actually comprehending
what is being discussed. 

> There is no need for Org to deal with daylight savings, as UTC
> underlying functions are expected to deal with it. Time zone database,
> C library, I cannot know. But any error there shall go to system
> maker. Developing such complexity on Org level is not necessary.
>

Yet more indication you don't understand the issue. Nobody has suggested
that org does daylight savings calculation - in fact, the one constant
from all the issues raised in this thread is that all the time zone
calculations, conversion between time zones, calculation/conversion to
display format etc is handled by system libraries not org. 


> For Emacs it makes fun to have various calendars, but for
> international time, that has to be handled by system libraries.
>
>> 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.
>
> Sure, but that is not calculation for higher level like Org, it is for
> lower level, like system library. Discussion shall be given to
> developers of GNU C library to solve calculations with daylight
> savings. If such functions do not exist, then they can be made.
>

You still missed the point. It isn't about the calculation - where that
happens is largely irrelevant and as has been stated numerous times, org
will use the built-in Emacs interface to system facilities for this.

The issue is far more fundamental. Display the agenda with correct
meeting times regardless of daylight savings transitions. As only
meeting with participants from different timezones are affected by such
transitions, we need a way to distinguish those timestamps from
timestamps for meetings with all participants in the same time zone.

>> 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.
>
> ☺️ A meeting can have time zone. My friend, that is exactly how we do
> meetings, I have even given examples from my life on meeting
> scheduling on this mailing list. 
>

Nobody said meetings cannot have time zones. Again, work on your
comprehension. It seems you skim read then jump to the wrong
conclusion.

A meeting does NOT have a time zone. Participants in the meeting have
time zones and it is possible that every participant in the meeting is
in a different time zone. The meeting itself has no time zone.



>
>> 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.
>
> Then again you have to tell that it is "UTC", which means you are
> already specifying some time zone.

hence the bit where I said 

"However, to make this 'workable' for most people, the interface for
 managing timestamps needs to make this easy."

>
> You could tell that Org always thinks of UTC, but that again means UTC
> as mark, must be somewhere placed, all users must know that it is UTC,
> and again there is need for users to display time in their time zone.
>
> What do you achieve by that design? 
>

It achieves exactly the flexibility needed. As has been made clear many
many times in this thread, what we are talking about is the ability to
add time zone information, not a requirement to do so. If your use case
needs that, then org becomes more useful. If it is of no benefit in your
case, then you don't have to use it.

To reiterate for the last time, there are 2 clear and different use
cases for timestamps 

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

[Alexander Adolf]

Tim Cross  writes:

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

Or to any other timezone. The key point here is that you _do_ specify a
timezone. Then, everybody can convert that and have it displayed in any
timezone they find useful.

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

[Alexander Adolf]

Robert Horn  writes:

> [...]
> Getting the rules and explanation clear is the issue.  It's a mistake
> that a great many people make with scheduling meetings.  Those two
> behaviors need different encodings because they behave differently.
> [...]

AFAIU, setting "clear rules" for this seems impossible. Around DST
changeovers, there are ambiguous time-of-day specifications, which occur
more than once on that date. Hence, for such events UTC time
specifications must be used, or everybody is doomed to either arrive
hours early, or hours late for the appointment.

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

[Alexander Adolf]

Robert Horn  writes:

> [...]
> The issue is clarity of the expected rules for the format.  If I
> schedule a meeting for 10:05 DST,
> [...]

In all calendaring software I have used thus far, I don't do that. I can
specify a date and time of day only (but never "DST"). The software then
works out (likely with the help of the OS, and using POSIX APIs) whether
that is DST or not, whenever the event's offset to UTC is needed (e.g.
to display the event in another timezone).

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

[Alexander Adolf]

Daryl Manning  writes:

> [...]
> I'd just be excited to have us run through the basic use cases and then see
> some more "tricky" ones. I imagine there are things we'd just have to
> say... too tricky for (eg. flight takes off in one TZ and range allows it
> to land in timezone... stuff like that might be tricky.).
> [...]

This case doesn't seem tricky to me for as long as both time
specifications have time zone information.

For cross-timezone flights, the VCS calendar appointments airlines send
out by email to customers typically have start and end times given in
UTC. The user's calendaring app will convert that to the time zone in
which the OS of the user's laptop currently pretends to be.

Same thing for flights spanning DST changeovers, btw. A UTC
specification is unambiguous in this case, too.

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

[Philipp Kiefer]

I've uploaded two screencasts to illustrate the issues described in my 
last message:


1. Org Mode-paste subtree low-level item swallowed: 
https://imgur.com/a/CZ5lDaH . This relates to what I assume the passage 
from the manual is trying to say should not happen:


"makes sure that the subtree
remains an independent subtree and does not swallow low level entries."

2. Org Mode-paste subtree on empty heading glitch: 
https://imgur.com/a/AT5pDj6 . See my last message.


Further, you suggest I use C-S- to demote the subtree after 
pasting it at the same level as the subtree at point. But what if I used 
a numerical prefix argument to copy or cut several subtrees, maybe 5 or 
10? Not very convenient at all to demote them all by hand...


I still hold that pasting headings / subtress either at the same level 
or at the child level of the target heading is part of the bread and 
butter of outline editing and should be as straightforward as possible. 
I'm rather sure the current numeric prefixes of org-paste-subtree to 
select a distinct level at which to paste are needed / used much less 
frequently than a "paste at child level" prefix (maybe C-u C-u?) would 
be if it was implemented.


Best

Philipp


On 19.01.2023 10:44, Ihor Radchenko wrote:

Philipp Kiefer  writes:


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.

Just paste the subtree and press C-S- to demote it immediately.
It would not save you many keystrokes if there was yet another prefix
argument.


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.

Sorry, but I cannot reproduce.
Could you please provide detailed instructions about what you did?

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

[Robert Horn]

Ihor Radchenko  writes:

> Robert Horn  writes:
>
>>> Not really. Countries may change DST at any moment in future. Or decide
>>> to switch calendars (consider countries near the day transition line).
>>>
>>> And "past local time, according to the DST rules in effect at the time"
>>> is also an option that might be useful in certain scenarios.
>>>
>> The issue is clarity of the expected rules for the format.  If I
>> schedule a meeting for 10:05 DST, but the rules change so that it is not
>> DST at that location at that time in the future, what is the expected
>> interpretation?  It could be:
>
> Let me clarify. I do not think that we need to offer selecting DST/no
> DST in the timestamp. Instead, we offer something like
> <2028-12-11 18:00@Europe/Berlin>, specifying local time, including
> possible DST transitions or any other political decisions the country
> might make regarding the local time rules.
>

That would cover it for me.  So, 18:00@Europe/Berlin is the "then local
time", 18:00@CET would be Central European standard time and 18:00@CEST
would be Central European Summer Time.  18:00@UTC would be 19:00@CET and
18:00@CEST. I've found that by far the most common scheduling uses the
"then local time" because that's what people usually want.  I know when
someone schedules a meeting in late March they rarely figure out whether
it will be summer time or standard time.


> Or, if the preference is specifying time in such a way that it is
> unaffected by the local time rules (for example, "+1 hours from now,
> no matter what the DST/no DST or whatever rules will happen in the
> middle"), one can use explicit UTC offsets like <2028-12-11
> 18:00@UTC+02>

Interesting question.  Some uses (like scheduling physical process) want
+4 hours to mean 4 hours later regardless of leap seconds or summer time
changes.  But most people scheduling issues where they say "in 24 hours"
they actually mean +24 in local time.  At the transition to or from
summer time the phrase "within 24 hours" usually means 24 hours except
on the transition days when it's 23 or 25 hours.

Don't worry about TAI.  People who are working in TAI are unlikely to
expect org to support TAI. 


-- 
Robert Horn
rjhorn...@gmail.com

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

[Osher Jacob]

Thanks for the suggestions!

On Wed, Jan 18, 2023 at 7:09 AM Matt  wrote:

>
> 1. Another naive work around attempt.  Again, I'm going from memory,
> documentation, and what I have previously written.
>
> I have in my init a command to open a terminal when working on Windows
> that looks like:
>
> (start-process "cmd" nil "cmd.exe" "/C" "start" "cmd.exe" "/K" "cd"
> dir)
>
> This starts a cmd process with /c which terminates the prompt after the
> command that follows is run.  The command  That follows starts another cmd
> process with /k which changes the directory and leaves the terminal open.
>
> I have another command to open QGIS that does the same thing:
>
> (start-process "cmd" nil "cmd.exe" "/C" "start" "\"qgis\"" "cmd.exe"
> "/K" "C:\\Program Files\\QGIS 3.22.3\\bin\\qgis.bat")
>
> It's not clear to me why the extra call to a second cmd with /k is
> needed.  Maybe it's copy-pasta or Windows being Windows.
>
> Anyway, I mention these because I wonder if we might be able to do
> something similar.
>
> Try changing `shell-file-name' to "cmd.exe" (ideally, the full path) and
> `shell-command-switch' to "/k" (or maybe "-k").  My hope would be that the
> final call would look something like,
>
> cmd.exe /k cmd.exe /k 
>
> Given my analysis, I'm not sure if there's a way we could trick the call
> into being `cmd.exe /c cmd.exe /k input-file'.
>


On Wed, Jan 18, 2023 at 11:05 AM Ihor Radchenko  wrote:

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

Unfortunately, it seems like cmdproxy.exe and cmd.exe cannot accept an
input file as a command-line argument and execute it.

In the case of running :
cmdproxy.exe /c cmdproxy.exe /c C:/tmp/inp

We get:
cmdproxy.exe /c cmdproxy.exe /c C:/tmp/inp
'C:/tmp/inp' is not recognized as an internal or external command,
operable program or batch file.


If we're insistent on passing the input through the command line arguments,
I can think of two ways to go about this, but both seem undesirable:
- Dumping the content of the input buffer into a ".bat" file and then
passing it as an argument. That way we end up executing "cmdproxy.exe /c
cmdproxy.exe input.bat", but then batch files produce a slightly different
behaviour than running in the context of an interactive shell.
or
- Concating the lines together with the "&" in between them. This would
look like 'cmdproxy.exe /c cmdproxy.exe /c "echo 1 & echo 2 & echo 3",
which is also a pretty nasty solution in my opinion.

This leads me to your next point, which sounds like the most natural way to
go about it.

2. We could write some ob-shell code to explicitly handle Windows cmd and
> powershell.  For example, call `process-file' similar to the stdin/cmdline
> branch of `org-babel-sh-evaluate'.
>
> I'm open to this, but, like I've said, I don't have a Windows machine to
> work on right now.  I'd not be able to verify it.  I, and I'm sure others,
> would be happy to guide you if that's something you'd like to help
> implement.
>
>
I think it could be enough to make sure the input ends with a newline, in
which case it could be done the way I proposed in the first message, that
is changing:
(t (org-babel-eval shell-file-name (org-trim body))
to
(t (org-babel-eval shell-file-name (concat (org-trim body) "\n"))

I think as long as this change doesn't break the code in non-Windows
operating systems (How would we go about verifying this?), it would be
preferable due to its simplicity and minimality.

If for any other reason you would rather not change
the org-babel-sh-evaluate, and would like to implement a separate function
for Windows, that's also a viable option.
I am willing to try and go down that path, although I'm not a very
experienced lisper.

Do any of these options sound like they could work well?

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

[Thomas S. Dye]

Aloha Jean Louis,

Jean Louis  writes:


* Thomas S. Dye  [2023-01-19 09:37]:
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.


User in Grece needs appointment at 9 o'clock, and writes it as:
<2023-01-20 Fri 09:00> He also has TIMEZONE (either system or 
Org file
based) set to "EET". That way the time has been recorded in UTC 
for
Org purposes, and UTC has been solved. For Greek user it is 
completely
solved. Org calculates UTC based on configured time zone. But 
when it

is 16:00 o'clock in Greece, it is 06:00 in Seattle.

Online appointment is sent to user in Seattle, with the time 
zone
PST. He receives the Org file from Greece, at 8:00 o'clock, 
which has
settings inside TIMEZONE="EET". At first user thinks that 
appointment
is in just 1 hour, because he can see "08:00", but Org 
gracefully
notifies user that appointment is (probably) in a different time 
zone,
and asks user if user would like to have it displayed in PST 
time
zone. User answers with "Yes" and on his screen appears that 
meeting
is actually at <2023-01-20 Fri 23:00>, he prepares himself for 
longer

evening, and waits for his Greek partner on Jitsi Meet:
https://meet.jit.si/ to get online.

It confirms your hypothesis, yes, all times are calculated as 
UTC, but
all time stamps at export, sharing, or change of time zone, 
shall be

displayable in understandable manner to human user.

Only occurrences require absolute time, UTC.  Events do not.  They 
follow the user's space/time.



> Org in this state can't handle such things.

Org can do the useful thing: translate the UTC timestamp into 
local time and
report both UTC and local time.  User will be able quickly to 
determine if

local time is incorrect for some reason, such as DST or travel.


Other way around, it has to translate time stamp into UTC time 
in the first place. 


Yes, to store the time stamp, Org must take it from the event time 
of the user and translate it to UTC.  When reporting an occurrence 
to the user, then Org must translate from UTC to the user's 
space/time.  User might have a toggle, like pretty entities, that 
either shows UTC or translation to user's space/time.


Expecting that all user among so many various time zones write 
their
time stamps in UTC is not reasonable. Org users are advanced, I 
know,
but majority of note takers with other applications will not 
even
think of different time zones, it is surprise they get when 
dealing
internationally. People are not ready for calculating or even 
viewing
their own time in UTC time zone, unless they are English or 
Icelandic,

Portuguese, or Africans in parts of the West Africa.

Org should translate from the user's space/time to absolute time, 
UTC.  The user has to tell Org what is the space/time relationship 
to absolute time.  Org might use the timezone machinery to suggest 
a space/time relationship to absolute time, and it might warn the 
user when the user's suggested relationship differs from the value 
reported by the timezone machinery.



Storing timestamps in UTC solves the interval problem Ihor
raised. Intervals always make sense in absolute time.  Moving 
them

to event time leads to the insanity Ihor mentioned.


The other way around. Assuming that time stamps are UTC raises
problems for all other people:
https://upload.wikimedia.org/wikipedia/commons/8/88/World_Time_Zones_Map.png

Org now does not support time stamps, right?

So people write timestamps in their own time zone! Is it right?


IIUC, Org currently stores events, which are relative to the 
user's space/time.  This works for events, but breaks for 
occurrences, which require absolute time, UTC.




My time stamp here is <2023-01-19 Thu 17:12> now, what is yours?


<2023-01-19 Thu 06:08>  This is an event, specified relative to my 
space/time.




Forcing users to write time stamps in UTC would cause havoc.


Agreed, Org should help.



Thus time stamps already have their time zones, it is just not
recorded in Org file. 


Events don't need a time zone, only occurrences need absolute 
time.




Options can be created so that:

- user always and automatically record time zone in Org file, 
for
  example from system time zone, so that when first time 
  property is

  invoked that it stays there:

#+TIMEZONE: EET

Or like this

* TODO Appointment on Jitsy Meet with Greek investor
  DEADLINE: <2023-01-20 Fri 09:00>
  :PROPERTIES:
  :TIMEZONE: EET
  :END:

or inside of the time zone.

When such heading is read in Seattle, Washington, Org will tell 
to

user or ask to translate it to PST time.

In such translations, EET time is first converted to UTC, for 
reason

of using system libraries, and not complicating Org, and then
converted to PST time zone.


The Org user in Seattle would either see UTC or toggle to see UTC 
translated to Seattle space/time, assuming user set space/time 
relationship to 

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

[Jean Louis]

* Tim Cross  [2023-01-19 10:48]:
> 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

I do not use Org for time stamps. I am using PostgreSQL. My time
stamps show correctly (hopefully) as I rely on the design of that
software. I may be very wrong. Though as user I want simple thing, to
record time, and that time has to be displayed in my time zone, and I
want to have functions which will provide for example accounting
statement in the time zone of the recipient in Washington, USA. As
simple as that.

There is no need for Org to deal with daylight savings, as UTC
underlying functions are expected to deal with it. Time zone database,
C library, I cannot know. But any error there shall go to system
maker. Developing such complexity on Org level is not necessary.

For Emacs it makes fun to have various calendars, but for
international time, that has to be handled by system libraries.

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

Sure, but that is not calculation for higher level like Org, it is for
lower level, like system library. Discussion shall be given to
developers of GNU C library to solve calculations with daylight
savings. If such functions do not exist, then they can be made.

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

☺️ A meeting can have time zone. My friend, that is exactly how we do
meetings, I have even given examples from my life on meeting
scheduling on this mailing list. 

We say "Greek time 9 o'clock AM" -- and we meet and talk to each
other. If there is any daylight saving, so? My computer will think
about it. Not me. I have alarm that counts down, I must rely on my
devices. 

See:

System time and hardware clock
https://www.suse.com/support/kb/doc/?id=16358

> The Linux kernel maintains a system time. This time is initialized at boot 
> time using the hardware clock(also known as real time clock, RTC, BIOS clock 
> or CMOS clock). As the hardware clock does not provide information as to 
> whether it is kept in UTC or in local time, this needs to be configured 
> explicitly, in YaST -> System -> /etc/sysconfig Editor -> System -> 
> Environment -> Clock -> HWCLOCK.

> Linux changing to and from DST

> Linux will change to and from DST when the HWCLOCK setting is set to `-u', 
> i.e. when the hardware clock is set to UTC (which is closely related to GMT), 
> regardless of whether Linux was running at the time DST is entered or left.

> When the HWCLOCK setting is set to `--localtime', Linux will not
> adjust the time, operating under the assumption that your system may
> be a dual boot system at that time and that the other OS takes care of
> the DST switch. If that was not the case, the DST change needs to be
> made manually.

As you can see it is up to system libraries and user settings how to
provide DST. 

Org need not touch that, only convert from time zone time to UTC, from
UTC to time zone time.

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

Then again you have to tell that it is "UTC", which means you are
already specifying some time zone. 

You could tell that Org always thinks of UTC, but that again means UTC
as mark, must be somewhere placed, all users must know that it is UTC,
and again there is need for users to display time in their time zone.

What do you achieve by that design? 

You will get confusion, as you are forcing majority of the world first
to understand what is UTC.

Computers don't do that, they ask you, where are you? Athens, Greece?
Thanks, here is your time.

They don't tell you "let us keep meeting time in UTC" confusing users.

Follow the decade long trend human usability trend and use time zones.

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

Time stamp does not need to have TZ data, and your function desire is
just fine and 

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

[Jean Louis]

* Ihor Radchenko  [2023-01-19 13:43]:
> So, we should let the user specify time zone to be used for export.
> Then, when sending an email, you can export the heading to text/html and
> Org will set the target time zone as requested.

Exactly.

Follow the iCalendar export option TIMEZONE. Why did author insist on it?

(info "(org) iCalendar Export")

>The iCalendar export back-end includes ‘SUMMARY’, ‘DESCRIPTION’,
> ‘LOCATION’, ‘TIMEZONE’ and ‘CLASS’ properties from the Org entries when
> exporting.  To force the back-end to inherit the ‘LOCATION’, ‘TIMEZONE’
> and ‘CLASS’ properties, configure the ‘org-use-property-inheritance’
> variable.

When exporting file or not exporting, the recipient may receive the
file and be in different time zone. If file has no time zone property,
then user in different time zone cannot know what time is being talked
about.

That means that function of sending appointments (headings or TODO
tasks) should embed timezone property in such heading. Or the function
that exports Org file shall embed something like #+TIMEZONE: PST in
the Org file, or at least ask user, or allow such exports by
customized functions.

And all stamps like "Created: " in HTML shall get its time zone,
because without it, time remains ambigous, and also in probably 98%
cases wrong. Why display wrong time? If it is for user only, that is
fine, but if HTML is published on web server for others, the time has
significance.

-- 
Jean

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

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

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

[Jean Louis]

* Thomas S. Dye  [2023-01-19 09:37]:
> 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.

User in Grece needs appointment at 9 o'clock, and writes it as:
<2023-01-20 Fri 09:00> He also has TIMEZONE (either system or Org file
based) set to "EET". That way the time has been recorded in UTC for
Org purposes, and UTC has been solved. For Greek user it is completely
solved. Org calculates UTC based on configured time zone. But when it
is 16:00 o'clock in Greece, it is 06:00 in Seattle.

Online appointment is sent to user in Seattle, with the time zone
PST. He receives the Org file from Greece, at 8:00 o'clock, which has
settings inside TIMEZONE="EET". At first user thinks that appointment
is in just 1 hour, because he can see "08:00", but Org gracefully
notifies user that appointment is (probably) in a different time zone,
and asks user if user would like to have it displayed in PST time
zone. User answers with "Yes" and on his screen appears that meeting
is actually at <2023-01-20 Fri 23:00>, he prepares himself for longer
evening, and waits for his Greek partner on Jitsi Meet:
https://meet.jit.si/ to get online.

It confirms your hypothesis, yes, all times are calculated as UTC, but
all time stamps at export, sharing, or change of time zone, shall be
displayable in understandable manner to human user.

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

Other way around, it has to translate time stamp into UTC time in the first 
place. 

Expecting that all user among so many various time zones write their
time stamps in UTC is not reasonable. Org users are advanced, I know,
but majority of note takers with other applications will not even
think of different time zones, it is surprise they get when dealing
internationally. People are not ready for calculating or even viewing
their own time in UTC time zone, unless they are English or Icelandic,
Portuguese, or Africans in parts of the West Africa.

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

The other way around. Assuming that time stamps are UTC raises
problems for all other people:
https://upload.wikimedia.org/wikipedia/commons/8/88/World_Time_Zones_Map.png

Org now does not support time stamps, right?

So people write timestamps in their own time zone! Is it right?

My time stamp here is <2023-01-19 Thu 17:12> now, what is yours?

Forcing users to write time stamps in UTC would cause havoc.

Thus time stamps already have their time zones, it is just not
recorded in Org file. 

Options can be created so that:

- user always and automatically record time zone in Org file, for
  example from system time zone, so that when first time property is
  invoked that it stays there:

#+TIMEZONE: EET

Or like this

* TODO Appointment on Jitsy Meet with Greek investor
  DEADLINE: <2023-01-20 Fri 09:00>
  :PROPERTIES:
  :TIMEZONE: EET
  :END:

or inside of the time zone.

When such heading is read in Seattle, Washington, Org will tell to
user or ask to translate it to PST time.

In such translations, EET time is first converted to UTC, for reason
of using system libraries, and not complicating Org, and then
converted to PST time zone.

-- 
Jean

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

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

[BUG] org-open-line in tables broken with stripe-table-mode [9.6.1 (release_9.6.1 @ /usr/share/emacs/29.0.60/lisp/org/)]

[Thomas Schneider]

Dear maintainers,

I’ve run into an issue with Org tables in Emacs 29 since it updated Org
to 9.6.  While I think it is a very similar issue to [0] and thus
probably not Org’s problem, I nevertheless would like to at least record
this for others.

This issue only manifests together with stripe-table-mode from [1].
With that active, C-o (i. e., #'org-open-line) fails with some “argument
out of range” error.

Steps to reproduce:

---
wget https://melpa.org/packages/stripe-buffer-20141208.1508.el
cat << EOF > x.org
|   |
| # |
EOF
emacs -Q -l stripe-buffer-20141208.1508.el --file x.org
M-x stripe-table-mode RET
C-n  # point should now be at the beginning of the 2nd line
C-o  # Result: org-table-insert-row: Args out of range: 7, 12
---

>From a user point of view, this was broken by Org 9.6, but as outlined
above, the issue may as well be with stripe-buffer.  In any case, I `git
bisect`ed Org and found that this happens since commit fa7530c7b (Rename
old function call to use org-fold).

The following patch to stripe-buffer partially solves the issue: C-o no
longer fails, but in the table that I found the issue in, C-o and
everything that causes formulas to be (re-)calculated still takes very
long if and only if stripe-table-mode is enabled.

---
diff --git a/stripe-buffer.el b/stripe-buffer.el
index 5a185db..e9a1b57 100644
--- a/stripe-buffer.el
+++ b/stripe-buffer.el
@@ -189,13 +189,13 @@ Used by `stripe-table-mode' Only the first matching group 
will be painted."
   (let (( visible-ranges (sb/buffer-visible-regions-compressed))
 ranges)
 (cl-dolist (vr visible-ranges)
-  (save-excursion
+  (save-excursion (save-match-data
 (goto-char (car vr))
 (while (and (<= (point) (cdr vr))
 (re-search-forward stripe-in-table-regex (cdr vr) t)
 (not (invisible-p (match-beginning 0
   (push (cons (match-beginning 1) (match-end 1)) ranges)
-  )))
+  
 (sb/compress-ranges ranges)))
 
 (defun sb/redraw-all-tables ( ignore)
---

Whether or not this issue is with Org, I’d appreciate any feedback on
this.

Thanks,
Thomas

[0]: https://lists.gnu.org/archive/html/emacs-orgmode/2022-12/msg0.html
[1]: https://github.com/sabof/stripe-buffer


Emacs  : GNU Emacs 29.0.60 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.35, 
cairo version 1.17.6)
 of 2023-01-18
Package: Org mode version 9.6.1 (release_9.6.1 @ 
/usr/share/emacs/29.0.60/lisp/org/)

current state:
==
(setq
 org-link-elisp-confirm-function 'yes-or-no-p
 org-bibtex-headline-format-function #[257 "\300%1\236A\207" [:title] 3 
"\n\n(fn ENTRY)"]
 org-export-before-parsing-hook '(org-attach-expand-links)
 org-cycle-tab-first-hook '(org-babel-hide-result-toggle-maybe 
org-babel-header-arg-expand)
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-show-empty-lines
  org-cycle-optimize-window-after-visibility-change 
org-cycle-display-inline-images)
 org-link-from-user-regexp "|\\"
 org-mode-hook '(#[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-fold-show-all append 
local] 5]
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-babel-show-result-all 
append local] 5]
 org-babel-result-hide-spec org-babel-hide-all-hashes
 #[0 "\301\211%10\207" [imenu-create-index-function 
org-imenu-get-tree] 2]
 turn-on-auto-fill)
 org-babel-load-languages '((emacs-lisp . t) (sqlite . t))
 org-confirm-shell-link-function 'yes-or-no-p
 outline-isearch-open-invisible-function 'outline-isearch-open-invisible
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-src-mode-hook '(org-src-babel-configure-edit-buffer 
org-src-mode-configure-edit-buffer)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-speed-command-hook '(org-speed-command-activate 
org-babel-speed-command-activate)
 org-fold-core-isearch-open-function 'org-fold-core--isearch-reveal
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe 
org-babel-header-arg-expand)
 org-link-shell-confirm-function 'yes-or-no-p
 org-babel-pre-tangle-hook '(save-buffer)
 org-agenda-loop-over-headlines-in-active-region nil
 org-occur-hook '(org-first-headline-recenter)
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-link-parameters '(("attachment" :follow org-attach-follow :complete 
org-attach-complete-link)
   ("id" :follow org-id-open)
   ("eww" :follow org-eww-open :store org-eww-store-link)
   ("rmail" :follow org-rmail-open :store 
org-rmail-store-link)
   ("mhe" :follow org-mhe-open :store org-mhe-store-link)
   ("irc" :follow org-irc-visit :store org-irc-store-link 
:export org-irc-export)
   ("info" :follow org-info-open :export org-info-export 
:store
 

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

[Edgar Lux]

Dear list,

I send the attached patch for your consideration. It allows to use biber for 
bibliographies. I tested it with this:

(require 'oc-natbib)

#+cite_export: natbib
#+LaTeX_HEADER: \usepackage[style=numeric-comp,sorting=none, 
hyperref=true,backref=true,url=true,backend=biber,natbib=true]{biblatex}
#+LaTeX_HEADER: \addbibresource{../../Sources/sources.bib}

[cite:@mytest]

\printbibliography[heading=none]

These won't work
#+bibliography:
#+print_bibliography:

Thank you very much.

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

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

[Ihor Radchenko]

No Wayman  writes:

> No Wayman  writes:
>
>> The attached patch should take care of that.

Thanks!

I played a bit more with the patch and noticed that remote tag lookup is
not performed prior to _any_ make command.
For example, there is a noticeable delay on my network when running
something as simple as make clean.

Maybe it would be better to download the tags instead of running
ls-remote every time? I also imagine that ls-remote might pull newer
tags compared to the actual clone.

An alternative could be postponing git ls-remote call to when the actual
targets using GITVERSION are being called.

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

Re: org-habit and hourly repeats

[Ihor Radchenko]

Felipe Balbi  writes:

> Thanks for the links and information. It's unfortunate that it's not 
> supported,
> but I guess I can live with it, no problem :-)

Patches welcome ;)
Feel free to ask anything if you want to figure out how org-habit code
works.

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

Re: org-habit and hourly repeats

[Felipe Balbi]

Hi,

On Thu, Jan 19, 2023 at 1:03 PM Ihor Radchenko  wrote:
> > That's very interesting, because repeated tasks clearly mention hourly 
> > repeats:
> >
> > https://orgmode.org/manual/Repeated-tasks.html
> >
> > "You can use yearly, monthly, weekly, daily and hourly repeat cookies by
> > using the ‘y’, ‘m’, ‘w’, ‘d’ and ‘h’ letters."
>
> Repeated tasks do support hourly repeats. But not habits, as long as
> habit-specific logic is concerned.

Got it :-)

> >> I afraid that things are not that simple.
> >
> > Do you mind expanding on this? Just generally curious, really.
>
> I tried to list some things in
> https://list.orgmode.org/orgmode/87leplsggg.fsf@localhost/
>
> For example, habit consistency graph assumes that habits are repeated
> every day or longer.
>
> Generally, adding hourly habits will require careful checking of
> org-habit.el code. In addition, org-agenda cannot display repeated tasks
> when their repeat interval is less than a day (it is a minor annoyance
> though; should not be a blocker)

Thanks for the links and information. It's unfortunate that it's not supported,
but I guess I can live with it, no problem :-)

cheers

--
balbi

Re: org-habit and hourly repeats

[Ihor Radchenko]

Felipe Balbi  writes:

>> Habits occurring multiple times a day are not properly supported in
>> general. See https://list.orgmode.org/orgmode/87leplsggg.fsf@localhost/
>
> That's very interesting, because repeated tasks clearly mention hourly 
> repeats:
>
> https://orgmode.org/manual/Repeated-tasks.html
>
> "You can use yearly, monthly, weekly, daily and hourly repeat cookies by
> using the ‘y’, ‘m’, ‘w’, ‘d’ and ‘h’ letters."

Repeated tasks do support hourly repeats. But not habits, as long as
habit-specific logic is concerned.

>> I afraid that things are not that simple.
>
> Do you mind expanding on this? Just generally curious, really.

I tried to list some things in
https://list.orgmode.org/orgmode/87leplsggg.fsf@localhost/

For example, habit consistency graph assumes that habits are repeated
every day or longer.

Generally, adding hourly habits will require careful checking of
org-habit.el code. In addition, org-agenda cannot display repeated tasks
when their repeat interval is less than a day (it is a minor annoyance
though; should not be a blocker)

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

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

[Ihor Radchenko]

gaut...@gautierponsinet.xyz writes:

> So, the current situation is the following:
> ...
> Is that correct?

Yes. "simple date with hour range" should be displayed the same with
"timerange (same day)", including faces and begin/end time being
displayed together.

It will be the most consistent.

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

Yes, if you can.

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

Applying faces should be easier. You may just add code applying
`org-agenda-calendar-event' face when timestamp is within a single day
to `org-agenda-get-blocks'. See d1 and d2 variables. They store
start/end date.

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

Re: org-habit and hourly repeats

[Felipe Balbi]

Hi,

On Thu, Jan 19, 2023 at 12:47 PM Ihor Radchenko  wrote:
>
> Felipe Balbi  writes:
>
> > 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:
>
> Habits occurring multiple times a day are not properly supported in
> general. See https://list.orgmode.org/orgmode/87leplsggg.fsf@localhost/

That's very interesting, because repeated tasks clearly mention hourly repeats:

https://orgmode.org/manual/Repeated-tasks.html

"You can use yearly, monthly, weekly, daily and hourly repeat cookies by
using the ‘y’, ‘m’, ‘w’, ‘d’ and ‘h’ letters."

>
> > 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?
>
> I afraid that things are not that simple.

Do you mind expanding on this? Just generally curious, really.

-- 
balbi

Re: org-habit and hourly repeats

[Ihor Radchenko]

Felipe Balbi  writes:

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

Habits occurring multiple times a day are not properly supported in
general. See https://list.orgmode.org/orgmode/87leplsggg.fsf@localhost/

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

I afraid that things are not that simple.

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

Re: One of my Org files hangs Emacs

[Max Nikulin]

On 19/01/2023 11:11, Richard Kim wrote:


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


Did it happen for remote files opened via TRAMP?

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

[Ihor Radchenko]

Jean Louis  writes:

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

Now I understand, I think.

So, we should let the user specify time zone to be used for export.
Then, when sending an email, you can export the heading to text/html and
Org will set the target time zone as requested.

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

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

I am leaning towards this approach.
We already do things like

<2023-01-31 Thu +1m> -> <2023-03-03 Fri +1m>

and people are OK with it, seemingly.

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

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

You need to come to an agreement about when to do the meeting. Be it
your TZ, and other participant's TZ, or some other fixed TZ (including
UTC or offsets from it).

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

`org-read-date' should definitely be extended to understand time zones.
As for the display, we have `org-display-custom-times'. Might need to
extend it in future, but maybe the existing functionality is already
good enough.

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

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

Can we expect the same to work on Windows? If so, maybe we don't need
all the dancing around rounding off in `org-timestamp-change' and
instead simply use time API?

Re: 11:00 CET -> 11:00 CEST

Note that Org does not exactly offer much of convenience even without
considering TZ.

<2023-01-31 Thu +1m> -> <2023-03-03 Fri +1m>
And nobody really complained so far.
So, maybe we don't even need to care about these subtleties in practice?

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

Re: [BUG] CUSTOM_id ignored on blocks by ox-beamer

[Ihor Radchenko]

Alan Schmitt  writes:

>> (2) modify `org-beamer-environments-default' to insert label
>> appropriately.
>>
>> Patches welcome!
>
> Thank you for the detailed instructions. Here is my attempt at this.
> I’ve tested it and it works.

Thanks!

>>From 1747786c7106d0d90d9e8752e361552afacb2d4d Mon Sep 17 00:00:00 2001
> From: Alan Schmitt 
> Date: Sun, 8 Jan 2023 17:20:31 +0100
> Subject: [PATCH] Add labels to latex export of beamer blocks
>
> A new option %l is available to be used in `org-beamer-environments-*'
> to insert the label of the current block, obtained using
> `org-babel--get-label'

Please add a changelog entry detailing the definitions where the changes
happened. See https://orgmode.org/worg/org-contribute.html#commit-messages

> -("theorem""t" "\\begin{theorem}%a[%h]""\\end{theorem}")
> -("definition" "d" "\\begin{definition}%a[%h]" 
> "\\end{definition}")
> -("example""e" "\\begin{example}%a[%h]""\\end{example}")
> -("exampleblock"   "E" "\\begin{exampleblock}%a{%h}"   
> "\\end{exampleblock}")
> +("theorem""t" "\\begin{theorem}%a[%h]%l""\\end{theorem}")
> +("definition" "d" "\\begin{definition}%a[%h]%l" 
> "\\end{definition}")
> +("example""e" "\\begin{example}%a[%h]%l""\\end{example}")
> +("exampleblock"   "E" "\\begin{exampleblock}%a{%h}%l"   
> "\\end{exampleblock}")

Please document the new %l option in the docstring of
`org-beamer-environments-extra' and add a notice to etc/ORG-NEWS file.

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

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

[M . ‘quintus’ Gülker]

Am Donnerstag, dem 19. Januar 2023 schrieb András Simonyi:
> hopefully somebody more knowledgeable than me can comment on how
> viable this is, but would a @@csl like export snippet construct help
> with the problem?
> In that case your macro could be along the lines of
>
> #+MACRO: name @@csl:$1@@

It is an interesting approach, but it has a drawback. I use this macro
also in the ordinary text when I refer to persons without an explicit
citation. That is, the macro has to work both in a citation and in
normal text. Even if a @@csl: construct would be ignored in normal text,
I cannot see how to write the macro then, because something like

#+MACRO: name @@csl:$1latex:\textsc{$1}html:$1@@

would still transfer the @@latex: and @@html: constructs into the
footnote. They would have to be expressly ignored by the citation
processor.

  -quintus

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

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

[Ihor Radchenko]

András Simonyi  writes:

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

So, do I understand correctly that italics, bold, subscript,
superscript, small-caps, and nocase must be passed to the CSL processor
in a format understood by CSL? Everything else could just be left in Org
and later exported according to actual export settings?

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

What if we pass Org constructs as verbatim html? That way, LaTeX
formatter should not alter the text.

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

May we:
1. Convert the Org markup supported by CSL into CSL-understood HTML
format
2. Convert all other Org markup into verbatim
3. Convert back non-verbatim markup altered by CSL into Org
4. Perform exporting Org->current export backend as usual.

(In the worst case scenario, we might replace non-convertable Org markup
constructs into dummy text and later replace the dummies back into
original Org markup)

WDYT?

Also, small-caps and nocase are currently not supported by Org. Maybe it
would make sense to document how to pass these constructs to CSL
properly.

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

Re: One of my Org files hangs Emacs

[Ihor Radchenko]

Richard Kim  writes:

> I would suggest disabling "org persist" which has caused so much grief for me.
>
> (setq org-element-cache-persistent nil)

org-persist can only affect opening and closing the file. I doubt that
it is the culprit here.

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

Note the most users do not experience such problems. Could you file a
separate bug report describing your situation in more details? We can
then try to work something out.

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

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

Just paste the subtree and press C-S- to demote it immediately.
It would not save you many keystrokes if there was yet another prefix
argument.

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

Sorry, but I cannot reproduce.
Could you please provide detailed instructions about what you did?

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

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

[Ihor Radchenko]

András Simonyi  writes:

> In that case your macro could be along the lines of
>
> #+MACRO: name @@csl:$1@@
>
> and -- assuming the custom export backend approach I proposed in the
> patch -- we would only need to make sure that the inline @@csl export
> snippets are exported as is by this "csl"  backend.

I think it could be a good option. Especially if the macro also provides
a good fallback for non-CSL citation backends.

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

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

[M . ‘quintus’ Gülker]

Am Donnerstag, dem 19. Januar 2023 schrieb András Simonyi:
> 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?

I am not sure this targets the usecase I am pursuing, which is to use
macros to produce @@latex: escape constructs in order to have small-caps
markup in the citation footnotes:

#+MACRO: name @@latex:\textsc{$1}html:$1@@

If the macro resolves, but the @@latex construct does not, that would be
problematic. That being said, I /found/ an alternative that works,
albeit it is a bit ugly. I can create an explicit footnote, use a
[cite/default/bare:] construct (to suppress the terminal period) within
it and terminate the citation before the macro begins. That way, the
macro is outside of the citation construct. This construction is however
unfortunate when I want to cite multiple sources and have the macro used
on an earlier one, e.g.:

[fn:1] [cite/default/bare:@foo p. 5], countering {{{name(Doe’s)}}} 
argument; [cite/default/bare:@bar p. 37].

It would be nicer if I could just write into the main text

[cite:@foo p. 5, countering {{{name(Doe’s)}}} argument;@bar p. 37]

I can however live with the more elaborate construction, if nothing
else.

  -quintus

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

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

[András Simonyi]

Dear All,

On Thu, 19 Jan 2023 at 09:35, M. ‘quintus’ Gülker
 wrote:

> I am not sure this targets the usecase I am pursuing, which is to use
> macros to produce @@latex: escape constructs in order to have small-caps
> markup in the citation footnotes:
>
> #+MACRO: name @@latex:\textsc{$1}html:$1@@
>
> If the macro resolves, but the @@latex construct does not, that would be
> problematic.

hopefully somebody more knowledgeable than me can comment on how
viable this is, but would a @@csl like export snippet construct help
with the problem?
In that case your macro could be along the lines of

#+MACRO: name @@csl:$1@@

and -- assuming the custom export backend approach I proposed in the
patch -- we would only need to make sure that the inline @@csl export
snippets are exported as is by this "csl"  backend.

best wishes,
András

org-ref (including cite or not) and references with numbers exporting to HTML

[Uwe Brauer]

Hi 

I am using org-ref and helm and have two quetions



1. When I use org-ref-helm-insert-cite-link, either I obtain
   cite:tao06:_global
   or
   cite:Choquet-Bruhat_09
   but I cannot spot any difference  in my bibfile, save that the
   tao06 reference has a : in its key and indeed adding a : to the
   second  reference also insert a cite:
   any reason for this behavior?

2. Independent of this, when exporting to HTML
   In the text, the references are tao06:_global with a link
   how can I have numbers with links instead


thanks


-- 
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine. 
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/