Regression in parsing of 'X' from 3.0.8 to 3.1.1 ?

[dchandekstark]

3.0.8

irb(main):002:0> d = Date.edtf('199X')
=> Mon, 01 Jan 1990..Fri, 31 Dec 1999
irb(main):003:0> d.class
=> EDTF::Decade

3.1.1

irb(main):002:0> d = Date.edtf('199X')
=> Mon, 01 Jan 1990
irb(main):003:0> d.class
=> Date

[inukshuk]

This is probably intentional. '199X' is a single year in the 1990s, but it's not specified which one. This is semantically different from the decade which covers all the years of the 90s.

This library was written when EDTF was still a draft -- there were some changes to the syntax when it was adopted by ISO. I've updated the grammar since then, but only in edtf.js so far. I haven't had the time to update the Ruby library with the new grammar, but we had a PR for version 3.1 to align with some of the changes (including the X unspecified symbol). This is what caused the change.

At some point I'd like to update Ruby version using the grammar and API I use in edtf.js. There '199X' gives you an unspecified year (with a min/max range of 1990 to 1999). To get the decade you'd have to use the unfortunate (in my opinion) three-letter syntax '199' or the interval '1990/1999' which is probably more intuitive.

[dchandekstark]

@inukshuk Thanks for your thoughtful reply. If I read the standard correctly as represented on the LoC page, what we want for our use case is probably the "set representation" [1990..1999]. Confusion seems to arise in the distinctions between the "levels" of support. In Level 1, 199X is possibly the closest you can get to the Level 2 "set representation", and it sounds like edtf.js could more or less give us that as you mention. I might try using the js lib in our Ruby code as a test.

[inukshuk]

Good point, the set representation is also a possibility. The difference between that and the interval syntax, I believe is that with the set you explicitly state that you mean those individual years, not the entire decade.

The way it's implemented in edtf.js they would be almost the same though. The idea is that each extended date can be mapped to an exact time range and also enumerated. For example, 1990/1999 will cover (in comparisons) the full range from 00:00 on 1990-01-01 to 24:00 1999-12-31 UTC. But since both ends have year precision, if you enumerate the interval, you will get a list of the individual years. Of course this is a tricky with mixed precisions, e.g. 1990/199-04 makes sense for comparisons, but when enumerating the current implementation would give you all the years and then also the month of April '99.