Fix parsing of non-year sets with "open middle"

[JeroenDeDauw]

Dates like this are currently not parsed correctly: {2020-01..2020-04} (result: 2020)

Those with years do work: {2020..2024}

Failing test can be found at: https://github.com/ProfessionalWiki/EDTF/commit/efae874792a377b992f1f293f7f927c4754d78b9

[JeroenDeDauw]

Should also verify things work correctly with open start and with open end.

[chaudbak]

Should we have a support for this case: {2020..2020-05}? Given that two values have different precision, should we throw an error? Or is it going to be array of 2020-01, 2020-02, 2020-03, 2020-04, 2020-05?

[JeroenDeDauw]

Excellent question. @mzeinstra

[mzeinstra]

That is indeed a good question. #58 might give us a way out of this?

On Sun, 21 Mar 2021 at 12:53, Jeroen De Dauw @.***> wrote:

Excellent question. @mzeinstra https://github.com/mzeinstra

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/ProfessionalWiki/EDTF/issues/55#issuecomment-803563564, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABK54J3DKO7XDCFVW6HJXKDTEXM43ANCNFSM4ZPE6UGA .

[JeroenDeDauw]

https://github.com/ProfessionalWiki/EDTF/issues/58 is a distinct issue.

The one raised by @chaudbak is about what {2020..2020-05} means in the first place. There are no examples of these ".. ranges" with mismatching precision (ie year and month) in the public spec, so perhaps it is not even valid EDTF.

[mzeinstra]

Ah I see now, I'll ask the experts.

[mzeinstra]

From our local experts

"The ISO standard says that the two time expressions in a range element (“..”) should be of the same precision. {2020-01..2020-05} is ISO standard “each month from January 2020 to May 2020, meaning that {2020..2020-05} is not ISO standard"

I would advise that we do not support {2020..2020-05}

[JeroenDeDauw]

@chaudbak so yes, we should throw an error if the precision is not the same

[JeroenDeDauw]

@chaudbak did you fully complete this task? If so, you can close it.