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

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

a with "!" is explained in more details. > If users wish to get some warnings, let them customize single option. This will be less fine-grained approach. For some timestamps, you don't need warnings. Of course, default customization may be also provided to enable warnings for ti

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

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 be ambiguous as well. The extreme case is 18

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

For the Poll, the Jeans proposal would be to introduce manually: [2024-02-04 12:00 @America/Vancouver] And org to convert it into: [2024-02-04 12:00 @-08,America/Vancouver] ? Ihor's would add the option to get warnings, in case tzdata changes, when that timestamp is generated? [2024-02-04 12:00 @

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-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. - The UTC offset is not certain to remain fixed in the future. - If you do not have the time of creation of the

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

Ypo writes: > 4. For the Poll: What would be the expected behavior if we used the UTC > offset?  [2024-02-04 12:00 @-08,America/Vancouver] >     - We should know beforehand the DST of Vancouver, or there would be > warnings. It seems more difficult for the user: maybe the "-08," should > be o

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

Samuel Wales writes: > On 2/1/23, Ihor Radchenko wrote: >> the best we can do is minimizing the breakage when designing the new syntax > > as a small nit [followup is not needed as i do not want to distract > from the big boys talking about quantum dst on pluto for timest

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

pear. TZ database would be handling those issues, that is the purpose of it. Using UTC offset in future timestamps does not make sense as it is not time that one can calculate in present time with certainty for reason that future TZ database does not exist in present time. Here is good recomme

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: >> It is a correct TZ value 🤷 > > Time zone value? TZ environment variable value -- 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)

use too many people, unless such time is only for logging purposes. But Org timestamps like DEADLINE, SCHEDULE, are really meant for a human. Internally, in calculations, program shoulde find time time zone, UTC offset, calculate, go to UTC, again to time zone, and again represent proper time. And

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-04 13:58]: > I used "UTC+2" because it is how offsets are often represented. > For example, https://time.is/London is displaying the following: > > Time in London, United Kingdom now > ... > Time zone > - Currently Greenwich Mean Time (GMT), UTC +0 >

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

-04 do. 21:00>, but it will increase maintenance burden, see below. 1. Doubt: I suppose my agenda timestamp would be: [2024-02-04 do. 21:00]. (Spain local time). Correct? Agenda may display timestamps in your current time zone using overlays or just by formatting during generation of agenda. 2

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

out quantum dst on pluto for timestamps > with [axial precession change :[]*, or follow up, as i have given up > on the topic of tz for timestamps :]]: > > it might be that i was not making a point for which it is entirely > true that what you and everybody else is proposing, i.e. ex

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

On 2/1/23, Ihor Radchenko wrote: > the best we can do is minimizing the breakage when designing the new syntax as a small nit [followup is not needed as i do not want to distract from the big boys talking about quantum dst on pluto for timestamps with [axial precession change :[]*, or follow

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

Great link! https://spin.atomicobject.com/2016/07/06/time-zones-offsets/ "Given a local time and an offset, you can know UTC time, but you do not know which time zone you’re in (because multiple timezones have the same offset)." So, given a time zone you can know the offset (Google it, for ex

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

Great link! https://spin.atomicobject.com/2016/07/06/time-zones-offsets/ "Given a local time and an offset, you can know UTC time, but you do not know which time zone you’re in (because multiple timezones have the same offset)." So, given a time zone you can know the offset (Google it, for examp

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

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

ows that your timestamp is most probably try to correct it, as saving time with invalid timestamp with some programs does not work, as I have demonstrated. Fact is that some timestamps mentioned in the conversations are invalid. Such invalid timestamps were generated by human, not by computer.

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

Jean Louis writes: > Specifying time zone is not ambiguous as long as you use the TZ > database for specifications! That's wrong and you know it. For example [2023-10-29 02:30 @Europe/Berlin] is ambiguous. Period. And that some examples got a bit off has been quite obvious and has already

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-01 14:12]: > Let me try to explain better. Just specifying time zone is ambiguous > once per year during daylight transition. For reason to make it unambiguous, people (representatives of countries in international associations) are creating the TZ database, and maintain

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-02 11:38]: > Jean Louis writes: > > > * 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 a

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

Ihor Radchenko writes: > Note that an alternative is > [2022-11-12 10:30-11:00] > [2022-11-12 10:30-11] > [2022-11-12 10:30-11:00-11] > which is much less confusing. Hmmm... is it? I read a lot different timestamps these days and currently I'm very careful reading th

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

Hi Ihor, >>> with CST being ambiguous (and also not supported by `encode-time’). >> >> I imagine here one could ignore unrecognised but non-conflicting timestamps. > > There is no reliable way to detect if a time zone abbreviation is > ambiguous or not. `encode-time

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

Timothy writes: >> with CST being ambiguous (and also not supported by `encode-time’). > > I imagine here one could ignore unrecognised but non-conflicting timestamps. There is no reliable way to detect if a time zone abbreviation is ambiguous or not. `encode-time' will not si

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

gapore over +07 > > Consider the requests about time zone abbreviations. Without “always > warn”, we can do > > [2022-11-12 Sat 12:00] > > with CST being ambiguous (and also not supported by `encode-time’). I imagine here one could ignore unrecognised but non-conflicting t

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

ption. A slight disadvantage is more verbose syntax for simple timestamps like [2022-11-12 10:30+02] [2022-11-12 10:30 @+02] >>2022-11-12 12:00+07 @!Asia/Singapore >> >>Org will calculate the internal time for both +07 offset and >>Asia/Singapore time zone. If th

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

Samuel Wales writes: > perhaps some cities are not listed? what is one supposed to do then? > find a city with equivalent geography and tz policy? Time zones have nothing to do with cities. The same city may have multiple time zones in some cases. You just need to know that current time zone in

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

Max Nikulin writes: > 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, >

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

on't need to worry about time zones than honestly you probably don't need time zones in your timestamps. And at least you know the UTC offset, don't you? Time zone abbreviation will gain you nothing if you know UTC offset because time zone abbreviations don't code information ab

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

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

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 [...] > Sam

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

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 t

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

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

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

On 02/02/2023 04:57, Heinz Tuechler wrote: My impression is that many of non experts like me don't know in which time zone they are living. For you own time zone: Open Development tools in a browser ([F12]), switch to console, type new Intl.DateTimeFormat().resolvedOptions().timeZone I

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

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 e

  1   2   3   4   5   6   7   8   9   >