From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.bugs Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates Date: Wed, 29 Dec 2021 11:29:44 -0800 Organization: UCLA Computer Science Department Message-ID: References: <7c22f300-eedb-da65-db02-e82025ec2f48@cs.ucla.edu> <25023.40959.627321.685762@orion.rgrjr.com> <875yrjpp03.fsf@gnus.org> <25024.42989.718735.680188@orion.rgrjr.com> <871r26i5n0.fsf@gnus.org> <25028.53876.304365.706795@orion.rgrjr.com> <87zgoq2vwm.fsf@gnus.org> <25029.60989.564217.290743@orion.rgrjr.com> <87bl1428x5.fsf@gnus.org> <25031.40994.286546.498819@orion.rgrjr.com> <87ee5zzjpg.fsf@gnus.org> <25035.12991.328986.987982@orion.rgrjr.com> <87o84z782g.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2292"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Cc: 52209@debbugs.gnu.org To: Lars Ingebrigtsen , Bob Rogers Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Dec 29 20:31:18 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n2efO-0000S9-Nn for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 29 Dec 2021 20:31:18 +0100 Original-Received: from localhost ([::1]:38864 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n2efC-0006Ue-GP for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 29 Dec 2021 14:31:10 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:51372) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n2eeA-0006QL-Rh for bug-gnu-emacs@gnu.org; Wed, 29 Dec 2021 14:30:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:38852) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n2eeA-0001d2-Gy for bug-gnu-emacs@gnu.org; Wed, 29 Dec 2021 14:30:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1n2eeA-0008Bt-8i for bug-gnu-emacs@gnu.org; Wed, 29 Dec 2021 14:30:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Dec 2021 19:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 52209 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 52209-submit@debbugs.gnu.org id=B52209.164080619431447 (code B ref 52209); Wed, 29 Dec 2021 19:30:02 +0000 Original-Received: (at 52209) by debbugs.gnu.org; 29 Dec 2021 19:29:54 +0000 Original-Received: from localhost ([127.0.0.1]:50398 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n2ee2-0008B9-Av for submit@debbugs.gnu.org; Wed, 29 Dec 2021 14:29:54 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:39500) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n2ee0-0008As-M2 for 52209@debbugs.gnu.org; Wed, 29 Dec 2021 14:29:53 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 6D4A91600FC; Wed, 29 Dec 2021 11:29:46 -0800 (PST) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id rfE8RBBswkLC; Wed, 29 Dec 2021 11:29:44 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id BF903160142; Wed, 29 Dec 2021 11:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Y2Lqi8anLUWk; Wed, 29 Dec 2021 11:29:44 -0800 (PST) Original-Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 913931600FC; Wed, 29 Dec 2021 11:29:44 -0800 (PST) Content-Language: en-US In-Reply-To: <87o84z782g.fsf@gnus.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:223377 Archived-At: On 12/29/21 07:19, Lars Ingebrigtsen wrote: > Bob Rogers writes: > >> I am currently working on broadening what the parser will accept, >> though I think it is close to a usable state. > > Makes sense to me. Perhaps Paul has some comments; added to the CCs. My first comment is "be careful what you're getting into" :-). I'm trying to retire from date-parsing as its users are never happy and rightly so. But here goes. I took a quick look at and have a few comments. * Calling it parse-date is a bit confusing, as it parses both dates and times. I suggest calling it parse-timestamp or parse-date-time instead. (I know the existing package is called parse-time but we can't fix that.) * If the package is called X, the error should be called X-error. Currently the package is called parse-date and the error is called date-parse-error, which is confusing. * The patch should also modify the comment at the start of parse-time.el to indicate parse-date-time as another possibility. * I suggest preferring the symbol 'rfc-email' for parsing email-related dates, for consistency with the --rfc-email option of GNU 'date'. This should use the current RFC (5322 now, perhaps updated later). I suppose you could also advertise 'rfc-822' for strict RFC 822 conformance, and similarly 'rfc2822' for strict 2822 conformance, but I expect these alternatives would be less useful in practice. > + nil => like us-date with two-digit years disallowed. This doesn't sound like a good default. For example, it completely mishandles dates in Brazil, which use DD/MM/YYYY format. > +Anything else is treated as iso-8601 if it looks similar, else > +us-date with two-digit years disallowed. This might be a better default (for nil), but it should have an explicit name other than nil. > + * For all formats except iso-8601, parsing is case-insensitive. It's pretty common for ISO 8601 parsers to be case-insensitive. For example, Java's OffsetDateTime.parse(CharSequence) allow both lower and upper case T and Z. Perhaps some people need strict ISO 8601 parsers, but I imagine a more-generous parser would be more useful. So you could have iso-8601 and iso-8601-strict; or you could have a strictness arg; or something like that. > + * Commas and whitespace are ignored. This is quite wrong for some formats, if you want to be strict. And even if not, commas are part of ISO 8601 format and can't be ignored if I understand what you mean by "ignored". > + * Two digit years, when allowed, are in the 1900's when > +between 50 and 99 inclusive and in the 2000's when between 0 and > +49 inclusive. This disagrees with the POSIX standard for 'date' (supported by GNU 'date'), which says 69-99 are treated as 1969-1999 and 00-68 are treated as 2000-2068. I suggest going with the POSIX heuristic if you're going to use a fixed heuristic for dates at all. Better might be to have an optional argument of context specifying the default time for incomplete timestamps. You can use that the context to fill in more-significant parts that are missing. E.g., if the year is missing, you take it from the context; if the century is missing, you take that from the context. The default context would be empty, i.e., missing years or centuries would be an error. For more formats that need parsing, see: https://en.wikipedia.org/wiki/Date_format_by_country https://metacpan.org/search?q=datetime%3A%3Aformat You don't need to support them all now, but you should take a look at what's out there and make sure the API can be extended to handle them.