Boost logo

Boost :

From: Jeff Garland (jeff_at_[hidden])
Date: 2001-03-23 21:55:54

It turns out I have spent a bit of time working on this problem. I have been
working on a library I call the Generic Date Time Library(GDTL). So far, I
think every point raised in this thread was included in my motivations (see
below) and design of GDTL. I got interested in this several years ago when I
helped design/write some time classes to support a satellite control system. We
had to worry about details like leap second tables along with efficiently
supporting all sorts of time based calculations. In some cases we also needed
to have precision down to micro seconds. On the other hand, we had other places
where we needed to store millions of times in a database (each day) with only
second-level precision. So in this case, forcing micro second resolution
unnecessarily bloated the size of the database. In the end we had more than one
time library. Some good components, indeed, but we were never quite smart
enough, and a host of project realities kept us from getting everything into a
single library. But it got me to thinking about whether it could even be done.
So, I starting building GDTL as a test case for my own exploration of generic
programming and advanced C++ design techniques. In addition, I wanted to get
some highly configurable C++ date/time which would be highly portable. So, with
that backdrop, here is the set of goals I worked out:

Motivation / Goals:

-- Provide a basis for performing efficient time calculations
   -- days between dates
   -- durations of times
   -- durations of dates and times together
-- Provide concrete classes for manipulation of time
   -- date, time, date_time, date_duration, time_duration
   -- support for infinity - positive infinity, negative infinity
-- Provide clock interface for
   -- retrieving the current date time information to populate classes
   -- pluggable access to a network / high resolution time sources
-- Provide input and output for time including
   -- pluggable multi-lingual support
   -- provide ISO8601 compliant time facet
-- Realize C++ std library compatible concepts and patterns
   -- I/O facets for different locales
   -- traits based customization of internal representations for size versus
   -- time-based iteration
-- Provide the maximum possible reusability and flexibility by
   -- Allowing the use of different epochs and precision (eg: seconds versus
microseconds, dates starting at the year 2000 versus dates starting in 1700)
   -- Options for configuring unique calendar representations (Gregorian, +
   -- Allow for flexible adjustments including leap seconds

Design Overview:

Underlying the generic date-time library design is the idea that time is
monotonic (This idea comes from the way GPS systems deal with time). That is,
any point in time can be represented as a number of "ticks" from a known
starting time or epoch. A tick represents some period of time with a known
precision (eg: millisecond, hour, century etc). Calendar and time traits
classes provide for the calculation of a "view" on top of the internal monotonic
representation. All adjustments for leap years, leap seconds, time zones,
various calendars, etc are handled by the calendar and time traits classes.

I currently have working implementations of a date/time templates using a
Gregorian calendar, duration classes, calendar iterators (imagine a last day of
the month iterator), and some other pieces. I have completely ignored the
input/output aspects of the library b/c I am not an expert in locales and I know
it will be lots of not terribly interesting work.

The bad news is that a fair amount of work is needed to cleanup the current
implementation, and adding the locales and other I/O aspects are a big job. I
am currently over busy at my day job (until May at least) to give any
significant time to GDTL.....


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