RE: [boost] Date/Time formal review

From: Jeff Garland (jeff_at_[hidden])
Date: 2002-04-16 12:09:33

> That's necessarily O/S-specific; so the timezone class that
> > I wrote uses the pimpl idiom.  The only implementation that
> > I wrote accepts POSIX TZ strings.  (Actually a superset.
> > It accepts strings like "CST6CDT" which, I understand,
> > is not really a good POSIX TZ string.)
> >
> > Actually, this is from a civil time library that I was going
> > to submit to Boost; but I didn't when I saw that the GDTL folk
> > were first to publish.  8-)
>
> I realize time constraints may not allow it, but what would be beneficial to
> me is if you could try and create a new time system using the GDTL based on
> your civil time library.  That would give all of us some insight into how
> well the G in GDTL works.
>
> > A thought:  is civil time sufficiently different from other
> > uses of time (astronomical, historical, etc.) to warrant
> > a separate library?  The need to represent time zones seems
> > like a special requirement that the others don't share;
> > and that's a difference in interface, not just a difference
> > in range, precision and accuracy.
>
> I don't *think* it would require a separate library.  I would hope that the
> design allows for the creation of a system of civil times.

As Bill suggests, I believe the answer is that it requires a custom time system for 'local' civil
time to be 'well supported'.  For example, some first class support for timezones and the ability to
construct and convert times using those timezone classes.  To do this obviously requires changes to
both the interface and the implementation of the time system.  And I believe that the GDTL design
provides the ability to do this through extension and use of the library facilities rather than
building a 'completely different library'.

As a sketch, here is how I would see the 'civil time' class we are discussing added to the current
library.  For sake of discussion, lets say we had a timezone class you already wrote :-)
1) add new subdirectory under boost/gdtl/civil_time
2) define a new civil_time_system class.  This class is responsible for defining the rules of the
time system and the types used internally the generic time class.  Based on our discussion it might
be make sense that the time type would contain a pointer the timezone type, but would internally
convert all local times to UTC.  The gregorian calendar could be used as is for the underlying date
representations and interface.
3) derive a new time class civil_time from gdtl::gdtl_time (found in boost/gdtl/time.hpp) adding in
interfaces which allow for specification of a timezone.
4) Provide a time duration by deriving from gdtl::gdtl_time_duration.  You might customize the
allowed resolution of the time representation since the needs of civil time would typically only
require 1 second level time resolution.
5) Add some typedefs to generate matching iterators, time periods, and clock interfaces.
6) Add some custom time formats and parsing as desired for conversion to/from strings.  There are
some generic tools in the library core to help with this as well.

On first blush this might seem like alot of things to do, but the vast majority of this simple
instantiation of templates.  Cruise thru the files in /boost/gdlt/posix_time -- there isn't much
code in most of them.  And of course, you can do less if you don't want to have all the features.

As I said before, I expect that some time zone classes to eventually be added and something like
this civil time class would also be added.

Jeff