Having thought a bit more about exactly what I'm trying to accomplish, you're right that I don't need infinite timestamp values. It somehow struck me as an incompleteness of some sort, which caused me to get distracted from my original goals.
Now that I've reread this part of the postgres documentation (it had been long enough I forgot important details), the reasoning behind the behavior of nulls in the input of a timestamp range makes a lot more sense to me... and while I do have a use case for cover?, it's not one where a bounded infinite time range would be useful in place of unbounded... so it even seems possible I might not actually need cover? implemented separately on the PGRange to begin with. As for the DateTime conversion, I'm definitely less confident now that it wasn't a problem of my own making somehow. Thanks for the focus. On Wed, May 4, 2016 at 4:47 PM, Jeremy Evans <[email protected]> wrote: > On Wednesday, May 4, 2016 at 3:15:39 PM UTC-7, Chris Riddoch wrote: >> >> Thanks Jeremy, that code gave me a good start on this. It almost works >> when I have convert_infinite_timestamps set to :nil. I think all the >> utility functions necessary are already in place so that I can make it >> handle :string and :float, once I spend a bit more time reading this file >> and a bit more of the pg extension support code. >> >> Now I'm just trying to figure out why the type conversions are giving me >> Time objects instead of DateTime for the endpoints of the range. Most >> places in my application where dates are involved use DateTime, with >> 'timestamp with time zone' behind them. Even when I have >> Sequel.datetime_class = DateTime, the PGRange is converting them to Time. >> This would be fine, except that DateTime and Time aren't comparable with >> each other with their <, >, etc. operators. >> >> Thanks for all your help with this. >> > > Can you explain why infinite timestamp support would matter? Timestamp > ranges shouldn't use infinite timestamp values, they should just be > unbounded on that end ( > http://www.postgresql.org/docs/9.5/static/rangetypes.html#RANGETYPES-INFINITE). > I guess you could use infinite timestamp values in a range, but it's > probably a bad idea. > > I'm not sure what problems you are having with DateTime, if you set > Sequel.datetimeclass = DateTime, then the begin/end values of PGRange > instances should be DateTime objects: > > DB.get(Sequel::Postgres::PGRange.new(Time.now, nil, > :db_type=>'tsrange')).begin.class > # INFO -- : (0.000362s) SELECT tsrange('2016-05-04 > 15:41:41.701081-0700',NULL,'[]') AS "v" LIMIT 1 > # => Time > Sequel.datetime_class = DateTime > # => DateTime > DB.get(Sequel::Postgres::PGRange.new(Time.now, nil, > :db_type=>'tsrange')).begin.class > # INFO -- : (0.000380s) SELECT tsrange('2016-05-04 > 15:41:51.065161-0700',NULL,'[]') AS "v" LIMIT 1 > # => DateTime > > Could you post a self contained example showing the problem you are having? > > Thanks, > Jeremy > > -- > 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. > -- 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.
