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
