From: merch-redmine@... Date: 2020-07-20T19:16:38+00:00 Subject: [ruby-core:99240] [Ruby master Feature#16470] Issue with nanoseconds in Time#inspect 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: