From: mame@... Date: 2020-06-23T02:58:21+00:00 Subject: [ruby-core:98918] [Ruby master Feature#16470] Issue with nanoseconds in Time#inspect Issue #16470 has been updated by mame (Yusuke Endoh). Interesting, I can reproduce the performance difference: ``` $ time ./miniruby -e '100000.times { Time.utc(2007, 11, 1, 15, 25, 0, 123456.789.to_r) }' real 0m0.633s user 0m0.622s sys 0m0.011s $ time ./miniruby -e '100000.times { Time.utc(2007, 11, 1, 15, 25, 0, 123456.789.rationalize) }' real 0m0.607s user 0m0.587s sys 0m0.020s ``` Note that `#to_r` is 10 times faster than `#rationalize`: ``` $ time ./miniruby -e '100000.times { 123456.789.to_r }' real 0m0.059s user 0m0.039s sys 0m0.020s $ time ./miniruby -e '100000.times { 123456.789.rationalize }' real 0m0.598s user 0m0.587s sys 0m0.010s ``` I think that this is because `#to_r` produces relatively big denominator, which makes addition slower during `Time.utc` calculation. (I have no opinion about the `Time.utc` issue itself. Sorry.) ---------------------------------------- Feature #16470: Issue with nanoseconds in Time#inspect https://bugs.ruby-lang.org/issues/16470#change-86297 * Author: andrykonchin (Andrew Konchin) * Status: Open * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Ruby 2.7 added nanosecond representation to the return value of `Time#inspect` method. Nanosecond is displayed as `Rational` as in the following example: ```ruby t = Time.utc(2007, 11, 1, 15, 25, 0, 123456.789) t.inspect # => "2007-11-01 15:25:00 8483885939586761/68719476736000000 UTC" ``` The nanosecond value `8483885939586761/68719476736000000` can be expanded to `0.12345678900000001`. This is different from the stored nanosecond: ```ruby t.nsec # => 123456789 t.strftime("%N") # => "123456789" ``` I assume it isn't expected, and will be fixed. -- https://bugs.ruby-lang.org/ Unsubscribe: