Re: A proposed enhancement in entering timestamps

[Marcin Borkowski <mbork@mbork.pl>]

On 2016-03-24, at 14:09, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:

> Hello,
>
> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> On 2016-03-18, at 17:51, Marcin Borkowski <mbork@mbork.pl> wrote:
>>
>>> I'm now reading org-read-date-analyze to be able to enable US military
>>> format for hours (e.g., 2100 instead of 21:00).  This is potentially
>>> very useful (at least for me), since I'll be able to enter the hour with
>>> one hand (colon is on shift-semicolon on my keyboard).  Another idea
>>> would be to enable 21.00 (this notation is sometimes used in Poland).
>>> Would there be demand for such a feature?
>>
>> Hi all,
>>
>> and thanks Eric and Sam for positive feedback.
>
> I agree that US military format can be interesting. However, I think
> 21.00 could conflict with European format for dates.

Well, both can.  I've been thinking about it today and decided that the
easiest way to accomplish this without breaking anything would be to
replace "dddd" (i.e., four digits) or "dd.dd" at the end of `ans' in
`org-read-date-analyze' with "dd:dd", possibly with some added test for
the case when this could be mistaken for a date (or its part).  This way
I wouldn't have to touch `parse-time-string' (which I'm quite afraid to
touch, as I wrote).

A quick test I've done right now shows that "dd.dd" on itself is not
interpreted in any special way by `org-read-date-analyze', but /is/ by
`org-read-date'.  This looks like a bug to me.

I'll come back to this issue after Easter.

>> One thing that would tremendously help is tests.  I think these
>> functions are rather fragile, in the sense that it's very easy to break
>> something (`parse-time-string' is a total mess, for example - it is
>> "clever", yes, but proving that it actually works seems next to
>> impossible), so without an extensive test suite I wouldn't touch these
>> functions.  Does anyone have - or can make - a set of valid (in
>> `org-read-date' sense) strings to make tests first and then modify these
>> functions?  (I could make it myself, but I might forget about some cases -
>> and there are a lot of them!  And it's even nontrivial to test the
>> coverage, since large part of the `parse-time-string' /logic/ is hidden
>> in the /variable/ `parse-time-rules', which btw has a 1-line
>> docstring...)
>
> I cannot speak for `parse-time-string', but `org-read-date' already has
> some tests in `test-org/org-read-date'. You can add more if you want to.

Thanks!

> Regards,

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University