Chronos 101: "Points" in Time`
It is common to imagine that a point in time is a precise instant in time, based on the idea that a number line is the optimal mathematical model of time, and based on the idea that an instant is a dimensionless point whose location on the number line can be specified as a real number. In practice, however, the "real number line" model of time does not pass muster.
One problem is that the physics of time does not correspond to the real-number line model, because time is quantized: There is a minimum possible measurable length of time, known as the Planck Time, and also a minimum possible measurable amount of distance and of mass, known respectively as the Planck Length and the Planck Mass.
Another problem is that, in practice, we can't measure durations of time to anywhere near a Plank-time level of precision. Few are those with access to a clock that can measure durations of time with even nanosecond precision--and even that's a billion times less precise than the highest precision time duration measurement we've been able to achieve up to now (2006,) and 10^37 times less precise than a Planck Time.
Generally, physical measurements are not infinitely precise. There are usually "error bars" that prevent the "data points" collected by measurement devices from truly being dimensionless "points." This certainly applies to the measurement of time durations. There is little to be gained from pretending otherwise.
And then there's the problem of clock synchronization. Even without considering the fact that General Relativity prevents the concept of simultaneity among a set of events from having any absolute reality or well-defined physical meaning, clocks simply cannot be perfectly synchronized. Even if clocks existed that could timestamp events with infinite precision, no two of those clocks would ever agree as to the precise timestamp of any one event (to infinite precision.) If each clock that timestamps an event (with infinite precision) provides a slightly different time value, which one is correct?
Also, even if durations of time could physically (and not just conceptually) have infinitesimal extent, it would nevertheless not be possible to specify most "points" in time with infinite precision (the exception being those whose location on the timeline happens to be expressible as a rational number.) You can't physically write out a number with an infinite number of digits, nor store such a number in computer memory. The number must be rounded or truncated.
Considering all the points above, it should therefore be clear that any specification or measurement of a "point" in time (as a coordinate on a number line, expressed as a real number) is necessarily an approximation, even without considering the issues of quantization, quantum uncertainty and General Relativity.
In spite of the foregoing problems and issues, we humans insist on measuring time using discrete, countable durations of time. We like to pretend that each event can be timestamped at a precise instant, and so unambiguously placed in a particular second, minute, hour, day, month and year. There's nothing wrong with that, provided we understand that physical law limits us to approximations valid only to some finite limit of precision.
Consequently, Chronos represents "points" in time to some specified resolution, because physical law prevents "time points" from actually being dimensionless points on a timeline. Chronos does not recognize nor attempt to support what most would conceive of as "instants" in time. Rather, a Chronos point-in-time value specifies the initial instant of some interval of time whose duration is no smaller than the resolution of the internal numeric representation. So Chronos points-in-time are not dimensionless points, but rather intervals of time.
Note that the model of time used by Chronos means that there are no gaps in the Chronos timeline. Chronos thus avoids the problem that occurs in the model of time typically adopted by other date/time libraries, which can only represent some of the points on their limeline, and leave most of the points on the line unspecifiable (so that, in effect, they have to translate most timepoints up or down to the nearest point-in-time representable by the internal implementation of their date/time values.) Of course, in practice the result is the same. But the "dimensionless point" model of points-in-time often leads to strange architectural and design decisions that are not well-motivated, and can even cause suboptimal code.
Currently, Chronos provides three different classes that implement the concept of a "point in time." One is the class YearMonthDay, which has a resolution of one calendar day--which means both that its temporal extent is one day, and also that the minimal (non-zero) difference between any two instances of YearMonthDay is one day. The second one is the class Timepoint, which has a resolution of one nanosecond--which means both that its temporal extent is one nanosecond, and also that the minimal (non-zero) difference between any two instances of Timepoint is one nanosecond. The last one is the class InfiniteTimepoint, whose two instances represent either the infinite past ("InfiniteTimepoint past") or the infinite future ("InfiniteTimepoint future.") InfiniteTimepoints have infinite duration.
So a Chronos "date" (instance of YearMonthDay) is simply a point in time whose resolution (and temporal extent) is one calendar day. And since the only difference between a YearMonthDay and a Timepoint is the representational resolution, there is no reason that they both cannot be mostly type compatible (which, in fact, they are.)
There are also two other fundamental types of time values supported by Chronos: Durations of time (temporal extents) and periods of time (temporal intervals.) A time duration has a length of time, but has no location on the timeline (e.g., "one day," "fifty years," "3 minutes 20.3989 seconds.") A time interval has both a starting point-in-time (a location on the time lime, to some limit of resolution) and a duration (whose extent can be any durational value, not just "day" and "nanosecond"; for example "the time interval starting at 2006-12-22T03:13:06.325914 and lasting for 15 days, 12 hours, 19 minutes and 23.43557 seconds.")
Chronos provides several classes that implement durational values, and the class Timeperiod that implements time intervals.
Part 2: Chronos 101: Durational Values
