François Pinard <pin...@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.