[ruby-core:53584] [CommonRuby - Feature #8096] introduce Time.current_timestamp

Issue #8096 has been updated by headius (Charles Nutter).


Responding to some concerns:

1. nanoTime deficiencies

Yes, System.nanoTime is not monotonic. It is designed to be a timestamp from the start of the process, as fast as possible across platforms, and with as fine-grained resolution as possible. That's one goal of a timestamp. I suppose the primary question here is what the timestamp is wanted for... I can see a few use classes:

* Runtime metric-gathering (profiling, timing, etc). This case will want to be FAST and FINE grained to the greatest extent possible. Monotonicity may or may not be important, but ensuring low overhead is paramount.
* Wall clock current time timestamp, for persisting, communicating wall-clock times, possible for runtime metric gathering. This needs to be FAST, but maybe not as fine-grained. Most processes you'd persiste to a database aren't going to need ns or even 袖s precision. In Java, this would be System.currentTimeMillis, which provides millisecond precision slightly slower than nanoTime.
* Lower-precision wall clock timestamps, for application-level use. Again, you'd want this to be fast, but at this level ms or even second precision may be acceptable.

The same code I posted could be monotonic with System.currentTimeMillis; it just wouldn't be able to provide 袖s or ns precision.

2. 32-bit Fixnum is not big enough

I sometimes forget that MRI isn't always using 64-bit numeric values. In JRuby, Fixnum and Float are *always* 64-bit, regardless of the JVM or platform you're running on. As kosaki pointed out, however, a small Bignum (e.g. 64-bit precision) would still be much smaller than a full Time object, so I think returning Bignum on 32-bit platforms is quite acceptable. JRuby would likely always just return Fixnum.

3. Other issues with timestamping

There's various gotchas people run into when using even the JVM's fastest timestamp facilities. Among them:

* nanoTime does not reflect time spent sleeping; if you suspend the machine, the CPU clocks don't advance, so nanoTime does not advance.
* Accurate clocks can be expensive to provide in virtualized environments. I have confirmed cases where System.currentTimeMillis performed *terribly* under certain VMs that tried to guarantee accuracy with regards to the host system as well as the virtualized runtime. This is more a kernel-level thing though; if you're using a kernel-level API that claims to be monotonic, there's a good chance some VM software will bend over backwards to support that guarantee.

In any case, I think we can all agree that having to construct an entire Time object every time you want a timestamp is unreasonable...especially since Time gets its value from a kernel-level call we could simply expose to the user directly.
----------------------------------------
Feature #8096: introduce Time.current_timestamp
https://bugs.ruby-lang.org/issues/8096#change-37777

Author: vipulnsward (Vipul Amler)
Status: Feedback
Priority: Low
Assignee: 
Category: 
Target version: 


=begin
A lot of scenarios and applications require the use of (({Time.now.to_i})) which is used as current_timestamp in systems.

The introduction of (({Time.current_timestamp})) {or something with similar with different name} would provide implicit integer timestamp instead of going from 
(({Time.now})) -> time_object -> to_i -> integer timestamp value

So instead of

 Time.now.to_i # Outputs => 1363274618

one could use

 Time.current_timestamp # Outputs => 1363274618

=end



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