Basically what I need to do is order events in my table by updated_at. Then take updated_at of last updated event and in next query ask for events, which has updated_at bigger then provided. But events are updated quite often, so difference can be on milliseconds level, that why i decided to work with those dates in its float form (to also include milliseconds). But I ended with described issues (so in my case, time to time based on rounding magic, I am receiving once again already selected event because timestamp is parsed as lower)...
On Monday, July 14, 2014 7:47:21 PM UTC+2, Petr Kaleta wrote: > > Hey Jeremy, > I am running on jRuby 1.7.13. But still, this doesn't make any sense, why > ruby is doing this :/ > > I don't understand your point with rounding already rounded time. > Basically I don't understand why ruby is converting 918000 to 917999. > > > On Monday, July 14, 2014 7:22:23 PM UTC+2, Jeremy Evans wrote: >> >> On Monday, July 14, 2014 9:37:19 AM UTC-7, Petr Kaleta wrote: >>> >>> Hi, >>> I am dealing with quite strange microseconds representation issue once >>> doing simple time condition? >>> Please have a look on the following gist (for better readability) >>> >>> https://gist.github.com/PetrKaleta/704639f9e9bf8798b815 >>> >>> Am I doing something wrong? >>> >> >> This appears to be a floating point issue. Sequel uses Time#usec to get >> the microseconds: >> >> Time.at(1405341161.918000).usec # => 917999 >> >> I think on ruby 1.9+, it may be good to use Time#round with the >> appropriate precision, before trying to format the time. I'll try that >> soon. >> >> Thanks, >> Jeremy >> > -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sequel-talk. For more options, visit https://groups.google.com/d/optout.
