Time interfaces threads/file (was Design for a file system library)

From: Jeff Garland (jeff_at_[hidden])
Date: 2002-02-25 11:43:00

> -----Original Message-----
> From: Beman Dawes [mailto:bdawes_at_[hidden]]
> Sent: Monday, February 25, 2002 8:24 AM
> To: boost_at_[hidden]; boost_at_[hidden]
> Subject: RE: [boost] Re: Design for a file system library
>
>
> At 09:58 PM 2/24/2002, Jeff Garland wrote:
>
>  >> Seems like we should hold off on time until Jeff Garland and his group
>  >get
>  >> their time library proposal done.
>  >
>  >This hasn't been fully settled, but the generic time has the ability to
>  >extract
>  >the date, and the time of day (hours, minutes, seconds and fractions of a
>  >second).  The resolution of the fraction of seconds is something that can
>
>  >be
>  >adjusted so if we need nanoseconds and the system can provide them then
>  >that's
>  >we'll do.  The fractions of a second approach allows most code to handle
>  >the
>  >sub-second stuff generically for different resolutions.  However,
>  >nanosecond
>  >resolution won't be supported on many platforms, so we would need to play
>
>  >some
>  >tricks (like set nanoseconds to zero on all non-supporting platforms or
> use
>  >a
>  >templated time type to adjust the resolution by platform) to deal with
>  >this.
>
> I guess what I'm saying is that at least two potential Boost libraries
> (threads and filesystems) need some notion of time that goes beyond
> anything now in the standard, so we really need a Boost-now and
> standard-later solution so developers don't have to keep reinventing the
> wheel.

I agree.  Since GDTL supports the concept of multiple time systems for different
purposes, I'd like to gather the specific requirements for threads and
filesystems.  Here's what I see from the current file discussion and the current
threads library:

* represent time durations (eg: 01:02:03.0000001) (thread only)
* convert durations to counts a different resolutions (micro, nano, etc) (thread
only)
* represent time points  (eg: 2002-02-25 08:00:00.0000001) (both)
* represent time points with resolutions down to nano-seconds (both)
* provisions for platforms that don't support nano-seconds (both)
* get the current time point from the clock (both)
* add durations to a time point (thread only)
* compare timepoints  (eg: > < == !=) (both)
* compare durations   (eg: > < == !=) (thread only)
* ability output a time point to a string (file only -- clients)
* a desire to minimize the dependencies

Some things you DON'T need:
* ability to represent time points prior to 1970
* ability to represent 'special values': not-a-time, infinities
* ability to output time durations to string (except maybe for debugging)
* ability to parse a string and build a time point or duration

Thoughts?

Jeff