Re: [BUG] Typo in docs (creating timestamps) [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.4/lisp/org/)]

emacs-orgm...@city17.xyz writes: > I am reading > https://orgmode.org/manual/Creating-Timestamps.html > > Quote: >> When called with a prefix argument, use the alternative format which >> contains date and time. The default time can be rounded to multiples >> of 5 minutes. See the option org-times

[BUG] Typo in docs (creating timestamps) [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.4/lisp/org/)]

Hi, I am reading https://orgmode.org/manual/Creating-Timestamps.html Quote: > When called with a prefix argument, use the alternative format which > contains date and time. The default time can be rounded to multiples > of 5 minutes. See the option org-timestamp-rounding-minutes. The correct n

Re: [PATCH] Re: Better support optional weekday in Org mode timestamps

Jens Schmidt writes: > Please check the attached patch and let me know what you think. Applied, onto main. Thanks! https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=829b3556d7 -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at .

Re: [PATCH] Re: Better support optional weekday in Org mode timestamps

esist to add more general test coverage for `org-timestamp-change'. Basically to tweak timestamps at every item position up and down, both with and w/o time and both with and w/o weekdays. Please check the attached patch and let me know what you think. Thanks. From 33b25f91a50101f67e8a998c370

Re: [PATCH] Re: Better support optional weekday in Org mode timestamps

Jens Schmidt writes: > [ Readding tomás since this thread got more high-level again ... ] > > On 2025-04-20 13:27, Ihor Radchenko wrote: > >> Looks reasonable. > > Thanks. More or less by chance I let Org's ERT tests run with > `org-timestamp-formats' set to `("%Y-%m-%d" . "%Y-%m-%d %H:%M")'. >

Re: [PATCH] Re: Better support optional weekday in Org mode timestamps

eekday name "%a" is considered semi-optional in these formats, ;; see https://list.orgmode.org/87fricxatw.fsf@localhost/. It is ;; "optional" because the `org-timestamp-*' functions work alright on ;; weekday-less timestamps in paragraphs when one omits the "%a". Bu

Re: Seconds in timestamps (was: time formats in org-timestamp-formats)

Ihor Radchenko 2025.04.14 01:07 writes: > > Parsing these timestamps manually isn’t a big deal, but I’m > > curious — has there ever been discussion about extending this to a > > triplet structure (date, date+time, date+time+seconds) for more > > flexibility? > >

Seconds in timestamps (was: time formats in org-timestamp-formats)

kend, but I see that functions > like `org-format-timestamp` and `org-timestamp-to-time` only handle > minute precision. Org timestamp syntax does not support seconds. See https://orgmode.org/worg/org-syntax.html#Timestamps > Since timestamps are such a fundamental feature, changing the

Re: Optional weekday in Org mode timestamps

Jens Schmidt writes: >> FYI, weekday is optional. It also adapts to the language settings. > > What exactly do you mean by "optional" here? It means that you can type in [2025-04-13] or [2025-04-13 8:24] and they will be valid timestamps recognized by Org mode. &

Re: Optional weekday in Org mode timestamps

supported to configure > `org-time-stamp-formats' to exclude the weekday? > > Handling overlayed timestamps always felt awkward to me, so I > tried tinkering with the latter, setting the variable to > > ("%Y-%m-%d" . "%Y-%m-%d %H:%M") > > At f

Re: Optional weekday in Org mode timestamps

Jens Schmidt writes: > Bump ... Your email is #24 in the #B-priority todo list :) -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at . Support Org development at , or support my work at

Re: Optional weekday in Org mode timestamps

d to configure > `org-time-stamp-formats' to exclude the weekday? > > Handling overlayed timestamps always felt awkward to me, so I > tried tinkering with the latter, setting the variable to > > ("%Y-%m-%d" . "%Y-%m-%d %H:%M") > > At first glance th

Optional weekday in Org mode timestamps

al" here? - Do you mean one can configure these overlays with `org-time-stamp-custom-formats' to exclude the weekday? - Or do you mean it is supported to configure `org-time-stamp-formats' to exclude the weekday? Handling overlayed timestamps always felt awkward to me, so I t

Re: [FR] [ox-html] export timestamps and durations via HTML5 element

Ihor Radchenko writes: > Lukas Epple writes: > ... >> If we are using HTML5 () to export, we are entitled to >> use the element [1] [2] which allows attaching a machine readable >> date, time, datetime or duration to text. Consequently, I propose that >> we change the rendering to something

Re: [PATCH] Enable makeindex with org-publish-use-timestamps-flag

On 2025-03-02, Ihor Radchenko wrote: > Jens Lechtenboerger writes: > The whole idea of transient cache does not work, I think. I reverted the > commit introducing it. > >> Subject: [PATCH] ox-publish.el: Enable makeindex with >> org-publish-use-timestamps-flag > &g

Re: [PATCH] Enable makeindex with org-publish-use-timestamps-flag (was: Bug? Option :makeindex does not work with org-publish-use-timestamps-flag)

Subject: [PATCH] ox-publish.el: Enable makeindex with > org-publish-use-timestamps-flag Applied, onto main, leaving only the new test and changing the commit message accordingly. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=15bc232209 -- Ihor Radchenko // yantar92

[PATCH] Enable makeindex with org-publish-use-timestamps-flag (was: Bug? Option :makeindex does not work with org-publish-use-timestamps-flag)

On 2025-02-23, Ihor Radchenko wrote: > Jens Lechtenboerger writes: > >> I publish with the default value for org-publish-use-timestamps-flag >> (set to t) and I use ":makeindex t" to create a keyword index. >> >> Then, files that are skipped during export

Re: Bug? Option :makeindex does not work with org-publish-use-timestamps-flag

Jens Lechtenboerger writes: > I publish with the default value for org-publish-use-timestamps-flag > (set to t) and I use ":makeindex t" to create a keyword index. > > Then, files that are skipped during export (as determined by > org-publish-needed-p) are not includ

Re: problem in sorting headings that start with timestamps

Uwe Brauer writes: >> You can sort alphabetically. But timestamp is considered a part of the >> headline. >> If you need something custom, provide custom key/comparison function for >> `org-sort-entries'. > > So you mean I should write a new sort function myself and use advice to > «connect» it

Re: problem in sorting headings that start with timestamps

> Uwe Brauer via "General discussions about Org-mode." > writes: > You can sort alphabetically. But timestamp is considered a part of the > headline. > If you need something custom, provide custom key/comparison function for > `org-sort-entries'. So you mean I should write a new sort function

Bug? Option :makeindex does not work with org-publish-use-timestamps-flag

Hi there, I publish with the default value for org-publish-use-timestamps-flag (set to t) and I use ":makeindex t" to create a keyword index. Then, files that are skipped during export (as determined by org-publish-needed-p) are not included in the index, which is surprising to me. I

Re: problem in sorting headings that start with timestamps

2025-02-08 09:51> All > --8<---cut here---end--->8--- > > If I run `org-sort` the header `*Test 1` than I can sort the lines only > with respect to the timestamps but *not* alphabetically. You can sort alphabetically. But timestamp is consi

Re: [FR] [ox-html] export timestamps and durations via HTML5 element

; > 1) In the example above, I've used an RFC3339 format string which > includes the local time zone. Since I've written that code, I've become > somewhat convinced that we should not include the timezone (at least not > by default). While it is nice that this would actu

problem in sorting headings that start with timestamps

If I run `org-sort` the header `*Test 1` than I can sort the lines only with respect to the timestamps but *not* alphabetically. On the other side --8<---cut here---start->8--- * Test 2 ** First <2025-02-08 09:46> ** All <2025-02

[FR] [ox-html] export timestamps and durations via HTML5 element

Hi everyone, * Feature Request currently HTML export will always render timestamps, both plain and from a clock/planning element to something like the following HTML: [2025-01-31 Fri] If we are using HTML5 () to export, we are entitled to use the element [1] [2] which allows

Re: [PATCH] Fix ox-icalendar export of diary timestamps

Ihor Radchenko writes: >> +To export active timestamps only without diary timestamps, users can >> +set ~org-export-with-timestamps~ and ~org-icalendar-with-timestamps~ >> +to ~active-exclude-diary~. > > Maybe you can emphasize more that "without diary timestamp&quo

Re: [PATCH] Fix ox-icalendar export of diary timestamps

Jack Kamm writes: > Unfortunately I found a case in the wild where this change caused a > temporary problem in org-caldav: > https://github.com/dengste/org-caldav/issues/315 > ... > I attach a patch to do this, by adding an option `active-exclude-diary' > for `org-icalend

Re: [PATCH] Fix ox-icalendar export of diary timestamps

ub.com/dengste/org-caldav/issues/315 I was able to fix the problem on org-caldav side, but it made me think that I should have added an option to keep the old behavior (export active timestamps excluding diary timestamps). I attach a patch to do this, by adding an option `active-exclude-diary

Re: Timestamps with a repeater and an end date

Emily Bourke writes: > I tried <2024-11-29 Fri 11:30-12:00 +2w>--<2025-01-10 Fri>, intending that to > mean “11:30-12:00, every two weeks, starting on 2024-11-29 and ending on > 2025-01-10”, but it seems org mode (org-version 9.7.11) interpreted this > instead as every day between those dates,

Re: Timestamps with a repeater and an end date

Response below/inline for email Emily Bourke wrote: > (original email sent 10 Jan 2025 at 09:25) > > Is there a way in org to have timestamps with both a repeater and an end date? No, there isn't. The recommended way to achieve what you want is to create an entry for the first

Timestamps with a repeater and an end date

Hi, Is there a way in org to have timestamps with both a repeater and an end date? I tried <2024-11-29 Fri 11:30-12:00 +2w>--<2025-01-10 Fri>, intending that to mean “11:30-12:00, every two weeks, starting on 2024-11-29 and ending on 2025-01-10”, but it seems org mode (org-ve

Re: please, report on current status of orgmode timestamps with timezone

On 2024-12-08 14:03, Ihor Radchenko wrote: pinmacs writes: See https://list.orgmode.org/87tu063ox2.fsf@localhost/ and the parent thread for details. I am repeatedly seeing this in different places: patches welcome for the new timezone orgmode timestamps. But it points to a thread with 366

Re: please, report on current status of orgmode timestamps with timezone

pinmacs writes: >> See https://list.orgmode.org/87tu063ox2.fsf@localhost/ and the parent >> thread for details. > > I am repeatedly seeing this in different places: patches welcome for the > new timezone orgmode timestamps. But it points to a thread with 366+ > me

Re: please, report on current status of orgmode timestamps with timezone

rks in development version? This is an idea we have discussed as a feature request and decided that we should eventually implement time zone support. We even decided on the approximate timestamp markup. However, there is no actual code in Org mode that implements timestamps with time zones. Patches w

Re: please, report on current status of orgmode timestamps with timezone

opment version? This is an idea we have discussed as a feature request and decided that we should eventually implement time zone support. We even decided on the approximate timestamp markup. However, there is no actual code in Org mode that implements timestamps with time zones. Patches welcome! S

Re: [PATCH] Fix ox-icalendar export of diary timestamps

Jack Kamm writes: > Ihor Radchenko writes: > >> I agree that it makes sense. >> However, it is technically a breaking change. >> May you please add a news entry as well? > > Thanks, I've updated the patch with a news entry now. Thanks! Applied, onto main. https://git.savannah.gnu.org/cgit/emacs

Re: [PATCH] Fix ox-icalendar export of diary timestamps

: Jack Kamm Date: Sat, 14 Sep 2024 22:48:44 -0700 Subject: [PATCH] ox-icalendar: Fix export of diary-style timestamps * lisp/ox-icalendar.el (org-icalendar-entry): Include timestamps of type diary when `:with-timestamps' is `active'. * lisp/ox.el (org-export--skip-p): Include timestamp

Re: [PATCH] Fix ox-icalendar export of diary timestamps

Jack Kamm writes: > ox-icalendar skips the following event with a diary timestamp during > export: > > * First Sunday of the month > <%%(diary-float t 0 1)> > > ox-icalendar actually has longstanding code to handle diary timestamps > [1], but that code path i

Re: Proposal: Change publication timestamps

Jens Lechtenboerger writes: >>> Ideally, it would be nice to have tests as well. >> >> I added test cases in the attached patch. > > I amended the commit message. I hope this to be ready for inclusion. Thanks! Applied, onto main, with a small amendment to the commit message. https://git.savanna

please, report on current status of orgmode timestamps with timezone

Hi, From #11 OrgMeetup content [1] I see that a date with timestamp and timezone is used:     <2024-09-11 Wed 19:00-21:00 @+03,Europe/Istanbul> With orgmode version 9.7.10: 1. If I try to to =C-c C-c= minibuffer says: "Not at a timestamp"; well, at least, does not try to remove the timezone

Re: Proposal: Change publication timestamps

from the final plist." +removed from the final plist. +Assign optional TIMESTAMP-FLAG to `org-publish-use-timestamps-flag'. +Optional PUBDIR specifies the `:publishing-directory', which +overrides the default of a randomly generated temporary directory. +If optional KEEP-PUBDIR-P is non-

[PATCH] Fix ox-icalendar export of diary timestamps

ox-icalendar skips the following event with a diary timestamp during export: * First Sunday of the month <%%(diary-float t 0 1)> ox-icalendar actually has longstanding code to handle diary timestamps [1], but that code path is not reached, in part because `org-export--skip-p' a

Re: Proposal: Change publication timestamps

On 2024-08-15, Ihor Radchenko wrote: > Jens Lechtenboerger writes: > >>> See "14.4 Triggering Publication" section of Org mode manual: >>> >>>Org uses timestamps to track when a file has changed. The above >>> functions normall

Re: Proposal: Change publication timestamps (was: Publishing cache)

Jens Lechtenboerger writes: >> See "14.4 Triggering Publication" section of Org mode manual: >> >>Org uses timestamps to track when a file has changed. The above >> functions normally only publish changed files. You can override this >> [

Proposal: Change publication timestamps (was: Publishing cache)

> > See "14.4 Triggering Publication" section of Org mode manual: > >Org uses timestamps to track when a file has changed. The above > functions normally only publish changed files. You can override this > [...] I propose to change caching and checking of timesta

Re: Inactive timestamps show up in agenda

include every timestamp in Agenda? I don't know. > > > > For reference, the entries look like this: > > * TEST > > <2024-04-04 Do> > > [2024-04-04 Do] > > > > shows as > > > > Thu 4 Apr 2024 > > TEST > > [ TEST >

Re: Inactive timestamps show up in agenda

tries look like this: > * TEST > <2024-04-04 Do> > [2024-04-04 Do] > > shows as > > Thu 4 Apr 2024 > TEST > [ TEST > > Yes, there's no closing square bracket. Check your customization for `org-agenda-include-inactive-timestamps'.

Inactive timestamps show up in agenda

Both <2024-04-04 Do> and [2024-04-04 Do] show up in Agenda-View. Google couldn't really help me on that, and I'm thinking maybe there's a flag I set to include every timestamp in Agenda? I don't know. For reference, the entries look like this: * TEST <2024-04-04 Do> [2024-04-04 Do] shows as Thu

Re: [BUG] with scheduled event containing inactive timestamps

2024 > 14:00.. >filename:15:15.. Scheduled: TODO Org-agenda Bug Report Timestamp: This is exactly the same problem you reported previously. Solved by setting `org-agenda-search-headline-for-time' to nil. That said, I think I know how to change agenda to

[BUG] with scheduled event containing inactive timestamps

Create an org file named filename.org containing the following text: * TODO Org-agenda Bug Report Timestamp: [2024-01-04 Thu 15:15] SCHEDULED: <2024-01-05 Fri> Expected result: Friday 5 January 2024 filename: Scheduled: TODO Org-agenda Bug Report Timestamp: [2024-01-04 Thu 15:15]

[PATCH] org.el: Respect org-extend-today-until in timestamps with ++

* org.el (org-auto-repeat-maybe): Changed org-auto-repeat-maybe, so that switching a repeating todo with a timestamp of the form <… ++…> respects `org-extend-today-until'. --- lisp/org.el | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index c037b

Re: [PATCH] org.el: Respect org-extend-today-until in timestamps with ++

0:00:00 2001 From: Valentin Herrmann Date: Sun, 13 Aug 2023 18:44:49 +0200 Subject: [PATCH] org.el: Respect org-extend-today-until in timestamps with ++ MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * org.el (org-auto-repeat-maybe): Changed org-auto-repe

Re: [PATCH] org.el: Respect org-extend-today-until in timestamps with ++

something like <2023-08-13 2:00 ++8h>? > `org-extend-today-until' should probably be ignored then. > Attachments: 0001-org.el-Respect-org-extend-today-until-in-timestamps-.patch 3.0 KB [Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.14.0] T

Re: [PATCH] org.el: Respect org-extend-today-until in timestamps with ++

Ihor Radchenko writes: > "Valentin G. J. Herrmann" writes: > >> Ok, so I guess I was stupid in another way :E >> I do in fact have the FSF copyright assignment (Though probably under an >> old email address: herr.valentin.m...@gmail.com). I still included the >> TINYCHANGE comment. The attache

Re: [PATCH] org.el: Respect org-extend-today-until in timestamps with ++

"Valentin G. J. Herrmann" writes: > I've now added org-test-with-time-locale so that the test results are > independent of the running machine. I think it's much cleaner this way > than using .* > ... > +(org-test-with-time-locale "en_US.UTF-8" > + (org-test-at-time "<2014-03-04 02:35>"

Re: [PATCH] org.el: Respect org-extend-today-until in timestamps with ++

"Valentin G. J. Herrmann" writes: > Ok, so I guess I was stupid in another way :E > I do in fact have the FSF copyright assignment (Though probably under an > old email address: herr.valentin.m...@gmail.com). I still included the > TINYCHANGE comment. The attached patch should finally work. Ba

Re: [PATCH] org.el: Respect org-extend-today-until in timestamps with ++

"Valentin G. J. Herrmann" via "General discussions about Org-mode." writes: > In the attachments is a better version with tests that also addresses > your latest critique. Thanks! > + (setq time > +(save-match-data > +

Re: [PATCH] org.el: Respect org-extend-today-until in timestamps with ++

something like <2023-08-13 2:00 ++8h>? > `org-extend-today-until' should probably be ignored then.From 317ab3f132825af9e5caaf0dc1812df545f0ad5f Mon Sep 17 00:00:00 2001 From: Valentin Herrmann Date: Sun, 13 Aug 2023 09:48:42 +0200 Subject: [PATCH] org.el: Respect org-extend-today-until i

Re: [PATCH] org.el: Respect org-extend-today-until in timestamps with ++

Ihor Radchenko writes: >> (while (or (= nshift 0) >> - (not (time-less-p nil time))) >> + (not (time-less-p nil (time-add >> time-to-extend time > > And this compares "now" with year 1970. Will always return

Re: [PATCH] org.el: Respect org-extend-today-until in timestamps with ++

Valentin Herrmann via "General discussions about Org-mode." writes: > * org.el (org-auto-repeat-maybe): Changed org-auto-repeat-maybe, so that > switching a repeating todo with a timestamp of the form <… ++…> respects > `org-extend-today-until'. Thanks, this would make sense. However, I have com

[PATCH] org.el: Respect org-extend-today-until in timestamps with ++

* org.el (org-auto-repeat-maybe): Changed org-auto-repeat-maybe, so that switching a repeating todo with a timestamp of the form <… ++…> respects `org-extend-today-until'. --- lisp/org.el | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index c037b

Re: [BUG] Linking SCHEDULED and DEADLINE repeating timestamps to avoid desynchronization

Thanks for confirming the issue. For the record, after doing some more research it looks like at least one other person came across this issue, and the workaround was using org-edna in place of the repeaters, which will push the timestamps together to the same date offset prior to the

[BUG] Linking SCHEDULED and DEADLINE repeating timestamps to avoid desynchronization

duled and deadlines, making sure that they shift by the same number of days in future, when their repeaters are the same. However, I do not think that it should be done for all other timestamps under heading. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at &l

Linking SCHEDULED and DEADLINE repeating timestamps to avoid desynchronization

Hi everyone, I just stumbled across a surprising behavior with combined SCHEDULED and DEADLINE timestamps that repeat. Here is the example org file contents: * TODO My late recurring todoSCHEDULED: <2023-04-12 Wed ++1w> DEADLINE: <2023-04-13 Thu ++1w> Right now it is Wednesday (2023

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

because offsets are saved despite missed IANA TZ ID. In respect to Org offsets and time zone identifiers are discussed in this thread in details. As a format for humans it should be more permissible and convenient for direct typing. There is no reason to insist on UTC where timestamps with fixed

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

Jean Louis writes: > Where you Ihor responded with this message: > https://lists.gnu.org/archive/html/emacs-orgmode/2023-02/msg00018.html > >> [2022-11-12 14:00 @UTC+2] >> [2022-11-12 14:00 @UTC-2:30] > >> are also fine within the proposed format. > > I am not sure what did you intend to show, di

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

Jean Louis writes: > Discussion started from something like this: > > 2022-11-12 12:00+02 @UTC > > and that is different case, where Ihor was suggesting that: 2022-11-12 > 12:00 is UTC time, not local time, where by +02 is offset (I say not > UTC offset) to be added or deducted on that time. No,

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

. Don't use any offsets with UTC time as not to confuse people. Use local time representation of UTC timestamps. For UTC timestamp there is no problem to be in future or in past. > These offsets are convenient to protect timestamp from regulatory > changes in time zones. UTC time is conve

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

gt; international standards. > > iCalendar proposes different way of representation of time in future,haw > that is, it could be UTC time in future, or it could be date, time and > time zone. Using UTC offset for future is redundant, as in present > time when you are writing future

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

* Ihor Radchenko [2023-02-15 18:17]: > Jean Louis writes: > > > That is not same case as Ihor, when he designated it as > > > > 2030-02-09 12:00 -0800 @UTC > > because there are no offsets @UTC time zone. > > I do not recall providing such example. May you point me to the message > where you s

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 [2023-02-14 19:50]: > > What Ihor proposed is time stamp like: > > > > 2023-02-14 Tue 12:00:00 +0800 @UTC > > > > Though I just say when we put "UTC" that means normally "UTC time > > zone" and such has no prefix that is positive or negative, can be > > zero. > > Sigh. UTC is

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

Jean Louis writes: > That is not same case as Ihor, when he designated it as > > 2030-02-09 12:00 -0800 @UTC > because there are no offsets @UTC time zone. I do not recall providing such example. May you point me to the message where you saw me writing -0800 @UTC? -- Ihor Radchenko // yantar9

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

On 14/02/2023 22:59, Jean Louis wrote: What Ihor proposed is time stamp like: 2023-02-14 Tue 12:00:00 +0800 @UTC I am not sure that combination of +0800 and UTC was intentional. The following is redundant, but there is nothing wrong while offset and time zone identifier are in agreement:

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

Jean Louis writes: * Max Nikulin [2023-02-14 14:45]: On 14/02/2023 16:45, to...@tuxteam.de wrote: > On Tue, Feb 14, 2023 at 10:41:38AM +0100, Heinz Tuechler > wrote: > > Jean Louis wrote/hat geschrieben on/am 14.02.2023 07:00: > > > Then just representation must be clear: @UTC is unclear

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

* Max Nikulin [2023-02-14 14:45]: > On 14/02/2023 16:45, to...@tuxteam.de wrote: > > On Tue, Feb 14, 2023 at 10:41:38AM +0100, Heinz Tuechler wrote: > > > Jean Louis wrote/hat geschrieben on/am 14.02.2023 07:00: > > > > Then just representation must be clear: @UTC is unclear in those > > > > cases

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

On Tue, Feb 14, 2023 at 10:41:38AM +0100, Heinz Tuechler wrote: > Jean Louis wrote/hat geschrieben on/am 14.02.2023 07:00: [...] > > Then just representation must be clear: @UTC is unclear in those > > cases, but @RELTOUTC would be clear. > > > > @RELTOUTC seems unfortunate, as it states only t

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

* Heinz Tuechler [2023-02-14 12:44]: > Jean Louis wrote/hat geschrieben on/am 14.02.2023 07:00: > > * to...@tuxteam.de [2023-02-12 16:50]: > > > On Sun, Feb 12, 2023 at 12:33:40PM +0300, Jean Louis wrote: > > > > * Ihor Radchenko [2023-02-10 13:48]: > > > > > Jean Louis writes: > > > > > > > >

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

On 14/02/2023 16:45, to...@tuxteam.de wrote: On Tue, Feb 14, 2023 at 10:41:38AM +0100, Heinz Tuechler wrote: Jean Louis wrote/hat geschrieben on/am 14.02.2023 07:00: Then just representation must be clear: @UTC is unclear in those cases, but @RELTOUTC would be clear. @RELTOUTC seems unfortuna

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

Jean Louis wrote/hat geschrieben on/am 14.02.2023 07:00: * to...@tuxteam.de [2023-02-12 16:50]: On Sun, Feb 12, 2023 at 12:33:40PM +0300, Jean Louis wrote: * Ihor Radchenko [2023-02-10 13:48]: Jean Louis writes: If you start adding in Org "fixed" time with UTC offset, that is a new type o

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

* to...@tuxteam.de [2023-02-12 16:50]: > On Sun, Feb 12, 2023 at 12:33:40PM +0300, Jean Louis wrote: > > * Ihor Radchenko [2023-02-10 13:48]: > > > Jean Louis writes: > > > > > > > If you start adding in Org "fixed" time with UTC offset, that is a new > > > > type of timestamp, as it is not com

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

On Sun, Feb 12, 2023 at 12:33:40PM +0300, Jean Louis wrote: > * Ihor Radchenko [2023-02-10 13:48]: > > Jean Louis writes: > > > > > If you start adding in Org "fixed" time with UTC offset, that is a new > > > type of timestamp, as it is not common in world. > > > > It is how ISO8601 defines off

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

Could it be reasonable to collect the hypothetical cases where relative timestamps would be used? So, alternatives and solutions could be evaluated more easily. For example: | External Input  | User's input | Org o

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

TC offset from floating time 2030-02-09 12:00, and one can derive UTC time. That is totally alright as representation of time. That is how past timestamps are represented in local time. Why not -- you can use it for future. I find it less useful for exchange purposes, almost useless, but you can do

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

ld be followed? > Reading the linked RFC spec, I did note that the motivation for the time > format used in calendar is mainly scheduling meetings for people > residing in different time zones. And I think that is what we are talking about, about conclusive time representation in cases w

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

On 10/02/2023 10:29, Jean Louis wrote: 2030-02-09 12:00 -08 @UTC -- this time CANNOT be said to be "fixed UTC" I do not see any reason why obviously invalid timestamp draws so much attention. Resolution may be rather concise: behavior is *undefined* since field values are mutually inconsist

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

c, I did note that the motivation for the time format used in calendar is mainly scheduling meetings for people residing in different time zones. I can see how the icalendar format is reasonable within that specific purpose. I cannot see why Org timestamps should be limited to meetings. Note th

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

Another program in future, and human, must know did the organizer of > > event, had in mind: > > I would like to remind you that timestamps are not necessarily used for > meetings. And not always shared with other people. Ok, and I have asked you to provide practical examples. Calculation

Re: [BUG] M-S- does not adjust clock timestamps as described in docs [9.5.5]

Robert Nikander writes: > I’m pretty much a beginner with the clock features, so I don’t have an > opinion yet on how it should work. But yes, it seems like clarifying the > manual there would be an improvement. Fixed, on main. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5

Re: [BUG] M-S- does not adjust clock timestamps as described in docs [9.5.5]

> On Feb 8, 2023, at 6:11 AM, Robert Nikander > wrote: > > I’m pretty much a beginner with the clock features, so I don’t have an > opinion yet on how it should work. But yes, it seems like clarifying the > manual there would be an improvement. > > I don’t know what agenda clock check is.

Re: [BUG] M-S- does not adjust clock timestamps as described in docs [9.5.5]

> On Feb 8, 2023, at 5:14 AM, Ihor Radchenko wrote: > > Robert Nikander writes: > >> […] >> >> If I put point on the minutes of 12:30 (second line) and hit S-M-, it >> moves the time to 12:35, but nothing else moves. Based on the docs, I >> thought it would shift one of the other lines. >

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

or example, when you want to schedule something exactly 10024 hours in future, regardless of time zone changes. The same can be done by specifying the timestamp in UTC directly. > Another program in future, and human, must know did the organizer of > event, had in mind: I would like to remind

Re: [BUG] M-S- does not adjust clock timestamps as described in docs [9.5.5]

Robert Nikander writes: > But it doesn't seem to work like that. For example > >* Testing it out >:LOGBOOK: >CLOCK: [2023-02-07 Tue 12:35]--[2023-02-07 Tue 12:45] => 0:10 >CLOCK: [2023-02-07 Tue 12:20]--[2023-02-07 Tue 12:30] => 0:10 >CLOCK: [2023-02-06 Mon 12:20]--[2023-02-

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

* ypuntot [2023-02-05 16:03]: > For the Poll, the Jeans proposal would be to introduce manually: > [2024-02-04 12:00 @America/Vancouver] I never recommend or recommended to anybody, ever, to make timestamps manually. That is for computer to make it right. For human, that is to use ca

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

* Max Nikulin [2023-02-05 20:06]: > On 05/02/2023 01:59, ypuntot wrote: > > Then, given the time zone and the local time, you can know UTC. > > If orgmode gets the UTC there is not ambiguity. > > Mapping from local time to UTC may be ambiguous, so mapping from local time > to time zone offset may

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

* Ihor Radchenko [2023-02-06 17:11]: > Jean Louis writes: > > > * Ihor Radchenko [2023-02-05 13:45]: > >> [2024-02-04 12:00 @-08,America/Vancouver] will use fixed -8 offset > > > > What does that mean practically? Provide example for better > > understanding. > > It means "when I scheduled th

[BUG] M-S- does not adjust clock timestamps as described in docs [9.5.5]

Hi, The docs say this about S-M + arrow keys on clock log lines. (In section: 8.4.1 - Dates and Times > Clocking Work Time > Clocking Commands) ‘S-M-’ (‘org-timestamp-up’) ‘S-M-’ (‘org-timestamp-down’) On ‘CLOCK’ log lines, increase/decrease the timestamp at point and the one of th

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

* Marcin Borkowski [2023-02-06 18:34]: > Out of curiosity: in what time zone you were when you sent this??? In EAT, by heart in Berlin, Europe, at time in future during DST, as to test various features. Forgot to change time back by using NTP. And e-mail went, discovering few problems in the ma

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

On Mon, Feb 06, 2023 at 04:34:15PM +0100, Marcin Borkowski wrote: > Out of curiosity: in what time zone you were when you sent this??? > > > On 2023-10-29, at 02:04, Jean Louis wrote: > > > * to...@tuxteam.de [2023-02-01 12:22]: Sorry. I've lost the thread's thread. Are you asking Jean Louis

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

Out of curiosity: in what time zone you were when you sent this??? On 2023-10-29, at 02:04, Jean Louis wrote: > * 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 calcula

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

when > that timestamp is generated? > [2024-02-04 12:00 @-08,!America/Vancouver] > ? This is not Ihor's. All three timestamps are within the discussed format. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Or

  1   2   3   4   5   6   7   8   9   >