On 2016-03-18, at 17:51, Marcin Borkowski <mb...@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. It seems that it is harder than I thought. `org-read-date-analyze' relies on `parse-time-string'. It is relatively easy to make the latter function accept both 21.00 and 2100, but the way `org-read-date-analyze' uses `parse-time-string' makes things a bit difficult. So, it will take me a couple of days, I guess. 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...) > Best, Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University
