Re: [Boost-users] date_time clocks, microsec_clock, etc

On Sun, 02 May 2004 20:08:49 -0500, Aaron W. LaFramboise wrote

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.

It depends on which compiler you use on Win32. Those that support a posix interface (eg gcc on cygwin). I think Borland and some other might as well. But yes, there should probably be a Win32 version that uses file time.

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.

Ok.

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.

The 'microsec_time_clock' class uses gettimeofday -- an interface that can support up to microsecond resolution. Of course if the clock isn't that accurate, the results won't be either.

However, if the system clock was used in combination with the Pentium cycle counter, we could probably get precision in excess of a nanosecond.

With what algorithm would we achieve this? It's not obvious to me how this would work...

Perhaps an interface for such a clock system might be: typedef boost::date_time::clock myclock; To get the above imagined clock, I might use: clock

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

Sure we could do something like that, but it might be simplier to have a few predefined types that work commonly.

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?

Not explicitly, but I'm willing to work with you or anyone else on this. One of the core design principles of date_time is that it should be easy to add a new clock without altering the core temporal types. If you take a look at boost/date_time/microsec_time_clock.hpp you can see it isn't that difficult to adapt an API to provide the time. The main issue is figuring out which API to use and how to adapt it into providing the current a yyyy-mm-dd hh:mm:ss.fraction_seconds information. Jeff