A little correction to what I wrote: Date.new(2000,1,1,Date::GREGORIAN) inspects to #<Date: 2000-01-01 ((2451545j,0s,0n),+0s,-Infj)>
The "-infj" made me think this was representing a 'negative infinity' DateTime... a comment in ruby's ext/date/date_core.c led me astray. It says: Date.new(2001,2,3,Date::GREGORIAN).start #=> -Infinity It turns out this -Infinity is a constant in Float, and not a DateTime. The DateTime::Infinity class is defined in ext/date/lib/date.rb and looks like it was meant to be able to represent both infinities, but the class is incomplete at best. So, it looks like my best option may be to implement some of Range's methods in the PGRange class. And maybe try floating a patch to ruby-core to make the DateTime::Infinity class do something expected. On Tue, May 3, 2016 at 9:06 PM, Chris Riddoch <[email protected]> wrote: > Hi, folks. > > I've been working with postgresql's tstzrange types with sequel, and have > found the convert_infinite_timestamps option very helpful in making it > possible to handle the ranges where 'infinity' or '-infinity' is a value at > one of the ends of a tstzrange. The PGRange seems meant to work with > ranges where the native ruby Range class just doesn't have the features > necessary. > > But the current implementation of cover? for the PGRange class, line 407 > to 411 [0] delegates to the native ruby Range class. When I call cover? (or > any of the other methods delegated to Range) on a PGRange that uses one of > the infinity values, I get an error like the following: > > ArgumentError: bad value for range > from .../gems/sequel-4.34.0/lib/sequel/extensions/pg_range.rb:500:in > `initialize' > > I started writing tests for implementations of these methods for the > PGRange class to at least not delegate in the cases where > convert_infinite_timestamps is set to :float (which is what I'm using) or > would otherwise result in an ArgumentError... > > Working through this, I now think the logic of valid_ruby_range? is > incomplete. But not all cases of infinity will problems, so I can't just > test for that: > > ((1.0)..Float::INFINITY).cover?(10) => true > > Here's a curiosity I just found by way of a stack overflow post[1]: > DateTime::Infinity.new > > (DateTime.now()..DateTime::Infinity.new).cover?(DateTime.new(2017,1,1,0,0,0)) > => true > > It took a little trying to get a range that goes the other direction, but > this seems to work: > > (Date.new(2000,1,1,Date::GREGORIAN)..DateTime.now()).cover?(DateTime.new(2012,1,1,0,0,0)) > => true > > So maybe one option is to make use of these when converting DateTime > ranges, instead of of the current convert_implement_timestamps code? It > sort of seems like every option is a bit of a hack. I've already started > on some tests, which I've put into my fork on github, in a branch > pg-tstzrange-cover. [2] Suggestions? > > [0] > https://github.com/jeremyevans/sequel/blob/master/lib/sequel/extensions/pg_range.rb#L410 > [1] > http://stackoverflow.com/questions/12567639/is-there-a-way-to-express-infinite-time-in-ruby > [2] https://github.com/riddochc/sequel/tree/pg-tstzrange-cover > > -- > Chris Riddoch > http://www.syntacticsugar.org/ > -- Chris Riddoch http://www.syntacticsugar.org/ -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/sequel-talk. For more options, visit https://groups.google.com/d/optout.
