From: Bill Seymour (bill-at-the-office_at_[hidden])
Date: 2002-04-16 06:43:23
> > 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?
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.
> 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)
require calculations across multiple time zones...the problem
given on the WIKI page is a good example. (Being one who
likes riding trains, I'd be more interested in calculation
a schedule for, say, the /Texas Eagle/; but that's a separate
Also, I usually think that worrying about I/O-time efficiency
is penny-wise and pound-foolish.
> The current submission does no automatic conversions --
> these are left to the user.
We agree on that. The question is when, and how often, the user
needs to do the conversions.
> 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.)
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-)
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk