Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-02-25 13:50:14

At 11:43 AM 2/25/2002, Jeff Garland wrote:

>> -----Original Message-----
>> From: Beman Dawes [mailto:bdawes_at_[hidden]]
>> 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
>> wheel.
>I agree. Since GDTL supports the concept of multiple time systems for
>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
>threads library:
>* represent time durations (eg: 01:02:03.0000001) (thread only)
>* convert durations to counts a different resolutions (micro, nano, etc)
>* represent time points (eg: 2002-02-25 08:00:00.0000001) (both)
>* represent time points with resolutions down to nano-seconds (both)

A suggestion: figure out the maximum resolution any (actual, not
theoretical) current system will need. Then assume Moore's law has quite a
bit of life left. Adjust accordingly. If that means nano-seconds, fine,
but it is obvious in 15-years that pico-seconds will be needed, make
allowances now.

>* 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

OK, I guess. Another question to ask yourself is how far do you want a
filesystem (or less likely, a thread) to last? In other words, when does
roll-over occur going forward? I'd assume a couple of hundred years on the
theory a file might really last 50 years, but you should then add a big
fudge factor to stifle endless arguments about what the exact number should

>* 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

Looks good,


Boost list run by bdawes at, gregod at, cpdaniel at, john at