GNU bug report logs -
#52209
28.0.60; [PATCH] date-to-time fails on pure dates
Previous Next
Full log
Message #64 received at 52209 <at> debbugs.gnu.org (full text, mbox):
On 12/29/21 07:19, Lars Ingebrigtsen wrote:
> Bob Rogers <rogers-emacs <at> rgrjr.homedns.org> 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
<https://bugs.gnu.org/52209#58> 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.
This bug report was last modified 3 years and 172 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.