Re: Clock time implied as 00:00

[Nick Dokos <nicholas.dokos@hp.com>]

François Pinard <pinard@iro.umontreal.ca> wrote:

> Hi, Org people.
> 
> This morning, I just noticed this line:
> 
> CLOCK: [2011-12-29 jeu 9:30]--[2011-12-29 jeu 11:44] => 11:44
> 
> because of the strange 11:44 total.  My error is clear, as I wrote 9:30
> instead of 09:30.  Correcting it gives a move reasonable total:
> 
> CLOCK: [2011-12-29 jeu 09:30]--[2011-12-29 jeu 11:44] =>  2:14
> 
> Yet, forgetting a leading 0 is an easy mistake (I know I should not make
> mistakes!), and then, maybe (I'm not sure) Org mode could deliver
> unexpected or misleading statistics out of a silent error.  Not such a
> problem for me, yet it could have become one if I missed it.
> 
> Would it be reasonable to suggest that Org mode be more lenient about
> missing leading zeroes?
> 

There are two regexps that match timestamps, org-ts-regexp0 and
org-ts-regexp1 (and two more, derived from the first two). In each case
the part that matches the HH:MM part is as follows:

"... \\([0-9]\\{2\\}\\):\\([0-9]\\{2\\}\\)..."

in words: "exactly two digits, followed by a colon, followed by exactly
two digits".  Modifying them so that the HH part can be "one or two
digits" seems to make org-parse-time-string work correctly with the above
input:

"... \\([0-9]\\{1,2\\}\\):\\([0-9]\\{2\\}\\)..."

Whether this has undesirable consequences[fn:1], I don't know. Actually
it's only regexp0 that is used in org-parse-time-string, so strictly
speaking, only it needs to be modified.

Nick

Footnotes:

[fn:1] In particular, org-ts-regexp0 is explicitly used in org-odt.el, so at least that part
       needs to be checked for breakage, something that I have not done.