Issue #16470 has been updated by jeremyevans0 (Jeremy Evans).


akr (Akira Tanaka) wrote in #note-16:
> There are several examples time needs more than nanoseconds.
> 
> * SQLite supports arbitrary number of digits in fractional seconds
>   https://www.sqlite.org/lang_datefunc.html

SQLite ignores values after the millisecond when converting:

```
sqlite> SELECT CAST(strftime('%f', '2020-10-20 11:12:13.1237') AS NUMERIC);
13.124
```

> * POSIX pax format supports arbitrary number of digits in fractional seconds
>   http://pubs.opengroup.org/onlinepubs/007904875/utilities/pax.html#tag_04_100_13_05

This is a file archive format.  How many filesystems have greater than nanosecond resolution?

> * EXIF supports arbitrary number of digits in fractional seconds
>   http://www.exif.org/Exif2-1.PDF

Similarly, what camera supports greater than nanosecond resolution?

> * NTPv4's 128-bit date format has 64-bit fraction field : 2**(-64) second
>   https://tools.ietf.org/html/rfc5905#section-6
> * FreeBSD has struct bintime which can represent 2**(-64) second
>   https://svnweb.freebsd.org/base/head/sys/sys/time.h?view=markup&pathrev=363193#l55
>   It is visible from userland for datagram timestamp
>   https://www.freebsd.org/cgi/man.cgi?query=setsockopt
>   Ruby supports it as converting bintime to Time object
> * DB2 supports fractional seconds up to 12 digits in timestamp (12 digits represents picosecond)
>   https://www.ibm.com/support/knowledgecenter/SSEPGG_9.7.0/com.ibm.db2.luw.sql.ref.doc/doc/r0008474.html

These seem to be better reasons to support sub-nanosecond resolution.  I think either storing picoseconds or storing sec fraction as 64-bit integer are better approaches than storing a rational.  However, either change would be very invasive, and it seems unlikely to be worth the effort.

As rational is used internally, it seems reasonably for inspect output to include rational.  If a user wants to specific nanosecond, they should provide a rational instead of a float.  So I think this feature request can be closed.

Note that sub-nanosecond resolution should be considered Ruby-implementation-specific behavior, since JRuby and TruffleRuby support nanosecond, and mruby supports microsecond.

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

* Author: andrykonchin (Andrew Konchin)
* Status: Feedback
* 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: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>