Allow unspecified dates in iso8601-valid-p?

Allow unspecified dates in iso8601-valid-p?

[Joost Kremers]

Hi list,

The function `iso8601-valid-p` can be used to check if a string constitutes a
valid ISO8601-formatted date. It seems that ISO8601 is a big spec with several
modifications and extensions, so I'm sure it's hardly doable to support
everything the spec allows, but I'm wondering if it would be possible to allow
unspecified dates.

The relevant spec is described here:

https://www.datafix.com.au/BASHing/2020-02-12.html

(There are several parts here, the one I'm referring to is under "Unspecified").
It explains that a capital X can be used to indicate parts of a date that are
unspecified, i.e., "20XX" for a year in the 21st century.

The reason behind this request is that `bibtex.el`, when creating a key for an
entry, checks the date field against `iso8601-valid-p` and errors out if it
finds an invalid date. Problem is that sometimes publication dates simply are
not known or cannot be given, which is exactly the kind of reason why the
unspecified date extension to ISO8601 exists.

One option would be to add an additional argument to `iso8601-valid-p` that
indicates whether to allow unspecified dates or not, but in that case,
`bibtex.el` would have to be adjusted as well.

TIA

Joost


-- 
Joost Kremers
Life has its moments

Allow unspecified dates in iso8601-valid-p?

[Bob Rogers]

   From: Joost Kremers <joostkremers@fastmail.fm>
   Date: Mon, 04 Jul 2022 14:47:08 +0200

   Hi list,

   The function `iso8601-valid-p` can be used to check if a string
   constitutes a valid ISO8601-formatted date. It seems that ISO8601 is
   a big spec with several modifications and extensions, so I'm sure
   it's hardly doable to support everything the spec allows, but I'm
   wondering if it would be possible to allow unspecified dates.

   The relevant spec is described here:

   https://www.datafix.com.au/BASHing/2020-02-12.html

   (There are several parts here, the one I'm referring to is under
   "Unspecified").  It explains that a capital X can be used to indicate
   parts of a date that are unspecified, i.e., "20XX" for a year in the
   21st century . . .

Parsing such dates would seem to require a fair amount of work, as the
design of iso8601.el does not consider partially-specified date values.
What is more, the return value is in terms of decoded time objects,
which can only describe them as either present or absent.

   But if you only want to test ISO 8601 compliance, then ISTM it would
be better (and much easier) to write a new and completely separate
`iso8601-compliant-p` predicate for that purpose, since the charter of
`iso8601-valid-p` is to tell whether iso8601.el can parse something.

					-- Bob Rogers
					   http://www.rgrjr.com/

Re: Allow unspecified dates in iso8601-valid-p?

[Joost Kremers]

On Mon, Jul 04 2022, Bob Rogers wrote:
> Parsing such dates would seem to require a fair amount of work, as the
> design of iso8601.el does not consider partially-specified date values.
> What is more, the return value is in terms of decoded time objects,
> which can only describe them as either present or absent.

Ok, I see your point.

>    But if you only want to test ISO 8601 compliance, then ISTM it would
> be better (and much easier) to write a new and completely separate
> `iso8601-compliant-p` predicate for that purpose, since the charter of
> `iso8601-valid-p` is to tell whether iso8601.el can parse something.

The question then becomes if it's useful to write such a function, or would it
make more sense to account for unspecified dates in the relevant part of
bibtex.el.



-- 
Joost Kremers
Life has its moments

Re: Allow unspecified dates in iso8601-valid-p?

[Stefan Monnier]

> The question then becomes if it's useful to write such a function, or would it
> make more sense to account for unspecified dates in the relevant part of
> bibtex.el.

Not sure where it should live, but it could start with a hack like

    (defun iso8601-compilant-p (date)
      (iso8601-valid-p (replace-regexp-in-string "[xX]" "1" date)))


-- Stefan