inukshuk/edtf.js

Inconsistent behavior for iterators on unspecified dates

SylvainBigonneau opened this issue · 3 comments

Using EDTF.js v2.7.0, I am getting weird results with the next() iterator when applying it on unspecified years:

> edtf('201X').next().edtf // expecting "202X"... good
"202X"
> edtf('201X').prev().edtf // expecting "200X"... wrong
"201X"
> edtf('-22XX').next().edtf // expecting "-21XX"... wrong
"23XX"
> edtf('-22XX').prev().edtf // expecting "-23XX"... wrong
"22XX"

Not sure if unspecified years are supposed to be iterable, but the fact that the first test works makes me think they are.

Thanks, you're right! We currently expand the unspecified 'range' to its maximum (i.e., to 2019 in this example), but we need to use the minimum when subtracting.

Can you try with the latest changes? I've added checking for the minimum unspecified range.

If the reported edtf strings work as expected we could leave it as is, or, perhaps better normalize it, by resetting the result to the minimum always. Currently, when unspecified masks are in play, there is no normalized fixed point for each interval. For example, if you parse '201X' the parser will set the year to 2010, but because of the mask the real range is 2010-2019. A date with the same mask and the year set to 2016 would cover the same 'unspecified range'. Currently, using next will push you to the minimum of the next range and prev will push you to the maximum of the previous range.

Can you try with the latest changes? I've added checking for the minimum unspecified range.

Thanks, it works great on my side!

If the reported edtf strings work as expected we could leave it as is, or, perhaps better normalize it, by resetting the result to the minimum always. Currently, when unspecified masks are in play, there is no normalized fixed point for each interval. For example, if you parse '201X' the parser will set the year to 2010, but because of the mask the real range is 2010-2019. A date with the same mask and the year set to 2016 would cover the same 'unspecified range'. Currently, using next will push you to the minimum of the next range and prev will push you to the maximum of the previous range.

I don't have much of an opinion on this, I personally avoid using the builtin date methods, especially on unspecified dates...