Issue #16470 has been updated by Eregon (Benoit Daloze).


I'd guess it partly due to the Float itself losing precision.
But indeed it's quite unpretty. Maybe we should use #rationalize since that's closer to the Float#inspect output?

There is a usability problem here, it's basically impossible to read the output of Time#inspect in such a case, even though the input was readable.

```ruby
123456.789.to_r
# => (8483885939586761/68719476736)

123456.789.rationalize
# => (123456789/1000)

Time.utc(2007, 11, 1, 15, 25, 0, 123456.789).inspect
# => "2007-11-01 15:25:00 8483885939586761/68719476736000000 UTC"
```

This works as expected (using `r` for making it an exact Rational):
```ruby
p Time.utc(2007, 11, 1, 15, 25, 0, 123456.789r)
# => 2007-11-01 15:25:00.123456789 UTC
```

----------------------------------------
Bug #16470: Issue with nanoseconds in Time#inspect
https://bugs.ruby-lang.org/issues/16470#change-83588

* Author: andrykonchin (Andrew Konchin)
* Status: Open
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
* Target version: 
* ruby -v: 2.7
* Backport: 2.5: UNKNOWN, 2.6: UNKNOWN
----------------------------------------
Recently in Ruby 2.7 nanoseconds were added to a string representation produced by the `Time#inspect` method.

I encountered an issue when was working on new specs for the RubySpec project - nanoseconds are displaying like a Rational.

Let's illustrate it with example:

```ruby
t = Time.utc(2007, 11, 1, 15, 25, 0, 123456.789)
t.inspect # => "2007-11-01 15:25:00 8483885939586761/68719476736000000 UTC"
```

But nanoseconds are stored correctly:

```ruby
t.nsec # => 123456789
t.strftime("%N") # => "123456789"
```

So `123456789` is formatted as `8483885939586761/68719476736000000` which equals `0.12345678900000001`.

I assume it isn't expected behavior and will be fixed.



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>