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
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:
>
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 [...]
>
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
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
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
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
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:
>>> [
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.
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
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
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
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:
>
>>
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
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
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
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
* 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.
>
>
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
* 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
* 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
* 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
* 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
* 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
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
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
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
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
"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
--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.
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
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
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
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
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
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
[ 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
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
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_
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.
>
>
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
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
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
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
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,
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
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
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.
>
[ 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 -
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
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
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)
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
>
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!
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.
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
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
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
* 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
* 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
* 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.
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
62 matches
Mail list logo
