bug#21229: 24.5; parse-time-string ignore PM/AM

bug#21229: 24.5; parse-time-string ignore PM/AM

[Tino Calancha]

In the *scratch* buffer i evaluated  following expressions:

(format-time-string "%c" (current-time))
"Mon 10 Aug 2015 03:11:35 PM JST"

(apply 'encode-time(parse-time-string "Mon 10 Aug 2015 03:11:35 PM JST"))
(21959 38871)
(apply 'encode-time(parse-time-string "Mon 10 Aug 2015 03:11:35 AM JST"))
(21959 38871)

(apply 'encode-time(parse-time-string "Mon 10 Aug 2015 15:11:35 JST"))
(21960 16535)
(apply 'encode-time(parse-time-string "Mon 10 Aug 2015 03:11:35 JST"))
(21959 38871)




In GNU Emacs 24.5.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.23)
  of 2015-06-07 on calancha-ilc.kek.jp
System Description:	Scientific Linux release 6.6 (Carbon)

Configured using:
  `configure --with-gif=no'

Important settings:
   value of $LC_ALL:
   value of $LC_COLLATE: en_US.UTF-8
   value of $LC_CTYPE: en_US.UTF-8
   value of $LC_MESSAGES: en_US.UTF-8
   value of $LC_MONETARY: en_US.UTF-8
   value of $LC_NUMERIC: en_US.UTF-8
   value of $LC_TIME: en_US.UTF-8
   value of $LANG: en_US.UTF-8
   locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
   tooltip-mode: t
   electric-indent-mode: t
   mouse-wheel-mode: t
   tool-bar-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t
   line-number-mode: t
   transient-mark-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util help-fns mail-prsvr mail-utils parse-time xterm time-date
tooltip electric uniquify ediff-hook vc-hooks lisp-float-type mwheel
x-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list
newcomment lisp-mode prog-mode register page menu-bar rfn-eshadow timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer nadvice loaddefs button faces cus-face macroexp
files text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
dbusbind gfilenotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)

Memory information:
((conses 16 76628 4219)
  (symbols 48 17605 0)
  (miscs 40 39 188)
  (strings 32 9137 4875)
  (string-bytes 1 250937)
  (vectors 16 7162)
  (vector-slots 8 342020 32768)
  (floats 8 65 237)
  (intervals 56 199 4)
  (buffers 960 11)
  (heap 1024 10949 2008))

bug#21229: 24.5; parse-time-string ignore PM/AM

[Eli Zaretskii]

> Date: Mon, 10 Aug 2015 17:19:37 +0900 (JST)
> From: Tino Calancha <f92capac@gmail.com>
> 
> In the *scratch* buffer i evaluated  following expressions:
> 
> (format-time-string "%c" (current-time))
> "Mon 10 Aug 2015 03:11:35 PM JST"
> 
> (apply 'encode-time(parse-time-string "Mon 10 Aug 2015 03:11:35 PM JST"))
> (21959 38871)
> (apply 'encode-time(parse-time-string "Mon 10 Aug 2015 03:11:35 AM JST"))
> (21959 38871)

What do the following expressions produce?

  (parse-time-string "Mon 10 Aug 2015 03:11:35 PM JST")
  (parse-time-string "Mon 10 Aug 2015 03:11:35 AM JST")

bug#21229: 24.5; parse-time-string ignore PM/AM

[Tino Calancha]

|#> emacs -Q


(parse-time-string "Mon 10 Aug 2015 03:11:35 PM JST")
(35 11 3 10 8 2015 1 nil nil)
  (parse-time-string "Mon 10 Aug 2015 03:11:35 AM JST")
(35 11 3 10 8 2015 1 nil nil)



On Mon, 10 Aug 2015, Eli Zaretskii wrote:

>> Date: Mon, 10 Aug 2015 17:19:37 +0900 (JST)
>> From: Tino Calancha <f92capac@gmail.com>
>>
>> In the *scratch* buffer i evaluated  following expressions:
>>
>> (format-time-string "%c" (current-time))
>> "Mon 10 Aug 2015 03:11:35 PM JST"
>>
>> (apply 'encode-time(parse-time-string "Mon 10 Aug 2015 03:11:35 PM JST"))
>> (21959 38871)
>> (apply 'encode-time(parse-time-string "Mon 10 Aug 2015 03:11:35 AM JST"))
>> (21959 38871)
>
> What do the following expressions produce?
>
>  (parse-time-string "Mon 10 Aug 2015 03:11:35 PM JST")
>  (parse-time-string "Mon 10 Aug 2015 03:11:35 AM JST")
>

bug#21229: 24.5; parse-time-string ignore PM/AM

[Eli Zaretskii]

> Date: Tue, 11 Aug 2015 02:35:52 +0900 (JST)
> From: Tino Calancha <f92capac@gmail.com>
> cc: Tino Calancha <f92capac@gmail.com>, 21229@debbugs.gnu.org
> 
> 
> |#> emacs -Q
> 
> 
> (parse-time-string "Mon 10 Aug 2015 03:11:35 PM JST")
> (35 11 3 10 8 2015 1 nil nil)
>   (parse-time-string "Mon 10 Aug 2015 03:11:35 AM JST")
> (35 11 3 10 8 2015 1 nil nil)

So, as you see, the problem is in parse-time-string.  I'm not even
sure that function is supposed to be able to parse the output of %c,
since on my system that produces an obviously bogus result:

 (format-time-string "%c" (current-time)) => "8/10/2015 8:41:41 PM"

but

 (parse-time-string "8/10/2015 8:41:41 PM") => (41 41 8 8 nil 2010 nil nil nil)

Look, ma: no month! and the year is off!

However,

 (current-time-string) => "Mon Aug 10 20:44:52 2015"

and

 (parse-time-string "Mon Aug 10 20:44:52 2015") => (52 44 20 10 8 2015 1 nil nil)

as expected.

bug#21229: 24.5; parse-time-string ignore PM/AM

[Tino Calancha]

Maybe  parsing "%c" looks too ambitius for the
freedoom of the output format.

At least recognize the flag %p (AM/PM) could be worth
to support, because is found quite often,
Actually from the github of this code i see the comment:
;; Nobody else handles iso8601 correctly, let's do it ourselves.
Naively reading this, i would assume "%p" is supported.

I took a look in the code of parse-time.el and
"%p" is currently overlooked.

But parse-time-tokenize process correctly such kind of dates:

(parse-time-tokenize "Tue Aug 10 03:30:25 pm JST 2015")
("Tue" "Aug" 10 "03:30:25" "pm" "JST" 2015)
(parse-time-tokenize "Tue Aug 10 03:30:25 am JST 2015")
("Tue" "Aug" 10 "03:30:25" "am" "JST" 2015)

We may need something like:

once you find "am" "pm" look the token: "HH:MM:SS" and ask:

when "pm" and HH < 12: HH ---> HH + 12


On Mon, 10 Aug 2015, Eli Zaretskii wrote:

>> Date: Tue, 11 Aug 2015 02:35:52 +0900 (JST)
>> From: Tino Calancha <f92capac@gmail.com>
>> cc: Tino Calancha <f92capac@gmail.com>, 21229@debbugs.gnu.org
>>
>>
>> |#> emacs -Q
>>
>>
>> (parse-time-string "Mon 10 Aug 2015 03:11:35 PM JST")
>> (35 11 3 10 8 2015 1 nil nil)
>>   (parse-time-string "Mon 10 Aug 2015 03:11:35 AM JST")
>> (35 11 3 10 8 2015 1 nil nil)
>
> So, as you see, the problem is in parse-time-string.  I'm not even
> sure that function is supposed to be able to parse the output of %c,
> since on my system that produces an obviously bogus result:
>
> (format-time-string "%c" (current-time)) => "8/10/2015 8:41:41 PM"
>
> but
>
> (parse-time-string "8/10/2015 8:41:41 PM") => (41 41 8 8 nil 2010 nil nil nil)
>
> Look, ma: no month! and the year is off!
>
> However,
>
> (current-time-string) => "Mon Aug 10 20:44:52 2015"
>
> and
>
> (parse-time-string "Mon Aug 10 20:44:52 2015") => (52 44 20 10 8 2015 1 nil nil)
>
> as expected.
>

bug#21229: 24.5; parse-time-string ignore PM/AM

[Nicolas Richard]

Tino Calancha <f92capac@gmail.com> writes:
> Maybe  parsing "%c" looks too ambitius for the
> freedoom of the output format.

Also FWIW, parse-time-string won't parse (format-time-string "%c"
(current-time)) correctly in many non-english locales because it won't
recognize the month names.

In my french setup:
(format-time-string "%c" (current-time)) => "mar. 11 août 2015 07:34:35 CEST"

"mar" stands for "mardi" (= Tuesday), but will be understood as "March" :
(parse-time-string "mar. 11 août 2015 07:34:35 CEST") => (35 34 7 11 3 2015 nil nil nil)

> We may need something like:
>
> once you find "am" "pm" look the token: "HH:MM:SS" and ask:
>
> when "pm" and HH < 12: HH ---> HH + 12

Currently parse-time-string works with rules (they are found in
parse-time-rules), each setting one element of a (SEC MIN HOUR DAY MON
YEAR DOW DST TZ) list. When one such element is set, parse-time-string
won't modify it anymore. So we need a small change in the design here if
we want to take PM into account.

-- 
Nico

bug#21229: 24.5; parse-time-string ignore PM/AM

[Tino Calancha]

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



I attached a patch showing how i am dealing temporally with this
AM/PM issue.

We have rule for iso 8601:
"%Y-%m-%d"

It should be possible to add support for:
"%m/%d/%y"

(similarly as we have several rules for HH:MM:SS)

I guess its natural to support both.

Tino



On Tue, 11 Aug 2015, Nicolas Richard wrote:

> Tino Calancha <f92capac@gmail.com> writes:
>> Maybe  parsing "%c" looks too ambitius for the
>> freedoom of the output format.
>
> Also FWIW, parse-time-string won't parse (format-time-string "%c"
> (current-time)) correctly in many non-english locales because it won't
> recognize the month names.
>
> In my french setup:
> (format-time-string "%c" (current-time)) => "mar. 11 août 2015 07:34:35 CEST"
>
> "mar" stands for "mardi" (= Tuesday), but will be understood as "March" :
> (parse-time-string "mar. 11 août 2015 07:34:35 CEST") => (35 34 7 11 3 2015 nil nil nil)
>
>> We may need something like:
>>
>> once you find "am" "pm" look the token: "HH:MM:SS" and ask:
>>
>> when "pm" and HH < 12: HH ---> HH + 12
>
> Currently parse-time-string works with rules (they are found in
> parse-time-rules), each setting one element of a (SEC MIN HOUR DAY MON
> YEAR DOW DST TZ) list. When one such element is set, parse-time-string
> won't modify it anymore. So we need a small change in the design here if
> we want to take PM into account.
>
> -- 
> Nico
>

[-- Attachment #2: Type: text/plain, Size: 826 bytes --]

--- parse-time.el	2015-08-11 18:06:46.895638495 +0900
+++ parse-time_1.el	2015-08-11 19:19:20.855001776 +0900
@@ -182,7 +182,10 @@
 The values are identical to those of `decode-time', but any values that are
 unknown are returned as nil."
   (let ((time (list nil nil nil nil nil nil nil nil nil))
-	(temp (parse-time-tokenize (downcase string))))
+		(temp (parse-time-tokenize (downcase string)))
+		(has-pm nil))
+	(when (member "pm" temp)
+	  (setq has-pm t))
     (while temp
       (let ((parse-time-elt (pop temp))
 	    (rules parse-time-rules)
@@ -216,6 +219,8 @@
 				       (funcall this)))
 				 parse-time-val)))
 		  (rplaca (nthcdr (pop slots) time) new-val))))))))
+	(when (and has-pm (< (nth 2 time) 12))
+	  (setf (nth 2 time) (+ (nth 2 time) 12)))
     time))
 
 (provide 'parse-time)

bug#21229: 24.5; parse-time-string ignore PM/AM

[Andreas Schwab]

Tino Calancha <f92capac@gmail.com> writes:

> It should be possible to add support for:
> "%m/%d/%y"

What about "%d/%m/%y"?

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

bug#21229: 24.5; parse-time-string ignore PM/AM

[Tino Calancha]

"%m/%d/%y" is better option because is seems more
standard: it is listed in in the manuals of shell utility
`date'
and elisp function
`format-time-string'
as the output of the flag "%D"


|#> date +%D
08/11/15
(format-time-string "%D")
"08/11/15"

Tino


On Tue, 11 Aug 2015, Andreas Schwab wrote:

> Tino Calancha <f92capac@gmail.com> writes:
>
>> It should be possible to add support for:
>> "%m/%d/%y"
>
> What about "%d/%m/%y"?
>
> Andreas.
>
> -- 
> Andreas Schwab, SUSE Labs, schwab@suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."
>

bug#21229: 24.5; parse-time-string ignore PM/AM

[Andreas Schwab]

Tino Calancha <f92capac@gmail.com> writes:

> "%m/%d/%y" is better option because is seems more
> standard:

The nice things about standards is that there are so many to chose from.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

bug#21229: 24.5; parse-time-string ignore PM/AM

[Tino Calancha]

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


Exactly, there are a lot, its always a mess.

I attached my tentative idea to support
(format-time-string "%p")
(format-time-string "%D")

I didnt tested so much. Im sure you can find a better way.


(parse-time-string "08/11/15 08:37:48 PM")
(48 37 20 11 8 2015 nil nil nil)
(parse-time-string "08/11/15 08:37:48 AM")
(48 37 8 11 8 2015 nil nil nil)

Tino


On Tue, 11 Aug 2015, Andreas Schwab wrote:

> Tino Calancha <f92capac@gmail.com> writes:
>
>> "%m/%d/%y" is better option because is seems more
>> standard:
>
> The nice things about standards is that there are so many to chose from.
>
> Andreas.
>
> -- 
> Andreas Schwab, SUSE Labs, schwab@suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."
>

[-- Attachment #2: Type: text/plain, Size: 1736 bytes --]

--- parse-time.el	2015-08-11 18:06:46.895638495 +0900
+++ parse-time_3.el	2015-08-11 20:22:45.627737133 +0900
@@ -55,6 +55,7 @@
       (cond ((eq char ?+) 1)
 	    ((eq char ?-) -1)
 	    ((eq char ?:) ?d)
+	    ((eq char ?/) ?e)
 	    ((string-match "[[:upper:]]" (setq str (string char))) ?A)
 	    ((string-match "[[:lower:]]" str) ?a)
 	    ((string-match "[[:digit:]]" str) ?0)))))
@@ -156,6 +157,12 @@
 			(= (aref parse-time-elt 4) ?-)
 			(= (aref parse-time-elt 7) ?-)))
      [0 4] [5 7] [8 10])
+    ((5 4 3)
+     ,#'(lambda () (and (stringp parse-time-elt)
+			(= (length parse-time-elt) 8)
+			(= (aref parse-time-elt 2) ?/)
+			(= (aref parse-time-elt 5) ?/)))
+     [6 8] [0 2] [3 5])
     ((2 1 0)
      ,#'(lambda () (and (stringp parse-time-elt)
 			(= (length parse-time-elt) 5)
@@ -182,7 +189,10 @@
 The values are identical to those of `decode-time', but any values that are
 unknown are returned as nil."
   (let ((time (list nil nil nil nil nil nil nil nil nil))
-	(temp (parse-time-tokenize (downcase string))))
+		(temp (parse-time-tokenize (downcase string)))
+		(has-pm nil))
+	(when (member "pm" temp)
+	  (setq has-pm t))
     (while temp
       (let ((parse-time-elt (pop temp))
 	    (rules parse-time-rules)
@@ -216,6 +226,13 @@
 				       (funcall this)))
 				 parse-time-val)))
 		  (rplaca (nthcdr (pop slots) time) new-val))))))))
+    (let ((year (nth 5 time)))
+	  (cond ((and (>= year 50) (<= year 110))
+			 (setf (nth 5 time) (+ 1900 year)))
+			((and (>= year 0) (<= year 49))
+			 (setf (nth 5 time) (+ 2000 year)))))
+	(when (and has-pm (< (nth 2 time) 12))
+	  (setf (nth 2 time) (+ (nth 2 time) 12)))
     time))
 
 (provide 'parse-time)

bug#21229: 24.5; parse-time-string ignore PM/AM

[Stefan Monnier]

>> It should be possible to add support for:
>> "%m/%d/%y"
> What about "%d/%m/%y"?

Indeed.  I already bumped into such problems with parse-time-string
where it seemed to return a completely bogus result until I realized
that it picked a different ordering from the one I had.

The problem exists for "a-b-c" as well, tho I can't remember ever seeing
"YYYY-DD-MM" nor "MM-DD-YYYY" so if the year is spelled out as 4 digits,
the "a-b-c" format is somewhat reliable (at least within my part of the
world).


        Stefan

bug#21229: 24.5; parse-time-string ignore PM/AM

[Tino Calancha]

At some point one decision (order to support) should be taken 
because MM DD need to be identified:
07-11, november 7th?
Maybe July 11th?

My propose is support
date +%F (%Y-%m-%d already in vanilla emacs)
and
date +%D (%m/%d/%y)

It is straightforward to extend my previous patch adding one rule to 
support:
%m/%d/%Y (%Y instead of %y)

I think that cover enough date formats.

I understand is hard to remember if %m/%d/%y or %d/%m/%y
is supported: the documentation string of parse-time-string should 
be updated to clearly point out what input strings are valid.

Tino

On Tue, 11 Aug 2015, Stefan Monnier wrote:

>>> It should be possible to add support for:
>>> "%m/%d/%y"
>> What about "%d/%m/%y"?
>
> Indeed.  I already bumped into such problems with parse-time-string
> where it seemed to return a completely bogus result until I realized
> that it picked a different ordering from the one I had.
>
> The problem exists for "a-b-c" as well, tho I can't remember ever seeing
> "YYYY-DD-MM" nor "MM-DD-YYYY" so if the year is spelled out as 4 digits,
> the "a-b-c" format is somewhat reliable (at least within my part of the
> world).
>
>
>        Stefan
>

bug#21229: 24.5; parse-time-string ignore PM/AM

[Eli Zaretskii]

> Date: Wed, 12 Aug 2015 14:45:36 +0900 (JST)
> From: Tino Calancha <f92capac@gmail.com>
> Cc: Tino Calancha <f92capac@gmail.com>, Andreas Schwab <schwab@suse.de>,
> 	21229@debbugs.gnu.org, Nicolas Richard <youngfrog@members.fsf.org>
> 
> At some point one decision (order to support) should be taken 
> because MM DD need to be identified:
> 07-11, november 7th?
> Maybe July 11th?

Why not go with the locale's conventions?

> date +%D (%m/%d/%y)

IMO, this is not reasonable for locales which use %d/%m/%y (all of
Europe, AFAIK, and then some).

bug#21229: 24.5; parse-time-string ignore PM/AM

[Nicolas Richard]

Le 12/08/2015 07:45, Tino Calancha a écrit :
> At some point one decision (order to support) should be taken because MM DD need to be identified:
> 07-11, november 7th?
> Maybe July 11th?

Because of this, I think it is best to throw an error if it's not yyyy mm dd.

> the documentation string of parse-time-string should be updated to clearly point out what input strings are valid.

Yep (once the decision is made).

Nico.

bug#21229: 24.5; parse-time-string ignore PM/AM

[Tino Calancha]

As far as is clearly explained in the documentation string
of parse-time-string  i am fine with that.



On Wed, 12 Aug 2015, Eli Zaretskii wrote:

>> Date: Wed, 12 Aug 2015 14:45:36 +0900 (JST)
>> From: Tino Calancha <f92capac@gmail.com>
>> Cc: Tino Calancha <f92capac@gmail.com>, Andreas Schwab <schwab@suse.de>,
>> 	21229@debbugs.gnu.org, Nicolas Richard <youngfrog@members.fsf.org>
>>
>> At some point one decision (order to support) should be taken
>> because MM DD need to be identified:
>> 07-11, november 7th?
>> Maybe July 11th?
>
> Why not go with the locale's conventions?
>
>> date +%D (%m/%d/%y)
>
> IMO, this is not reasonable for locales which use %d/%m/%y (all of
> Europe, AFAIK, and then some).
>

bug#21229: 24.5; parse-time-string ignore PM/AM

[Lars Ingebrigtsen]

Tino Calancha <f92capac@gmail.com> writes:

> |#> emacs -Q
>
> (parse-time-string "Mon 10 Aug 2015 03:11:35 PM JST")
> (35 11 3 10 8 2015 1 nil nil)
>  (parse-time-string "Mon 10 Aug 2015 03:11:35 AM JST")
> (35 11 3 10 8 2015 1 nil nil)

Yeah, parse-time-string parses RFC822 date strings (and these days, also
ISO8601 strings) -- it is not something that parses locale-specific or
otherwise randomly-formatted strings.

So I don't think there's anything here to fix, and I'm closing this bug
report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no