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

[r6rsguy at free-comp-shop.com]

> From: John Cowan <cowan at mercury.ccil.org>
> 
> > What does Posix have to do with a language that may be implemented on
> > any OS?  Use UTC.
> 
> With what epoch?

I don't care at all, it's one addition to convert the epoch.
Use the Posix epoch if you like it, I did not specify
because I don't think it matters.

> If you are to represent time as a number,
> there has to be a zero time, or epoch.

Obviously.  Choose any you like.

> > In particular, Posix torques up leap seconds.
> 
> Yes, it does.  But almost all computers do too.

And will continue to do so if it keeps getting
written into standards.

> 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.

How many milliseconds is that?

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

Because time-of-day does not increase at a uniform rate.

> 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.

I am not worried about precision, I am worried
about correct arithmetic.

> > 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.

Write that more clearly and point out
the implications.

Or leave it up to the implementation,
as I advocate.

> > It may or may not be incremented when a leap second
> > passes.
> 
> The same as what I'm proposing, except that "may or
> may not" is just "may not" in my proposal.

You are *forbidding* an implementation to
increment the clock before a leap second?

> 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.

So what does your proposal do when the
file is out of date?  I think the uncertainty
is inherent in the situation.  But not important
for purposes of printing the date on the contract.

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

I agree.  I have no problem with your method of
printing the Mayan or French revolutionary calendar.
They don't need millisecond accuracy.

You can fix the whole problem, as far as I am
concerned. simply by making your instant into an count
of seconds with no fractional part.  Then the
sub-second timer can be added as separate API.

Otherwise it's false advertising.

  -- Keith