Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk