On Wed, 15 Dec 2010, Alex Shinn wrote:
> > Any monotonic clock with unspecified origin is sufficient to represent
> > passage of time. What Alex suggested was to use TAI clock specifically
> > to represent both passage of time and UTC (civil time, wall clock time,
> > "date", call it as you wish).
>
> I said no such thing.

True. You said that a good thing about providing TAI clock is that
you can easily obtain current POSIX seconds from it. Correct? My
argument is that you can't.

> I'm suggesting using TAI to represent an
> unambiguous point on a timeline,

OK.

TAI is of limited use here though. If you need to represent "now +
N seconds", you use a monotonic clock with arbitrary point of origin.
If you need to represent "2029-02-12 19:31:12.5 EET", you use a
date object that contains all the fields separately.

What are the use cases for TAI specifically? I think there aren't
many of them, and considering that you can't obtain current TAI on
most systems, I think that basing a time API on it isn't useful.

> and presumably a record-like data type for dates.

Now I'm confused. Will the date object internally store only TAI
seconds? If so, then you know full well that it won't be able to
represent future dates in a stable way.

> If you wanted to compute a
> date-time in the distant future and store it as TAI time, then your
> point about not knowing future leap seconds is valid.  However,
> if you computed that time via second-interval arithmetic (i.e. you
> want exactly n seconds in the future) you'd be guaranteed to
> have the same loss in precision using POSIX time.

Right. And this "loss in precision" in both cases is completely
unacceptable. You don't add physical seconds to POSIX time, just
as you don't covert yyyy-mm-dd hh:mm:ss.xx time into TAI seconds.
You always keep them separately.

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