I spent an entirely inappropriate amount of time digging into this
issue...
Here are some observations:
The #microseconds method LOOKS clumsy, but it's actually quite
optimized. Turns out the the sec_fraction component is a Rational
less than one. So converting as quickly as possible to som
Awesome, thanks for the reply.
- Ken
On Jan 15, 2010, at 10:24 AM, Jacob Lauemøller wrote:
> The problem only manifests itself if the sub-second part is stored with 4 or
> more significant digits. So if you only store and retrieve milliseconds (and
> thats the way I read your code) you shoul
The problem only manifests itself if the sub-second part is stored with 4 or
more significant digits. So if you only store and retrieve milliseconds (and
thats the way I read your code) you should be home safe.
On 15/01/2010, at 15.56, Ken Collins wrote:
>
> I plan on taking a look at this too
I plan on taking a look at this too. I think I had to solve it in the SQL
Server adapter in my own way since it only stores milliseconds. If you care to
look at our code, here are a few key sections in the tests.
http://github.com/rails-sqlserver/2000-2005-adapter/blob/master/test/cases/adapter
Thanks for the response -- we use PostgreSQL which does store all six
microsecond digits.
Jacob
On 15/01/2010, at 15.41, Chris Cruft wrote:
> I gave up on that kind of resolution when I found that MySQL doesn't
> support it! I'll try to test the patch though.
>
> -Chris
>
> On Jan 14, 10:20
I gave up on that kind of resolution when I found that MySQL doesn't
support it! I'll try to test the patch though.
-Chris
On Jan 14, 10:20 am, Jacob Lauemøller
wrote:
> Hi all,
>
> The microsecond handling in
> ActiveRecord::ConnectionAdapters::Column#fast_string_to_time and
> ActiveRecord::
