[Boost-users] date_time clocks, microsec_clock, etc

From: Aaron W. LaFramboise (aaronblue6_at_[hidden])
Date: 2004-05-02 20:08:49

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
Hello,

I'm a little curious whats in the works for date_time clock support.
Specifically, there still doesn't seem to be anything better than a
second-granularity clock for Win32.

In addition, the UNIX clock is not always as precise as it could be.
In particular, the popular Pentium and and some other architectures
have some sorts of cycle-granularity hardware clock or similar that
can exceed the usual operating system clock used for time.

Really--and I have no idea what work is presently being done on
this--it might do people in some problem domains (including myself, at
times) a lot of good to have clocks with separate notions of precision
and accuracy.  For example, on a Pentium, operating systems I care
about tend to have a maximum system clock accuracy around about a
millisecond plus or minus some, and its probably difficult or tricky
to get better than that.  However, if the system clock was used in
combination with the Pentium cycle counter, we could probably get
precision in excess of a nanosecond.  Perhaps an interface for such a
clock system might be:
typedef boost::date_time::clock<type_of_accuracy_you_need_here,
type_of_precision_you_need_here> myclock;
To get the above imagined clock, I might use:
clock<microsecond_accuracy, cycle_precision>

If the clock requested was unavailable on the platform, a compile time
error might result.

Of course, oftentimes we know the characteristics of a clock's
accuracy or precision, such as the Pentium cycle counter, but we don't
know exactly how precise it is, so it might be inappropriate to refer
to that clock as nanosecond_precision when it really might not be.

In summary, a reliable cross-platform sub second clock is one of the
features I miss most in date_time, and one of the features I can
afford to miss least.  Is anyone working on remedying this right now?

Aaron W. LaFramboise
OpenPGP fingerprint: CFB4 D883 17ED E9BE 6F16  1BF7 969F E586 75AC 33C4

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
iD8DBQFAlZuhxDYk2wAn5+8RAg5jAJ0XINhLFb4KikH+oK286PQfu6iMaQCgnTe5
SlmNLXTitPUWuUYMKrHIQgY=
=bJvg
-----END PGP SIGNATURE-----