While investigating #565, I noticed that JRuby converts a Float argument given to Time.at to a Java long, thus losing some precision.
This commit fixes that, plus keeps track of nanoseconds overflowing to the next millisecond, which is possible when the first argument is not a Fixnum.
Looking at MRI source, it seems to handle this by calling #to_r and rubyspec agrees with that. Maybe we want to do something similar instead?
Looks like the MRI fix for #565 was backported to 1.9.3 https://bugs.ruby-lang.org/issues/8194.
Could you squash the two commits into one? Also, if could you check if RubySpec needs a spec for this?
Add support for Floats as the first argument to Time.at.
- Keep track of nanoseconds overflowing to the next millisecond.
I squashed the the commits and rebased against master.
Rubyspec covers this, more or less, but it expects Floats to be converted using to_r. Fixnums, Bignums and Rationals are allowed as is, anything else that responds to to_r but not to_int gets converted to a Rational with to_r. This includes Floats as well. These specs fail with JRuby.
I have a version that does the conversion with to_r as well, but to me, it seems like more like a unnecessary implementation detail of MRI. The documentation explains that either argument maybe one of "Integer, Float, Rational", but it doesn't say anything about to_r being used internally.
I'm testing your non-to_r version right now. Unfortunately to_r may be intentional behavior, whether it is documented or not. This is definitely a grey area for the Ruby spec.
I would suggest you modify that patch to be based on this one, and we can merge this in so that the majority of cases that don't use to_r will start working. Then, you should file an issue asking for clarification of whether the to_r behavior is intentional and part of the specification or not.
Please open a second PR with the to_r calls if it turns out that ruby-core/matz believe that behavior is specified and required. Thanks so much for this!