A small fix in `org-read-date-analyze'

A small fix in `org-read-date-analyze'

[Marcin Borkowski]

[-- Attachment #1: Type: text/plain, Size: 276 bytes --]

Hi,

I attach a simple patch to enhance handling of two-digit years in
`org-read-date-analyze'.  (I have the FSF papers signed.)

Best,

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

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Enhance-year-handling.patch --]
[-- Type: text/x-patch, Size: 908 bytes --]

From 6406c46fe1394b107e87012696f058fe5f13215e Mon Sep 17 00:00:00 2001
From: Marcin Borkowski <mbork@mbork.pl>
Date: Thu, 17 Mar 2016 12:50:12 +0100
Subject: [PATCH] Enhance year handling

* lisp/org.el (org-read-date-analyze): Handle two-digit years with
`org-small-year-to-year' instead of just adding 2000
---
 lisp/org.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index 1f06cbd..9b3af05 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -17011,7 +17011,7 @@ user."
 			  (string-to-number (format-time-string "%Y"))))
 	    month (string-to-number (match-string 3 ans))
 	    day (string-to-number (match-string 4 ans)))
-      (when (< year 100) (setq year (+ 2000 year)))
+      (when (< year 100) (setq year (org-small-year-to-year year)))
       (setq ans (replace-match (format "%04d-%02d-%02d\\5" year month day)
 			       t nil ans)))
 
-- 
2.4.3

Re: A small fix in `org-read-date-analyze'

[Marcin Borkowski]

[-- Attachment #1: Type: text/plain, Size: 392 bytes --]


On 2016-03-17, at 12:52, Marcin Borkowski <mbork@mbork.pl> wrote:

> Hi,
>
> I attach a simple patch to enhance handling of two-digit years in
> `org-read-date-analyze'.  (I have the FSF papers signed.)

A better version (sorry for the noise).

Best,

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

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Enhance-year-handling.patch --]
[-- Type: text/x-patch, Size: 1362 bytes --]

From e98af1606de2479835da797e88eba332cabb233a Mon Sep 17 00:00:00 2001
From: Marcin Borkowski <mbork@mbork.pl>
Date: Thu, 17 Mar 2016 12:50:12 +0100
Subject: [PATCH] Enhance year handling

* lisp/org.el (org-read-date-analyze): Handle two-digit years with
`org-small-year-to-year' instead of just adding 2000
---
 lisp/org.el | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 1f06cbd..5adb370 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -17011,7 +17011,7 @@ user."
 			  (string-to-number (format-time-string "%Y"))))
 	    month (string-to-number (match-string 3 ans))
 	    day (string-to-number (match-string 4 ans)))
-      (when (< year 100) (setq year (+ 2000 year)))
+      (setq year (org-small-year-to-year year))
       (setq ans (replace-match (format "%04d-%02d-%02d\\5" year month day)
 			       t nil ans)))
 
@@ -17035,7 +17035,7 @@ user."
 			  (string-to-number (format-time-string "%Y"))))
 	    month (string-to-number (match-string 1 ans))
 	    day (string-to-number (match-string 2 ans)))
-      (when (< year 100) (setq year (+ 2000 year)))
+      (setq year (org-small-year-to-year year))
       (setq ans (replace-match (format "%04d-%02d-%02d\\5" year month day)
 			       t nil ans)))
     ;; Help matching am/pm times, because `parse-time-string' does not do that.
-- 
2.4.3

Re: A small fix in `org-read-date-analyze'

[Nicolas Goaziou]

Hello,

Marcin Borkowski <mbork@mbork.pl> writes:

>> I attach a simple patch to enhance handling of two-digit years in
>> `org-read-date-analyze'.  (I have the FSF papers signed.)
>
> A better version (sorry for the noise).

Thank you. 

Is it a TINYCHANGE or did you sign FSF papers?

Regards,

-- 
Nicolas Goaziou

Re: A small fix in `org-read-date-analyze'

[Marcin Borkowski]

On 2016-03-17, at 23:12, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:

> Hello,
>
> Marcin Borkowski <mbork@mbork.pl> writes:
>
>>> I attach a simple patch to enhance handling of two-digit years in
>>> `org-read-date-analyze'.  (I have the FSF papers signed.)
>>
>> A better version (sorry for the noise).
>
> Thank you. 
>
> Is it a TINYCHANGE or did you sign FSF papers?

Papers signed.

> Regards,

Best,

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

Re: A small fix in `org-read-date-analyze'

[Nicolas Goaziou]

Hello,

Marcin Borkowski <mbork@mbork.pl> writes:

> Papers signed.

OK. Applied. Thank you.

Regards,

-- 
Nicolas Goaziou

A proposed enhancement in entering timestamps (was: A small fix in `org-read-date-analyze')

[Marcin Borkowski]

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

> Hello,
>
> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> Papers signed.
>
> OK. Applied. Thank you.

Great, thanks!  (This is my first contribution to Org-mode!)

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?

> Regards,

Best,

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

Re: A proposed enhancement in entering timestamps

[Samuel W. Flint]

[-- Attachment #1: Type: text/plain, Size: 1176 bytes --]

:: Marcin Borkowski writes:

MB> On 2016-03-18, at 14:34, Nicolas Goaziou <mail@nicolasgoaziou.fr>
MB> wrote:

>> Hello,
>> 
>> Marcin Borkowski <mbork@mbork.pl> writes:
>> 
>>> Papers signed.
>> 
>> OK. Applied. Thank you.

MB> Great, thanks!  (This is my first contribution to Org-mode!)

MB> I'm now reading org-read-date-analyze to be able to enable US
MB> military format for hours (e.g., 2100 instead of 21:00).  This is
MB> potentially very useful (at least for me), since I'll be able to
MB> enter the hour with one hand (colon is on shift-semicolon on my
MB> keyboard).  Another idea would be to enable 21.00 (this notation is
MB> sometimes used in Poland).  Would there be demand for such a
MB> feature?

Yes!  This would be great, especially the no-separator US military
format, it would allow me to be much faster entering times!

Sam

>> Regards,

MB> Best,

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

-- 
Samuel W. Flint
4096R/266596F4
      (9477 D23E 389E 40C5 2F10  DE19 68E5 318E 2665 96F4)
(λs.s s) λs.s s

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: A proposed enhancement in entering timestamps

[Eric S Fraga]

On Friday, 18 Mar 2016 at 17:51, Marcin Borkowski 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?

+1 for both 2100 and 21.00 as I hate typing the :...
so I guess +2 from me. :-)

I would also like 21h.

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.91.1, Org release_8.3.4-626-gb62d55

Re: A proposed enhancement in entering timestamps (was: A small fix in `org-read-date-analyze')

[Marcin Borkowski]

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.

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

Re: A proposed enhancement in entering timestamps

[Nicolas Goaziou]

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.

> 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.

Regards,

-- 
Nicolas Goaziou

Re: A proposed enhancement in entering timestamps

[Marcin Borkowski]

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

Re: A proposed enhancement in entering timestamps

[Robert Horn]

>>> 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

This would be very convenient for me, but when it comes time to document
it a more proper name is 24-hour notation.  It's used by much more than
the US military.  It's standard for railway schedules in most of the
world, medical records in most of the world, aviation worldwide, and
other places.

I work mostly in 24-hr notation and putting that colon in the right
place is mistake prone.

R Horn

Re: A proposed enhancement in entering timestamps

[Marcin Borkowski]

On 2016-03-24, at 16:30, Robert Horn <rjhorn@alum.mit.edu> wrote:

>>>> 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
>
> This would be very convenient for me, but when it comes time to document
> it a more proper name is 24-hour notation.  It's used by much more than
> the US military.  It's standard for railway schedules in most of the
> world, medical records in most of the world, aviation worldwide, and
> other places.

Well, this seems not that obvious to me:
https://en.wikipedia.org/wiki/24-hour_clock#Description .  It seems that
"24-hour notation" can also refer to the one with colon or full stop, so
it is ambiguous.  But if anyone comes up with a better name than "US
military time", I'm all for it.

> I work mostly in 24-hr notation and putting that colon in the right
> place is mistake prone.

Not only that, but it is plain old inconvenient.

> R Horn

Best,

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