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
