Export date range YYYY-MM-DD_YYYY-MM-DD as literal date

nickbart

Zotero cannot export date ranges, but a common workaround is to use an underscore as range separator, and replace it manually when using Zotero with LibreOffice or Word (https://forums.zotero.org/discussion/6111/2/better-date-field/#Item_14).

Unlike Zotero, pandoc-citeproc automatically parses "literal" dates of the form YYYY_YYYY in CSL JSON as date ranges (https://github.com/jgm/pandoc-citeproc/issues/65).

In order to be able to use date ranges with months and days, too, at least with pandoc-citeproc, it would be useful if Zotero exported any date containing an underscore, or at least all dates of the form YYYY_YYYY, YYYY-MM_YYYY-MM, and YYYY-MM-DD_YYYY-MM-DD to CSL JSON as "literal" dates.

In addition, I suggest to allow the use of a double hyphen instead of an underscore in such cases, too. Unlike an underscore, this is a standard way of representing a date range separator, and is in fact endorsed by ISO 8601, sec. 4.4.2: "In certain application areas a double hyphen is used as a separator instead of a solidus."

nickbart

Pinging this issue – any reason why dates containing underscores should not uniformly be exported to CSL JSON as "literal" – or, even better, properly parsed?

Currently, exporting an entry with a date field "2014-01-03_2014-02-04" to CSL JSON produces the odd:

"issued": {
"date-parts": [
[
"2014",
1,
3
]
],
"season": "2014-02-04"
},
rather than the expected:

"issued": {
"literal": "2014-01-03_2014-02-04"
},
Or, properly parsed:

"issued": {
"date-parts": [
[ 2014, 1, 3 ]
[ 2014, 2, 4 ]
],
},

aurimas

We first need to settle on proper backend format for dates (issue here), then we can think about converting it to CSL JSON on export.

nickbart

My point is merely: There is an existing, well-known workaround for date ranges, using an underscore to have the date exported as "literal", which then gives users the option to fix it manually (or, when using pandoc-citeproc, automatically).
Couldn’t zotero simply export ALL dates containing underscores as "literal", giving users the option to fix more complex dates themselves, too, rather than parsing dates in a way that is unexpected and doesn’t really seem to serve a useful purpose.

aurimas

That's the thing with workarounds. They're not explicitly intended behavior. I don't think Zotero will put in explicit code to support this format (at least that's my view on it, Dan may disagree). Once we can establish proper date formats for ranges, etc., Zotero will support exporting them correctly to CSL.

I'm also not sure how I feel about exporting all dates with underscores as literal. I'm mostly concerned about automatically imported dates that would suffer from this, not so much user-entered data.

nickbart

Ok, I'll try again from a somewhat different angle:

Zotero does use somewhat hackish solutions at times if necessary, e.g., specifying additional fields in the "Extra" field.

I don't really understand why an even less hackish approach can't be tried for the date field – with the perspective of migrating to a more permanent solution once that becomes available, of course.

So, my proposal: Allow date ranges in the ISO 8601 (3e 2004) format1985/1986
1985-04/1986-06
1985-04-12/1986-06-25or, if you are worried about the slash or solidus "/", accept ISO 8601's alternative, a double hyphen1985--1986
1985-04--1985-06
1985-04-12--1985-06-25
If Zotero parsed these exact three patterns with either or both of the separators, I fail to see how any of these could be confused with anything that is not intended to be read as a date range, neither in user-entered nor in automatically imported dates.

And it would really solve the issue of date ranges being unavailable in Zotero for the time being, even without the current "replace the underscore later" hack.

nickbart

What's more, it turns out that {:issued: 2012-01-22/2012-02-23} in Zotero's "Extra" field is exported as is – and, provided the "Date" field itself is empty, citeproc-js can actually parse and render this date range correctly, including both months and days. So all it would take for this to work nicely is to keep Zotero from parsing obvious ISO date ranges in its own (incorrect) way, and to just export them as-is.

nickbart

Pardon me for being insistent, but have you considered that the current way EDTF Level 0 date strings are parsed does not make the least bit of sense – in particular the appearance of the bizarre “season” element?

We’re just talking about the patterns “dddd/dddd”, “dddd-dd/dddd-dd”, and “dddd-dd-dd/dddd-dd-dd” (“d” for digit). None of these could possibly be confused with any other date format I ever came across – in particular since years must have four digits –, so it’d be great if these – and just these for the moment – could be parsed as what they clearly are supposed to be, i.e., date ranges.

Examples of current, incorrect output:

1985/1986

is exported to CSL JSON:

"issued": {
    "date-parts": [
        [
            "1985"
        ]
    ],
    "season": "1986"
}

1985-04/1986-06

is exported to CSL JSON:

"issued": {
    "date-parts": [
        [
            "1985"
        ]
    ],
    "season": "1986-06"
}

and 1985-04-12/1986-06-25

is exported to CSL JSON:

"issued": {
    "date-parts": [
        [
            "1985",
            4,
            12
        ]
    ]
}

Quite clearly, these should be exported as (last example only):

"issued": {
    "date-parts": [
        [
            "1985",
            4,
            12
        ],
        [
            "1986",
            6,
            25
        ]
    ]
}

I really hope this relatively small fix can be introduced soon. For the time being this would completely fix the annoying issue of Zotero not being able to handle date ranges at all.