From: "mpglover (Matt Glover)" <mpglover@...>
Date: 2013-10-25T12:33:57+09:00
Subject: [ruby-core:58032] [ruby-trunk - Bug #7829] Rounding error in Ruby	Time


Issue #7829 has been updated by mpglover (Matt Glover).


david_macmahon (David MacMahon) wrote:
>  The three main reasons for preferring the decimal approximation for Float seconds (or microseconds) are:
>  
>  1) No unpleasant surprises for users, especially when using Float literals as in the original bug report.
>  
>  2) Almost all users will have a fairly limited decimal precision of time (i.e. milliseconds, microseconds, nanoseconds) so the decimal approximation of the Float is likely to be equal to the true value whereas the binary approximation will not be.
>  
>  3) Users with very high and/or non-decimal precision of time are unlikely to be using Floats anyway.

Just wanted to second this. I came rather close to filing a bug report about, I think, the same core issue. In part because these two tests led me to believe Ruby did prefer the decimal approximation:
- https://github.com/ruby/ruby/blob/f79aeb60e7e49c0430f2685719c8c4772cfc6f95/test/ruby/test_time.rb#L57
- https://github.com/ruby/ruby/blob/f79aeb60e7e49c0430f2685719c8c4772cfc6f95/test/ruby/test_time.rb#L75

However a similar looking test fails:
> assert_equal(0, (Time.at(1.9) + 0.1).usec)
<0> expected but was <999999>.

I assume that 999999 is the expected result for reasons described earlier in the ticket. Unless/until Dave's suggestions are implemented it may be helpful to adjust those tests to make it obvious the Float-related behavior is expected.
----------------------------------------
Bug #7829: Rounding error in Ruby Time
https://bugs.ruby-lang.org/issues/7829#change-42613

Author: loirotte (Philippe Dosch)
Status: Closed
Priority: Normal
Assignee: akr (Akira Tanaka)
Category: doc
Target version: next minor
ruby -v: ruby 1.9.3p194 (2012-04-20 revision 35410) [i686-linux]
Backport: 


Even if I know the precision errors related to the implementation of IEEE 754 floating values, I'm very surprised of:

irb(main):001:0> Time.utc(1970,1,1,0,0,12.860).strftime("%H:%M:%S,%L")
=> "00:00:12,859"

The fact is that I obtain:

irb(main):002:0> Time.utc( 1970, 1, 1, 0, 0, 12.860 ).subsec
=> (60517119992791/70368744177664)
irb(main):003:0> Time.utc( 1970, 1, 1, 0, 0, 12.860 ).subsec.to_f
=> 0.8599999999999994

If I well understand the precision error that is reported for the 12th or 14th digit after the comma, I don't understand why the rounding process gives an unexpected result for this value. In this case, the last significant digit of my value is impacted, and it appears to be a embarrassing behavior. For other values, the obtained result is as expected:

irb(main):001:0> Time.utc(1970,1,1,0,0,12.880).strftime("%H:%M:%S,%L")
=> "00:00:12,880"

Moreover, this is a part of the Time class and I don't know any way to fix it in a program (and I don't know the full list of values reproducing this issue...)


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