Where are the nanoseconds from (new Timestamp(...)).getNanos()?

Thread view:

lbrtchx@hotmail.com - 13 Nov 2006 11:44 GMT

I had previously read that System.currentTimeMillis() is not that
accurate, now I noticed that java doesn't really give the nanoseconds.
.
What is it I am not getting right here?
.
thanx
lbrtchx
// - - - code examples
import java.io.*;
import java.util.*;
import java.sql.*;
import java.text.*;

// __
public class JFineTm00{
private static final boolean IsSetOut = false;
// __
public static void main(String[] aArgs){
// __
long lTm00 = System.currentTimeMillis();
String aFrmt = "yyyyMMddHHmmss";
DateFormat formatter = new SimpleDateFormat(aFrmt);
formatter.setTimeZone(TimeZone.getTimeZone("GMT"));
String aDtF = formatter.format(new java.util.Date(lTm00));
// __
java.util.Date uDt = new java.util.Date(lTm00);
System.err.println("// __ new java.util.Date(lTm00): |" + uDt + "|");
// __
System.err.println("// __ System.currentTimeMillis(): |" + lTm00 +
"|");
// __
Timestamp TS = new Timestamp(lTm00);
System.err.println("//__ [" + aFrmt + "]:(new
Timestamp(_)).getNanos(): |" + aDtF + ":" + TS.getNanos() + "|");
}
}

Reply to this Message

jmjatlanta - 13 Nov 2006 13:38 GMT

Retrieve a timestamp field from a database that supports nanoseconds,
and you'll get your nanoseconds.

Manipulate the nanoseconds field and save it, and it will continue to
have nanoseconds.

Create a new Timestamp, and since Java doesn't use nanoseconds, you
won't have your nanoseconds.

Disclaimer: I didn't test my theories, I just read the link below. My
assumption is that the java.sql.Timestamp is to support databases that
deal with nanoseconds. Adding full nanosecond support to the language
would require some thinking as to what to do in cases where the
underlying OS does not support them.

http://java.sun.com/j2se/1.4.2/docs/api/java/sql/Timestamp.html

Hope this helps.

Reply to this Message

Patricia Shanahan - 13 Nov 2006 13:53 GMT

> Retrieve a timestamp field from a database that supports nanoseconds,
> and you'll get your nanoseconds.
[quoted text clipped - 14 lines]
>
> Hope this helps.

Also, you need to separate timestamps and elapsed time measurement.
Nanoseconds may not make that much sense in timestamps, because they are
hard to keep correct in any absolute sense.

If you need a precise elapsed time measurement, use System.nanoTime().

Patricia

Reply to this Message

lbrtchx@hotmail.com - 14 Nov 2006 00:26 GMT

THank you for th eupdate Patricia
// __

http://java.sun.com/j2se/1.5.0/docs/api/java/lang/System.html#nanoTime()
// __
nanoTime
public static long nanoTime()
.
Returns the current value of the most precise available system timer,
in nanoseconds.
.
This method can only be used to measure elapsed time and is not
related to any other notion of system or wall-clock time. The value
returned represents nanoseconds since some fixed but arbitrary time
(perhaps in the future, so values may be negative). This method
provides nanosecond precision, but not necessarily nanosecond accuracy.
No guarantees are made about how frequently values change. Differences
in successive calls that span greater than approximately 292 years (263
nanoseconds) will not accurately compute elapsed time due to numerical
overflow.
.
For example, to measure how long some code takes to execute:
long startTime = System.nanoTime();
// ... the code being measured ...
long estimatedTime = System.nanoTime() - startTime;
.
Returns: The current value of the system timer, in nanoseconds.
.
Since: 1.5
.

Reply to this Message

lbrtchx@hotmail.com - 15 Nov 2006 01:25 GMT

... so values may be negative
.
I have indeed noticed that negative differences appear quite often
while using:
...
long lTm00 = System.currentTimeMillis();
longRunningProcess();
long lTm02 = System.currentTimeMillis();
System.out.println("// __ (lTm02 - lTm00): |" + (lTm02 - lTm00) +
"|");
...
Something I find very odd is that even if the process runs for a long
time, negative differences may appear, even large differences
.
Why?
.
lbrtchx

Reply to this Message

lbrtchx@hotmail.com - 15 Nov 2006 02:08 GMT

however a simple script like the following shows you that hwclock
always gives you forward values
.
#!/bin/bash

var0=0
LIMIT=100

while [ "$var0" -lt "$LIMIT" ]
do
echo -n "$var0 "
hwclock
var0=`expr $var0 + 1`
done

exit 0
.
lbrtchx

Reply to this Message

alexandre_paterson@yahoo.fr - 20 Nov 2006 21:24 GMT

> however a simple script like the following shows you that hwclock
> always gives you forward values

Hi there,

a few random thoughts...

If you're on Linux, you can "strace" your Bash shell script
and a simple Java program calling System.currentTimeMillis()
and/or System.nanoTime().

You'll see that hwclock is querying the "Real-Time Clock"
(open /dev/rtc), which I think is mandated by hwclock's specs.

Both System.currentTimeMillis() and System.nanoTime() call
Linux's gettimeofday(...), the implementation of which depends
on the hardware available, the options chosen when compiling
the kernel, etc. That implementation could very well use the
newer HPET "timer" (the 'T' stands for timer, so I'm being
redundant ;) or it could use the TSC, or the PIT, etc. The TSC
is known to be broken on some architectures (synch problems,
problems with CPUs 'throttling' their speed, etc.).

It used to be that the timesource for gettimeofday() could be set
in real-time on Linux, which may be fun for you to experiment with
(but I don't know if this is still the case).

Reply to this Message

Where are the nanoseconds from (new Timestamp(...)).getNanos()?

Free Magazines