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

Max Nikulin writes: > On 15/01/2023 03:30, Tim Cross wrote: >> The UTC time stays the same, but the >> meeting time for me changes twice per year (moving forward/backward an >> hour). > > Meeting time remains the same expressed as local time (15:00), but alternates > between > 04:00 and 05:00

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

On Sun, Jan 15, 2023 at 06:43:19AM +1100, Tim Cross wrote: > Max Nikulin writes: > > > On 14/01/2023 20:08, Jean Louis wrote: > >> * Max Nikulin [2023-01-14 10:14]: > >>> Let's assume <2023-01-15 Sun 09:00 +1> > >>> > >>> It may be suitable for timestamps in the past, but future is more tricky.

Re: Bug: Inconsistent behaviour about inline markup

Hi Christian, > Please point to the correct documentation if there is one. See . All the best, Timothy -- Timothy (‘tecosaur’/‘TEC’), Org mode contributor. Learn more about Org mode at . Support Org development

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

On 14/01/2023 18:42, Ihor Radchenko wrote: <2023-01-14 Sat 18:22@Asia/Singapore> (SGD and similar abbreviations are often ambiguous) Such format is ambiguous for timezones with DST around backward time jump. Before/after time transition should be specified in addition, e.g. by combining

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

On 14/01/2023 22:05, Ihor Radchenko wrote: writes: Now there's still enough work for the applications to do: presentation, parsing, disambiguation, if necessary asking the user for help. Someone mentioned PostgreSQL -- this is a nice example of what can be done beyond the (comparatively!)

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

On 14/01/2023 22:05, Ihor Radchenko wrote: In addition, we may provide some mechanism to set the time zone for: 1. Individual files 2. For all files, including possible time zone transitions over time. What I mean by (2) is when the user travels from, say, Australia to USA, it could be possible

Re: Thoughts on this ob language generator

Thanks a lot Tim, I really appreciate you responding (as you said, it can be discouraging to not get any response) For the record, I just tried this simple example and it works #+begin_src emacs-lisp :results silent (create-ob-npx :name "ob-nbb" :language "clojurescript"

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

On 15/01/2023 03:30, Tim Cross wrote: The UTC time stays the same, but the meeting time for me changes twice per year (moving forward/backward an hour). Meeting time remains the same expressed as local time (15:00), but alternates between 04:00 and 05:00 UTC. So repeating schedule can not be

Re: Thoughts on this ob language generator

George Mauer writes: > I had a need the other day to execute some typescript in an org document. Now > I know that there's an > ob-typescript package but that doesn't quite work the way I want and expects > typescript to be installed > globally (which runs into a variety of versioning issues).

Re: [FR] Allow end date and max repeat count for timestamps with repeaters (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

On 1/14/23, Ihor Radchenko wrote: > However, I do not see why we cannot implement them within the current > Org timestamp syntax: my concern would be personal code and 3rd-party packages, which might have their own peculiar parsing. that parsing might even be of non-org files with org syntax

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

Ihor Radchenko writes: > to...@tuxteam.de writes: > >>> ... Having an >>> ability to specify time zones manually will already cater needs for a >>> number of users. >> >> Definitely. But the time stamp (with time zone) in itself doesn't >> carry enough context to actually decide that. It's even

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

to...@tuxteam.de writes: > [[PGP Signed Part:Undecided]] > On Sat, Jan 14, 2023 at 03:05:22PM +, Ihor Radchenko wrote: >> writes: >> >> > Now there's still enough work for the applications to do: presentation, >> > parsing, disambiguation, if necessary asking the user for help. Someone >> >

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

Max Nikulin writes: > On 14/01/2023 20:50, Tim Cross wrote: >> I"m sorry, but I don't follow. The UTC time is the only time whihc is >> not affected by daylight savings transitions, so is the only stable >> metric. All the others are relative to that time but can change based on >> things like

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

Max Nikulin writes: > On 14/01/2023 20:08, Jean Louis wrote: >> * Max Nikulin [2023-01-14 10:14]: >>> Let's assume <2023-01-15 Sun 09:00 +1> >>> >>> It may be suitable for timestamps in the past, but future is more tricky. >>> There is no problem if you are going to watch Lunar eclipse. However

Bug: Inconsistent behaviour about inline markup

Hello, I'm not sure if this is a bug or intended by design. Please point to the correct documentation if there is one. I'm also not sure if Orgmode is the related component here or if there is any other? What I describe is in the context of auto-formating markup in orgmode. When you type

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

On Sat, Jan 14, 2023 at 05:06:31PM +, Ihor Radchenko wrote: > to...@tuxteam.de writes: > > >> ... Having an > >> ability to specify time zones manually will already cater needs for a > >> number of users. > > > > Definitely. But the time stamp (with time zone) in itself doesn't > > carry

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

to...@tuxteam.de writes: >> ... Having an >> ability to specify time zones manually will already cater needs for a >> number of users. > > Definitely. But the time stamp (with time zone) in itself doesn't > carry enough context to actually decide that. It's even not that > easy to wrap one's head

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

On 14/01/2023 20:08, Jean Louis wrote: * Max Nikulin [2023-01-14 10:14]: Let's assume <2023-01-15 Sun 09:00 +1> It may be suitable for timestamps in the past, but future is more tricky. There is no problem if you are going to watch Lunar eclipse. However if your plan is to attend a local event

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

On 14/01/2023 20:50, Tim Cross wrote: I"m sorry, but I don't follow. The UTC time is the only time whihc is not affected by daylight savings transitions, so is the only stable metric. All the others are relative to that time but can change based on things like changes in DST transition

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

On Sat, Jan 14, 2023 at 03:05:22PM +, Ihor Radchenko wrote: > writes: > > > Now there's still enough work for the applications to do: presentation, > > parsing, disambiguation, if necessary asking the user for help. Someone > > mentioned PostgreSQL -- this is a nice example of what can be

Re: Possible error in manual

J G writes: > 2.2.3 Catching invisible edits > > Sometimes you may inadvertently edit an invisible part of the buffer and be > confused on what has been edited and how to undo the mistake. > Setting org-fold-catch-invisible-edits to non-nil helps preventing this. See > the docstring of

Re: [PATCH] lisp/ob-octave.el, was [PATCH] rfc: using ert-deftest with side-effects

On 14/01/2023 20:04, Leo Butler wrote: line 0: warning: iconv failed to convert degree sign This warning makes no sense to me. Just a guess. Some code creates a plot with the "°" character, but worker locale is ASCII, not UTF-8 (en_US.UTF-8, C.UTF-8, etc.)

cgit and merge commit

On 14/01/2023 17:35, Ihor Radchenko wrote: Max Nikulin writes: So Matt did not squashed commits before committing to the main branch and detailed commit messages are preserved. That is why I do not consider cgit render as a strong enough reason for reverting. Should we then report a bug to

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

writes: > Now there's still enough work for the applications to do: presentation, > parsing, disambiguation, if necessary asking the user for help. Someone > mentioned PostgreSQL -- this is a nice example of what can be done beyond > the (comparatively!) boring details of time zone management

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

On Sat, Jan 14, 2023 at 02:38:05PM +, Ihor Radchenko wrote: [...] > > Or to put it in another way - currently, it is well understood where org > > timestamps fall down. However, once you add TZ and provide the > > expectation TZ data will be respected correctly, all bets are off. > > I

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

Tim Cross writes: >> This is not the problem we need to worry about. We can use whatever >> Emacs provides and rely on future improvements in Emacs where things are >> deficient. We should not aim for 100% accurate time zone support. Just >> good enough. It's not Org's job to implement the gory

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

Ihor Radchenko writes: > Tim Cross writes: > >> Daryl mentioned elsewhere in this thread that how hard this feature >> would be depends largely on the available libraries for elisp with >> respect to working with date/time values. Sadly, the available elisp >> libraries are inadequate in this

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

Max Nikulin writes: > On 14/01/2023 16:32, Tim Cross wrote: >> If org was to add TZ capabilities to timestamps, the underlying format >> would have to be UTC. > ... >> can change based on various criteria, including political whims >> (e.g. Australia eastern DST transition date was changed in

Pixel table alignment (was: [BUG] [ox-odt] ODT export Chinese/Han script inserts unexpected spaces in each consecutive line)

Cantoraz Chou writes: > With `pangu-spacing' package installed, set > `pangu-spacing-real-insert-separtor' to nil. A well-chosen monospaced > font are also used to ensure one CJK character is alignment with two > Alphanumerics. > > Think of following table: > > #+begin_src org > | Alphanumeric |

Timestamp format during export (was: [BUG] [ox-odt] ODT export Chinese/Han script inserts unexpected spaces in each consecutive line)

Cantoraz Chou writes: > In my experience, most of weird troubles are related to the (1) language > habit or (2) mixed use of Ideographs and alphanumeric. > > Eg. for (1). > > The Org export option keyword `DATE' use a fixed built-in timestamp > format which is rarely used in Chinese. It's

Re: [BUG] [ox-odt] ODT export Chinese/Han script inserts unexpected spaces in each consecutive line

Ihor Radchenko wrote: > Fixed, on bugfix. > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=cd967ce00 Thanks for your fix! - [OT] > P.S. As Chinese user, do you have other gotchas Org might need to > address? In my experience, most of weird troubles are related to the (1)

Re: Index not translated to pt-BR

Rafael Bento writes: > Hello, good morning! > > The table of Contents doesn't translate when exporting to utf-8 or ODT > with pt_BR as the value for the LANGUAGE keyword. I believe the line > below (6180, ox.el file): > > ("pt_BR" :html "ndice" :utf8 "Índice" :ascii "Indice") > > should be

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

Tim Cross writes: > Consider for example an agenda file where the TODO items have been added > while I am here in Australia (currently +11:00 w/ DST). Tomorrow I fly > to Europe where I will be working for the next 6 weeks. I need all my > TODOs with active timestamps to be updated to Berlin's

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

Ihor Radchenko writes: > Tim Cross writes: > >> I agree this would be a great feature to add. However, after having >> looked at it in some detail, I realise that not only is it not a trivial >> task, it is actually a very large and complex task and will require >> extensive work which will

Re: [PATCH] lisp/ob-octave.el, was [PATCH] rfc: using ert-deftest with side-effects

Leo Butler writes: >> The gnuplot graphics toolkit is not actively maintained and has a number >> of limitations that are unlikely to be fixed. Communication with gnuplot >> uses a one-directional pipe and limited information is passed back to the >> Octave interpreter so most changes made

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

* Max Nikulin [2023-01-14 10:14]: > Let's assume <2023-01-15 Sun 09:00 +1> > > It may be suitable for timestamps in the past, but future is more tricky. > There is no problem if you are going to watch Lunar eclipse. However if your > plan is to attend a local event there is a chance that you

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

* Daryl Manning [2023-01-14 09:30]: > To Jean Louis' point: using timestamps without timezones is a don't in much > of computing these days and perhaps hearkens back to the simpler age emacs > and org originated in. =] (kidding!). I see it that way, yes. Isn't it so. -- Jean Take action in

Re: [PATCH] lisp/ob-octave.el, was [PATCH] rfc: using ert-deftest with side-effects

On Fri, Jan 13 2023, Ihor Radchenko wrote: > Ihor Radchenko writes: > >> So, the test failure is real. > > The error buffer contents when the test fails is the following: > > warning: using the gnuplot graphics toolkit is discouraged > > The gnuplot graphics toolkit is not actively maintained

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

Russell Adams writes: >> Calc's time zone calculations are hard coded. We should rather rely on >> OS library primitives. They have better chances to get updated as >> politics changes in some countries. > > I had no idea. > > Wouldn't Emacs be updated eventually if timezones change? Doesn't it

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

On Sat, Jan 14, 2023 at 12:19:17PM +, Ihor Radchenko wrote: > Russell Adams writes: > > > Doesn't Emacs Calc have timezone conversion functions natively? > > Calc's time zone calculations are hard coded. We should rather rely on > OS library primitives. They have better chances to get updated

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

Russell Adams writes: > Doesn't Emacs Calc have timezone conversion functions natively? Calc's time zone calculations are hard coded. We should rather rely on OS library primitives. They have better chances to get updated as politics changes in some countries. -- Ihor Radchenko // yantar92,

[FR] Allow end date and max repeat count for timestamps with repeaters (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

Russell Adams writes: >> > I know they include better repeat information. Maybe we can >> > build on that? >> >> Is it really better? Apart from sexps, diaries support cron-like >> repeaters, but more limited. > > They have repeat with a end date or max iterations. Good point. These two

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

On Sat, Jan 14, 2023 at 11:35:00AM +, Ihor Radchenko wrote: > Russell Adams writes: > > > Can't Org also ready diary formatted timestamps? > > We support diary sexps. > > > Do those include timezones? > > No, AFAIK. sexps may (they are just Elisp functions, anyway). > > > I know they include

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

On 14/01/2023 16:32, Tim Cross wrote: If org was to add TZ capabilities to timestamps, the underlying format would have to be UTC. ... can change based on various criteria, including political whims (e.g. Australia eastern DST transition date was changed in 2000 because Sydney hosted the

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

Daryl Manning writes: > Can you give an example like below? What does it look like? > And say, with a recurring data like once a week and a warning of 5d early? > > I believe /most/ people would be looking for something grokable like: > <2023-01-14 Sat 18:22 SGT> or say > <2023-01-14 Sat 18:22

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

Russell Adams writes: > Can't Org also ready diary formatted timestamps? We support diary sexps. > Do those include timezones? No, AFAIK. sexps may (they are just Elisp functions, anyway). > I know they include better repeat information. Maybe we can > build on that? Is it really better?

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

Tim Cross writes: > Daryl mentioned elsewhere in this thread that how hard this feature > would be depends largely on the available libraries for elisp with > respect to working with date/time values. Sadly, the available elisp > libraries are inadequate in this area. While many of the functions

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

Hey Ihor, Sorry, I had a little trouble understanding the way you have the syntax written in that timestamps doc. Can you give an example like below? What does it look like? And say, with a recurring data like once a week and a warning of 5d early? I believe /most/ people would be looking for

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

Tim Cross writes: > I agree this would be a great feature to add. However, after having > looked at it in some detail, I realise that not only is it not a trivial > task, it is actually a very large and complex task and will require > extensive work which will almost certainly result in breakage

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

On Sat, Jan 14, 2023 at 08:32:30PM +1100, Tim Cross wrote: > If org was to add TZ capabilities to timestamps, the underlying format > would have to be UTC. My previous post where I suggested there was two > 'layers', the underlying storage layer (used for calculations like > duration or comparison

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

Max Nikulin writes: > On 14/01/2023 02:06, Jean Louis wrote: >> This is good for review as related to PostgreSQL database: > > I agree that PostgreSQL is an example of good implementation of time-related > calculations. > >>

Re: ob-shell intentions and paperwork (was Bash results broken?)

Max Nikulin writes: > And changes made by this commit are included into diff shown for the > merge commit 4f319088ba by cgit. E.g. gitk for local repository does not > show any changes for the merge commit. > > So Matt did not squashed commits before committing to the main branch > and