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

[Charles Philip Chan]

> "Ihor" == Ihor Radchenko  writes:

Hi  Ihor,

Ihor> This is bad news.

Ihor> 17.16.2 The ‘capture’ protocol section of Org manual recommends

Ihor> To use this feature, add a bookmark with an arbitrary name, e.g.,
Ihor> ‘Org: capture’, and enter this as ‘Location’:

Ihor> javascript:location.href='org-protocol://capture?' + new
Ihor> URLSearchParams({ template: 'x', url: window.location.href, title:
Ihor> document.title, body: window.getSelection()});

Ihor> With the annoying Firefox dialogue, things get very annoying.  Even
Ihor> though I do understand the motivation of devs.  But they broke
Ihor> bookmarklets :'(

I have been using this org-protocol addon[1] for more than a year and it has
been rock solid for me. According to the author, bookmarklets are getting less
and less useful because CSP (Content Security Policy) blocking them on many
sites (for example Github)[2].

Charles

Footnotes:
[1] 
https://addons.mozilla.org/en-US/firefox/addon/org-protocol/?utm_source=addons.mozilla.org&utm_medium=referral&utm_content=search

[2]  https://github.com/vifon/org-protocol-for-firefox




signature.asc
Description: PGP signature

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

[Max Nikulin]

On 31/01/2023 14:04, Jean Louis wrote:

I have given facts, and references with the sole intention to help in
understanding so that Org programmers do not start relying on UTC
offset alone, as that is not how other programs work.


From my point of view at the beginning you were promoting that Org must 
use purely UTC timestamps just because PostgreSQL recommends timestamptz 
type. Now you are insisting that every timestamp must have timezone with 
rules describing DST and other transitions. In both cases you are doing 
it with excessive passion. Currently you are arguing with people who 
have already agreed that location-based timezones are important, e.g. 
Tim and Thomas. I am in doubts if it is helpful to someone.


P.S.
- There are cases when local time + time zone must be stored.
- There are cases when UTC or UTC + fixed offset must be stored.
- There are cases when UTC or UTC + fixed offset is enough, however time 
zone can be added.

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

[Ihor Radchenko]

Karl Voit  writes:

>> Ok. What about
>>
>> (let ((context (epg-make-context nil t t)))
>>   (epg-decrypt-string context (epg-encrypt-string context "test" 
>> (epg-list-keys context org-crypt-key
>>
>
> It asks me for the passphrase of the orgmode key (the correct one)
> and prints out "test".

We just followed what org-crypt does... And you see no error.
I have no more ideas how to investigate the original failure without a
reproducer.

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

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

[Ihor Radchenko]

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

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

Emacs29: sqllite support for orgroam on Windows?

[c . buhtz]

Making OrgRoam usable on Windows is quit hard because of the SQLlite 
component.

I don't want to go into details. It is possible but not easy.

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?


Kind
Christian

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

> just a thought/reminder.  there are "semantics" and "encoding".  a spec
> like ISO-8601 specifies both.  the important thing for org-mode is to
> use an encoding that
>
> 1. is easily parsable/understandable by the mere mortal
>
> 2. allows expression of all the semantics of the underlying spec/specs
>(be that ISO-8601, this new IETF spec, the Library of Congress spec,
>etc.)
>
> 3. and, importantly, is designed to *try* to follow updates to the
>underlying spec/specs (which will inevitably happen)

I agree with these three points.

Following the previous discussion and the various links provided, I have
reviewed the main discussed timestamp standards and would like to
propose the new Org timestamp syntax that will allow specifying time
zone information.

I will not follow the standards fully because the available standards
are not designed to be easily understood by humans. I will also omit
the ideas from the standards that are unrelated to time stamps (but
still outline them below, and keep them in mind for
forward-compatibility). I will, however, try to use the syntax close to
the standards where possible.

1. https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/
   proposal is extending ISO8601/RFC3339 with time zone information. In
   addition to UTC offset defined in ISO8601, it allows specifying the
   time zone identifier and auxiliary information.

   Examples:

   2022-07-08T02:14:07+02:00[Europe/Paris]
   (both offset, and time zone are specified)
   Note that we cannot use "[]" symbols because they are incompatible
   with current timestamp syntax that must not contain closing "]>"
   inside the timestamp.

   1996-12-19T16:39:57-08:00[America/Los_Angeles][u-ca=hebrew]
   (preferred calendar is specified in addition to time zone)
   Note: calendar spec is out of scope of time zone discussion - if we
   decide to add it in future, we can simply add new parts to
   timestamps, just like repeater interval and warning period.

   Further, the draft proposes an idea, which have also been discussed
   in this thread: making use of redundant UTC offset + time zone
   information to detect possible unexpected changes in time zone rules:

   2022-07-08T00:14:07+00:00[!Europe/London]
   ("!" identifies that +00:00 offset, if not consistent with
   Europe/London at the timestamp time, must be signalled to user or
   generally not ignored)

2. https://www.loc.gov/standards/datetime/ does not contain any new
   ideas relevant to time zones, although it has many other ideas wrt
   approximate/incomplete timestamps. I will outline them later, but
   they do not directly affect the proposed new Org timestamp syntax.
   
|---|
| The proposed new timestamp syntax |
|---|

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 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 @!Euro

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

[Daryl Manning]

Dense poll. I had a question about this format which is what I assume I'd
be using if using org-mode with this on a day-to-day basis if given the
choice.
(from 2. Timestamp with time zone specifier)

 2022-11-12 10:00 @EST+5  # TZ syntax

Normally, when I'm communicating things like standard and daylight savings
time via mail or verbally, I'd use this if writing emails or what have you.
ie. 2023-01-31 10:00 EST (or EDT)

Is the +5 offset in the example from the poll here to disambiguate the EST
from other ESTs (I realize from
https://en.wikipedia.org/wiki/List_of_time_zone_abbreviations these are not
always unique) or is the idea that someone would have to specify the
timezone offset each entry rather than saying EST or EDT?

thanks,
Daryl.




On Tue, Jan 31, 2023 at 6:48 PM Ihor Radchenko  wrote:

> Greg Minshall  writes:
>
> > just a thought/reminder.  there are "semantics" and "encoding".  a spec
> > like ISO-8601 specifies both.  the important thing for org-mode is to
> > use an encoding that
> >
> > 1. is easily parsable/understandable by the mere mortal
> >
> > 2. allows expression of all the semantics of the underlying spec/specs
> >(be that ISO-8601, this new IETF spec, the Library of Congress spec,
> >etc.)
> >
> > 3. and, importantly, is designed to *try* to follow updates to the
> >underlying spec/specs (which will inevitably happen)
>
> I agree with these three points.
>
> Following the previous discussion and the various links provided, I have
> reviewed the main discussed timestamp standards and would like to
> propose the new Org timestamp syntax that will allow specifying time
> zone information.
>
> I will not follow the standards fully because the available standards
> are not designed to be easily understood by humans. I will also omit
> the ideas from the standards that are unrelated to time stamps (but
> still outline them below, and keep them in mind for
> forward-compatibility). I will, however, try to use the syntax close to
> the standards where possible.
>
> 1. https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/
>proposal is extending ISO8601/RFC3339 with time zone information. In
>addition to UTC offset defined in ISO8601, it allows specifying the
>time zone identifier and auxiliary information.
>
>Examples:
>
>2022-07-08T02:14:07+02:00[Europe/Paris]
>(both offset, and time zone are specified)
>Note that we cannot use "[]" symbols because they are incompatible
>with current timestamp syntax that must not contain closing "]>"
>inside the timestamp.
>
>1996-12-19T16:39:57-08:00[America/Los_Angeles][u-ca=hebrew]
>(preferred calendar is specified in addition to time zone)
>Note: calendar spec is out of scope of time zone discussion - if we
>decide to add it in future, we can simply add new parts to
>timestamps, just like repeater interval and warning period.
>
>Further, the draft proposes an idea, which have also been discussed
>in this thread: making use of redundant UTC offset + time zone
>information to detect possible unexpected changes in time zone rules:
>
>2022-07-08T00:14:07+00:00[!Europe/London]
>("!" identifies that +00:00 offset, if not consistent with
>Europe/London at the timestamp time, must be signalled to user or
>generally not ignored)
>
> 2. https://www.loc.gov/standards/datetime/ does not contain any new
>ideas relevant to time zones, although it has many other ideas wrt
>approximate/incomplete timestamps. I will outline them later, but
>they do not directly affect the proposed new Org timestamp syntax.
>
> |---|
> | The proposed new timestamp syntax |
> |---|
>
> 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 tim

lesser-than as open paren

[Andreas Röhler]

Hi,

when taking notes in plain org-mode, run into trouble for instance with 
this scala-snippet:


  def scalaFiles =
    for {
    file <- filesHere
    if file.getName.endsWith(".scala")
  } yield file

With cursor on lesser-than sign, get a type-mismatch.

The culprit resides in org.el:

  (modify-syntax-entry ?< "(>")
  (modify-syntax-entry ?> ")<")

Maybe use this modification only when a special case requires it?


Thanks,

Andreas

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

[Max Nikulin]

On 31/01/2023 15:11, Charles Philip Chan wrote:

I have been using this org-protocol addon[1] for more than a year and it has
been rock solid for me. According to the author, bookmarklets are getting less
and less useful because CSP (Content Security Policy) blocking them on many
sites (for example Github)[2].


Thank you for the reminder. Using an add-on to extract metadata, I have 
never tried if bookmarklets are affected by CSP.


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



[2]  https://github.com/vifon/org-protocol-for-firefox


This extension uses browser.tabs.update method to launch external 
protocol handler. Perhaps in some cases it is better than assigning 
window.location.href from a content script like in older


https://github.com/sprig/org-capture-extension/

however I have seen issues with both methods. It is a grey zone and it 
is hard to predict which one will be more reliable in next versions of 
browsers. Actually some people believe that even mailto: was a hack, it 
is not a resource identifier as it can be expected from URI


https://github.com/w3c/web-share/blob/main/docs/explainer.md#why-not-make-a-share-uri-scheme-like-mailto-instead-of-a-javascript-api
https://github.com/chromium/ballista/issues/21
Expand on why registerProtocolHandler and registerProtocolHandler are a hack

The question I have to ask myself, though, is if we were designing
mailto: today, would we do it the same way? And I think the answer is
"no, mailto: is and always was a hack, because we didn't have JavaScript".


So we should not expect that org-protocol: will work reliably in 
browsers. Position of a firefox developers concerning external handlers 
for custom protocols:


Bug 1744018 - External scheme handler launched by an add-on can be 
blocked despite user action

https://bugzilla.mozilla.org/show_bug.cgi?id=1744018#c16

Pairing the extension with a native application and use the
nativeMessaging API seems a better fit for the use case you are describing

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:

>>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]
>
> I have already explained today that above calculation cannot be
> unambigous. Please verify my references and practical examples. When
> user thinks that span is X hours, the real span could be X-1 or X+1

This has been discussed in the previous emails.
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. In contrast, writing [2022-10-29
2:15-5:15 @Europe/Berlin] is ambiguous as it may imply both
2:15CEST-5:15CET (4 hours) or 2:15CET-5:15CET (3 hours).

Specifying just @Europe/Berlin is ambiguous around the daylight savings
transition. To resolve the ambiguous, we should either introduce DST
flag or simply allow specifying the UTC offset directly. Since DST is
not guaranteed to be +-1 hour (it may be more, up to 1 full day), DST
flag is more problematic than UTC offset.

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

Daryl Manning  writes:

> Dense poll. I had a question about this format which is what I assume I'd
> be using if using org-mode with this on a day-to-day basis if given the
> choice.
> (from 2. Timestamp with time zone specifier)
>
>  2022-11-12 10:00 @EST+5  # TZ syntax
>
> Normally, when I'm communicating things like standard and daylight savings
> time via mail or verbally, I'd use this if writing emails or what have you.
> ie. 2023-01-31 10:00 EST (or EDT)

AFAIK, 2023-01-31 10:00 @EST will work.
We need "@" because otherwise we may run into trouble if we need to
add more information fields to timestamp syntax.

> Is the +5 offset in the example from the poll here to disambiguate the EST
> from other ESTs (I realize from
> https://en.wikipedia.org/wiki/List_of_time_zone_abbreviations these are not
> always unique) or is the idea that someone would have to specify the
> timezone offset each entry rather than saying EST or EDT?

The aim is to pass the @ transparently to glibc. Anything you can
put into TZ environment variable should do. AFAIK, "EST" is allowed via
TZDB (see https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)

Note that we will eventually adapt the interactive commands to simplify
entering the time zones. Adding time zone completion is one of the
obvious useful features.

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

[Jean Louis]

* Max Nikulin  [2023-01-31 11:16]:
> On 31/01/2023 14:04, Jean Louis wrote:
> > I have given facts, and references with the sole intention to help in
> > understanding so that Org programmers do not start relying on UTC
> > offset alone, as that is not how other programs work.
> 
> From my point of view at the beginning you were promoting that Org must use
> purely UTC timestamps just because PostgreSQL recommends timestamptz
> type.

I am not promoter of "UTC timestamps", you have mixed me maybe with
some other person. Last time you misquoted me.

That PostgreSQL recommends time stamp with time zone is only in so far
related to Org as for program design decisions.

There is plethore of other programs using time, just look in any
calendar and underground.

I do not promote anything, I give suggestions to developers to make
decisions that will not impact people. 

My proposal is not that what you describe, but I will repeat it here
for clarity:

- Timestamps may be left how they are now with small addition

- Time stamp could get time zone (I never said UTC, neither UTC
  offset) -- I would myself never suggest to people to place
  timestamps in time zone, but to simply use the local system time
  zone. Case to use time stamps with time zone would be then when such
  time stamp is isolated in the whole Org file and as such, the task
  has to be sent to other people, shared, or published. This is finely
  grained.

- Heading could have time zone property, then all time stamps in that
  heading would easily be calculated for sharing purposes.

- If not heading, then user could set up file #+TIMEZONE property, if
  such is or should be different to system time zone

- Without any settings in Org, Org may use system time zone to
  calculate future time difference.

And I said that is in Emacs Lisp similar to logical OR:

timestamp-time-zone OR heading-time-zone OR file-time-zone OR system-time-ZONE

So please do not misinterpret and reiterate what I never proposed or suggested.

> Now you are insisting that every timestamp must have timezone with
> rules describing DST and other transitions.

Absolutely not, I cannot find myself in your description.

> In both cases you are doing it with excessive passion.

You are free to describe it as you wish. And?

> Currently you are arguing with people who have already agreed that
> location-based timezones are important, e.g. Tim and Thomas. I am in
> doubts if it is helpful to someone.

I do not argue with people nothing as because of their name or
position, as people are not object of discussion.

Neither my last writing was related to "location based time zone" but
to UTC offset.

All my writing is directed to Org developers to get access to
references before making any decisions how to calculate times.

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

[Ihor Radchenko]

[ adding Org ML back to CC ]

Daryl Manning  writes:

> OMG it would be amazing if (simply) going <2023-01-31 10:00 @EST> or when
> daylight savings time hits <2023-01-31 10:00 @EDT> worked.
>
> would be *super* happy with that as a user who spends a lot of time dealing
> with other time zones. =]

You can play around with the following

(format-time-string "%Y-%m-%d %a %H:%M" (current-time) "EST")
(format-time-string "%Y-%m-%d %a %H:%M" (current-time) "Asia/Singapore")

(format-time-string "%Y-%m-%d %a %H:%M" (current-time) "EDT") ; => not correct
(format-time-string "%Y-%m-%d %a %H:%M" (current-time) "EDT5") ;=> correct, 
because daylight saving is not active now

"EDT" is not supported (at least, on my system). AFAIK, the correct TZ
format is
(format-time-string "%Y-%m-%d %a %H:%M" (current-time) "EST5EDT")

(Side note: we should probably detect unsupported time zone names and
issue a warning)

Note that Emacs provides `timezone-zone-to-minute', but, as you see in
the docstring below, EST must not be used because it may be ambiguous
outside USA. (That's why POSIX TZ format demands the offset part in
addition to time zone abbreviation)

`current-time-zone' is also not helpful here:
(current-time-zone nil "EDT") ;=> (0 "EDT") == UTC??
(current-time-zone nil "EST") ;=> (-18000 "EST")
(current-time-zone nil "EST5EDT") ;=> (-18000 "EST")

(defvar timezone-world-timezones
  '(("PST" .  -800)
("PDT" .  -700)
("MST" .  -700)
("MDT" .  -600)
("CST" .  -600)
("CDT" .  -500)
("EST" .  -500)
("EDT" .  -400)
("AST" .  -400) ;by 
("NST" .  -330) ;by 
("UT"  .  +000)
("GMT" .  +000)
("BST" .  +100)
("MET" .  +100)
("EET" .  +200)
("JST" .  +900)
("GMT+1"  .  +100) ("GMT+2"  .  +200) ("GMT+3"  .  +300)
("GMT+4"  .  +400) ("GMT+5"  .  +500) ("GMT+6"  .  +600)
("GMT+7"  .  +700) ("GMT+8"  .  +800) ("GMT+9"  .  +900)
("GMT+10" . +1000) ("GMT+11" . +1100) ("GMT+12" . +1200) ("GMT+13" . +1300)
("GMT-1"  .  -100) ("GMT-2"  .  -200) ("GMT-3"  .  -300)
("GMT-4"  .  -400) ("GMT-5"  .  -500) ("GMT-6"  .  -600)
("GMT-7"  .  -700) ("GMT-8"  .  -800) ("GMT-9"  .  -900)
("GMT-10" . -1000) ("GMT-11" . -1100) ("GMT-12" . -1200))
  "Time differentials of timezone from GMT in +-HHMM form.
This list is obsolescent, and is present only for backwards compatibility,
because time zone names are ambiguous in practice.
Use `current-time-zone' instead.")

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

* Ihor Radchenko  [2023-01-31 14:48]:
> I will not follow the standards fully because the available standards
> are not designed to be easily understood by humans.

Very right, thank you.

> 1. https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/
>2022-07-08T02:14:07+02:00[Europe/Paris]

The above looks nice, though not as clear from human view point as
compared to standard Org time stamps, which are very readable.

> 2. https://www.loc.gov/standards/datetime/ does not contain any new

I would disregard above, as that is US government, not international
document. Reason why they use UTC offset alone is that they decided
they do not need more than that.

Org is international and should not be bound to US only.

>-MM-DD [optional day name] HH:MM[^ \]>]*?[+-−]HH[MM]?
>-MM-DD [optional day name] HH:MM[^ \]>]*?Z[ \]>]

>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

It looks nice, but I have demonstrated that calculations by using UTC
offset can't be accurate.

Please disprove and rectify me, by using practical examples, you could
disprove my practical example offered previously.

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

I have already explained today that above calculation cannot be
unambigous. Please verify my references and practical examples. When
user thinks that span is X hours, the real span could be X-1 or X+1

> 3. (1) and (2) can be combined
> 
>2022-11-12 12:00+08 @Asia/Singapore

That is how it should be, the UTC offset combined, with the time zone. 

And I suggest avoiding such timestamps by default, rather using time
stamps as usual, and having heading time zone property, file time zone
property and Org using system time zone in absence of any of them.

Providing practical example or functions on how to calculate it should
give better feeling which way will be better.

This is very simple timestamp, readable, with weekday:

<2023-01-31 Tue 16:13>

I propose to remain that way, how it is, with addition:

1. If user wish, could add time zone, including UTC offset. Adding
   only UTC offset makes no sense, and adding time zone without UTC
   offset will cause difficulties in future. Thus:

<2023-01-31 Tue 16:13+03 @Africa/Nairobi>

2. Otherwise heading could have time stamp when necessary to
   distinguish it from other headings:

* My heading
  :PROPERTIES:
  :TIMEZONE: +03 @Africa/Nairobi
  :END:

Then this time stamp <2023-01-31 Tue 16:13> would 

3. Otherwise file could have time stamp, if necessary to distinguish
   it from other files on the same system:

#+TIMEZONE: +03 @Africa/Nairobi

4. Otherwise system time zone

That way you only upgrade time stamps with UTC offset and time zone,
only when necessary, leaving everything else how it is, with addition
of better calculations and related functions.

All of the timestamps, including those simple existing one like
<2023-01-31 Tue 16:21> in Org can be made unambigous in their
representation or exchange by using UTC offset, plus the time zone, by
using those properties.

And very good reference on that link:
https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/

Although serialization with offset time zones is supported in this
document for backwards compatibility with java.time.ZonedDateTime
[JAVAZDT], use of offset time zones is strongly discouraged.  In
particular, programs MUST NOT copy the UTC offset from a timestamp
into an offset time zone in order to satisfy another program which
requires a time zone annotation in its input.  Doing this will
improperly assert that the UTC offset of timestamps in that location
will never change, which can result in incorrect calculations in
programs that add, subtract, or otherwise derive new timestamps from
the one provided.  For example, 2020-01- 01T00:00+01:00[Europe/Paris]
will let programs add six months to the timestamp while adjusting for
Summer Time (Daylight Saving Time).  But the same calculation applied
to 2020-01-01T00:00+01:00[+01:00] will produce an incorrect result
that will be off by one hour in the timezone Europe/Paris.


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

[Julien Cubizolles]

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.

diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index ceb1fc833..81be37448 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -453,6 +453,15 @@ https://orgmode.org/worg/code/scripts/x11idle.c";
   :package-version '(Org . "9.7")
   :type 'string)
 
+(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.
+Case of a pgtk Emacs instance."
+  :group 'org-clock
+  :package-version '(Org . "9.7")
+  :type 'string)
+
 (defcustom org-clock-goto-before-context 2
   "Number of lines of context to display before currently clocked-in entry.
 This applies when using `org-clock-goto'."
@@ -1199,6 +1208,17 @@ If `only-dangling-p' is non-nil, only ask to resolve dangling
   "Return the current Mac idle time in seconds."
   (string-to-number (shell-command-to-string "ioreg -c IOHIDSystem | perl -ane 'if (/Idle/) {$idle=(pop @F)/10; print $idle; last}'")))
 
+(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
+
 (defvar org-x11idle-exists-p
   ;; Check that x11idle exists.  But don't do that on DOS/Windows,
   ;; since the command definitely does NOT exist there, and invoking
@@ -1214,6 +1234,10 @@ If `only-dangling-p' is non-nil, only ask to resolve dangling
   "Return the current X11 idle time in seconds."
   (/ (string-to-number (shell-command-to-string org-clock-x11idle-program-name)) 1000))
 
+(defun org-pgtk-idle-seconds ()
+  "Return the current X11 idle time in seconds."
+  (/ (string-to-number (shell-command-to-string org-clock-pgtkidle-program-name)) 1000))
+
 (defun org-user-idle-seconds ()
   "Return the number of seconds the user has been idle for.
 This routine returns a floating point number."
@@ -1222,6 +1246,8 @@ This routine returns a floating point number."
 (org-mac-idle-seconds))
((and (eq window-system 'x) org-x11idle-exists-p)
 (org-x11-idle-seconds))
+   ((and (eq window-system 'pgtk) org-pgtkidle-exists-p)
+(org-pgtk-idle-seconds))
(t
 (org-emacs-idle-seconds
 

> Please, make sure that the pgtk option works on Wayland as well (or not,
> but we will then need to wait until someone tests the patch on Wayland).

It's working in Wayland, with a pgtk build.

-- 
Julien Cubizolles

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

[Fraga, Eric]

Ihor,

given a choice, I would vote for the second (using @) but would be happy
with either.  My needs are simple, however, so whatever is easiest to
implement would be fine with me.  I'm not bothered, for instance, about
the daylight savings transition as I'm usually in bed... ;-)

But I definitely would love to have time zones of some sort as I'm
frequently travelling between different zones and having meetings across
zones.

Thank you in advance!

eric

-- 
: Eric S Fraga, with org release_9.6.1-199-g7ad779 in Emacs 30.0.50

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

[Ihor Radchenko]

"Fraga, Eric"  writes:

> given a choice, I would vote for the second (using @) but would be happy
> with either.  My needs are simple, however, so whatever is easiest to
> implement would be fine with me.  I'm not bothered, for instance, about
> the daylight savings transition as I'm usually in bed... ;-)

To clarify, it is not first or second. (1), (2), and (3) are all the
options to be incorporated. It is not a choice. Users just might need
different combinations depending on specific needs.

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

Re: lesser-than as open paren

[Fraga, Eric]

On Tuesday, 31 Jan 2023 at 13:26, Andreas Röhler wrote:
> when taking notes in plain org-mode, run into trouble for instance with
> this scala-snippet:

[...]

> With cursor on lesser-than sign, get a type-mismatch.

This is why I have

(modify-syntax-entry ?< ".")
(modify-syntax-entry ?> ".")

in my org mode settings.

-- 
: Eric S Fraga, with org release_9.6.1-199-g7ad779 in Emacs 30.0.50

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

[Fraga, Eric]

Hi Ihor,

On Tuesday, 31 Jan 2023 at 18:13, Ihor Radchenko wrote:
> To clarify, it is not first or second. (1), (2), and (3) are all the
> options to be incorporated. It is not a choice. Users just might need
> different combinations depending on specific needs.

Ahhh, my bad.  Okay, works for me then!  More than I need (at the
moment, of course).

Thanks again,
eric

-- 
: Eric S Fraga, with org release_9.6.1-199-g7ad779 in Emacs 30.0.50

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

[Greg Minshall]

Ihor,

thanks for all the information.

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

cheers, Greg

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

[Bruno Barbier]

Max Nikulin  writes:

> Bruno, as a cb_thunderbird user, would you like to share your experience 
> and to expand
>
> https://orgmode.org/worg/org-faq.html#orgc6f8478
> 10.8. Can I create links to Thunderbirds emails?
>
> by adding a brief description of this add-on?

Hi Max,

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

I just added a section about cb_thunderlink. I'm not sure how to
organize things with the other information about Thunderbird. And, I'm
not sure about how to properly format names, etc. for the wiki.

See the attached patch.

What do you think ?

Bruno


>From 4beb7ee307544be868a0d058763aa61558f0701b Mon Sep 17 00:00:00 2001
From: Bruno BARBIER 
Date: Tue, 31 Jan 2023 20:33:22 +0100
Subject: [PATCH] org-faq: links with thunderbird: Add cb_thunderlink

---
 org-faq.org | 48 
 1 file changed, 48 insertions(+)

diff --git a/org-faq.org b/org-faq.org
index 0410d368..1aaa3f2a 100644
--- a/org-faq.org
+++ b/org-faq.org
@@ -2051,6 +2051,54 @@ so the following recipe is obsolete:
 Notice that this link uses Message-ID to reference a particular
 message as well.
 
+*** Using the =cb_thunderlink= add-on
+The add-on =cb_thunderlink= for Thunderbird allows:
+   1. to generate direct links from emails inside Thunderbird,
+   2. and to reopen the emails following these links.
+
+ Installation
+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.
+
+Once everything is installed, follow the steps below to make org
+compatible links in Thunderbird, and to teach org how to open these
+links.
+
+ Copying links from Thunderbird
+In Thunderbird, open the =Options= page for the =cb_thunderlink= add-on
+and add a new link type named =org= in the =Configurable links= section.
+
+#+begin_example
+[[mid:$msgid$][$author_name$: $subject$ ($date_iso$)]]
+#+end_example
+
+To get an org link for a given email, open the contextual menu, click
+the =cb_thunderlink= entry and choose the entry named =org=. This
+copies, into the clipboard, a link to this email; you can then paste
+it in Emacs.
+
+
+ Opening the emails from Emacs
+To teach org how to open these links, add the following lines in
+your configuration file, configuring the variable
+=cbthunderlink-app= to match your system.
+
+#+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*"
+ cbthunderlink-app
+ (concat "thunderlink://messageid=" message-id)))
+(org-add-link-type "mid" 'org-email-open)
+#+end_src
+
+
 * Plain Lists
   :PROPERTIES:
   :CUSTOM_ID: Plain-Lists
-- 
2.39.1

[BUG] hang in org-element-cache-map triggered by org-icalendar-export-to-ics

[Hanno Perrey]

Dear all,

I have noticed a problem in =org-element-cache-map= that can be
triggered under specific circumstances through
=org-icalendar-export-to-ics= where the execution of the latter would
simply hang apparently indefinitely. This happens if

- =org-icalendar-store-UID= set to ='t=

- =org-icalendar-use-scheduled= set to = '(event-if-not-todo))=

- the buffer is narrowed to a tree with multiple sub-headings, each with
  a scheduled time

If =org-element-use-cache= is set to =nil= then the export succeeds
almost instantly.

I attach an org file with detailed steps for reproducing this on the
latest =main= using =make repro= on Emacs 28.1.90. I am a little stuck
debugging this further as I am not at all familiar with the inner
workings of Org's element cache. Any help or suggestions would be much
appreciated as I am using just this particular configuration quite
frequently when capturing new events and importing them into my calendar.


Thanks and cheers,

Hanno

--
Hanno Perrey
https://hoowl.se


test_subtree_ical_export.org
Description: Lotus Organizer

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:

> Greg Minshall  writes:
>
>> just a thought/reminder.  there are "semantics" and "encoding".  a spec
>> like ISO-8601 specifies both.  the important thing for org-mode is to
>> use an encoding that
>>
>> 1. is easily parsable/understandable by the mere mortal
>>
>> 2. allows expression of all the semantics of the underlying spec/specs
>>(be that ISO-8601, this new IETF spec, the Library of Congress spec,
>>etc.)
>>
>> 3. and, importantly, is designed to *try* to follow updates to the
>>underlying spec/specs (which will inevitably happen)
>
> I agree with these three points.
>
> Following the previous discussion and the various links provided, I have
> reviewed the main discussed timestamp standards and would like to
> propose the new Org timestamp syntax that will allow specifying time
> zone information.
>
> I will not follow the standards fully because the available standards
> are not designed to be easily understood by humans. I will also omit
> the ideas from the standards that are unrelated to time stamps (but
> still outline them below, and keep them in mind for
> forward-compatibility). I will, however, try to use the syntax close to
> the standards where possible.
>
> 1. https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/
>proposal is extending ISO8601/RFC3339 with time zone information. In
>addition to UTC offset defined in ISO8601, it allows specifying the
>time zone identifier and auxiliary information.
>
>Examples:
>
>2022-07-08T02:14:07+02:00[Europe/Paris]
>(both offset, and time zone are specified)
>Note that we cannot use "[]" symbols because they are incompatible
>with current timestamp syntax that must not contain closing "]>"
>inside the timestamp.
>
>1996-12-19T16:39:57-08:00[America/Los_Angeles][u-ca=hebrew]
>(preferred calendar is specified in addition to time zone)
>Note: calendar spec is out of scope of time zone discussion - if we
>decide to add it in future, we can simply add new parts to
>timestamps, just like repeater interval and warning period.
>
>Further, the draft proposes an idea, which have also been discussed
>in this thread: making use of redundant UTC offset + time zone
>information to detect possible unexpected changes in time zone rules:
>
>2022-07-08T00:14:07+00:00[!Europe/London]
>("!" identifies that +00:00 offset, if not consistent with
>Europe/London at the timestamp time, must be signalled to user or
>generally not ignored)
>
> 2. https://www.loc.gov/standards/datetime/ does not contain any new
>ideas relevant to time zones, although it has many other ideas wrt
>approximate/incomplete timestamps. I will outline them later, but
>they do not directly affect the proposed new Org timestamp syntax.
>
> |---|
> | The proposed new timestamp syntax |
> |---|
>
> 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 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
>

Re: lesser-than as open paren

[Tim Cross]

Andreas Röhler  writes:

> Hi,
>
> when taking notes in plain org-mode, run into trouble for instance with this
> scala-snippet:
>
>   def scalaFiles =
>     for {
>     file <- filesHere
>     if file.getName.endsWith(".scala")
>   } yield file
>
> With cursor on lesser-than sign, get a type-mismatch.
>
> The culprit resides in org.el:
>
>   (modify-syntax-entry ?< "(>")
>   (modify-syntax-entry ?> ")<")
>
> Maybe use this modification only when a special case requires it?
>

when you say "when taking notes in plain org-mode" do you mean the above
code snippet is just in your org file and not inside either a source or
example block?

If so, I think that would be expected behaviour. Code snippets really
need to be either in an example block or preferably a source code block.

Re: [BUG] hang in org-element-cache-map triggered by org-icalendar-export-to-ics

[Ihor Radchenko]

Hanno Perrey  writes:

> I have noticed a problem in =org-element-cache-map= that can be
> triggered under specific circumstances through
> =org-icalendar-export-to-ics= where the execution of the latter would
> simply hang apparently indefinitely. This happens if
>
> ...
> I attach an org file with detailed steps for reproducing this on the
> latest =main= using =make repro= on Emacs 28.1.90.

Thanks for reporting and for the clear reproducer!
Fixed, on bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=32b64607a

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

[Samuel Wales]

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.  i cannot take a close
look.

just a few tiny nits tht shouldn't realy affect much or quite possibly
reflect ignorance:

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.

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?


On 1/31/23, Ihor Radchenko  wrote:
> Greg Minshall  writes:
>
>> just a thought/reminder.  there are "semantics" and "encoding".  a spec
>> like ISO-8601 specifies both.  the important thing for org-mode is to
>> use an encoding that
>>
>> 1. is easily parsable/understandable by the mere mortal
>>
>> 2. allows expression of all the semantics of the underlying spec/specs
>>(be that ISO-8601, this new IETF spec, the Library of Congress spec,
>>etc.)
>>
>> 3. and, importantly, is designed to *try* to follow updates to the
>>underlying spec/specs (which will inevitably happen)
>
> I agree with these three points.
>
> Following the previous discussion and the various links provided, I have
> reviewed the main discussed timestamp standards and would like to
> propose the new Org timestamp syntax that will allow specifying time
> zone information.
>
> I will not follow the standards fully because the available standards
> are not designed to be easily understood by humans. I will also omit
> the ideas from the standards that are unrelated to time stamps (but
> still outline them below, and keep them in mind for
> forward-compatibility). I will, however, try to use the syntax close to
> the standards where possible.
>
> 1. https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/
>proposal is extending ISO8601/RFC3339 with time zone information. In
>addition to UTC offset defined in ISO8601, it allows specifying the
>time zone identifier and auxiliary information.
>
>Examples:
>
>2022-07-08T02:14:07+02:00[Europe/Paris]
>(both offset, and time zone are specified)
>Note that we cannot use "[]" symbols because they are incompatible
>with current timestamp syntax that must not contain closing "]>"
>inside the timestamp.
>
>1996-12-19T16:39:57-08:00[America/Los_Angeles][u-ca=hebrew]
>(preferred calendar is specified in addition to time zone)
>Note: calendar spec is out of scope of time zone discussion - if we
>decide to add it in future, we can simply add new parts to
>timestamps, just like repeater interval and warning period.
>
>Further, the draft proposes an idea, which have also been discussed
>in this thread: making use of redundant UTC offset + time zone
>information to detect possible unexpected changes in time zone rules:
>
>2022-07-08T00:14:07+00:00[!Europe/London]
>("!" identifies that +00:00 offset, if not consistent with
>Europe/London at the timestamp time, must be signalled to user or
>generally not ignored)
>
> 2. https://www.loc.gov/standards/datetime/ does not contain any new
>ideas relevant to time zones, although it has many other ideas wrt
>approximate/incomplete timestamps. I will outline them later, but
>they do not directly affect the proposed new Org timestamp syntax.
>
> |---|
> | The proposed new timestamp syntax |
> |---|
>
> 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

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-01-31 16:46]:
> >>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]
> >
> > I have already explained today that above calculation cannot be
> > unambigous. Please verify my references and practical examples. When
> > user thinks that span is X hours, the real span could be X-1 or X+1
> 
> This has been discussed in the previous emails.
> 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 seems you have different personal purposes for time representation
in Org.

How about making a list, why at all are you doing it? Is it for
scientific experiment that you run in your place 3 hours? Or for
people travelling or exchanging times.

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

Why not simply give up on setting up times correctly?

> In contrast, writing [2022-10-29 2:15-5:15 @Europe/Berlin] is
> ambiguous as it may imply both 2:15CEST-5:15CET (4 hours) or
> 2:15CET-5:15CET (3 hours).

Why don't you make the experiment and show how it is ambiguous?

Where is the error in this comparison of Europe/Berlin time and CET
time?

Is daylight savings change what you expect? I am not sure and I am
asking you about this.

Here is practical example, is there anything wrong?

How is it ambigious?

 2022-10-29 02:15:00+02 | 2022-10-29 01:15:00
 2022-10-29 02:20:00+02 | 2022-10-29 01:20:00
 2022-10-29 02:25:00+02 | 2022-10-29 01:25:00
 2022-10-29 02:30:00+02 | 2022-10-29 01:30:00
 2022-10-29 02:35:00+02 | 2022-10-29 01:35:00
 2022-10-29 02:40:00+02 | 2022-10-29 01:40:00
 2022-10-29 02:45:00+02 | 2022-10-29 01:45:00
 2022-10-29 02:50:00+02 | 2022-10-29 01:50:00
 2022-10-29 02:55:00+02 | 2022-10-29 01:55:00
 2022-10-29 03:00:00+02 | 2022-10-29 02:00:00
 2022-10-29 03:05:00+02 | 2022-10-29 02:05:00
 2022-10-29 03:10:00+02 | 2022-10-29 02:10:00
 2022-10-29 03:15:00+02 | 2022-10-29 02:15:00
 2022-10-29 03:20:00+02 | 2022-10-29 02:20:00
 2022-10-29 03:25:00+02 | 2022-10-29 02:25:00
 2022-10-29 03:30:00+02 | 2022-10-29 02:30:00
 2022-10-29 03:35:00+02 | 2022-10-29 02:35:00
 2022-10-29 03:40:00+02 | 2022-10-29 02:40:00
 2022-10-29 03:45:00+02 | 2022-10-29 02:45:00
 2022-10-29 03:50:00+02 | 2022-10-29 02:50:00
 2022-10-29 03:55:00+02 | 2022-10-29 02:55:00
 2022-10-29 04:00:00+02 | 2022-10-29 03:00:00
 2022-10-29 04:05:00+02 | 2022-10-29 03:05:00
 2022-10-29 04:10:00+02 | 2022-10-29 03:10:00
 2022-10-29 04:15:00+02 | 2022-10-29 03:15:00
 2022-10-29 04:20:00+02 | 2022-10-29 03:20:00
 2022-10-29 04:25:00+02 | 2022-10-29 03:25:00
 2022-10-29 04:30:00+02 | 2022-10-29 03:30:00
 2022-10-29 04:35:00+02 | 2022-10-29 03:35:00
 2022-10-29 04:40:00+02 | 2022-10-29 03:40:00
 2022-10-29 04:45:00+02 | 2022-10-29 03:45:00
 2022-10-29 04:50:00+02 | 2022-10-29 03:50:00
 2022-10-29 04:55:00+02 | 2022-10-29 03:55:00
 2022-10-29 05:00:00+02 | 2022-10-29 04:00:00
 2022-10-29 05:05:00+02 | 2022-10-29 04:05:00
 2022-10-29 05:10:00+02 | 2022-10-29 04:10:00
 2022-10-29 05:15:00+02 | 2022-10-29 04:15:00

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

Those changes are recorded in time zone databases.

Unless you consider programming without using time zone databases,
then I can surely understand that it will be ambiguous. 

> To resolve the ambiguous, we should either introduce DST flag

DST is property of time zone. You do not introduce it, you read it
from time zone database.

But maybe you wish to implement time zones in Org.

In that case I can only say "Good luck" to accuracy.

> or simply allow specifying the UTC offset directly.

UTC offset is not reliable, and is also derived from time zone
database. 

Try it out, make tests, create experiments, compare if that approach
will be usable, publish it and put in for testing.

> Since DST is not guaranteed to be +-1 hour (it may be more, up to 1
> full day), DST flag is more problematic than UTC offset.

Is not if you always pull the latest tz database. Political changes
are pretty careful to people and decisions are announced ahead of the
change.

So do you think that you cannot use tz database in Emacs Lisp?

Maybe it will be necessary to make new Lisp functions defined in C
language, accessing the time zone database.

But it is not for Org to implement new tz database in Emacs Lisp, that
will become unmaintainable work. But why not, if you wish, but
accuracy of time will be questionable.

Researching following pages will give you idea with what you are
trying to deal with on Org level:

How to Read the tz Database:
https://data.iana.org/time-zones/tz-how-to.html

List of tz database time zones - Wikipedia:
https://en.wikipedia.org/wiki/List_of_tz_database_time_zones

tz database - Wikipedia:
https://en.wikipedia.org/wiki/Tz_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)

[Thomas S. Dye]

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

All the best,
Tom
--
Thomas S. Dye
https://tsdye.online/tsdye

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

[tomas]

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.

Cheers
-- 
t


signature.asc
Description: PGP signature