Update DateRow to use ruby Time rather than broken NSDate.dateWithTimeIn... #60

Merged
merged 1 commit into from Jan 16, 2013

Conversation

Projects
None yet
2 participants
Contributor

dlongmuir commented Jan 16, 2013

...tervalSince1970

Owner

clayallsopp commented Jan 16, 2013

Hmm how is NSDate.dateWithTimeIntervalSince1970 broken?

Contributor

dlongmuir commented Jan 16, 2013

If you leave the row definition in the KitchenSink example but use the previous NSDate-based DateRow you will see that changing the picker doesn't always update the field value properly. This is initially what Steve Ross mentioned on the mailing list.

From what I sent to motion support:

I would expect t1 and t2 to be the same or very close:

t1 = Time.now.to_i
t2 = NSDate.date.timeIntervalSince1970.to_i
puts “Time now = #{t1} NSDate = #{t2} diff = #{t2-t1}”

They are not and on different runs I have seen these numbers be different by anywhere between 64 and 230 seconds.

Second, t2 never changes. If I run the above code every second using an NSTimer I get:

Time now = 1351967360 NSDate = 1351967232 diff = -128
Time now = 1351967361 NSDate = 1351967232 diff = -129
Time now = 1351967362 NSDate = 1351967232 diff = -130

Laurent responded that it was something they were looking at fixing:
"The compiler optimizes floating-point values in a way that makes them lose 2 bits of precision, which unfortunately impact the way Time objects are converted back and forth to NSDate equivalents."

Contributor

dlongmuir commented Jan 16, 2013

Sorry for the confusion in the commit comment - I'm talking about timeIntervalSince1970

clayallsopp merged commit 12cdf9a into clayallsopp:master Jan 16, 2013

Owner

clayallsopp commented Jan 16, 2013

Gah that is a pickle. Thanks for the PR! Merged

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment