Re: [boost] Date/Time formal review

From: Joachim Achtzehnter (joachim_at_[hidden])
Date: 2002-04-17 15:48:38

George A. Heintzelman wrote:
>
> I think Jeff is right here. I've imagined things like, having an
> 'instant' and an 'interval', both opaque types, and both of which can
> be represented differently in different systems. 'Instant' isn't much
> of a problem, I think. But interval is.

Interval isn't a problem either. But it is important not to confuse
concepts. By sticking with a physical model at the core of the library the
concepts "time point" (or "instant" as you call it), "time interval"
(defined by two time points), and "duration" (distance between two time
points) have universal meaning independent of the calendar system chosen
to label time points.

> For example, suppose you're in the financial world. Even putting aside
> the issue of business days, if I add 1 year to a particular instant, I
> want to get an instant which represents the same wall-clock time on the
> same date next year.

Yes, this is similar to the example I mentioned about locating the time
point corresponding to local midnight. These concepts make sense only in
the context of a calendar/time system. They are clearly not the same
concept as the physical duration defined above. In my view it would be a
mistake to pretend they are the same. Functionality of this kind should be
defined at the calendar/time system layer separate from the concepts
defined at the physical layer. The physical concepts, e.g. duration, still
have the same meaning even if you choose a certain calendar/time
representation for labeling time points.

> But that interval, while a logical constant, is not a fixed number of
> seconds, because of leap days and leap seconds. So I would not be able
> to specify the desired interval as a generic opaque interval here.

"Advancing by one year" is an important operation at the calendar/time
layer, but it is distinct from adding a certain physcial duration to a
time point. A given application may need either or both of these
operations, hence it is important to keep them separate.

> On the other hand, if I do the same thing in an astronomical
> application, I may want to add 365.25... days exactly, not caring about
> wall clock time.

Here you are adding a physcial duration to a time point.

> Going back to the business world for another example, corporate bonds
> accrue interest based on a 360-day year in which each month has 30 days.
> (In real terms, what that means is that if you buy a bond on March 1st,
> you pay the seller 60 days interest even though it's only been held (in
> non-leap-years) 59 days.) This wreaks havoc with figuring the interval
> between two dates, for a computer (though it makes life easier for
> typical humans ;).

This does not deal with physical durations. You need different concepts
for this.

> In summary, these things are quite complicated outside the simple realm
> of physics (okay, physics time is only simple in Newton-land, but I
> digress).

Yes, ageed. As Jeff has pointed out himself in an earlier posting a
date/time library should support both aspects of time: the physical
aspects and the political/human aspects. It is better to model these as
separate concepts (and provide both where appropriate) instead of
pretending they are the same and defining them differently for different
calendar/time representations.

Joachim

-- 
work:     joachima_at_[hidden]   (http://www.netacquire.com)
private:  joachim_at_[hidden]          (http://www.kraut.ca)