Re: [boost] Date/Time formal review

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
issue.  8-)

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.

--Bill Seymour