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.