RE: [boost] Date/Time formal review

From: Jeff Garland (jeff_at_[hidden])
Date: 2002-04-15 15:11:02

> > Yes, I would almost always recommend storage of date/times
> > as UTC if multiple time zones are involved.  However, if our
> > application only represents times in a single timezone
> > (say one without DST) we might have to pay for a lot of
> > unnecessary conversion.
> >
>
> Well, in the case you gave, since no conversion of any kind
> is required, just /assume/ that you've got local time and
> pay nothing.  8-)

I thought you were suggesting that the date and time classes should internally convert to UTC?

> In the case when some conversions are required, always
> storing civil time as UTC means that you need to pay
> only at I/O time (or perhaps when a civil time is constructed
> from some representation that's assumed to be local time).
> It seems to me that the "unnecessary" conversions are the ones
> that must happen in order to do some calculation.

That is exactly the tradeoff.  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.

> Well, sure; but if the conversion happens only at I/O time,
> then there's no requirement for the conversion to modify
> the date/time object itself.  In a datetime class that I use,
> a datetime can be converted to/from a std::tm for I/O (the
> library has no I/O of its own); and the conversion takes
> an optional timezone object as an argument (defaults to UTC).

The current submission does no automatic conversions -- these are left to the user.  The type of
thing you are suggesting would be a nice extension.  Out of curiosity, what do you use for the TZ
parameter?

Jeff