GNU bug report logs - #21229
24.5; parse-time-string ignore PM/AM

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 21229 in the body.
You can then email your comments to 21229 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Tino Calancha <f92capac <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.5; parse-time-string ignore PM/AM
Date: Mon, 10 Aug 2015 17:19:37 +0900 (JST)

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

Message #8 received at 21229 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Tino Calancha <f92capac <at> gmail.com>
Cc: 21229 <at> debbugs.gnu.org
Subject: Re: bug#21229: 24.5; parse-time-string ignore PM/AM
Date: Mon, 10 Aug 2015 20:29:38 +0300

> Date: Mon, 10 Aug 2015 17:19:37 +0900 (JST)
> From: Tino Calancha <f92capac <at> 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")

Message #11 received at 21229 <at> debbugs.gnu.org (full text, mbox):

From: Tino Calancha <f92capac <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Tino Calancha <f92capac <at> gmail.com>, 21229 <at> debbugs.gnu.org
Subject: Re: bug#21229: 24.5; parse-time-string ignore PM/AM
Date: Tue, 11 Aug 2015 02:35:52 +0900 (JST)

|#> 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 <at> 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")
>

Message #14 received at 21229 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Tino Calancha <f92capac <at> gmail.com>
Cc: f92capac <at> gmail.com, 21229 <at> debbugs.gnu.org
Subject: Re: bug#21229: 24.5; parse-time-string ignore PM/AM
Date: Mon, 10 Aug 2015 20:46:30 +0300

> Date: Tue, 11 Aug 2015 02:35:52 +0900 (JST)
> From: Tino Calancha <f92capac <at> gmail.com>
> cc: Tino Calancha <f92capac <at> gmail.com>, 21229 <at> 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.

Message #17 received at 21229 <at> debbugs.gnu.org (full text, mbox):

From: Tino Calancha <f92capac <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Tino Calancha <f92capac <at> gmail.com>, 21229 <at> debbugs.gnu.org
Subject: Re: bug#21229: 24.5; parse-time-string ignore PM/AM
Date: Tue, 11 Aug 2015 11:36:12 +0900 (JST)

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 <at> gmail.com>
>> cc: Tino Calancha <f92capac <at> gmail.com>, 21229 <at> 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.
>

Message #20 received at 21229 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Richard <youngfrog <at> members.fsf.org>
To: Tino Calancha <f92capac <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 21229 <at> debbugs.gnu.org
Subject: Re: bug#21229: 24.5; parse-time-string ignore PM/AM
Date: Tue, 11 Aug 2015 10:32:55 +0200

Tino Calancha <f92capac <at> 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

Message #23 received at 21229 <at> debbugs.gnu.org (full text, mbox):

From: Tino Calancha <f92capac <at> gmail.com>
To: Nicolas Richard <youngfrog <at> members.fsf.org>
Cc: Tino Calancha <f92capac <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>,
 21229 <at> debbugs.gnu.org
Subject: Re: bug#21229: 24.5; parse-time-string ignore PM/AM
Date: Tue, 11 Aug 2015 19:37:00 +0900 (JST)

[Message part 1 (text/plain, inline)]

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

[parse-time.patch (text/plain, attachment)]

Message #26 received at 21229 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> suse.de>
To: Tino Calancha <f92capac <at> gmail.com>
Cc: 21229 <at> debbugs.gnu.org, Nicolas Richard <youngfrog <at> members.fsf.org>
Subject: Re: bug#21229: 24.5; parse-time-string ignore PM/AM
Date: Tue, 11 Aug 2015 12:40:09 +0200

Tino Calancha <f92capac <at> 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 <at> suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Message #29 received at 21229 <at> debbugs.gnu.org (full text, mbox):

From: Tino Calancha <f92capac <at> gmail.com>
To: Andreas Schwab <schwab <at> suse.de>
Cc: Tino Calancha <f92capac <at> gmail.com>, 21229 <at> debbugs.gnu.org,
 Nicolas Richard <youngfrog <at> members.fsf.org>
Subject: Re: bug#21229: 24.5; parse-time-string ignore PM/AM
Date: Tue, 11 Aug 2015 19:52:00 +0900 (JST)

"%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 <at> 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 <at> suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."
>

Message #32 received at 21229 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> suse.de>
To: Tino Calancha <f92capac <at> gmail.com>
Cc: 21229 <at> debbugs.gnu.org, Nicolas Richard <youngfrog <at> members.fsf.org>
Subject: Re: bug#21229: 24.5; parse-time-string ignore PM/AM
Date: Tue, 11 Aug 2015 13:00:29 +0200

Tino Calancha <f92capac <at> 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 <at> suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Message #35 received at 21229 <at> debbugs.gnu.org (full text, mbox):

From: Tino Calancha <f92capac <at> gmail.com>
To: Andreas Schwab <schwab <at> suse.de>
Cc: Tino Calancha <f92capac <at> gmail.com>, 21229 <at> debbugs.gnu.org,
 Nicolas Richard <youngfrog <at> members.fsf.org>
Subject: Re: bug#21229: 24.5; parse-time-string ignore PM/AM
Date: Tue, 11 Aug 2015 20:47:19 +0900 (JST)

[Message part 1 (text/plain, inline)]

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 <at> 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 <at> suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."
>

[parse-time_%p_%D.patch (text/plain, attachment)]

Message #38 received at 21229 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Andreas Schwab <schwab <at> suse.de>
Cc: Tino Calancha <f92capac <at> gmail.com>, 21229 <at> debbugs.gnu.org,
 Nicolas Richard <youngfrog <at> members.fsf.org>
Subject: Re: bug#21229: 24.5; parse-time-string ignore PM/AM
Date: Tue, 11 Aug 2015 12:05:49 -0400

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

Message #41 received at 21229 <at> debbugs.gnu.org (full text, mbox):

From: Tino Calancha <f92capac <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Tino Calancha <f92capac <at> gmail.com>, Andreas Schwab <schwab <at> suse.de>,
 21229 <at> debbugs.gnu.org, Nicolas Richard <youngfrog <at> members.fsf.org>
Subject: Re: bug#21229: 24.5; parse-time-string ignore PM/AM
Date: Wed, 12 Aug 2015 14:45:36 +0900 (JST)

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
>

Message #44 received at 21229 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Tino Calancha <f92capac <at> gmail.com>
Cc: f92capac <at> gmail.com, schwab <at> suse.de, 21229 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca, youngfrog <at> members.fsf.org
Subject: Re: bug#21229: 24.5; parse-time-string ignore PM/AM
Date: Wed, 12 Aug 2015 15:39:13 +0300

> Date: Wed, 12 Aug 2015 14:45:36 +0900 (JST)
> From: Tino Calancha <f92capac <at> gmail.com>
> Cc: Tino Calancha <f92capac <at> gmail.com>, Andreas Schwab <schwab <at> suse.de>,
> 	21229 <at> debbugs.gnu.org, Nicolas Richard <youngfrog <at> 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).

Message #47 received at 21229 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Richard <nrichard <at> members.fsf.org>
To: Tino Calancha <f92capac <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Andreas Schwab <schwab <at> suse.de>, 21229 <at> debbugs.gnu.org,
 Nicolas Richard <youngfrog <at> members.fsf.org>
Subject: Re: bug#21229: 24.5; parse-time-string ignore PM/AM
Date: Wed, 12 Aug 2015 14:41:00 +0200

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.

Message #50 received at 21229 <at> debbugs.gnu.org (full text, mbox):

From: Tino Calancha <f92capac <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Tino Calancha <f92capac <at> gmail.com>, schwab <at> suse.de, 21229 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca, youngfrog <at> members.fsf.org
Subject: Re: bug#21229: 24.5; parse-time-string ignore PM/AM
Date: Wed, 12 Aug 2015 21:46:51 +0900 (JST)

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 <at> gmail.com>
>> Cc: Tino Calancha <f92capac <at> gmail.com>, Andreas Schwab <schwab <at> suse.de>,
>> 	21229 <at> debbugs.gnu.org, Nicolas Richard <youngfrog <at> 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).
>

Message #53 received at 21229 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Tino Calancha <f92capac <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 21229 <at> debbugs.gnu.org
Subject: Re: bug#21229: 24.5; parse-time-string ignore PM/AM
Date: Mon, 24 Aug 2020 20:35:55 +0200

Tino Calancha <f92capac <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.