[-- Attachment #1: Type: text/plain, Size: 394 bytes --] When specifying times in the tags/properties matcher you can use relative time notation, such as <yesterday> or <-1w>. This patch allows this to be used in other places, such as the :tstart and :tend parameters of clocktable. Btw, I couldn't quite understand the exact meaning of :block, :tstart and :tend as decribed in the manual. Is there a better explanation somewhere? thanks, ilya [-- Attachment #2: 0001-Time-specifications-Allow-specifying-relative-times.patch --] [-- Type: text/plain, Size: 2021 bytes --] From d19778b3fc624e14237d69cc76a4aa9cb8450697 Mon Sep 17 00:00:00 2001 From: Ilya Shlyakhter <ilya_shl@alum.mit.edu> Date: Fri, 30 Mar 2012 21:19:12 -0400 Subject: [PATCH] Time specifications: Allow specifying relative times * org.el (org-parse-time-string): Allow strings supported by tags/properties matcher (eg <now>, <yesterday>, <-7d>) if the time starts with < and ends with >. This means that e.g. in the clocktable parameters you can specify :tstart "<-1w>" :tend "<now>". TINYCHANGE --- lisp/org.el | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 4d2ae87..995dffd 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -16016,16 +16016,19 @@ When SHOW-ALL is nil, only return the current occurrence of a time stamp." This should be a lot faster than the normal `parse-time-string'. If time is not given, defaults to 0:00. However, with optional NODEFAULT, hour and minute fields will be nil if not given." - (if (string-match org-ts-regexp0 s) - (list 0 - (if (or (match-beginning 8) (not nodefault)) - (string-to-number (or (match-string 8 s) "0"))) - (if (or (match-beginning 7) (not nodefault)) - (string-to-number (or (match-string 7 s) "0"))) - (string-to-number (match-string 4 s)) - (string-to-number (match-string 3 s)) - (string-to-number (match-string 2 s)) - nil nil nil) + (cond + ((string-match "^<.+>$" s) + (decode-time (seconds-to-time (org-matcher-time s)))) + ((string-match org-ts-regexp0 s) + (list 0 + (if (or (match-beginning 8) (not nodefault)) + (string-to-number (or (match-string 8 s) "0"))) + (if (or (match-beginning 7) (not nodefault)) + (string-to-number (or (match-string 7 s) "0"))) + (string-to-number (match-string 4 s)) + (string-to-number (match-string 3 s)) + (string-to-number (match-string 2 s)) + nil nil nil)) (error "Not a standard Org-mode time string: %s" s))) (defun org-timestamp-up (&optional arg) -- 1.7.9.3
Hi Ilya,
Ilya Shlyakhter wrote:
> Btw, I couldn't quite understand the exact meaning of :block, :tstart and
> :tend as decribed in the manual. Is there a better explanation
> somewhere?
The block allows you to specify some chunk which is definable easily:
- yesterday
- lastweek
- thismonth
- 2012-02
- 2012-03-30
- etc.
#+BEGIN: clocktable :scope ("file.org") :block 2012-02
#+END:
`tstart' and `tend' serve for when you want to specify some range of dates
which is not expressable that way: for example, last Monday (`tstart') to
Wednesday (`tend').
Best regards,
Seb
--
Sebastien Vauban
Hi Ilya,
Ilya Shlyakhter <ilya_shl@alum.mit.edu> writes:
> When specifying times in the tags/properties matcher you can use relative
> time notation, such as <yesterday> or <-1w>. This patch
> allows this to be used in other places, such as the :tstart and :tend
> parameters of clocktable.
Applied, thanks!
--
Bastien
Bastien (2012-04-20 13:13:12 +0200) wrote: > Ilya Shlyakhter <ilya_shl@alum.mit.edu> writes: > >> When specifying times in the tags/properties matcher you can use >> relative time notation, such as <yesterday> or <-1w>. This patch >> allows this to be used in other places, such as the :tstart and :tend >> parameters of clocktable. > > Applied, thanks! This is a very useful patch for allowing "sliding windows" of time, e.g. to know "how much time have I clocked during the last four weeks?". However, I'm looking at the Git master branch and I see that the patch hasn't actually been applied [there][1] yet (and the [original thread][2] is from March). Is there any problem with it? Am I looking at the wrong repo? [1]: http://orgmode.org/cgit.cgi/org-mode.git/tree/lisp/org.el#n16359 [2]: http://comments.gmane.org/gmane.emacs.orgmode/54101 Thanks a lot, -- Ivan Vilata i Balaguer -- https://elvil.net/
Hi Ivan, Ivan Vilata i Balaguer <ivan@selidor.net> writes: > However, I'm looking at the Git master branch and I see that the patch > hasn't actually been applied [there][1] yet (and the [original > thread][2] is from March). Is there any problem with it? Am I looking > at the wrong repo? > > [1]: http://orgmode.org/cgit.cgi/org-mode.git/tree/lisp/org.el#n16359 > [2]: http://comments.gmane.org/gmane.emacs.orgmode/54101 I'm not sure what went wrong on your side but the patch has been applied here: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=001bcb9645bf0a5ea72f09ae502a8410319473c0 HTH, -- Bastien
Bastien (2012-11-13 23:02:40 +0100) wrote: > Ivan Vilata i Balaguer <ivan@selidor.net> writes: > >> However, I'm looking at the Git master branch and I see that the >> patch hasn't actually been applied [there][1] yet (and the [original >> thread][2] is from March). Is there any problem with it? Am I >> looking at the wrong repo? >> >> [1]: http://orgmode.org/cgit.cgi/org-mode.git/tree/lisp/org.el#n16359 >> [2]: http://comments.gmane.org/gmane.emacs.orgmode/54101 > > I'm not sure what went wrong on your side but the patch > has been applied here: > > http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=001bcb9645bf0a5ea72f09ae502a8410319473c0 Sure I can see the patch, but then how come the version of ``org-parse-time-string`` in the head of both the master and maint branches is still the one from before the patch was applied? It's quite strange... I apologise if I'm getting confused with git or the way the Org repo is structured, but maybe the change was accidentally reverted later. In any case, thanks for your answer! -- Ivan Vilata i Balaguer -- https://elvil.net/
Ivan Vilata i Balaguer writes: > Bastien (2012-11-13 23:02:40 +0100) wrote: >> I'm not sure what went wrong on your side but the patch >> has been applied here: >> >> http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=001bcb9645bf0a5ea72f09ae502a8410319473c0 > > I apologise if I'm getting confused with git or the way the Org repo is > structured, but maybe the change was accidentally reverted later. It was reverted with 6f78edd68c, two hours after having been applied. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Achim Gratz (2012-11-14 20:44:55 +0100) wrote: > Ivan Vilata i Balaguer writes: >> Bastien (2012-11-13 23:02:40 +0100) wrote: >>> I'm not sure what went wrong on your side but the patch >>> has been applied here: >>> >>> http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=001bcb9645bf0a5ea72f09ae502a8410319473c0 >> >> I apologise if I'm getting confused with git or the way the Org repo >> is structured, but maybe the change was accidentally reverted later. > > It was reverted with 6f78edd68c, two hours after having been applied. So the relative time specifications patch caused some kind of problem? That'd be a real shame, the feature could be very useful. :( Thanks for the info, -- Ivan Vilata i Balaguer -- https://elvil.net/
Hi Ivan, Ivan Vilata i Balaguer <ivan@selidor.net> writes: > So the relative time specifications patch caused some kind of problem? Yes. The problem was that inactive time-stamps were not correctly parsed anymore. > That'd be a real shame, the feature could be very useful. :( I just applied an updated patch to master which brings this useful feature back. Best, -- Bastien