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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk