Re: [boost] Date/Time formal review

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-04-16 09:08:55

----- Original Message -----
From: "Bill Seymour" <bill-at-the-office_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, April 16, 2002 6:43 AM
Subject: Re: [boost] Date/Time formal review

> > 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.

Possibly, but date/time classes give you more utility then just the type of
calculations you're talking about.  For instance, they have a uniform data
representation that makes it easy to convert to other formats, including
binary formats, for further I/O operations.

> 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-)

I'm not sure it's actually "most", but I'm not sure that it matters.  You're
arguments are *very* appropriate for a large number of applications and
should be addressed.  In general, I'd prefer a representation in UTC because
it would optimize for the most common need.  The calculations to translate
from UTC to local is trivial in comparison to the processing needed for I/O
to begin with, so it seems a bit of over optimization in that case.

> Also, I usually think that worrying about I/O-time efficiency
> is penny-wise and pound-foolish.

Probably for the reason I just gave, no?

At least the GDTL design gives us a solution... we can just create a new
time system that behaves the way we want it to.  However, I still have to
evaluate how well this plumbing works in this regard.

> > 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-)

I realize time constraints may not allow it, but what would be beneficial to
me is if you could try and create a new time system using the GDTL based on
your civil time library.  That would give all of us some insight into how
well the G in GDTL works.

> 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.

I don't *think* it would require a seperate library.  I would hope that the
design allows for the creation of a system of civil times.

Bill Kempf