Charlie,

Your fix is probably right on.  I just have a a couple of salient points just in case. 

1) Java System.nanoTime() needs java 1.5 so you have to check if you are going to put it in a release that allows < Java 1.5.

2)  //  A suggested solution

private static double __initialclock__ = 0.0;
public static double clock() {
     if (__initialclock__ == 0.0) {
        // set on first call
        __initialclock__ = System.nanoTime();  // keep __initialclock__ in nanoSeconds
        return 0.0;  // I would add this return here - it could improve accuracy by a  few microseconds
    }
    return (System.nanoTime() - __initialclock__) / 1000000000.0;  // convert the time to seconds here

 - Bob

-----Original Message-----
From: Charlie Groves <charlie.groves@gmail.com>
To: boblusebob@aim.com
Cc: jython-dev@lists.sourceforge.net
Sent: Fri, 23 Nov 2007 9:14 pm
Subject: Re: [Jython-dev] Jython Clock Resolution

On Nov 23, 2007 3:33 PM,  <boblusebob@aim.com> wrote:
> Thank you Charlie. You of course are right about time.time(). It couldn't
> be improved using nanoTime. Time clock should be relatively easy though and
> should improve things by quite a bit. I will put my example scripts
> together with a naive first pass at a solution and open a problem.

It's a pretty simple change, and I think I've already got it in my
local copy. If you just want to create a bug and upload the example
script, that'd be good. I was just hoping to test against your
expectations before committing it.

> I imagine Python uses getTimeOfDay() on unix like systems for time.time().
> time.time() could could still be improved using JNI and getTimeOfDay() on
> Unix like systems and then Jython's resolution would basically match Pythons
> (since Pythons Windows XP resolution for time.time() really isn't any better
> than Jythons). I understand that it isn;'t quite as simple of an
> enhancement though to use JNI. Does/would Jython consider using JNI and c
> for time.time()?

Since the docs don't promise anything better than second resolution
for time.time, I don't think it's worth the headaches of JNI to
provide better resolution from time.time. There's some talk of using
JNA to provide easier access to native functionality for things that
don't have a counterpart in straight Java, so if that lands it should
be easier to do this sort of thing.

Charlie

Check Out the new free AIM(R) Mail -- Unlimited storage and industry-leading spam and email virus protection.