From: bill_kempf (williamkempf_at_[hidden])
Date: 2001-12-20 11:04:27
--- In boost_at_y..., "Dave Gomboc" <dave_at_c...> wrote:
> > Sorry, I'm not sure whether I understand. Would you use TWO
> > datetime_instant objects (or one instant and one span?) to
represent
> > December 17, 2001? What advantage does this have? Please give an
> > example.
>
> Neither. I'd use one datetime_range.
Rarely do I use a datetime_range type of concept. I usually work
with either a datetime_instant or a datetime_duration. I realize
that other people's needs will vary from mine, but forcing me to use
a datetime_range to indicate either of the other two (how can a range
accurately represent a duration?) would just make my life miserable.
> Clearly, when working just with days, one can use datetime_instant
and
> forget about it. But when working with a mixture of single days,
ranges
> of days, months, years, you name it, I've found it much more
convenient
> to simply treat everything as ranges of datetimes. In that case,
the
> day of December 17 would be represented publicly as:
>
> datetime_range.begin() => December 17, 2001, 12:00am
> datetime_range.end() => December 18, 2001, 12:00am
> datetime_range.duration() => 1 day
So make your datetime_range constructible frome a datetime_instant.
This makes your life easy while not complicating mine. Further,
having individual concepts for all three types allows for use of more
strongly typed operations. If I need to set the birth_date for an
employee the operation should take a datetime_instant insuring that a
user doesn't pass in a three day range.
I see a need for three types (not suggesting these as the names,
though):
datetime_range
datetime_instant
datetime_duration
I don't see a need for a seperate date or time type. The
datetime_instant can default the time to midnight and be used for
dates. The time type is really a datetime_duration (it's the amount
of time that's passed within an arbitrary given day).
Bill Kempf