RE: [boost] Date/Time formal review

From: Jeff Garland (jeff_at_[hidden])
Date: 2002-04-17 09:45:27

> The library suffers from a fundamental design flaw: it doesn't separate
> the concepts of "time" and "calendar". Time intervals and points in time
> are natural physical quantities that should be manipulated independently

The civil calendar (in particular local time) is governed by the rules of legislators not physics.

> of the units we choose to measure them with. The approach taken by the
> "GDTL" (I don't think there's anything "generic" about it) would lead to
> an explosion of mutually incompatible sub-libraries for every calendar
> anybody wanted to use.

GDTL doesn't try and 'force' radically different date/time systems into the exact same mold.  Rather
it is an attempt to build constructs that enable rapid construction of new and consistent date/time
systems.  I believe sub-libraries is exactly the right way to handle this because the rules,
constraints, and usage of these libraries is sufficiently different that it demands independent
documentation.

> A date/time library should have types representing "point in time" and
> "time interval"; these would be opaque, with operations for arithmetic

It does.

> on them but no intrinsic connection with any kind of human calendar.
> Then you can add "calendar" types that represent a broken down time
> represented in a specific calendar. The calendar types would have no
> arithmetic properties themselves; they exist only to handle the
> conversion between the opaque time types and calendar-specific
> representations.

Well we think about it a bit differently.  The calendar or time_system provides the arithmetic
rules, types, and broken_down types for each system.

> Building Eurocentric assumptions into the language is exactly what the
> likes of Unicode and C++'s locale system have been developed to get rid
> of. I strongly believe that any proposal that doesn't separate the real
> physical concepts and their culture-specific representations into
> orthogonal components should be automatically rejected.

Physical concepts are one domain and civil time concepts are another.  Date-time systems must handle
both.

> On a tangential note, I also suggest that the concept labelled "time
> period" in the GDTL doesn't belong in a time library. It's a generic
> concept that would be better modelled as a template that can be
> instantiated on arithmetic types.

True, the concept could apply beyond time periods and the template does work for things other than
times.  I'd could happily go elsewhere if we have a place for it.  There are some other things in
the library that might fit into that category as well such as wrapping_int.

Jeff