I'd decided to test my time (clock) values against the example code in the
uuid draft. The problem was (a: I'm 10yrs rusty in C/C++) and b) I'd get
about a 34.07xx year difference in my return values versus what the C code
in the draft is giving. Eventually, I figured out to upcast the time
struct's return values to unsigned long long before multiplying and that
gave much better results. ... anyone see anything not ok, I think I'm ok
with this?
int main() {
struct timeval tp;
gettimeofday(&tp, (struct timezone *)0);
/* Offset between UUID formatted times and Unix formatted times.
UUID UTC base time is October 15, 1582.
Unix base time is January 1, 1970.*/
unsigned long long offset = 0x01B21DD213814000;
printf ("\nUUID w/o upcast: %llu", (tp.tv_sec * 10000000) +
(tp.tv_usec * 10) + offset);
printf ("\nUUID: %llu", ((unsigned long long)tp.tv_sec * 10000000)
+ ((unsigned long long)tp.tv_usec * 10) + offset);
return 0;
}
With that I'll create a bugzilla enhancement to add the UUIDClock and
UUIDSystemClock code for review. UUIDClock has changed to an interface,
UUIDSystemClock uses the System class to get the time, without the thread
and other code to compensate for time resolution issues. The code that was
in UUIDClock I now have in a class called UUIDThreadClock (having some
issues with the unit tests seeming to hang, I'll send when I can get that
resolved).
It would be difficult for me to use the C code in the unit tests (but not
impossible I suppose.) I guess the question is .. should the unit tests have
this / JNI code? I felt it was important to test against the C reference
code in the UUID draft appendix, since any errors in implementation for this
code can't be fixed easily (the unique contract depends on correctly
implementing the spec.)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
