Re: POSIX TS spec reverses the meaning of TZ offset compared to ISO

[Heinz Tuechler]

Max Nikulin wrote/hat geschrieben on/am 02.02.2023 04:22:

On 02/02/2023 04:57, Heinz Tuechler wrote:

My impression is that many of non experts like me don't
know in which time zone they are living.


For you own time zone: Open Development tools in a browser ([F12]),
switch to console, type

 new Intl.DateTimeFormat().resolvedOptions().timeZone



Thank you, Max.
It seems to me that this shows the time zone I selected at set up of the
computer, in my case Europe/Berlin. Using package lutz in R with correct
coordinates I see Europe/Vienna, based on open street map.
Days ago I did not even know that Berlin and Vienna are in different
time zones.


I am sure there are a lot of web pages that do the same.

On linux you can use the following tool

timedatectl

Unfortunately Emacs does not have API to obtain time zone identifier,
only offset and abbreviation are exposed by GNU libc. POSIX does not
have such requirement.


Is it trivial to find the [continent/city] timezone name to a specific
place?


For other places: since data to build time zone map are available, there
should be web sites that allows to find identifier for any location.
Sorry, I do not use them, so I can not recommend a particular one.

An application that is able to read locally installed tzdata may assist
by filtering the list by time offset or by the continent (or the ocean,
see e.g. Pacific/Apia trips across the International date line to
America and back to Asia with Australia).

Re: Properly handle defaults in org-set-property

[Janek F]

That is exactly what I use, as you can see in my dotfiles:
https://code.ftt.gmbh/janek/dotfiles/src/branch/main/.config/doom/config.el#L293

But it leads to the exact aforementioned problem...


--- Original Message ---
Ihor Radchenko  schrieb am Dienstag, 20. September 2022 um 
10:10:


> Janek F xer...@pm.me writes:
> 
> > As discussed in 
> > https://emacs.stackexchange.com/questions/71774/pass-default-value-to-org-set-property/71777,
> >  providing a default to org-set-property does not always work.
> > 
> > It calls `org-read-property-value`, which only uses the supplied default 
> > value if it can compute a list of allowed values for the property. But 
> > then, the default value has to be part of that `_ALL` list.
> > 
> > Can this be changed so it always uses the given default?
> 
> 
> Why don't you just use
> 
> (map! :desc "Set ID property" "lI"
> '(lambda ()
> (interactive)
> (org-set-property "ID" (org-read-property-value "ID" nil "default-value"
> 
> ?
> 
> --
> Ihor Radchenko,
> Org mode contributor,
> Learn more about Org mode at https://orgmode.org/.
> Support Org development at https://liberapay.com/org-mode,
> or support my work at https://liberapay.com/yantar92

Re: POSIX TS spec reverses the meaning of TZ offset compared to ISO (was: [POLL] Proposed syntax for timestamps with time zone info

[tomas]

On Wed, Feb 01, 2023 at 10:57:47PM +0100, Heinz Tuechler wrote:
> to...@tuxteam.de wrote/hat geschrieben on/am 01.02.2023 14:51:

[...]

> > This is unfortunate indeed. I'd tend to pick one and not to allow
> > both, out of fear of counfusion. And if I had to pick one, I'd pick
> > ISO [...]

> Same for me, I usually see ISO offset. Further, I am used to exchange
> time designations (CET, EST, PDT,...) instead of [continent/city]
> timezone names [...]

Note that they mean subtly different things: CET is "Central European
Time", which has a fixed offset of one hour. Europe/Berlin rather means
"whatever offset is valid at this time" (which, as we have seen, is
ambiguous some of the time and faulty at the other end).

You want the second if you want to schedule a regular meeting in your
city at the local bar. You want the first in a log file.

Cheers
-- 
t


signature.asc
Description: PGP signature

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

[Greg Minshall]

thanks, Tomas and Ihor,

> > [2022-11-12 12:00 @Asia/Singapore] vs. [2022-11-12 12:00 @ Asia/Singapore]
> > 
> > Either way is possible.
> > I am in favour of my variant though :)
> 
> Same with me. I read @ as a sigil [1]
...
> [1] https://en.wikipedia.org/wiki/Sigil_(computer_programming)

i'll try to get my head around the sigils (but appreciate that either
way is valid).

cheers, Greg

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

[Timothy]

Hi Ihor,

Thanks for the detailed proposal! The effort you’ve put into soliciting feedback
and working out an effective and concise proposal is most commendable .

> I propose two forms of time zone information in Org timestamps
>
> 1. Timestamp with explicit UTC offset
>
>-MM-DD [optional day name] HH:MM[^ \]>]*?[+-−]HH[MM]?
>-MM-DD [optional day name] HH:MM[^ \]>]*?Z[ \]>]
>
>“-” is latin “HYPHEN-MINUS” (code 0x2D)
>“−” is unicode “MINUS SIGN” (code 0x2212), as prescribed by ISO8601
>we will not actually use it when generating timestamps, but allow it
>to keep some compatibility with ISO standard.
>
>“Z” in the second format refers to “Zulu” time (another name for UTC)
>and must be either the last character in the timestamp or the
>last character before space. Not sure if many users are familiar with
>“Z” convention, but it is (1) in ISO; (2) succinct for users who are
>familiar with it. We will prefer +00 number offset in auto-generated
>timestamps.
>
>Examples:
>2022-11-12 12:00+02 # 12:00 UTC+2
>2022-11-12 14:00+0230 # 14:00 UTC+2:30
>2022-11-12 14:00-0230 # 14:00 UTC-2:30
>2022-11-12 14:00Z # 14:00 UTC
>
>The offset is a subset of what is defined by ISO8601.
>
>Note that unlike ISO8601, “:” is not allowed in the offset specifier.
>This is to disambiguate with the time intervals in Org timestamps:
>[2022-11-12 Sat 08:00]–[2022-11-12 Sat 09:00]  in Org is a time range from 
> 8am to 9am.
>
>For time ranges, we will only allow a single offset and time zone
>specifier for both start and end times:
>[2022-11-12 Sat 08:00]–[2022-11-12 Sat 09:00]
>If different time zones are necessary to specify the start/end times,
>users can still use full timestamp range syntax
>[2022-11-12 Sat 08:00]–[2022-11-12 Sat 22:00]
>
>The format is also forward-compatible with extending Org timestamps
>for second/sub-second precision: 2022-11-12 14:00:05.0012+0230 will
>remain valid if we decide to adopt such format.

This functions well, however I see a potential to be confusing at a glance here.
Consider the visual similarity of 10:30 to 11:00 in local time and 10:30 in
UTC-11, and the combination of both.

┌
│ [2022-11-12 10:30-11:00]
│ [2022-11-12 10:30-1100]
│ [2022-11-12 10:30-11:00-1100]
└

I’d be inclined to put the UTC offset together with the time zone name if
possible. Do you think something along the lines of `@-1100,America/Anchorage'
could be viable? I’d think that would reduce the chance of confusion.

┌
│ [2022-11-12 10:30-11:00]
│ [2022-11-12 10:30 @-1100]
│ [2022-11-12 10:30-11:00 @-1100]
└

Looking at this, I also personally rather like that it puts all the timezone
information together in a single `@TZINFO' token.

> 2. Timestamp with time zone specifier
>
>-MM-DD [optional day name] HH:MM[^ ]* @[!]?<[^ \]>]>
>
>For now, time zone name will only be processed when it follows TZ
>POSIX format. If necessary, the proposed syntax will still allow
>extensions to TZ POSIX.
>
>Examples:
>2022-11-12 12:00 @Asia/Singapore # tzdb syntax
>2022-11-12 10:00 @Europe/Berlin
>2022-11-12 10:00 @!Europe/Berlin # “!” does nothing here, see below
>2022-11-12 10:00 @EST+5 # TZ syntax
>2022-11-12 10:00 @EST+5EDT,M3.2.0/2,M11.1.0/2 # manual time zone spec 
> allowed in TZ
>
>The “@” symbol is selected to disambiguate time zone specifier from
>other auxiliary information in the timestamp. Like calendar name,
>which might be added in future. Note that we cannot use […] from
>the standard draft. I selected “@” because it is read as “at” -
>location specifier.
>
>The “!” symbol is adapted from
>
>
>I use space before “@” to improve readability. We deviate from the
>standard here so may as well. In contrast, no space before [+-]offset
>is closer to the standard yet not cluttering the timestamp too much
>(IMHO).

This looks like it works rather nicely to me.

> 3. (1) and (2) can be combined
>
>2022-11-12 12:00+08 @Asia/Singapore
>
>Org will unconditionally use +08 offset and ignore the time zone
>name. We prefer absolute offset because it is non-ambiguous wrt
>out-of-date tzdb on the computer. One may also not update the TZ
>variable upon travelling - the system clock will again be more likely
>accurate.
>
>This redundant time offset info can serve as human-readable
>indication of absolute time, while the time zone name will indicate
>the location.
>
>2022-11-12 12:00+07 @!Asia/Singapore
>
>Org will calculate the internal time for both +07 offset and
>Asia/Singapore time zone. If they do not match, Org will issue a
>warning. The offset will still be preferred if we have to proceed.
>
>This can be useful when planning future meetings and sending Org file
>with a timestamp to 

Re: POSIX TS spec reverses the meaning of TZ offset compared to ISO (was: [POLL] Proposed syntax for timestamps with time zone info

[Max Nikulin]

On 02/02/2023 04:57, Heinz Tuechler wrote:

My impression is that many of non experts like me don't
know in which time zone they are living.


For you own time zone: Open Development tools in a browser ([F12]), 
switch to console, type


 new Intl.DateTimeFormat().resolvedOptions().timeZone

I am sure there are a lot of web pages that do the same.

On linux you can use the following tool

timedatectl

Unfortunately Emacs does not have API to obtain time zone identifier, 
only offset and abbreviation are exposed by GNU libc. POSIX does not 
have such requirement.



Is it trivial to find the [continent/city] timezone name to a specific
place?


For other places: since data to build time zone map are available, there 
should be web sites that allows to find identifier for any location. 
Sorry, I do not use them, so I can not recommend a particular one.


An application that is able to read locally installed tzdata may assist 
by filtering the list by time offset or by the continent (or the ocean, 
see e.g. Pacific/Apia trips across the International date line to 
America and back to Asia with Australia).

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

[Max Nikulin]

On 01/02/2023 23:45, Ihor Radchenko wrote:


Note how `encode-time' TIME argument has both DST flag and the time zone
name:

(SECOND MINUTE HOUR DAY MONTH YEAR IGNORED DST ZONE)

DST is necessary exactly in the ambiguous situations like I described,
when we must know if day saving time is in effect or not __in addition__
to time zone name.


Warning: just be aware that sometimes DST is not enough to resolve 
ambiguity. E.g. in the following example attempt to pass non-nil DST 
signals an error:


zdump -v Africa/Juba | grep 2021
Africa/Juba  Sun Jan 31 20:59:59 2021 UT = Sun Jan 31 23:59:59 2021 EAT 
isdst=0 gmtoff=10800
Africa/Juba  Sun Jan 31 21:00:00 2021 UT = Sun Jan 31 23:00:00 2021 CAT 
isdst=0 gmtoff=7200

Re: POSIX TS spec reverses the meaning of TZ offset compared to ISO (was: [POLL] Proposed syntax for timestamps with time zone info

[Samuel Wales]

perhaps some cities are not listed?  what is one supposed to do then?
find a city with equivalent geography and tz policy?


On 2/1/23, Heinz Tuechler  wrote:
> to...@tuxteam.de wrote/hat geschrieben on/am 01.02.2023 14:51:
>> On Wed, Feb 01, 2023 at 01:26:36PM +, Ihor Radchenko wrote:
>>> [ adding Org ML back to CC ]
>>>
>>> Christian Moe  writes:
>>>
> Note, however, that because we are conforming to POSIX TZ, @UTC+2 is
> two
> hours _behind_ the Greenwich.

 Ouch.
>>>
>>> This is probably something we need to discuss further.
>>>
>>> Dear All,
>>>
>>> There is potential confusion coming from the different interpretations
>>> of the time zone offsets used in ISO8601 and POSIX TZ specs:
>>
>> This is unfortunate indeed. I'd tend to pick one and not to allow
>> both, out of fear of counfusion. And if I had to pick one, I'd pick
>> ISO, which I've seen more often in the wild. But this might quite
>> well be some sort of bias.
>>
>> Cheers
>>
> Same for me, I usually see ISO offset. Further, I am used to exchange
> time designations (CET, EST, PDT,...) instead of [continent/city]
> timezone names. My impression is that many of non experts like me don't
> know in which time zone they are living. Is it trivial to find the
> [continent/city] timezone name to a specific place?
> best, Heinz
>
>


-- 
The Kafka Pandemic

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

Re: POSIX TS spec reverses the meaning of TZ offset compared to ISO (was: [POLL] Proposed syntax for timestamps with time zone info

[Heinz Tuechler]

to...@tuxteam.de wrote/hat geschrieben on/am 01.02.2023 14:51:

On Wed, Feb 01, 2023 at 01:26:36PM +, Ihor Radchenko wrote:

[ adding Org ML back to CC ]

Christian Moe  writes:


Note, however, that because we are conforming to POSIX TZ, @UTC+2 is two
hours _behind_ the Greenwich.


Ouch.


This is probably something we need to discuss further.

Dear All,

There is potential confusion coming from the different interpretations
of the time zone offsets used in ISO8601 and POSIX TZ specs:


This is unfortunate indeed. I'd tend to pick one and not to allow
both, out of fear of counfusion. And if I had to pick one, I'd pick
ISO, which I've seen more often in the wild. But this might quite
well be some sort of bias.

Cheers


Same for me, I usually see ISO offset. Further, I am used to exchange
time designations (CET, EST, PDT,...) instead of [continent/city]
timezone names. My impression is that many of non experts like me don't
know in which time zone they are living. Is it trivial to find the
[continent/city] timezone name to a specific place?
best, Heinz

Re: [BUG] LaTeX aligned equations do not have right spacing [9.6.1 (release_9.6.1 @ /home/yhu/dev/prefix/org-mode/emacs/site-lisp/org/)]

[Leo Butler]

On Wed, Feb 01 2023, Ihor Radchenko  wrote:

> Rick Hu  writes:
>
>> Example text in org mode:
>> \begin{align}
>> H_1(x) = & 3 x^2 - 2 x^3 \\
>> S_1(x) = &  -2 x^2 + x^3 \\
>> \end{align}
>>
>> When I export this to html and display on a browser, the spacing
>> between the equal sign and the terms behind is very small.
>> This is not the right amount around an equal sign.
>
> Could you please elaborate? Maybe attach a screenshot?


Not a bug. See the attached.

Leo

#+TITLE: [BUG] LaTeX aligned equations do not have right spacing
#+AUTHOR: L. Butler
#+OPTIONS: toc:nil num:nil

* Report
#+begin_example
From: Rick Hu 
Subject: [BUG] LaTeX aligned equations do not have right spacing [9.6.1
 (release_9.6.1 @ /home/yhu/dev/prefix/org-mode/emacs/site-lisp/org/)]
To: "emacs-orgmode@gnu.org" 
Date: Mon, 30 Jan 2023 20:38:43 + (2 days, 15 minutes, 16 seconds ago)

Example text in org mode:
\begin{align}
H_1(x) = & 3 x^2 - 2 x^3 \\
S_1(x) = &  -2 x^2 + x^3 \\
\end{align}

When I export this to html and display on a browser, the spacing
between the equal sign and the terms behind is very small.
This is not the right amount around an equal sign.

Emacs  : GNU Emacs 28.2 (build 1, x86_64-pc-linux-gnu)
of 2022-09-21
Package: Org mode version 9.6.1 (release_9.6.1 @ /home/yhu/dev/prefix/org-mode/emacs/site-lisp/org/)
#+end_example

* Analysis
Let's typeset the \LaTeX{} code above:

\begin{align}
H_1(x) = & 3 x^2 - 2 x^3 \\
S_1(x) = &  -2 x^2 + x^3 \\
\end{align}

There are a few errors, I think, with the \LaTeX{} not Org. Here is the correction:

\begin{align}
H_1(x) & = 3 x^2 - 2 x^3 \\
S_1(x) & = -2 x^2 + x^3
\end{align}

Note that the spacing around the ~=~ sign is correct and there is no spurious third equation label.

** Corrected source

#+begin_example
\begin{align}
H_1(x) & = 3 x^2 - 2 x^3 \\
S_1(x) & = -2 x^2 + x^3
\end{align}
#+end_example

* Conclusion

Not a bug.


hu.pdf
Description: hu.pdf

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 Wed, 01 Feb 2023 07:05:45 -0500  Ihor Radchenko  wrote --- 

 > This and another commit are rather trivial - they are eligible for
 > bugfix. See https://orgmode.org/worg/org-maintenance.html#branches
 > I cherry-picked the commits for bugfix.

Noted for the future.

 > I also added a comment clarifying the purpose of the newline.
 > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=b4a1133a1

My apology for not carrying over the note.  Thank you for correcting it.

Re: PATCH for worg about cb_thunderlink (Re: Link from orgmode file to E-Mail (using kmail or notmuch))

[Bruno Barbier]

Max Nikulin  writes:

> On 01/02/2023 02:56, Bruno Barbier wrote:
> Is it intentional that you and the linked page avoid cb_thunderlink page 
> on the official add-on site?
> https://addons.thunderbird.net/en-us/thunderbird/addon/cb_thunderlink/

No. But visiting the author site being mandatory to install it, I
thought it was simpler to point directly there.

>> +To install the =cb_thunderlink=, see this web page:
>> +
>> +   https://camiel.bouchier.be/en/cb_thunderlink/installation?with_menu=1
>> +
>> +You need to install both the add-on and the OS integration.
>
> Often I prefer to see URL I am going to visit, however in this case I 
> would consider in-text link with description text hiding the address.

ok.

>> +#+begin_src elisp
>> +(defvar cbthunderlink-app nil
>> +  "The full path where you've installed your cb_thunderlink application.")
>> +
>> +(defun cbthunderlink-open (message-id)
>> +  "Open the given email. MESSAGE-ID is the message id."
>> +  (start-process "cb_thunderlink" " *cb_thunderlink*"
> --^

Yes. This is a buffer that is uninteresting to the user, see:

  (info "(elisp) Buffer Names")



> is it intentional space?
>> + cbthunderlink-app
>> + (concat "thunderlink://messageid=" message-id)))
>> +(org-add-link-type "mid" 'org-email-open)
>> +#+end_src
>
> I am in doubts if `org-add-link-type' should be recommended since
>
> (make-obsolete 'org-add-link-type "use `org-link-set-parameters' 
> instead." "9.0")

Oops. Right. I should change that, thanks (and use my new function name
`cbthunderlink-open', not the old one `org-email-open').

>
> I checked
> https://camiel.bouchier.be/en/cb_thunderlink/installation/windows
> https://camiel.bouchier.be/en/cb_thunderlink/installation/linux
> in both cases it promises to register thunderlink:// and 
> cbthunderlink:// handlers. From my point of view it may be a reason to 
> take advantage of `browse-url' package. It should allow to avoid 
> explicit code to start process and to delegate the task to this package 
> and to handle mid: links by `goto-address-mode' in non-org buffers.

That is what I first thought. But, I couldn't find an Emacs function
that would pass that URL to the OS desktop, asking it to open the
document.

I'm not using `browse-url' (except for web pages) and I wasn't aware of
`goto-address-mode'.

> By the way, if cb_thunderlink is more convenient than built-in way to 
> handle mid: links in thunderbird then support of mid: URI protocol is a 
> valid feature request for cb_thunderlink.

I'm not sure to understand. The `cb_thunderlink' add-on allow to build
the link in one click from inside Thunderbird; that the part that I find
really useful. And if Thunderbird is able to open an email from its
"mid:" URL, the prefered method should probably be to install only the
add-on inside Thunderbird, and use Thunderbird to reopen the "mid:" link.

>
> Let's wait several days, there is a chance that somebody else will add 
> more comments.

ok. Thanks for your comments.

Bruno

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

[Ihor Radchenko]

Jean Louis  writes:

>> [2023-03-29 02:30+2 @Europe/Berlin] (before transition)
>> [2023-03-29 02:30+1 @Europe/Berlin] (after transition)
>
> Both of the above time stamps do not exist, both are valid.
>
> If you meant daylight savings time stamps, then you maybe wanted to
> say following:
>
>> [2023-03-26 02:30+2 @Europe/Berlin] (before transition)
>> [2023-03-26 02:30+1 @Europe/Berlin] (after transition)

No. I meant 2023-10-29. When the clock moves backwards. Sorry for the
confusion.

   Sun, 29 Oct, 03:00   CEST → CET  -1 hour (DST end)   UTC+1h

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

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

[Ihor Radchenko]

Jean Louis  writes:

>> The problems of daylight savings transition points is fairly well
>> understood and I think it is fairly well accepted that there is
>> ambiguity arising from the use of daylight savings.
>
> The only ambiguity is if you miss to understand that "time zone"
> definition already contains specification of daylight savings.
>
> If you do understand it, then there will be no ambiguity at all.

You are incorrect here. In such scenarios, time zone name must also be
accompanied by DST flag. Just supplying the time zone is not enough.

Note how `encode-time' TIME argument has both DST flag and the time zone
name:

   (SECOND MINUTE HOUR DAY MONTH YEAR IGNORED DST ZONE)

DST is necessary exactly in the ambiguous situations like I described,
when we must know if day saving time is in effect or not __in addition__
to time zone name.

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

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

[Ihor Radchenko]

Jean Louis  writes:

> Using UTC offset for future time stamps is IMHO possibly much more
> problematic for the same reason of possible changes in future.

Yes. But it is also an advantage when the purpose is creating timestamp
independent of possible changes in future.

>> Complex time zones in timestamps will not rely on user's computer having
>> the up-to-date time zone database: [1916-09-12 12:00+01 @Europe/London]
>> unambiguously specifies the UTC offset yet emphasizing that the
>> timestamp is related to specific location (Europe/London, but not
>> Europe/Paris). In fact, one may somewhat abuse this format and specify
>> [1916-09-12 12:00+01 @France/Marseille] emphasizing the location.
>
> Then if they are not to relay on time zone database, on what they can
> rely as alternative?

I suggest ignoring @... if +01 is specified (unless "@!..." is provided).
Then, the timestamp is considered in a nautical time zone with fixed (+01)
offset from UTC.

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

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

[Ihor Radchenko]

Jean Louis  writes:

> Are you going to implement the connection to time zone database?

It will be enough to use Emacs time API. `encode-time' accepts time zone
as an argument. The time zone in `encode-time' must follow the format
for TZ environment variable. Under the hook, `encode-time' uses glibc
system library that connects to zoneinfo (IANA Time Zone Database).

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

Re: PATCH for worg about cb_thunderlink (Re: Link from orgmode file to E-Mail (using kmail or notmuch))

[Max Nikulin]

On 01/02/2023 02:56, Bruno Barbier wrote:

I've got an initial draft. It's not exactly what I'm using, as I tried
to make the configuration OS agnostic. And I'm using Thunderbird only
for accounts where I'm forced to use Win32 (else, I'm using notmuch).


Thank you, Bruno.

Is it intentional that you and the linked page avoid cb_thunderlink page 
on the official add-on site?

https://addons.thunderbird.net/en-us/thunderbird/addon/cb_thunderlink/


+To install the =cb_thunderlink=, see this web page:
+
+   https://camiel.bouchier.be/en/cb_thunderlink/installation?with_menu=1
+
+You need to install both the add-on and the OS integration.


Often I prefer to see URL I am going to visit, however in this case I 
would consider in-text link with description text hiding the address.



+#+begin_src elisp
+(defvar cbthunderlink-app nil
+  "The full path where you've installed your cb_thunderlink application.")
+
+(defun cbthunderlink-open (message-id)
+  "Open the given email. MESSAGE-ID is the message id."
+  (start-process "cb_thunderlink" " *cb_thunderlink*"

--^
is it intentional space?

+ cbthunderlink-app
+ (concat "thunderlink://messageid=" message-id)))
+(org-add-link-type "mid" 'org-email-open)
+#+end_src


I am in doubts if `org-add-link-type' should be recommended since

(make-obsolete 'org-add-link-type "use `org-link-set-parameters' 
instead." "9.0")


I checked
https://camiel.bouchier.be/en/cb_thunderlink/installation/windows
https://camiel.bouchier.be/en/cb_thunderlink/installation/linux
in both cases it promises to register thunderlink:// and 
cbthunderlink:// handlers. From my point of view it may be a reason to 
take advantage of `browse-url' package. It should allow to avoid 
explicit code to start process and to delegate the task to this package 
and to handle mid: links by `goto-address-mode' in non-org buffers.


By the way, if cb_thunderlink is more convenient than built-in way to 
handle mid: links in thunderbird then support of mid: URI protocol is a 
valid feature request for cb_thunderlink.


Let's wait several days, there is a chance that somebody else will add 
more comments.

Re: [POLL] Proposed syntax for timestamps with time zone info

[Jean Louis]

* Stefan Nobis  [2023-02-01 12:13]:
>  writes:
> 
> > 2023-03-23 02:30 @Europe/Berlin refers to /two/ points in time, thus
> > it /is/ ambiguous.
> 
> As far as I understand the definitions, the point in time "2023-03-23
> 02:30 @Europe/Berlin" is clearly defined as 2023-03-23 02:30 UTC+0100.
> 
> A bit more problematic would be "2023-03-26 02:30 @Europe/Berlin".
> Strictly speaking, this point in time does not exist, because in the
> night from 2023-03-25 to 2023-03-26 the clock will jump from 02:00
> directly to 03:00 in the time zone Europe/Berlin. Therefore the
> /interpretation/ of this timestamp is ambiguous.

Thank you!

The generation of invalid time stamps is programming bug.

> The real problem would be e.g. "2023-10-29 02:30 @Europe/Berlin". This
> point in time really exist twice, there is 02A:30 (02:30 UTC+0200) and
> 02B:30 (02:30 UTC+0100) in this night of switching back from DST to
> normal time!
> 
> So, in general, only using the time zone name may indeed lead to
> ambiguous interpretations of timestamps.

Exactly! Thank you!

With the correction that "this point in time really exists twice" --
well, not like that, you have specified 2 different time points by
specifying different UTC offset, so those are different time
points. Though I got your ▲

-- 
Jean

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

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

Re: org-clock idle time in pgtk Emacs

[Max Nikulin]

On 01/02/2023 20:15, Ihor Radchenko wrote:

+(defcustom org-clock-pgtkidle-program-name
+  (if (executable-find "jc-idle-time")
+  "jc-idle-time")
+  "Name of the program which prints idle time in milliseconds.


May I know where "jc-idle-time" is coming from? Is it a built-in command
on wayland?


During discussion in the later thread

Julien Cubizolles to emacs-orgmode. org-x11idle-exists-p with emacs 
--daemon. Fri, 28 Oct 2022 00:31:23 +0200. 
https://list.orgmode.org/871qqs6gqs@free.fr


I noticed a suggestion to use a d-bus method, unfortunately it is 
Gnome-specific


https://unix.stackexchange.com/questions/396911/how-can-i-tell-if-a-user-is-idle-in-wayland/
dbus-send --print-reply --dest=org.gnome.Mutter.IdleMonitor 
/org/gnome/Mutter/IdleMonitor/Core org.gnome.Mutter.IdleMonitor.GetIdletime


Another interface likely may give not really reliable results:

org.freedesktop.ScreenSaver GetSessionIdleTime

https://lists.freedesktop.org/archives/xdg/2007-March/009187.html
Stephan Kulow. screensaver dbus interfaces. Mon Mar 5 05:16:39 PST 2007

Unsure if some workaround like in xprintidle should be used on this way:
https://github.com/g0hl1n/xprintidle/blob/master/xprintidle.c#L150
 * Workaround: Check if if XServer is in a dpms state, check the
 * current timeout for this state and add this value to
 * the current idle time and return.
 */


+(defvar org-pgtkidle-exists-p
+  ;; Check that org-clock-pgtkidle-program-name exists.  But don't do that on 
DOS/Windows,
+  ;; since the command definitely does NOT exist there, and invoking
+  ;; COMMAND.COM on MS-Windows is a bad idea -- it hangs.
+  (and (null (memq system-type '(windows-nt ms-dos)))
+   (eq 0 (call-process-shell-command
+  (format "command -v %s" org-clock-pgtkidle-program-name)))
+   ;; Check that x11idle can retrieve the idle time
+   ;; FIXME: Why "..-shell-command" rather than just `call-process'?
+   (eq 0 (call-process-shell-command org-clock-pgtkidle-program-name


We may as well resolve this FIXME since we are at it.
Instead of the awkward combination of two `call-process-shell-command'
prompts, we can simply use `executable-find' + `call-process'.


Is there a reasonable way to avoid code duplication? I agree that 
`executable-find' may be better since `org-clock-pgtkidle-program-name' 
might contain spaces or shell specials causing issues with current code.

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

[Jean Louis]

* Ihor Radchenko  [2023-02-01 13:30]:
> Tim Cross  writes:
> 
> > The real question is, can the additional complexity associated with
> > including both a time zone name and an offset be justified in order to
> > handle the very small number of time stamps which will fall within the
> > daylight savings transition hour for those locations which have daylight
> > savings? Keep[ing in mind that the complexity is less to do with the
> > time stamp format and more to do with using that information in any
> > meaningful sense. This, combined with the reduced readability of such
> > time stamps and increased possibility of user confusion leads me to
> > question if allowing time stamps with both offset and time zone together
> > in the one time stamp is worthwhile. 
> 
> As I originally stated in the proposal, the real usefulness of combined
> offset+time zone is asking Org to double-check the consistency:

That is right, though that is not the fundamental reason for using UTC
offset and time zone.

Every good application should check if the time stamp is valid or
not. 

It should not allow user to specify invalid time stamps, and it should
not calculate and generate invalid time stamps.

The reason for UTC offset is future possible political changes of the
UTC offset.

It shall be assumed that time stamp from past was correct, that it was
generated by application that was using the time zone database, but
the UTC offset in present time could be changed, just as it was
mentioned for the Russian decision recently.

By using UTC offset and time zone from past, one can then use present
UTC offset definitions and calculate differences. However, there are
still rare changes with the past time zone definitions. 

Using UTC offset for future time stamps is IMHO possibly much more
problematic for the same reason of possible changes in future.

> Consider a time stamp far in future [2052-11-12 12:00+08 @!Asia/Singapore] 
> The time zone rules for Asia/Singapore may or may not remain the same
> due to political uncertainty. Today, we expect the offset to remain +08.
> If it changes in future, Org will warn the user.

Very right.

> In addition, I find specifying both the time zone and the offset
> useful for readability:

Thank you.

> Complex time zones in timestamps will not rely on user's computer having
> the up-to-date time zone database: [1916-09-12 12:00+01 @Europe/London]
> unambiguously specifies the UTC offset yet emphasizing that the
> timestamp is related to specific location (Europe/London, but not
> Europe/Paris). In fact, one may somewhat abuse this format and specify
> [1916-09-12 12:00+01 @France/Marseille] emphasizing the location.

Then if they are not to relay on time zone database, on what they can
rely as alternative?

--
Jean

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

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

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

[Jean Louis]

* Ihor Radchenko  [2023-02-01 15:23]:
> [2022-11-12 14:00 @UTC+2]
> [2022-11-12 14:00 @UTC-2:30]
> 
> are also fine within the proposed format.

The above format is unclear to me. I look at timestamps every day, too
many, often change them.

I cannot understand what you mean.

If there is considered UTC time zone, then the only prefix for such
time stamp is +00 and nothing else, or no prefix at all.

The time stamps that specify UTC offset are expressed in local time,
not in UTC time. 

Here are few examples of ordinary usage of UTC offset converted to UTC:

2023-01-07 09:21:11.019166+03 which means: 2023-01-07 06:21:11.019166 @UTC
2022-10-05 14:09:04.79737+03 which means: 2022-10-05 11:09:04.79737 @UTC

Due to that ordinary usage of time stamps, something like @UTC+2 where
you specify 14:00 o'clock, is unclear, if you mean UTC time plus 2,
like 16 o'clock, or you mean 12 o'clock.

Time stamps having UTC offset are in their representation such as in
calendar tied to the time zone, as they maybe are derived from system
time, where time zone need not be displayed in the time stamp, but it
is nevertheless there and used by program to derive the UTC offset.

And it is either UTC time, or local time plus UTC offset.

There is no UTC time plus UTC offset, why would anybody need that as
time stamp?

-- 
Jean

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

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

Re: [POLL] Proposed syntax for timestamps with time zone info

[Jean Louis]

* to...@tuxteam.de  [2023-02-01 12:22]:
> ...which stems from the fact that the very concept of "time zone"
> is somewhat ambiguous, too. 

For human who reads it without calculating anything, yes.

For computer which is supposed to be programmed by using the time zone
database, no.

> Some time zone designations carry the fact of whether they are
> supposed to be summer times or not with them (as with CET/CEST),
> some not (as above). The time zone database is only known for a
> limited time into future and may change with political
> vagaries. Yadda, yadda.

Very right. 

At least the history is more certain than the future in regards to
time calculations with computer.

-- 
Jean

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

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

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

[Jean Louis]

* Ihor Radchenko  [2023-02-01 15:42]:
> Indeed. Org is used by a variety of users with different needs. What I
> just demonstrated is that specifying the time zone is not always
> necessary in timestamps.

Specifying time zone in time stamps is not necessary!

But using the time zone is necessary if developers wish to provide
accuracy of time calculations for users.

Using the time zone is built-in, it is just matter of representation
of time at export or exchanges.

And time zone could be changed from the default system time, inside of
the time stamp, if not there, inside of heading property, if not
there, inside of the file time stamp property.

That way majority of time stamps can remain how they are with addition
of specification of time zone property.

> Note that my proposal allows specifying the time zone when you need
> it.

Thank you!

That is good proposal.

> Or not specifying it and specifying the UTC offset only.

If you mean, specifying _local time_ plus UTC offset, then that is not
how you can exchange information with participants in meeting. That is
unsure.

But if you mean specifying _UTC time_ plus the UTC offset, that is
alright to derive local time from it.

Preceding condition is that such UTC time plus the UTC offset was
calculated correctly.

And there need not be the ultimate goal in Org that all kinds of time
stamps can be calculated for the future.

That shall be the job of the function to verify if the timestamp can
be re-calculated or not, and function may warn the user to update it
with missing time zone.

Read "Putting It All Together"
https://spin.atomicobject.com/2016/07/06/time-zones-offsets/

Are you going to implement the connection to time zone database?

-- 
Jean

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

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

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

[Jean Louis]

* Tim Cross  [2023-02-01 12:53]:
> > Let me try to explain better. Just specifying time zone is ambiguous
> > once per year during daylight transition.
> >
> > [2023-03-29 02:30 @Europe/Berlin] is special.
> >
> > According to https://www.timeanddate.com/time/zone/germany/berlin,
> > 2023-03-29 is the time when the clock is shifted one hour back due to
> > the daylight saving transition. The wall time goes like
> >
> > 2023-03-29 02:30 -> ... -> 02:59 -> (CEST -> CET) 02:00 -> ... -> 2:30 
> > (again!)
> >
> > So, [2023-03-29 02:30 @Europe/Berlin] can mean two time points: before
> > and after the transition. Specifying explicit offset is thus necessary
> > in this specific scenario to disambiguate the timestamp:
> >
> > [2023-03-29 02:30+2 @Europe/Berlin] (before transition)
> > [2023-03-29 02:30+1 @Europe/Berlin] (after transition)
> 
> OK, in that case, I think what we are in danger of here is letting
> the perfect be the enemy of good.
> 
> The problems of daylight savings transition points is fairly well
> understood and I think it is fairly well accepted that there is
> ambiguity arising from the use of daylight savings.

The only ambiguity is if you miss to understand that "time zone"
definition already contains specification of daylight savings.

If you do understand it, then there will be no ambiguity at all.

> The real question is, can the additional complexity associated with
> including both a time zone name and an offset be justified in order
> to handle the very small number of time stamps which will fall
> within the daylight savings transition hour for those locations
> which have daylight savings?

That additional complexity is important for future, as we cannot know
what will be the future UTC offset due to political changes!

> Keep[ing in mind that the complexity is less to do with the time
> stamp format and more to do with using that information in any
> meaningful sense.

That is very correct, that is why Org shall keep time stamps simple in
it's basic form and allow users to specify precision as they wish.

> This, combined with the reduced readability of such time stamps and
> increased possibility of user confusion leads me to question if
> allowing time stamps with both offset and time zone together in the
> one time stamp is worthwhile.

As we promote Org to be good for "reproducible research" then for
those people will be of value, and many other groups who need time
precision. 

https://html.duckduckgo.com/html/?q=org+mode+reproducible


--
Jean

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

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

Re: Internal links to lines in different org files

[Ihor Radchenko]

kevin lucas  writes:

> Thanks for responding. I meant specifically the :: syntax with org IDs, and
> not filenames. I did confirm that this feature is currently only in Doom
> Emacs, see:
> https://github.com/doomemacs/doomemacs/blob/master/modules/lang/org/config.el#L639-L659

I am really curious why Doom author never considered contributing to Org
core. This style with numerous advices is a recipe for eventual
disaster.

> Regarding org-export-with-broken-links, is there a way to export the text
> of the link, and not kill all the text?

Currently, no.

I guess one may add a new possible value to
`org-export-with-broken-links', making it a custom function.

Alternatively, you may override the link transcoder in a custom derived
export backend (see `org-export-define-derived-backend').

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

Re: [BUG] LaTeX aligned equations do not have right spacing [9.6.1 (release_9.6.1 @ /home/yhu/dev/prefix/org-mode/emacs/site-lisp/org/)]

[Ihor Radchenko]

Rick Hu  writes:

> Example text in org mode:
> \begin{align}
> H_1(x) = & 3 x^2 - 2 x^3 \\
> S_1(x) = &  -2 x^2 + x^3 \\
> \end{align}
>
> When I export this to html and display on a browser, the spacing between the 
> equal sign and the terms behind is very small.
> This is not the right amount around an equal sign.

Could you please elaborate? Maybe attach a screenshot?

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

Re: org-clock-sum-today performance

[Ihor Radchenko]

Tijs Mallaerts  writes:

> After building emacs from the master branch (with Org mode version 9.6
> release_9.6-81-g563a43) I noticed the org-clock-sum-today function takes
> much more time compared to my previous emacs build (with Org mode version
> 9.5.4 release_9.5.4-19-g4dff42) in a large org buffer.
>
> Are there any settings that could speed up the calculation?

May you please
1. run M-x profiler-start  cpu 
2. Run org-clock-sum-today
3. M-x profiler-report
4. M-x profiler-report-write-profile
5. Share the saved profile

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

Re: Internal links to lines in different org files

[Ihor Radchenko]

kevin lucas  writes:

> 1. Is this feature indeed specific to Doom Emacs?
> 2. If this behavior isn’t in org mode, could it be added?

No. It is built-in.

> 3. Connected to this: if I export an org file containing an ordinary link
> to another node to PDF, the PDF compiles and I get a dead link in the file.
> If one tries to export org files with these double colon links there's an
> error message `Unable to resolve ID "foo::myname"`. Is there a way to
> generate the PDF just like in the first case?

See org-export-with-broken-links

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

Re: Bug report for ox-icalendar: newlines should be CRLF

[Ihor Radchenko]

"Stephen J. Eglen"  writes:

> The lines from BEGIN:VEVENT to CATEGORIES:test inclusive have CR (^M) as well
> as LF (^J) as newline [in the text above, I've converted the ^M to ***
> to see them eaer.  Is that intended?  Uploading the file to
> https://icalendar.org/validator.html gives me the error
>
>> Lines not delimited by CRLF sequence near line # 1
>> Reference: RFC 5545 3.1. Content Lines
>
> Nicolas (cc'ed) has confirmed that it seems to be a problem.  Before I
> work slowly on a suggested patch, does anyone have an idea on the best
> way forward?  Is it possible to encode the file as "DOS" ,using
> something like set-buffer-file-coding-system?  SOme lines do however
> have \r and \n see e.g. org-icalendar-fold-string which inserts both \r
> and \n

Sorry for the late reply.

Do I understand correctly that all the ical lines must use \r\n? [1]

If so, we can simply wrap the export output into
`org-icalendar-fold-string' in `org-icalendar-template'. Does it make
sense?

[1] https://icalendar.org/iCalendar-RFC-5545/3-1-content-lines.html


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

[BUG] LaTeX aligned equations do not have right spacing [9.6.1 (release_9.6.1 @ /home/yhu/dev/prefix/org-mode/emacs/site-lisp/org/)]

[Rick Hu]

--text follows this line--

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.


Example text in org mode:
\begin{align}
H_1(x) = & 3 x^2 - 2 x^3 \\
S_1(x) = &  -2 x^2 + x^3 \\
\end{align}

When I export this to html and display on a browser, the spacing between the 
equal sign and the terms behind is very small.
This is not the right amount around an equal sign.

Emacs  : GNU Emacs 28.2 (build 1, x86_64-pc-linux-gnu)
of 2022-09-21
Package: Org mode version 9.6.1 (release_9.6.1 @ 
/home/yhu/dev/prefix/org-mode/emacs/site-lisp/org/)




This message, and any attachments, is for use only by the intended recipients. 
This communication may contain information that is confidential, constitutes 
attorney work product, is privileged, or otherwise protected from disclosure. 
If you have received this message in error, Virtu requests that you notify us 
immediately, and that you immediately delete and do not review, copy, retain, 
or disseminate the message or its attachments.
FOR CANADIAN RECIPIENTS: Virtu believes that it has your implied consent to 
receive electronic communications as you are either an existing client of Virtu 
ITG Canada Corp., or its affiliates, or your email address was made available 
to Virtu.  However, if you wish to stop receiving electronic communications 
from Virtu, please click here to register your request:  please click here.  
Please note that we may not be able to accommodate this request for existing 
clients, where Virtu is required under securities laws or any other applicable 
regulations to send certain electronic communications related to your account.
For a list of Virtu’s Email Disclosures and Disclaimers, please go to 
https://www.virtu.com/email-disclaimer

Re: [BUG] Emacs-29.0.60: (setopt org-babel-load-languages ...) may cause warnings

[gerard . vermeulen]

Hi Igor,

On 31.01.2023 11:34, Ihor Radchenko wrote:

gerard.vermeu...@posteo.net writes:


The attached patch synchronizes the =defcustom= with the rest of the
code base, groups languages by org-babel file, and uses camel-case to
spell languages (the new fashion).


Thanks!
May you please convert the diff into a patch with changelog entry and
commit message? See 
https://orgmode.org/worg/org-contribute.html#org045e318


patch attached.

Two points:
1. I have assigned my copyright for Emacs stuff to the FSF
2. My initial version of the patch was against bugfix and now I have set 
:package-version to "9.6"
according to the instructions on the org-contribute page. I do not 
know if this is acceptable (it
feels a bit like breaking the rules), but I am happy to redo the 
patch for main.


Best regards -- Gerard

0001-org.el-Sync-org-babel-load-languages-with-Babel-file.patch
Description: Binary data

Re: Emacs29: sqllite support for orgroam on Windows?

[Ihor Radchenko]

c.bu...@posteo.jp writes:

> Am 01.02.2023 14:43 schrieb Ihor Radchenko:
>> See `org-roam-database-connector'
>
> Is this a (maybe) yes or (maybe) no?
>
> Can you please translate that answer to someone who doesn't know the 
> internals of Emacs and Lisp; a normal user?

This is a user option.
You can find details about it via the usual Emacs means:

1. M-x customize-group org-roam
2.  v org-roam-database-connector

I recommend https://protesilaos.com/codelog/2022-01-31-learning-emacs/
for more ways how to get help in Emacs.

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

Re: Emacs29: sqllite support for orgroam on Windows?

[c . buhtz]

Dear Ihor,

thanks for reply.

Am 01.02.2023 14:43 schrieb Ihor Radchenko:

See `org-roam-database-connector'


Is this a (maybe) yes or (maybe) no?

Can you please translate that answer to someone who doesn't know the 
internals of Emacs and Lisp; a normal user?


Asking an internet search engine it seems this is a variable or how you 
call it in Lisp?


But there is no public available (C-h and Lisp-code doesn't count) 
documentation about it.

I only can find it mentioned in org roam manual
https://www.orgroam.com/manual.html#Customizing-Node-Caching
But it is not described there just mentioned.

C-h o doesn't help because I only have Emacs 27 alive here and the text 
behind it is outdated because of that. And the text behind it is not on 
a user level but only on a Emacs-Lisp-programmer-level to understand.

Re: POSIX TS spec reverses the meaning of TZ offset compared to ISO (was: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and

[tomas]

On Wed, Feb 01, 2023 at 01:26:36PM +, Ihor Radchenko wrote:
> [ adding Org ML back to CC ]
> 
> Christian Moe  writes:
> 
> >> Note, however, that because we are conforming to POSIX TZ, @UTC+2 is two
> >> hours _behind_ the Greenwich.
> >
> > Ouch.
> 
> This is probably something we need to discuss further.
> 
> Dear All,
> 
> There is potential confusion coming from the different interpretations
> of the time zone offsets used in ISO8601 and POSIX TZ specs:

This is unfortunate indeed. I'd tend to pick one and not to allow
both, out of fear of counfusion. And if I had to pick one, I'd pick
ISO, which I've seen more often in the wild. But this might quite
well be some sort of bias.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Emacs29: sqllite support for orgroam on Windows?

[Ihor Radchenko]

c.bu...@posteo.jp writes:

> I read about Emacs 29 and its in build sqlite support.
> https://blog.phundrak.com/emacs-29-what-can-we-expect/#native-access-to-sqlite-databases
>
> In that case might it be easier with Emacs 29 to setup OrgRoam on 
> Windows because there is no need anymore to install an extra sqlite?

See `org-roam-database-connector'

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

Re: [BUG] org-manual: Using bookmarklet for org-capture is no longer reliable

[Ihor Radchenko]

Max Nikulin  writes:

> I think, we assume different definitions of "rock solid". Does it able 
> to detect that desktop configuration of org-protocol is broken and to 
> notify the user about failure? I do not use :immediate-finish templates, 
> but some people do. There is a risk to quietly lost captures. I do not 
> see other ways to detect errors besides a native messaging helper 
> application.
>
> (info "(org) Template elements") 
> https://orgmode.org/manual/Template-elements.html

Would it be reasonable to make org-protocol raise Emacs frame on
failure?

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

POSIX TS spec reverses the meaning of TZ offset compared to ISO (was: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-

[Ihor Radchenko]

[ adding Org ML back to CC ]

Christian Moe  writes:

>> Note, however, that because we are conforming to POSIX TZ, @UTC+2 is two
>> hours _behind_ the Greenwich.
>
> Ouch.

This is probably something we need to discuss further.

Dear All,

There is potential confusion coming from the different interpretations
of the time zone offsets used in ISO8601 and POSIX TZ specs:

https://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators:

Negative UTC offsets describe a time zone west of UTC±00:00, where
the civil time is behind (or earlier) than UTC so the zone
designator will look like "−03:00","−0300", or "−03".

https://www.di-mgt.com.au/wclock/help/wclo_tzexplain.html:

[Asia/Beijing]
TZ=CST-8

Minutes and seconds are optional, so CST-8 and CST-08:00:00 mean the
same thing. Note that the sign convention (+/-) used in a Posix TZ
string is the opposite to that used in Internet time offsets (RFC
3339) and in Arthur David Olson's TZ data files.

So, the equivalent time zone offsets in, say, Singapore will be:

[2023-02-01 12:00 @Asia/Singapore]
[2023-02-01 12:00+08] ;; local time 8 hours earlier than UTC as in ISO8601 spec
[2023-02-01 12:00 @UTC-08] ;; UTC is 8 hours earlier than local time as in 
POSIX TZ spec

This is potentially confusing.

We may, in theory, reverse the meaning of @UTC[+-]NN manually, but then
values like @EST+5 will remain reversed, again creating the confusion.
Or, if we reverse everything in @..., users more familiar with POSIX TZ
will get confused.

Any ideas?

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

Re: org-clock idle time in pgtk Emacs

[Ihor Radchenko]

Julien Cubizolles  writes:

> Ihor Radchenko  writes:
>
>>
>> As Tim pointed out, we cannot guarantee that things working on 'x build
>> will also work on 'pgtk. Instead of abusing settings for 'x window
>> system, can you please introduce a new function org-pgtk-idle-seconds
>> using a new variable org-clock-pgtkidle-program-name, similar to
>> org-x11-idle-seconds, and then update org-user-idle-seconds?
>
> Sorry for the delay, here is a patch to that effect.

Thanks!

> +(defcustom org-clock-pgtkidle-program-name
> +  (if (executable-find "jc-idle-time")
> +  "jc-idle-time")
> +  "Name of the program which prints idle time in milliseconds.

May I know where "jc-idle-time" is coming from? Is it a built-in command
on wayland?

> +(defvar org-pgtkidle-exists-p
> +  ;; Check that org-clock-pgtkidle-program-name exists.  But don't do that 
> on DOS/Windows,
> +  ;; since the command definitely does NOT exist there, and invoking
> +  ;; COMMAND.COM on MS-Windows is a bad idea -- it hangs.
> +  (and (null (memq system-type '(windows-nt ms-dos)))
> +   (eq 0 (call-process-shell-command
> +  (format "command -v %s" org-clock-pgtkidle-program-name)))
> +   ;; Check that x11idle can retrieve the idle time
> +   ;; FIXME: Why "..-shell-command" rather than just `call-process'?
> +   (eq 0 (call-process-shell-command org-clock-pgtkidle-program-name

We may as well resolve this FIXME since we are at it.
Instead of the awkward combination of two `call-process-shell-command'
prompts, we can simply use `executable-find' + `call-process'.

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

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

[Ihor Radchenko]

Samuel Wales  writes:

> amazing amount of work and good choices.  i won't object, although
> previous comments re syntax proliferation and 3rd party and personal
> code re stand, while acknowledging the replies.

There is no way around.
The feature has been demanded multiple times. It is _needed_ by users.
Since we clearly need the feature, the best we can do is minimizing the
breakage when designing the new syntax.

Note that the proposed syntax will even work with older versions of Org,
except that time zone information will be obviously ignored.

> bce and ce might be possibilities.  if negative numbers or somethigare
> not uniquely used for that.
>
> can any of this, or the semantics, be in emacs?  emacs has times all
> over the place.

`calendar-read-date' only supports AD, AFAIK. Also, glibc system library
may not work reliably on dates before 1970 (or 1900; I don't remember).

Calc appears to handle negative years though. But not
`parse-time-string'. On the other hand, directly specifying internal
time format works (but not sure if correctly):

(format-time-string "%Y-%m-%d %a %H:%M" (encode-time '(0 10 11 11 09 -1000)) 
"UTC-2:30")

> 1. Reduced timestamp precision:
>1985-04-12 (day precision, time omitted; available in Org)
>
> current agenda search query semantics seem /currently/ potentially
> confusing re in/equalities for today, now, day precision.  e.g. is
> today a specific minute or can = refer to any minute in the day?  is
> the manual clear?

The manual is not clear. I am not sure where it is important.

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

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

[tomas]

On Wed, Feb 01, 2023 at 12:48:12PM +, Ihor Radchenko wrote:
> Greg Minshall  writes:
> 
> >> 2022-11-12 12:00 @Asia/Singapore # tzdb syntax
> >
> > aesthetically, allowing a space after the "@" sign might be nice.  i
> > don't know what that would do to the parsing/BNF/whatever.
> 
> [2022-11-12 12:00 @Asia/Singapore] vs. [2022-11-12 12:00 @ Asia/Singapore]
> 
> Either way is possible.
> I am in favour of my variant though :)

Same with me. I read @ as a sigil [1]

Cheers

[1] https://en.wikipedia.org/wiki/Sigil_(computer_programming)
-- 
t


signature.asc
Description: PGP signature

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

[Ihor Radchenko]

Greg Minshall  writes:

>> 2022-11-12 12:00 @Asia/Singapore # tzdb syntax
>
> aesthetically, allowing a space after the "@" sign might be nice.  i
> don't know what that would do to the parsing/BNF/whatever.

[2022-11-12 12:00 @Asia/Singapore] vs. [2022-11-12 12:00 @ Asia/Singapore]

Either way is possible.
I am in favour of my variant though :)
Mostly because I find it more neatly grouped in more complex timestamps
like
[2022-11-12 12:00 @Asia/Singapore +1w -1d]

[2022-11-12 12:00 @ Asia/Singapore +1w -1d]
feels a slightly wrong. And extra space to type manually.

Other opinions welcome though. We can decide according to the majority.
There is no technical limitation when choosing space vs. no space.

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

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

[Ihor Radchenko]

Jean Louis  writes:

>> Consider that you are running a scientific experiment around daylight
>> saving time change: [2022-10-29 2:15-5:15+02]. You don't care that the
>> government decided that the wall clock should go like 2:15 -> 2:59 ->
>> [CEST -> CET] 2:00 -> 2:15 -> 2:59. Physics does not care. You just need
>> to make sure that the experiment runs exactly 3 hours without trying to
>> consider the currently used TZ rules.
>
> Sorry, I cannot see how running the experiment three hours long is 
> related to exchange of for example, appointments, or calendar events
> that shall be represented in possibly different time zones. 

It is not related.

> It seems you have different personal purposes for time representation
> in Org.

Indeed. Org is used by a variety of users with different needs. What I
just demonstrated is that specifying the time zone is not always
necessary in timestamps.

Note that my proposal allows specifying the time zone when you need it.
Or not specifying it and specifying the UTC offset only. Your use-case
with appointments is covered. My example is also covered.

> Are you sure that telling not to care is good notion?

Maybe I used the words wrongly. I meant that physical phenomena do not
follow human conventions and wall time.

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

Re: [BUG] org-open-at-point broken when on headline [9.6.1 (release_9.6.1-208-g0c0059 @ /home/b/s/org/org-mode/lisp/)]

[Marco Wahl]

Hello Ihor!

>> AFAICS org-open-at-point is broken in the case when point is on a
>> headline: org-open-at-point does not open any link.

> * This is test
> [[https:/orgmode.org]]

> C-c C-o works for me on current main.

Gaa!  Reported too quickly!  Again!

I guess the actual issue was located somewhere in front of the monitor.

Sorry for the noise!


Thanks!
-- 
Marco Wahl




On 2/1/23, Ihor Radchenko  wrote:
> Marco Wahl  writes:
>
>> AFAICS org-open-at-point is broken in the case when point is on a
>> headline: org-open-at-point does not open any link.
>
> * This is test
> [[https:/orgmode.org]]
>
> C-c C-o works for me on current main.
>
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: [BUG] org-open-at-point broken when on headline [9.6.1 (release_9.6.1-208-g0c0059 @ /home/b/s/org/org-mode/lisp/)]

[Ihor Radchenko]

Marco Wahl  writes:

> AFAICS org-open-at-point is broken in the case when point is on a
> headline: org-open-at-point does not open any link.

* This is test
[[https:/orgmode.org]]

C-c C-o works for me on current main.


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

[BUG] org-open-at-point broken when on headline [9.6.1 (release_9.6.1-208-g0c0059 @ /home/b/s/org/org-mode/lisp/)]

[Marco Wahl]

Hi!

AFAICS org-open-at-point is broken in the case when point is on a
headline: org-open-at-point does not open any link.

I checked the older version 0c00590606325e6f6f4756f567e36c074da0e890 and
I think it's okay.

Branch main.


Thanks!



Emacs  : GNU Emacs 30.0.50 (build 23, x86_64-pc-linux-gnu, GTK+
Version 3.24.34, cairo version 1.16.0)
 of 2023-02-01
Package: Org mode version 9.6.1 (release_9.6.1-208-g0c0059 @
/home/b/s/org/org-mode/lisp/)
-- 
Marco Wahl

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

[Ihor Radchenko]

Christian Moe  writes:

> From this perspective I'd be happier with the less concise, but super
> explicit
>
>   2022-11-12 14:00 UTC+2
>   2022-11-12 14:00 UTC-2:30

[2022-11-12 14:00 @UTC+2]
[2022-11-12 14:00 @UTC-2:30]

are also fine within the proposed format.

Note, however, that because we are conforming to POSIX TZ, @UTC+2 is two
hours _behind_ the Greenwich.

https://www.di-mgt.com.au/wclock/help/wclo_tzexplain.html:

Explanation of TZ strings

General format of an entry in the file wclocktz.ini:
[continent/city]
TZ=posix-tz-string

Time zones that do not have daylight savings have a simple TZ string,
e.g.

[Pacific/Honolulu]
TZ=HST10

Where HST is the designation for the time zone (in this case Hawaii
Standard Time) and 10 is the offset in hours. The offset indicates the
value one must add to the local time to arrive at Coordinated
Universal Time (UTC, aka GMT), and so it is positive for west of the
meridian, e.g. America, and negative for east, e.g. China.

[Asia/Beijing]
TZ=CST-8

Minutes and seconds are optional, so CST-8 and CST-08:00:00 mean the
same thing. Note that the sign convention (+/-) used in a Posix TZ
string is the opposite to that used in Internet time offsets (RFC
3339) and in Arthur David Olson's TZ data files.

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

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

[Ihor Radchenko]

Matt  writes:

> Pushed the change to `org-babel-eval'.

Thanks!

This and another commit are rather trivial - they are eligible for
bugfix. See https://orgmode.org/worg/org-maintenance.html#branches
I cherry-picked the commits for bugfix.

I also added a comment clarifying the purpose of the newline.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=b4a1133a1

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

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

[Christian Moe]

Hi,

I have only partly been able to follow the discussion, but this seems
like a very thoughtful proposal.

I'm just not super happy with the ISO format running clock time and
offset together, which I thinks makes clock times less readable when
you're just quickly glancing through notes.

>Examples:
>2022-11-12 12:00+02 # 12:00 UTC+2
>2022-11-12 14:00+0230 # 14:00 UTC+2:30
>2022-11-12 14:00-0230 # 14:00 UTC-2:30
>2022-11-12 14:00Z # 14:00 UTC

The '12:00+02' offset is not the 'dd:dd' shape I expect a clocktime
in. Also, since I don't think in UTC offsets, my brain goes '12:00 plus
2 hours' before 'the 12:00 that's 2 hours ahead of Greenwich'. The
extra cognitive load is admittedly small, and I'd probably probably get
used to it quickly if it were only the '+dd'. But I might still get
tripped up by an offset like '14:00-0230', which is unambiguous to a
computer, but synonymous with '14:00-02:30' to my brain.

>From this perspective I'd be happier with the less concise, but super
explicit

  2022-11-12 14:00 UTC+2
  2022-11-12 14:00 UTC-2:30

but I realize there are many considerations to balance here.

Yours,
Christian


>The offset is a subset of what is defined by ISO8601.
>
>Note that unlike ISO8601, ":" is not allowed in the offset specifier.
>This is to disambiguate with the time intervals in Org timestamps:
>[2022-11-12 8:00-9:00] in Org is a time range from 8am to 9am.
>
>For time ranges, we will only allow a single offset and time zone
>specifier for both start and end times:
>[2022-11-12 8:00-9:00+08]
>If different time zones are necessary to specify the start/end times,
>users can still use full timestamp range syntax
>[2022-11-12 8:00+03]--[2022-11-12 22:00+08]
>
>The format is also forward-compatible with extending Org timestamps
>for second/sub-second precision: 2022-11-12 14:00:05.0012+0230 will
>remain valid if we decide to adopt such format.
>
> 2. Timestamp with time zone specifier
>
>-MM-DD [optional day name] HH:MM[^ ]* @[!]?<[^ \]>]>
>
>For now, time zone name will only be processed when it follows TZ
>POSIX format. If necessary, the proposed syntax will still allow
>extensions to TZ POSIX.
>
>Examples:
>2022-11-12 12:00 @Asia/Singapore # tzdb syntax
>2022-11-12 10:00 @Europe/Berlin
>2022-11-12 10:00 @!Europe/Berlin # "!" does nothing here, see below
>2022-11-12 10:00 @EST+5 # TZ syntax
>2022-11-12 10:00 @EST+5EDT,M3.2.0/2,M11.1.0/2 # manual time zone spec 
> allowed in TZ
>
>The "@" symbol is selected to disambiguate time zone specifier from
>other auxiliary information in the timestamp. Like calendar name,
>which might be added in future. Note that we cannot use [...] from
>the standard draft. I selected "@" because it is read as "at" -
>location specifier.
>
>The "!" symbol is adapted from
>https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/
>
>I use space before "@" to improve readability. We deviate from the
>standard here so may as well. In contrast, no space before [+-]offset
>is closer to the standard yet not cluttering the timestamp too much
>(IMHO).
>
> 3. (1) and (2) can be combined
>
>2022-11-12 12:00+08 @Asia/Singapore
>
>Org will unconditionally use +08 offset and ignore the time zone
>name. We prefer absolute offset because it is non-ambiguous wrt
>out-of-date tzdb on the computer. One may also not update the TZ
>variable upon travelling - the system clock will again be more likely
>accurate.
>
>This redundant time offset info can serve as human-readable
>indication of absolute time, while the time zone name will indicate
>the location.
>
>2022-11-12 12:00+07 @!Asia/Singapore
>
>Org will calculate the internal time for both +07 offset and
>Asia/Singapore time zone. If they do not match, Org will issue a
>warning. The offset will still be preferred if we have to proceed.
>
>This can be useful when planning future meetings and sending Org file
>with a timestamp to someone else, potentially with obsolete tzdb.
>
> |---|
> |  |
> |---|
>
> Apart from the ideas mentioned above,
> https://www.loc.gov/standards/datetime/ contains a number of other
> interesting ideas that may or may not be adapted by Org in future.
> I will outline the ideas I find noteworthy to keep them in mind when
> considering changing (including current changes) in the timestamp
> syntax:
>
> 1. Reduced timestamp precision:
>1985-04-12 (day precision, time omitted; available in Org)
>1985-04 (month precision, day and time omitted, not available in Org)
>1985 (year precision)
>
>Current timestamp syntax proposal should not interfere.
>
> 2. Using "T" as date/time delimiter
>1985-04-12T23:20:30 (not supported by Org)
>
> 3. Using "/" for time intervals
>

[ANN] Looking for new maintainers for ox-latex.el (LaTeX export library)

[Ihor Radchenko]

[ This call is for __LaTeX__ exporter, unlike similar earlier call for
  HTML exporter ]

Hello,

I have been informed that our current ox-latex maintainer will no longer
able to perform his duties in full extent.

We thus need volunteers to help maintaining Org LaTeX export library -
lisp/ox-latex.el

Helping with the related ox-beamer.el will also be appreciated.

We need people fluent with Elisp with FSF copyright assignment (or
willing to sign it).



You do not need to be an expert of the functionality in the file or to
actively improve the file. Just take care of bug reports and feature
requests against this file by participating in the discussion on the
list.

You are not strictly required to follow the mailing list closely and
watch for the relevant emails. When necessary, the relevant messages
will be directly forwarded to your email.

[ see more details at https://orgmode.org/worg/org-maintenance.html ]

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

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

[Max Nikulin]

On 01/02/2023 16:38, Tim Cross wrote:

This, combined with the reduced readability of such
time stamps and increased possibility of user confusion leads me to
question if allowing time stamps with both offset and time zone together
in the one time stamp is worthwhile.


Readability should not suffer if time offset is optional. It may be 
omitted for non-ambiguous local time. Time offset may even improve 
readability if you are looking at a timestamp with time zone unknown to you.


Sterling posted the following links (originating from the same group):
https://tc39.es/proposal-temporal/docs/ambiguity.html
https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/

What I do not like is that disambiguation is option of conversion, not 
of timestamp.



For instance, it does not address:

   *  Future time given as a local time in some specified time zone,
  where changes to the definition of that time zone (e.g., a
  political decision to enact or rescind daylight saving time)
  affect the instant in time corresponding with the timestamp.


In this sense I like Python's approach with fold=1 or fold=2 despite in 
general JavaScript Temporal proposal looks more flexible.

https://www.python.org/dev/peps/pep-0495/

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

[Ihor Radchenko]

Tim Cross  writes:

> The real question is, can the additional complexity associated with
> including both a time zone name and an offset be justified in order to
> handle the very small number of time stamps which will fall within the
> daylight savings transition hour for those locations which have daylight
> savings? Keep[ing in mind that the complexity is less to do with the
> time stamp format and more to do with using that information in any
> meaningful sense. This, combined with the reduced readability of such
> time stamps and increased possibility of user confusion leads me to
> question if allowing time stamps with both offset and time zone together
> in the one time stamp is worthwhile. 

As I originally stated in the proposal, the real usefulness of combined
offset+time zone is asking Org to double-check the consistency:

Consider a time stamp far in future [2052-11-12 12:00+08 @!Asia/Singapore] 
The time zone rules for Asia/Singapore may or may not remain the same
due to political uncertainty. Today, we expect the offset to remain +08.
If it changes in future, Org will warn the user.

In addition, I find specifying both the time zone and the offset useful
for readability:

Complex time zones in timestamps will not rely on user's computer having
the up-to-date time zone database: [1916-09-12 12:00+01 @Europe/London]
unambiguously specifies the UTC offset yet emphasizing that the
timestamp is related to specific location (Europe/London, but not
Europe/Paris). In fact, one may somewhat abuse this format and specify
[1916-09-12 12:00+01 @France/Marseille] emphasizing the location.

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

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

[Tim Cross]

Ihor Radchenko  writes:

> Tim Cross  writes:
>
>>> Either I understand you wrong, or you don't know what you are
>>> talking about. 2023-03-23 02:30 @Europe/Berlin refers to /two/
>>> points in time, thus it /is/ ambiguous. If you use disambiguating
>>> "time zones" (MEZ vs MESZ in this case) you can resolve that.
>>
>> I think the confusion relates to context interpretation. If you see
>> @Europe/Berlin in isolation, then it is ambiguous as it can refer to two
>> different time zone definitions (standard v daylight savings).  However,
>> if you consider it in conjunction with a date and time, as in 2023-03-23
>> 02:30 @Europe/Berlin, then it isn't ambiguous - in that case, it really
>> just says 'Lookup the time zone offset in the databse for Berlin as of
>> that date and time.
>>...
>> Personally, I cannot see the use case of including both a fully
>> qualitifed time zone (as in @Europe/Berlin) and an offset...
>
> Let me try to explain better. Just specifying time zone is ambiguous
> once per year during daylight transition.
>
> [2023-03-29 02:30 @Europe/Berlin] is special.
>
> According to https://www.timeanddate.com/time/zone/germany/berlin,
> 2023-03-29 is the time when the clock is shifted one hour back due to
> the daylight saving transition. The wall time goes like
>
> 2023-03-29 02:30 -> ... -> 02:59 -> (CEST -> CET) 02:00 -> ... -> 2:30 
> (again!)
>
> So, [2023-03-29 02:30 @Europe/Berlin] can mean two time points: before
> and after the transition. Specifying explicit offset is thus necessary
> in this specific scenario to disambiguate the timestamp:
>
> [2023-03-29 02:30+2 @Europe/Berlin] (before transition)
> [2023-03-29 02:30+1 @Europe/Berlin] (after transition)

OK, in that case, I think what we are in danger of here is letting
the perfect be the enemy of good.

The problems of daylight savings transition points is fairly well
understood and I think it is fairly well accepted that there is
ambiguity arising from the use of daylight savings.

The real question is, can the additional complexity associated with
including both a time zone name and an offset be justified in order to
handle the very small number of time stamps which will fall within the
daylight savings transition hour for those locations which have daylight
savings? Keep[ing in mind that the complexity is less to do with the
time stamp format and more to do with using that information in any
meaningful sense. This, combined with the reduced readability of such
time stamps and increased possibility of user confusion leads me to
question if allowing time stamps with both offset and time zone together
in the one time stamp is worthwhile. 

Re: [POLL] Proposed syntax for timestamps with time zone info

[Stefan Nobis]

 writes:

> ...which stems from the fact that the very concept of "time zone" is
> somewhat ambiguous, too.

Yes - I think most of us here see that. Therefore I really appreciate
the flexible timestamp format Ihor suggested.

> If you really want to have fun with this (and this thread hasn't
> satisfied your thirst ;-) see [1].

Thanks for the link. Very interesting details that I didn't know
about yet.

-- 
Until the next mail...,
Stefan.

Re: [POLL] Proposed syntax for timestamps with time zone info

[Ihor Radchenko]

Stefan Nobis  writes:

> Ihor Radchenko  writes:
>
>> [2023-03-29 02:30 @Europe/Berlin] is special.
>
> I think you mean [2023-10-29 02:30 @Europe/Berlin]. :)

Yes, indeed. Thanks for pointing it out!

Re: [POLL] Proposed syntax for timestamps with time zone info

[Stefan Nobis]

Ihor Radchenko  writes:

> [2023-03-29 02:30 @Europe/Berlin] is special.

I think you mean [2023-10-29 02:30 @Europe/Berlin]. :)

-- 
Until the next mail...,
Stefan.

Re: [POLL] Proposed syntax for timestamps with time zone info

[tomas]

On Wed, Feb 01, 2023 at 10:06:15AM +0100, Stefan Nobis wrote:
>  writes:
> 
> > 2023-03-23 02:30 @Europe/Berlin refers to /two/ points in time, thus
> > it /is/ ambiguous.
> 
> As far as I understand the definitions, the point in time "2023-03-23
> 02:30 @Europe/Berlin" is clearly defined as 2023-03-23 02:30 UTC+0100.
> 
> A bit more problematic would be "2023-03-26 02:30 @Europe/Berlin".

[...]

This has already been cleared in the thread: I got the year the
wrong way around.

> The real problem would be e.g. "2023-10-29 02:30 @Europe/Berlin". This
> point in time really exist twice, there is 02A:30 (02:30 UTC+0200) and
> 02B:30 (02:30 UTC+0100) in this night of switching back from DST to
> normal time!
> 
> So, in general, only using the time zone name may indeed lead to
> ambiguous interpretations of timestamps.

...which stems from the fact that the very concept of "time zone"
is somewhat ambiguous, too. Some time zone designations carry the
fact of whether they are supposed to be summer times or not with
them (as with CET/CEST), some not (as above). The time zone database
is only known for a limited time into future and may change with
political vagaries. Yadda, yadda.

If you really want to have fun with this (and this thread hasn't
satisfied your thirst ;-) see [1].

Cheers

[1] https://en.wikipedia.org/wiki/British_Summer_Time#Early_history
-- 
t


signature.asc
Description: PGP signature

Re: [POLL] Proposed syntax for timestamps with time zone info

[Stefan Nobis]

 writes:

> 2023-03-23 02:30 @Europe/Berlin refers to /two/ points in time, thus
> it /is/ ambiguous.

As far as I understand the definitions, the point in time "2023-03-23
02:30 @Europe/Berlin" is clearly defined as 2023-03-23 02:30 UTC+0100.

A bit more problematic would be "2023-03-26 02:30 @Europe/Berlin".
Strictly speaking, this point in time does not exist, because in the
night from 2023-03-25 to 2023-03-26 the clock will jump from 02:00
directly to 03:00 in the time zone Europe/Berlin. Therefore the
/interpretation/ of this timestamp is ambiguous.

The real problem would be e.g. "2023-10-29 02:30 @Europe/Berlin". This
point in time really exist twice, there is 02A:30 (02:30 UTC+0200) and
02B:30 (02:30 UTC+0100) in this night of switching back from DST to
normal time!

So, in general, only using the time zone name may indeed lead to
ambiguous interpretations of timestamps.

-- 
Until the next mail...,
Stefan.

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

[Ihor Radchenko]

Tim Cross  writes:

>> Either I understand you wrong, or you don't know what you are
>> talking about. 2023-03-23 02:30 @Europe/Berlin refers to /two/
>> points in time, thus it /is/ ambiguous. If you use disambiguating
>> "time zones" (MEZ vs MESZ in this case) you can resolve that.
>
> I think the confusion relates to context interpretation. If you see
> @Europe/Berlin in isolation, then it is ambiguous as it can refer to two
> different time zone definitions (standard v daylight savings).  However,
> if you consider it in conjunction with a date and time, as in 2023-03-23
> 02:30 @Europe/Berlin, then it isn't ambiguous - in that case, it really
> just says 'Lookup the time zone offset in the databse for Berlin as of
> that date and time.
>...
> Personally, I cannot see the use case of including both a fully
> qualitifed time zone (as in @Europe/Berlin) and an offset...

Let me try to explain better. Just specifying time zone is ambiguous
once per year during daylight transition.

[2023-03-29 02:30 @Europe/Berlin] is special.

According to https://www.timeanddate.com/time/zone/germany/berlin,
2023-03-29 is the time when the clock is shifted one hour back due to
the daylight saving transition. The wall time goes like

2023-03-29 02:30 -> ... -> 02:59 -> (CEST -> CET) 02:00 -> ... -> 2:30 (again!)

So, [2023-03-29 02:30 @Europe/Berlin] can mean two time points: before
and after the transition. Specifying explicit offset is thus necessary
in this specific scenario to disambiguate the timestamp:

[2023-03-29 02:30+2 @Europe/Berlin] (before transition)
[2023-03-29 02:30+1 @Europe/Berlin] (after transition)

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

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

[Jean Louis]

* Tim Cross  [2023-02-01 11:10]:
> I think the confusion relates to context interpretation. If you see
> @Europe/Berlin in isolation, then it is ambiguous as it can refer to
> two different time zone definitions (standard v daylight savings).

Of course, without the time stamp, the time zone alone cannot give
time.

> However, if you consider it in conjunction with a date and time, as
> in 2023-03-23 02:30 @Europe/Berlin, then it isn't ambiguous - in
> that case, it really just says 'Lookup the time zone offset in the
> databse for Berlin as of that date and time.

Exactly that.

> Now that could change - for example, the German government might
> make a temporary or permanent change that would change the offset
> from UTC for that date+time the day after I look at it (or export
> it).

It cannot change in past.

It will not change drastically or capriciously as Germany aligns with
other countries and ISO standard.

It is more likely that ISO non-members deviate from international
coordination of time related definitions:

ISO - Members:
https://www.iso.org/members.html

> Personally, I cannot see the use case of including both a fully
> qualitifed time zone (as in @Europe/Berlin) and an offset, but I
> also don't know all possible use cases - there could well be use
> cases where you want/need to record both the location time zone as
> well as the offset at the point when you recorded the timestamp.

Time Zones vs. Offsets – What's the Difference? Which Is Best?:
https://spin.atomicobject.com/2016/07/06/time-zones-offsets/

Quoting:


- Given a time zone and a UTC time, you can know the offset—and
  therefore the local time.

- Given a local time and an offset, you can know UTC time, but you do
  not know which time zone you’re in (because multiple timezones have
  the same offset).

- Given UTC and an offset, you can know the local time.

- Given a time zone and an offset, you don’t know much. 

- That’s why a calendar systems work with time zones, offsets, and
  UTC; 

- we need the offset to go from local time to UTC, and we need the
  time zone to go from UTC to local time.

-- 
Jean

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

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

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

[Jean Louis]

* to...@tuxteam.de  [2023-02-01 10:20]:
> Either I understand you wrong, or you don't know what you are
> talking about. 2023-03-23 02:30 @Europe/Berlin refers to /two/
> points in time, thus it /is/ ambiguous. If you use disambiguating
> "time zones" (MEZ vs MESZ in this case) you can resolve that.

Help me with understanding. Which two points in time does it refer?

When I use time zone Europe/Berlin, it only refers to following time
stamp:

2023-03-23 02:30:00+01

What is the other point in time that it refers to?

-- 
Jean

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

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

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

[Jean Louis]

* Thomas S. Dye  [2023-02-01 10:05]:
> Aloha Jean Louis,
> 
> Jean Louis  writes:
> 
> > * Ihor Radchenko  [2023-01-31 16:46]:
> > > Specifying just @Europe/Berlin is ambiguous around the daylight
> > > savings
> > > transition.
> > 
> > Sorry, I cannot see practical example why is it ambiguous. Unless
> > programmer does not take all information in account, it is not
> > ambigous. People on this planet agree on time zones in advance, so
> > there are few changes that people cannot plan in advance.
> 
> Please see Russia's plan to put Eastern Ukraine on Moscow time, and then
> come back and argue that people on this planet agree on time zones in
> advance:
> 
> https://www.nytimes.com/2023/01/27/world/europe/russia-ukraine-time-zones.html?smid=url-share

Then I have not expressed me enough specific. 

When I said "people", I definitely did not think "all people", as
that is impossible.

The agreement of "people" is summarized by standards of International
Organization for Standardization (ISO) with ISO 8601 that includes
specification and representation of time and time zones.

There may be many disagreements on the world in relation to time
zones, and if they do not align it for international standard, we do
not need to consider it. 

While it may be specific disalignment problem in some country, their
citizen must anyway resort to ISO again for calculations.

We all rely on ISO standard. Not capricious decisions going behind that.

-- 
Jean

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

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

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

[Tim Cross]

 writes:

> [[PGP Signed Part:Undecided]]
> On Tue, Jan 31, 2023 at 11:12:00PM +0300, Jean Louis wrote:
>> * Ihor Radchenko  [2023-01-31 16:46]:
>> > Specifying just @Europe/Berlin is ambiguous around the daylight savings
>> > transition.
>> 
>> Sorry, I cannot see practical example why is it ambiguous. Unless
>> programmer does not take all information in account, it is not
>> ambigous. People on this planet agree on time zones in advance, so
>> there are few changes that people cannot plan in advance.
>
> (snipped the huge CC list)
>
> Either I understand you wrong, or you don't know what you are
> talking about. 2023-03-23 02:30 @Europe/Berlin refers to /two/
> points in time, thus it /is/ ambiguous. If you use disambiguating
> "time zones" (MEZ vs MESZ in this case) you can resolve that.
>

I think the confusion relates to context interpretation. If you see
@Europe/Berlin in isolation, then it is ambiguous as it can refer to two
different time zone definitions (standard v daylight savings).  However,
if you consider it in conjunction with a date and time, as in 2023-03-23
02:30 @Europe/Berlin, then it isn't ambiguous - in that case, it really
just says 'Lookup the time zone offset in the databse for Berlin as of
that date and time. Now that could change - for example, the German
government might make a temporary or permanent change that would change
the offset from UTC for that date+time the day after I look at it (or
export it). 

Personally, I cannot see the use case of including both a fully
qualitifed time zone (as in @Europe/Berlin) and an offset, but I also
don't know all possible use cases - there could well be use cases where
you want/need to record both the location time zone as well as the
offset at the point when you recorded the timestamp. This is why I'm in
favor of a flexible and extensible syntax and strongly disagree with any
argument which says we don't need UTC or we don't need abbreviated TZ
names or .