Re: [Scheme-reports] [r6rs-discuss] Date and time arithmetic library proposal for R7RS large Scheme

[John Cowan <cowan@x>]

r6rsguy@x scripsit:

> If fractions are allowed, why count milliseconds?

Given that it should be easy to implement most dates as fixed-size
objects, milliseconds seem like a good compromise between range and
precision.

> What does Posix have to do with a language that may be implemented on
> any OS?  Use UTC.

With what epoch?  If you are to represent time as a number,
there has to be a zero time, or epoch.  There are various
alternatives, such as the start of 1900 C.E. Gregorian (Common
Lisp), the start of 4173 B.C.E. Julian (Julian days), the start of
November 17, 1858 (modified Julian days), and lots more listed at
http://en.wikipedia.org/wiki/Julian_day .  But Posix-epoch time is
available to 1 second precision on every modern system, so I chose it.
It's also the only one close enough to the start of UTC timekeeping to
make conversions possible.

> In particular, Posix torques up leap seconds.

Yes, it does.  But almost all computers do too.  In any case, most
computer clocks aren't accurate to 1 part in 10^8, which is the
discrepancy between Posix time and UTC time since the beginning of UTC.

> Trying to put both time-and-date *and* precise sub-second intervals
> into one number is a loser.

Why?  2^53 is a lot of range, and the further away from the present,
the less precision we need or even can use, given the fundamental
uncertainties about things like day length.  It doesn't even make sense
to ask about UTC time much before 1970.

> In particular, does the current "instant" increment uniformly, or does
> it encode the current date?  It can not do both, and it is unclear
> which you intend.

The latter, as Posix clock() does.

> It may or may not be incremented when a leap second passes.  If it is
> not incremented then the same number will be given to the leap second
> as to the preceding second.  In other words, sometimes the time is
> 23:59:59 for two seconds before the new year arrives.  This ambiguity
> is the price of encoding the time-of-day as a single integer.

The same as what I'm proposing, except that "may or may not" is just
"may not" in my proposal.  That way, at least every second except a leap
second and the preceding second have fully specified instant values.
In your proposal, there's no knowing what they mean, as some leap seconds
but not others may be accounted for if the leap-second file (or other
source) is out of date.

> (tick-count) - An integer that is incremented at
> regular intervals as quickly as possible consistent
> with regularity.  This number will never decrease while
> the program is running, but may be changed arbitrarily
> when the system is re-booted or equivalent.
> 
> (ticks-per-second) - The tick rate of the above
> counter.  This number does not change, but may differ
> from system to system.
> 
> (epoch-of-zero-ticks) - the second, in time-of-day
> form, at the beginning of which the tick-count 
> was zero.  (extrapolated, the tick-count
> need not actually have been zero, indeed the
> computer need not have yet been built)

This is a good API, but functionally disjoint from what I'm dealing
with now.

-- 
John Cowan    cowan@x    http://ccil.org/~cowan
The whole of Gaul is quartered into three halves.
        --Julius Caesar

_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports