RE: [boost] Date/Time formal review

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

> Jeff Garland wrote:
> >
> > I have an experimental local time system that does exactly what you are
> > saying.  However, I didn't include this in the initial submission due to
> > the additional time required to both polish and review.
>
> In my opinion, without proper support for local time with DST changes the
> library will not be of much practical use. Perhaps, this experimental
> system should be added and reviewed as part of the submission?

The current submission does provide the ability to do this.  More than one user of the library has
already used it to convert from local to UTC times.  The only difference is the details of the
interaction.  The local time class would obviously provide superior encapsulation of these details.

> > There are tricky issues like how to handle time points that might be
> > outside the range of the target system.  Maybe you don't want to allow
> > that, maybe you want to allow extending the range of the system.  Both
> > might be reasonable.  There are also issues of accuracy.  For example if
> > you projecting a 'local time' into the past and you really need to get
> > the exact answer you have to take into account the ever changing DST
> > rules.  For example, during World War 2 (and many other periods) the DST
> > rules where different in the US than they are now.  This makes
> > calculation very difficult.
>
> Many of these objections go away if one chooses an appropriate system
> as the universal one. Using local time would obviously be silly. One would
> definitely use one that is not dependent on adhoc political decisions.

I wasn't suggesting using local time as the 'universal system'.  What I was discussing was some of
the problems involved with mapping something like 'local time' onto a universal system (read counted
system because all the proposals for universal systems are counted).

> Agree that there is not one right choice, but there are several reasonable
> ones.

This I agree with and I am open to collaborating on what the best choices.

Jeff