$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Jeff Garland (jeff_at_[hidden])
Date: 2002-04-17 16:40:02
>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.
You keep talking abstractly about some 'core' of the library that should 
be implemented with a 'physical' model.  I think this 'core' you 
talking about is an 'integer'.  Both the gregorian date and posix 
time systems ARE implemented internally with a counted rep and 
provide ONLY a physical duration model.  It is only once you start 
pinning down the Epoch, resolution, and conversions from the label 
form that any real behavior gets specified. 
If you can identify other useful features of the 'core' you are 
describing that go beyond what an integer type can provide, I'd
be happy to consider it.
>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.
I would expect for physics the preferred system would be TAI.  But then
again there is astro-physics which might need something else.  Neither
of these domains would be well supported by the submitted time system --
that is not the intent.  The intent of the current system is to provide
for more pedestrian date/time programming with an eye toward supporting
additional systems in the future for more specialized needs.  
In the end I think the stumbling block in the whole thread is the 
assumption that the physical model is somehow more fundamental.  I 
used to think this way as well, but now I don't believe either way is 
more fundamental, more right or wrong.  They are just different 
and GDTL is designed to support both.  
Jeff