I have this jQuery
function that returns the current time as the number of milliseconds since the epoch (Jan 1, 1970):
time = new Date().getTime
(Time.now.to_f * 1000).to_i
should do the same thing.
Javascript's gettime()
returns the number of milliseconds since epoch.
Ruby's Time.now.to_i
will give you the number of seconds since epoch. If you change that to Time.now.to_f
, you still get seconds but with a fractional component. Just multiply that by 1,000 and you have milliseconds. Then use #to_i
to convert it to an integer. And you end up with:
(Time.now.to_f * 1000).to_i
Get a Time object with Time.now
, calling #to_i
returns a Unix timestamp (seconds from epoch). #to_f
gives fractional seconds which you can use to get milliseconds from epoch:
Time.now.to_f * 1000
Using strftime, you can get the number of seconds and append fractional milliseconds (or smaller units, if needed):
2.2.2 :001 > t = Time.new
=> 2015-06-02 12:16:56 -0700
2.2.2 :002 > t.strftime('%s%3N')
=> "1433272616888"
Note though that this doesn't round, it truncates, as you can see with to_f
or if you go out to microseconds:
2.2.2 :003 > t.to_f
=> 1433272616.888615
2.2.2 :004 > t.usec
=> 888615
and the to_f
/ to_i
solution has the same problem:
2.2.2 :009 > (t.to_f * 1000).to_i
=> 1433272616888
so if you really care about millisecond accuracy, a better bet may be to_f
with round
:
2.2.2 :010 > (t.to_f * 1000).round
=> 1433272616889
That said, as noted in the docs, "IEEE 754 double is not accurate enough to represent the number of nanoseconds since the Epoch", so if you really really care, consider to_r instead of to_f
--
2.2.2 :011 > (t.to_r * 1000).round
=> 1433272616889
-- although if you're only rounding to milliseconds you're probably fine.
The typecast Integer(1e6*Time.now.to_f) returns a Bignum that can hold the milliseconds
Be careful, don't get confused. The fact that Ruby supports the idea of fractional seconds as a float doesn't actually make it a floating point number. I got into trouble with this when I was doing Wireshark timestamp time comparisons in Python... the time calculations in the pcap-ng just weren't working. It was only when I treated the two parts (integral seconds and integral nanoseconds) as both integers was I able to get proper numbers.
That's because floating point numbers have Accuracy problems. Indeed, a quick bit of Ruby will show you that to_f does not equal, say, nsec:
irb(main):019:0> t=Time.now
=> 2015-04-10 16:41:35 -0500
irb(main):020:0> puts "#{t.to_f}; #{t.nsec}"
1428702095.1435847; 143584844
Caveat Programmer. You may be safe to 3 significant digits, but the fact remains: Floating point numbers on computers are approximations. The nanosecond counters on modern computers are integers.