[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Scheme-reports] Comments on draft 6



Alex Shinn wrote:
>> Fair enough, and that question was less editorial than the others,
>> so let me clarify. Specifying TAI is an unusual decision, and it
>> seems to me that either using Unix time or not providing this
>> function at all will be better, but I can only claim so if we agree
>> on goals of introduction of this function.
> 
> As you say, there are generally two uses of monotonic time -
> as a timer, and as a timestamp (and basis for conversion to
> calendar time).  POSIX time is completely unusable for the
> former because it jumps a second.

Right. (And as John said, current-jiffy is for that).

> It is also broken for the
> latter because it is unable to represent the distinction between
> the first and second repetition of a leap second.  POSIX
> time was a mistake that should not be repeated.

Right.

> TAI time has neither of these problems - it is clearly the
> Right Thing.

TAI+leap second table is in all ways superior to POSIX time, yes.

> There are two concerns: first conversion to
> POSIX time for interoperability with broken systems.  I'd
> just as soon leave this to WG2 and not stain the core language
> with historical cruft that is not part of Scheme's history.
> Second, ease of implementation.  This is not as hard as
> one would think, and a reference implementation which
> supports runtime updates to the leap-second table will be
> provided.

Will you provide it before June 30, 2012 (when the next leap
second occurs)?

> In the worst case, TAI with no runtime updates
> is no more broken than POSIX time with no updates.

Well, the worst case is when an implementation obtains TAI
from correct POSIX time using outdated leap second tables.
(In this case TAI will both jump and lie).

My argument is this: all useful things you can do with TAI, but
cannot do with current-jiffy, can (and should) be done using a
proper date library (the one that reports 23:59:60 on leap seconds).
Since you can't implement such a library using only TAI (you need
leap second and timezone tables), and since it's problematic to
obtain TAI on many current systems, I argue that R7RS-small should
only provide a timer (current-jiffy), and R7RS-big should provide
a full date library.

Does anyone else agree with this?

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