* bug#21229: 24.5; parse-time-string ignore PM/AM @ 2015-08-10 8:19 Tino Calancha 2015-08-10 17:29 ` Eli Zaretskii 0 siblings, 1 reply; 17+ messages in thread From: Tino Calancha @ 2015-08-10 8:19 UTC (permalink / raw) To: 21229 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)) ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#21229: 24.5; parse-time-string ignore PM/AM 2015-08-10 8:19 bug#21229: 24.5; parse-time-string ignore PM/AM Tino Calancha @ 2015-08-10 17:29 ` Eli Zaretskii 2015-08-10 17:35 ` Tino Calancha 0 siblings, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2015-08-10 17:29 UTC (permalink / raw) To: Tino Calancha; +Cc: 21229 > 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") ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#21229: 24.5; parse-time-string ignore PM/AM 2015-08-10 17:29 ` Eli Zaretskii @ 2015-08-10 17:35 ` Tino Calancha 2015-08-10 17:46 ` Eli Zaretskii 2020-08-24 18:35 ` Lars Ingebrigtsen 0 siblings, 2 replies; 17+ messages in thread From: Tino Calancha @ 2015-08-10 17:35 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Tino Calancha, 21229 |#> 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") > ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#21229: 24.5; parse-time-string ignore PM/AM 2015-08-10 17:35 ` Tino Calancha @ 2015-08-10 17:46 ` Eli Zaretskii 2015-08-11 2:36 ` Tino Calancha 2020-08-24 18:35 ` Lars Ingebrigtsen 1 sibling, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2015-08-10 17:46 UTC (permalink / raw) To: Tino Calancha; +Cc: f92capac, 21229 > 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#21229: 24.5; parse-time-string ignore PM/AM 2015-08-10 17:46 ` Eli Zaretskii @ 2015-08-11 2:36 ` Tino Calancha 2015-08-11 8:32 ` Nicolas Richard 0 siblings, 1 reply; 17+ messages in thread From: Tino Calancha @ 2015-08-11 2:36 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Tino Calancha, 21229 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. > ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#21229: 24.5; parse-time-string ignore PM/AM 2015-08-11 2:36 ` Tino Calancha @ 2015-08-11 8:32 ` Nicolas Richard 2015-08-11 10:37 ` Tino Calancha 0 siblings, 1 reply; 17+ messages in thread From: Nicolas Richard @ 2015-08-11 8:32 UTC (permalink / raw) To: Tino Calancha; +Cc: 21229 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#21229: 24.5; parse-time-string ignore PM/AM 2015-08-11 8:32 ` Nicolas Richard @ 2015-08-11 10:37 ` Tino Calancha 2015-08-11 10:40 ` Andreas Schwab 0 siblings, 1 reply; 17+ messages in thread From: Tino Calancha @ 2015-08-11 10:37 UTC (permalink / raw) To: Nicolas Richard; +Cc: Tino Calancha, 21229 [-- 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) ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#21229: 24.5; parse-time-string ignore PM/AM 2015-08-11 10:37 ` Tino Calancha @ 2015-08-11 10:40 ` Andreas Schwab 2015-08-11 10:52 ` Tino Calancha 2015-08-11 16:05 ` Stefan Monnier 0 siblings, 2 replies; 17+ messages in thread From: Andreas Schwab @ 2015-08-11 10:40 UTC (permalink / raw) To: Tino Calancha; +Cc: 21229, Nicolas Richard 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." ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#21229: 24.5; parse-time-string ignore PM/AM 2015-08-11 10:40 ` Andreas Schwab @ 2015-08-11 10:52 ` Tino Calancha 2015-08-11 11:00 ` Andreas Schwab 2015-08-11 16:05 ` Stefan Monnier 1 sibling, 1 reply; 17+ messages in thread From: Tino Calancha @ 2015-08-11 10:52 UTC (permalink / raw) To: Andreas Schwab; +Cc: Tino Calancha, 21229, Nicolas Richard "%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." > ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#21229: 24.5; parse-time-string ignore PM/AM 2015-08-11 10:52 ` Tino Calancha @ 2015-08-11 11:00 ` Andreas Schwab 2015-08-11 11:47 ` Tino Calancha 0 siblings, 1 reply; 17+ messages in thread From: Andreas Schwab @ 2015-08-11 11:00 UTC (permalink / raw) To: Tino Calancha; +Cc: 21229, Nicolas Richard 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." ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#21229: 24.5; parse-time-string ignore PM/AM 2015-08-11 11:00 ` Andreas Schwab @ 2015-08-11 11:47 ` Tino Calancha 0 siblings, 0 replies; 17+ messages in thread From: Tino Calancha @ 2015-08-11 11:47 UTC (permalink / raw) To: Andreas Schwab; +Cc: Tino Calancha, 21229, Nicolas Richard [-- 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) ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#21229: 24.5; parse-time-string ignore PM/AM 2015-08-11 10:40 ` Andreas Schwab 2015-08-11 10:52 ` Tino Calancha @ 2015-08-11 16:05 ` Stefan Monnier 2015-08-12 5:45 ` Tino Calancha 1 sibling, 1 reply; 17+ messages in thread From: Stefan Monnier @ 2015-08-11 16:05 UTC (permalink / raw) To: Andreas Schwab; +Cc: Tino Calancha, 21229, Nicolas Richard >> 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#21229: 24.5; parse-time-string ignore PM/AM 2015-08-11 16:05 ` Stefan Monnier @ 2015-08-12 5:45 ` Tino Calancha 2015-08-12 12:39 ` Eli Zaretskii 2015-08-12 12:41 ` Nicolas Richard 0 siblings, 2 replies; 17+ messages in thread From: Tino Calancha @ 2015-08-12 5:45 UTC (permalink / raw) To: Stefan Monnier; +Cc: Tino Calancha, Andreas Schwab, 21229, Nicolas Richard 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 > ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#21229: 24.5; parse-time-string ignore PM/AM 2015-08-12 5:45 ` Tino Calancha @ 2015-08-12 12:39 ` Eli Zaretskii 2015-08-12 12:46 ` Tino Calancha 2015-08-12 12:41 ` Nicolas Richard 1 sibling, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2015-08-12 12:39 UTC (permalink / raw) To: Tino Calancha; +Cc: f92capac, schwab, 21229, youngfrog > 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). ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#21229: 24.5; parse-time-string ignore PM/AM 2015-08-12 12:39 ` Eli Zaretskii @ 2015-08-12 12:46 ` Tino Calancha 0 siblings, 0 replies; 17+ messages in thread From: Tino Calancha @ 2015-08-12 12:46 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Tino Calancha, schwab, 21229, youngfrog 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). > ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#21229: 24.5; parse-time-string ignore PM/AM 2015-08-12 5:45 ` Tino Calancha 2015-08-12 12:39 ` Eli Zaretskii @ 2015-08-12 12:41 ` Nicolas Richard 1 sibling, 0 replies; 17+ messages in thread From: Nicolas Richard @ 2015-08-12 12:41 UTC (permalink / raw) To: Tino Calancha, Stefan Monnier; +Cc: Andreas Schwab, 21229, 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#21229: 24.5; parse-time-string ignore PM/AM 2015-08-10 17:35 ` Tino Calancha 2015-08-10 17:46 ` Eli Zaretskii @ 2020-08-24 18:35 ` Lars Ingebrigtsen 1 sibling, 0 replies; 17+ messages in thread From: Lars Ingebrigtsen @ 2020-08-24 18:35 UTC (permalink / raw) To: Tino Calancha; +Cc: 21229 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2020-08-24 18:35 UTC | newest] Thread overview: 17+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-08-10 8:19 bug#21229: 24.5; parse-time-string ignore PM/AM Tino Calancha 2015-08-10 17:29 ` Eli Zaretskii 2015-08-10 17:35 ` Tino Calancha 2015-08-10 17:46 ` Eli Zaretskii 2015-08-11 2:36 ` Tino Calancha 2015-08-11 8:32 ` Nicolas Richard 2015-08-11 10:37 ` Tino Calancha 2015-08-11 10:40 ` Andreas Schwab 2015-08-11 10:52 ` Tino Calancha 2015-08-11 11:00 ` Andreas Schwab 2015-08-11 11:47 ` Tino Calancha 2015-08-11 16:05 ` Stefan Monnier 2015-08-12 5:45 ` Tino Calancha 2015-08-12 12:39 ` Eli Zaretskii 2015-08-12 12:46 ` Tino Calancha 2015-08-12 12:41 ` Nicolas Richard 2020-08-24 18:35 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).