I should have asked what version of Ruby you were using. #to_datetime is in 1.9.2 but not 1.8.7. If you are using 1.8.7 you'll have to do something like:
t = Time.now dt = DateTime.new(t.to_i) Probably still need to be careful about timezone just to make things more interesting. :) \T On Jun 17, 2011, at 3:35 PM, Glenn Little wrote: > I think that to_datetime is a rails addition. For this app I was > using ruby only. The performance issue is not really a problem In > the end, for this app I just punted and re-crafted my data and will > not be needing post-2038 dates. I agree though that always converting > to DateTime (or maybe some form of wrapper around the mysql2 > calls/results somewhere to convert to DateTime) is probably the best > way to cope with it. > > It sure seems like an odd design decision for a database interface to > return inconsistently-typed results (whose interfaces don't match) for > the same database field, dependent only on the field's value. I'd > think that consistency in a case like this would be pretty important. > Seemed odd enough that I figured I might just be missing something. > > -glenn > > On Fri, Jun 17, 2011 at 1:36 PM, Tony Doan <[email protected]> wrote: >> Hi Glenn, >> You are obsoletely right I've never noticed that before on this gem. If you >> take a look in ext/mysql2/result.c you'll find: >> if (seconds < MYSQL2_MIN_TIME || seconds > MYSQL2_MAX_TIME) { >> // use DateTime instead >> >> I guess the safest thing to do would be to always call .to_datetime >> (available on both Time and DateTime objects) on what you get back get back >> from the mysql2 gem. Math on DateTime will be slower, but it wouldn't have >> send you a DateTime unless it wasn't safe to cast it back down to a Time >> object. >> If this is in time critical code I guess you could special case the times >> when you get back DateTime objects so hopefully most of the time you are >> only doing math of Time objects. I'd probably start up just moving >> everything to DateTime and then if you see an unacceptable performance issue >> you can cross that bridge when/if it happens. :) >> \T >> On Jun 8, 2011, at 7:06 PM, Glenn Little wrote: >> >> I'm doing a project in ruby (no rails) using the mysql2 gem for my >> mysql database connection. I have some datetime fields in my tables. >> >> The problem is this. In most cases where the mysql datetime fields >> are "reasonable" (I think that means, prior to Jan 2038?), the mysql2 >> gem returns ruby Time values. However, when the dates are outside of >> that range, the mysql2 gem happens to return a DateTime value, which >> took me by surprise at first (since my code had assumed I'd get a Time >> object like usual). >> >> This obviously causes issues when doing comparisons to >> Time.now/DateTime.now etc since I end up with class mismatches >> occasionally and unpredictably. Has anyone dealt with this before? >> If so, is there a reasonably clean/elegant/transparent way of coping? >> >> Thanks... >> >> -glenn >> >> -- >> SD Ruby mailing list >> [email protected] >> http://groups.google.com/group/sdruby >> >> -- >> SD Ruby mailing list >> [email protected] >> http://groups.google.com/group/sdruby > > -- > SD Ruby mailing list > [email protected] > http://groups.google.com/group/sdruby -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby
