Boost logo

Boost :

From: Joachim Faulhaber (afojgo_at_[hidden])
Date: 2008-05-29 17:59:02

Hi Colin,

2008/5/29, Colin Caughie <c.caughie_at_[hidden]>:
> To answer your question with a question: What actual date/time do you think a
> default-constructed date_time should be, and by what time interval should ++
> increment it?
> To me it seems that any answers to these two questions must be completely
> arbitrary, in which case I'd question the usefulness of defining them.

>From my view as an author of generic code (in this case
interval-template code) these questions have been quite determined:

Coding for instance equality of intervals with open and closed bounds,
if a,b,c and d are values of a discrete type, like an integer based
time, the assumption, that there is a least unit (resolution) on the
values of that type is inevitable.
(a, b] == [c, d] is true, if(++a==c && b == d)

If the resolution is nanosec and I would increment in seconds the
result would be wrong.

In addition, for an object like an empty interval [1,0] you need to
generically express nullness and oneness.

Time is theoretically continuous but technically it's defined by a finite unit
"the duration of 9 192 631 770 periods of the radiation corresponding
to the transition between the two hyperfine levels of the ground state
of the caesium 133 atom" (

the ++ here is not the second but the time of the transition between levels.

Many date and time classes like boost::date_time classes are
implemented via an unsigned integral. So there is a finest resolution
on them and thus a smallest representable duration.

Incrementation (operator ++) has to be the incrementaton of such smallest unit.

Integer implemented date and time classes also have a minimal
representable time. This is naturally given by the 0 value of the
implementing unsigned integer. From the (limited) point of view of
such a special implementation, this is the beginning of all time and
thus the awesome event of a big bang ;-)

This would be my favourite candidate for a default constructor.

Of course the time origin is still a little arbitrary. Yet for my
generic code any value between min_time and max_time-1 was workable,
even a moving one (like today, which I won't prefer), but
unfortunately not a singularity.

>While I
> understand your initial distaste for the idea, a singular value actually seems
> like a pretty good way out.
> I haven't looked at your interval library (although I probably will, it sounds
> interesting), but one idea for using it with date_time might be to wrap
> date_time objects in a class of your own, which defines its own "big bang" time
> and default increment interval, e.g. 1 second.

That's what I had to do to make the librares play together:

boost::posix_time::ptime operator ++(boost::posix_time::ptime& x)
{ return x += boost::posix_time::ptime::time_duration_type::unit(); }

boost::posix_time::ptime operator --(boost::posix_time::ptime& x)
{ return x -= boost::posix_time::ptime::time_duration_type::unit(); }

inline boost::posix_time::ptime type<boost::posix_time::ptime>::neutron()
{ return boost::posix_time::ptime(boost::posix_time::min_date_time); }


Interval Template Library
download from

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