season range not recognized

[retorquere]

0011-21/0012-22 is not recognized by EDTF.js even though 0011-21 and 0012-22 are.

[inukshuk]

Thanks for reporting this issue @retorquere and @njbart! Seasons in intervals are rejected by the parser on purpose, because they are not valid (to the best of my knowledge). Looking at section 4.4 of the spec my understanding is that level 1 extends the ISO intervals by:

• Unknown and open start or end
• Uncertain and/or approximate start or end

And at level 2:

• Partial uncertain and/or approximate start or end
• Before or after tags

It does not mention intervals including 'seasons' (defined as sections of a year in section 4.7); there are multiple extended features, which, to my understanding, are not valid in intervals (e.g., long years, one of a set, multiple dates, etc.).

I think it would be relatively easy to add support for seasons in intervals, but I would like to be confident that it is actually valid. Alternatively, we could add it as a non-standard level 3 feature (to make it possible to switch it off), but if this is non-standard, I wonder if it really makes sense to do that -- shouldn't we try to use a standard syntax instead?

If we implement this, we'd also need to be clear if intervals should be strictly between seasons or if date / seasons intervals should be allowed. All EDTF objects have a shared interface (i.e., they have a min/max timestamp and can be enumerated) so mixed intervals are probably OK.

[inukshuk]

Searching the EDTF list archive, I found a suggestion to allow seasons in intervals, specifically for publication references. But it seems to me like this was not picked up for ISO 8601?

[retorquere]

4.4 doesn't mention seasons, no, but the way I'm reading it, it says "you can add these qualifiers to valid start/end dates", but doesn't specify there further restrictions on the dates. It does list a few samples under "formats", but those would also exclude 1980-04/1980-06.

[inukshuk]

The EBNF in Annex A definitely covers 1980-04/1980-06 in the L1Interval rule but does not include divisions/seasons.

[njbart]

Maybe I’m mistaken, but my interpretation is that 4.7 from the 2016-10-26 draft permits any year-and-month expression to be replaced by a year-and-season expression – and I think it’s uncontroversial that year-and-month ranges/intervals such as 1980-04/1980-06 are valid:

“4.7 Divisions of a year
For a year-and-month expression (e.g. 1984-04) the month component may take on values of 21 or above (in place of a month value, 01 through 12). These values signify a division of a year (e.g. “the season Spring”).
4.7.1 Level 1
The values 21, 22, 23, 24 may be used to signify ' Spring', 'Summer', 'Autumn', 'Winter', respectively. Format: YYYY-SS
Example:
· 2001-21 (Spring, 2001)”

[njbart]

@JohnLukeBentley – I know you have been involved in implementing ISO 8601/EDTF for biblatex, and have started the process of joining up to the relevant ISO committee – any additional insights from you?

[inukshuk]

It was just confirmed on the EDTF mailing list that seasons in intervals will not be supported by the upcoming standard.

I'm open to try and add this as an experimental feature (which can be turned off), however, if it's not going to be supported by the standard, I wonder if it wouldn't be better to prefer a different notation,

[retorquere]

I'm not at all up to speed with how the standard evolved, but it would seem odd to me to pick a different notation for seasons depending on the context where they're used.

[retorquere]

(BBT already has a workaround in place, BTW, so from my POV this is not urgent)

[njbart]

It was just confirmed on the EDTF mailing list that seasons in intervals will not be supported by the upcoming standard.

That decision – if that’s the final word – is deeply regrettable. In my opinion, it needs to be reversed as soon as possible, and we should try and find a way to make the voice of the CSL (and biblatex) community heard here. After all, season intervals are by no means uncommon in bibliographic data (one example from the Chicago Manual of Style, 16e, 14.271: “Autumn 1980–Summer 1981”), and they need to be entered, represented, and processed somehow. It just does not make any sense to promote ISO 8601/EDTF in general (including seasons – “do use 1980-23”), but at the same time introduce an exception for season intervals (“do not use 1980-23/1981-22”).

I wonder if it wouldn't be better to prefer a different notation

But how could that look like? In my opinion, given that YYYY-MM/YYYY-MM and YYYY-SS are valid, YYYY-SS/YYYY-SS is the only straightforward representation there is.

(BTW, biblatex does accept the YYYY-SS/YYYY-SS format in a date field, too.)

I'm open to try and add this as an experimental feature (which can be turned off)

I’m all in favour.

This would certainly facilitate the adoption of EDTF.js in all contexts where season ranges need to be processed (I’m thinking about, for example, citeproc-js), but it would also document the general need for this feature by way of including it in a reference implementation.