RE: [boost] Date/Time formal review

From: Jeff Garland (jeff_at_[hidden])
Date: 2002-04-16 11:06:59

Bill Seymour wrote:
>
> I'm suggesting that the objects /assume/ that they hold UTC
> when doing calculations, including conversions.  If no
> conversions are required, then no conversions are required;
> and the objects can hold whatever the user wants them to.

I see.  The current systems do not assume either way.  But I don't think it's really a problem to
use the way you are suggesting.

> > If you do 1000 calculations and 2 I/O's then you might want UTC.
> > If you do 1000 I/O's and 2 calculations then you might want to
> > store as local instead.  Depends on the application.
> >
>
> In the latter case, you also might want to reconsider using
> date/time classes at all, except in the rare instance when
> one of those two calculations needs to be done.
>
> My guess is that most actual applications that need to do /any/
> arithmetic on dates and times (beyond simple comparisons -
> and string comparisons work fine with the ISO representation)

Perhaps, but string comparisons can turn out to be very costly.  More disturbing is that the
performance will depend on the data.  For example, comparing a bunch of dates that have all the same
year-month combination would  be more expensive than comparing dates from different years.  A date
or time turned into an integer representation has a fixed comparison cost.

> > The type of thing you are suggesting would be a nice extension.
> > Out of curiosity, what do you use for the TZ parameter?
> >
>
> 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.)

I don't think the timezone has to be OS specific.  It is only OS specific if you have to depend on a
facility of the OS to perform the conversion.  In fact, I expect ultimately there will be a number
of different ways to 'specify' a timezone.  The JAVA libraries provide a couple different timezone
classes to allow dynamic creation of timezones.  The timezone database uses a region specifier (eg:
americas/new york) to distinguish zones.

Jeff