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
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk