=begin
It could be any number of purposes. On top of my head I could think of remote systems, timestamps persisted to Databases, Event marking, Security Systems, Time conversions, etc (Although these are very bad examples)

=begin
It could be any number of purposes. On top of my head I could think of remote systems, timestamps persisted to Databases, Event marking, Security Systems, Time conversions, etc (Although these are very bad examples)

=begin
It could be any number of purposes. On top of my head I could think of
remote systems, timestamps persisted to Databases, Event marking, Security
Systems, Time conversions, etc (Although these are very bad examples)

However this is one naive point. almost all programmer think following code makesalways positive.

t0 = System.nanoTime()
...
t1 = System.nanoTime()
t = t1 - t0

however this is not correct when following reasons.

some os don't support monotonic.

x86 has silly tsc implementation and time run backward when multiple cpus
even if using monotonic.
i.e. tsc time depend on individual cpus and os scheduler migrate process
across cpus transparency. that's intel silly.

That says, System.nanoTime encourage bad programming. but it works excellent when
we can ignore disadvantages.

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.

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.

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.

The java stuff is experimentation on my part, published version of the gem
has none of that.

You're pretty close. System.nanoTime is probably the closes thing to your "timestamp", but as kosaki points out it's not guaranteed to be monotonic (even your impl is not monotonic).

Why? Because on some Linux or BSD, monotonic time may not be supported. Time is then per-CPU, which means it can appear to go backward if read from one CPU and then read from another CPU. On Solaris, the old gethrtime has the same problem, but Java attempts to do a monotonic version with some processor tricks.

The java stuff is experimentation on my part, published version of the gem
has none of that.

You're pretty close. System.nanoTime is probably the closes thing to your "timestamp", but as kosaki points out it's not guaranteed to be monotonic (even your impl is not monotonic).

Actually since making the jruby branch, and based on some conversations here, I have changed the API of the gem (and the C implementation in master) to define a monotonic Time.timestamp method and a Time.now.to_i-equivalent wall-clock method, which I called Time.unix_timestamp because I couldn't think of a better name.

My intention was to update the jruby branch to use System.nanoTime for Time.timestamp, which I've finally gotten around to doing, but I see there are still potentially some polytonic (is that even a word?) issues to resolve. Fortunately I've not yet set up my VM to build jruby/java-native gems, or verified my hopefully MRI-and-jruby compatible gemspec, so my java code won't be released into the wild for some time yet.

Your implementation for MRI is probably just fine. I can help make the JRuby version "correct" using nanoTime and proper method binding. But a few questions remain:

Do we want a single Time.timestamp method?

If so, which timestamp is it?

If not, how many representations of timestamp do we want? It seems to me that our timestamp and Time.now.to_i should probably be derived the same way.

This discussion has already revealed, to me at least, that some people want a fast seconds-since-1969 method, and some people want a secure, high-precision monotonicically increasing value. I think the latter has the most merit, since there is currently no equivalent in Ruby; however both are legitimate requests.

Actually since making the jruby branch, and based on some conversations here, I have changed the API of the gem (and the C implementation in master) to define a monotonic Time.timestamp method and a Time.now.to_i-equivalent wall-clock method, which I called Time.unix_timestamp because I couldn't think of a better name.

My intention was to update the jruby branch to use System.nanoTime for Time.timestamp, which I've finally gotten around to doing, but I see there are still potentially some polytonic (is that even a word?) issues to resolve. Fortunately I've not yet set up my VM to build jruby/java-native gems, or verified my hopefully MRI-and-jruby compatible gemspec, so my java code won't be released into the wild for some time yet.

I could submit a PR for master that provides the same methods in a JRuby-compatible way, if you'd like.

Do we want a single Time.timestamp method?

If so, which timestamp is it?

If not, how many representations of timestamp do we want? It seems to me that our timestamp and Time.now.to_i should probably be derived the same way.

This discussion has already revealed, to me at least, that some people want a fast seconds-since-1969 method, and some people want a secure, high-precision monotonicically increasing value. I think the latter has the most merit, since there is currently no equivalent in Ruby; however both are legitimate requests.

Yes, those seem like the key points. The monotonicity guarantees of the latter are hard to meet, though...on any impl. it might have to be specified as "high-precision CPU-level timestamp, which will be monotonic on most systems (but this is not guaranteed)".

So we have:

Time.timestamp: A ns-precision timestamp based on the fastest, most accurate timer possible on the current platform. Although not guaranteed, this value will be monotonic on most systems.

Time.something_timestamp: A timestamp representing the number of seconds since the epoch.

My intention was to update the jruby branch to use System.nanoTime for Time.timestamp, which I've finally gotten around to doing, but I see there are still potentially some polytonic (is that even a word?) issues to resolve. Fortunately I've not yet set up my VM to build jruby/java-native gems, or verified my hopefully MRI-and-jruby compatible gemspec, so my java code won't be released into the wild for some time yet.

I could submit a PR for master that provides the same methods in a JRuby-compatible way, if you'd like.

That would be really handy. I've been fiddling a bit more the past couple of days, and I can't quite get it to work properly. I don't know if the failure is in the class file, the jar, or loading it in the test.rb

So we have:

Time.timestamp: A ns-precision timestamp based on the fastest, most accurate timer possible on the current platform. Although not guaranteed, this value will be monotonic on most systems.

Time.something_timestamp: A timestamp representing the number of seconds since the epoch.

I suggest epoch_timestamp for the latter.

I chose unix_timestamp because that's what MySQL calls it (UNIX_TIMESTAMP and FROM_UNIXTIME), and a quick and very scientific Google poll shows me that "unix timestamp" has ~893k results, "epoch timestamp" ~463k, "posix timestamp" ~430k; and the second, third, and fifth results for "timestamp" are www.unixtimestamp.com/, www.epochconverter.com/ (the "Easy epoch/Unix timestamp converter for computer programmers.") and www.onlineconversion.com/unix_time.htm, etc. so the "Unix" name is in pretty common usage.