Implement parse and equality for intervals with open begin dates.

[grosscol]

I've run across the issue of not being able to compare intervals that have an open begin dates. In order to test translating date ranges to and from user input fields for start and end, I needed to check that the resulting interval was equal to the expected value for the input. This works well for intervals with a begin date, but does not work when the begin date is left unbounded.

# Open end date intervals are created as expected.
Date.edtf('2015/open')
EDTF::Interval.new(EDTF.parse('2016'), :open)
#<EDTF::Interval:0x00559308b1acd8 @from=Fri, 01 Jan 2016, @to=:open>
#<EDTF::Interval:0x00559308fbc228 @from=Fri, 01 Jan 2016, @to=:open>

# Open begin date intervals are not created as expected.
Date.edtf('open/2012')
EDTF::Interval.new(:open, EDTF.parse('2013'))
# nil
# <EDTF::Interval:0x00559308bfb5d0 @from=:open, @to=Tue, 01 Jan 2013>

# Equality comparison of intervals does not function with open begin dates.
a = EDTF::Interval.new(:open, EDTF.parse('2013'))
b = EDTF::Interval.new(:open, EDTF.parse('2013'))
a == b
#expected true.  Recieved: 
#  ArgumentError: comparison of Date with :open failed
#  .../ruby/gems/2.3.0/gems/edtf-2.3.1/lib/edtf/interval.rb:201:in `<'

[inukshuk]

This is the expected behavior: 'open' may be used when no end date is specified. (You can have an 'unknown' start though)

I think with the upcoming ISO 8601-2 profile open starts will be possible (it will probably be one of '/2016', '*/2016' or '../2016' depending on which proposed syntax is adopted).

[inukshuk]

Hmm, but we should probably throw an error for EDTF::Interval.new(:open, EDTF.parse('2013')) to avoid confusion.

[grosscol]

I see. So unknown is the value I should have been using. I must have missed that reading through the parser. I concur about throwing an error when open is specified. Do you think ArgumentError would be appropriate?

[inukshuk]

Yes, I'd say ArgumentError would be appropriate. Though we shouldn't throw it in the constructor but define a setter for from/to instead.

The other problem is with the exception when comparing the two intervals, because I this would happen if you use :unknown too. Do you think it would make sense to return Infinity or -Infinity instead of nil for open/unknown?

[grosscol]

Hmm... I hadn't considered that case since I am explicitly avoiding Date.edtf('unknown/open'). Although open on both ends is a theoretically valid interval. It's the corner case.

For an open interval, I would expect:
min to return 0
max to return Infinity
coverage and inclusion to be entirely dependent on the defined side if start or end isn't unknown/open
coverage and inclusion to be nil for an unknown/open interval

Maybe handling unknown/open could be another ticket. There might be some folks from DPLA who would chime in on that thread.

[no-reply]

👍 on ArgumentError for #new(:open, end_date) and 👍 for a new ticket dealing with interval comparison.

[inukshuk]

I agree @no-reply

I added Argument Errors if from is anything other than a date or :unknown; or if to is anything other than a date, :unknown, or :open