Nick Bart <[log in to unmask]>:
> I’m not sure what the roadmap for ISO 8601 looks like, and yes, I’ve seen the message stating “at this stage no further technical changes are allowed without compelling reason”.
I believe what was meant with that was that the use of 21 through 24 in Level 1 (and so on for Level 2) for "seasons" in the numeric MM field could not be reconsidered any more. However, ...
> Still, I’d like to object to the “decision” that season intervals “won't be supported (not initially at least)”, and I would indeed argue that there is a compelling reason to make that change, even late in the day.
... I thought the whole reason for overloading this field was that many implementations would hardly need to change at all. In particular, it would probably be more complicated to explicitly disallow stuff like 1980-23/1981-22 than to implicitly allow it.
> Given that YYYY-MM/YYYY-MM and YYYY-SS are valid, YYYY-SS/YYYY-SS is a highly straightforward and not in the least ambiguous or otherwise problematic representation.
> (In fact, at least three popular reference management packages, Zotero, biblatex, and pandoc, have been using the YYYY-SS/YYYY-SS notation for some time now –
Biblatex seems to have adopted EDTF Level 1 back in mid-2016 and [Pandoc] is built upon that. I couldn't find anything specific to seasons in the Zotero documentation except that [CSL] supports 4 named seasons in output.
If Biblatex indeed supports MM values 21 through 24 also in intervals, that proves my point. Implementations will just treat them like 01 through 12, except when they are strongly validating dates. It is not helpful to differentiate SS from MM, better only use the latter.
> and, frankly, I don’t see what else they could use if they both wish to use the ISO 8601 date format, and need to process season intervals.)
If seasons were exact terms their start and end dates could be converted to one of the other ISO formats of course, especially in intervals.