Re: boost support for date/time handling?

From: Dave Gomboc (dave_at_[hidden])
Date: 2001-12-20 15:15:24

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

Well, begin() + duration() = end(), so it's clear that a range can
accurately represent a duration.  There's even more than one way to do
it.  Of course, if you really want durations, not ranges, then you might
well use a separate abstraction for them, as you suggest.

> 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 don't agree with your suggested use of stronger typing here:

  a) If having exactly the birth date, as opposed to a general idea
     of when someone was born, or a more specific idea (e.g. minute,
     used in hospitals) is a _requirement_, then this constraint
     could, and I'd say should, be handed in design-by-contract
     manner.

A single day is an interval of time.  This isn't analogous to
circle/ellipse.  It's fundamental to the concept of a day.

  b) I'd say that it shouldn't be a requirement, because it is not
     valid (= satisfiable for all people).  Granted, this is
     unlikely to be a problem with some database of 1000 local
     employees, but it's quite possible to not know one's birth date.
     Many people born in a war-torn area can relate to this.  Another
     example: we will never have precise birthdates for many important
     people of history.

A three-day range may be the best one can do.  Why not accept it as
valid?  This would absolutely be a typical range to assign when you've
been able to track down someone's baptismal certificate.

Discretizing time is common-place, but IMO the practice does not provide
advantage here.  Systems written in such a manner perform well when all
data is in line with the designers' expecations, but are not robust.

> I see a need for three types (not suggesting these as the names,
> though):
>
> datetime_range
> datetime_instant
> datetime_duration

"date" could be dropped from all of them, but people used to looking for
"datetime" might find time_instant, time_duration, and time_range (or
better, time_interval) weird.  Then again, perhaps not.

> 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).

There's still the templating aspect.  These three things with usual
periods probably cover off the work you and I do, but astronomers
needing leap seconds and geologists needing numbers that don't fit into,
say, a 32-bit integer might object.

Dave Gomboc