Date ranges, fuzzy dates, dates BCE

[fbennett]

Dates are in flux at the moment, with a firm desire in CSL circles to rely on the Library of Congress EDTF (Extended Date Time Format) standard, but with uncertainty over whether, when eventually finished, that standard will cover all of the use cases needed for rendering citations.

When EDTF becomes available, work will remain to build and test out revisions to the parsing module behind the Zotero UI, for the support of date ranges, fuzzy dates, and dates BCE.

As a first step toward that eventual goal, the attached patch (against the current trunk at r7344) supplies an option that will send the raw date string stored by Zotero to citeproc-js when formatting citations, for onward processing by the processor's own internal parsing module.

This isn't meant as a permanent solution, and I've given the option an ugly name to underline its temporary nature; but it does provide a channel for testing the parser behavior, against the day when agreement can be reached on a serialized date form suitable for data exchange and official recognition in a well specified CSL input format. If the parser proves sufficiently robust, it may also provide a solution for users who require support for these kinds of dates.

[ajlyon]

Would it be feasible to make the EDTF parser a separate project from citeproc-js, so that Zotero doesn't have to (1) copy the code into the Zotero codebase or (2) call citeproc-js to get parsed dates?

Of course, option 2 isn't that bad, since citeproc-js is part of Zotero anyway, but maybe making a closely related edtf-js might be a better solution. One might imagine that a JavaScript implementation of the new EDTF standard would be widely useful.

[dstillman]

That's probably a good idea. Passing a 'raw' date is trivial, as Frank's patch shows, but Zotero uses strToDate() (its own date-parsing function) all over the codebase for various things, and not having access to all the parsed dates could be a problem.

If there was an edtf-js, I'd also port it to PHP for use on the server.

[fbennett]

Putting date parsing in a separate module shared between CSL and Zotero is an excellent idea. There would need to be compromises, since EDTF is both over- and (possibly) under-inclusive of our needs.

There are two layers: the parsing of feral dates into EDTF, and the parsing of house-broken EDTF itself. In parsing feral dates, a parser should be aimed at data required for citations -- the time, fine-grained imprecision, days-after-a-date, week-of-the-year, stuff like that should be abandoned to save complexity. The same goes for house-broken dates: it would be up to the implementer whether to support things like Nth day of the year.

On the under-inclusive side, the current EDTF draft explicitly excludes seasons from its coverage (presumably because EDTF is meant for specifying precise dates and times, and seasons are ambiguous). If that position doesn't change, we'll need to accept the need to diverge from the standard, and reach a general agreement among CSL-related projects about how to shoehorn seasons into an otherwise-conformant EDTF date string:

​http://www.loc.gov/standards/datetime/spec.html