Below are several issues I've found with the current state of SRFI 19 that
should be addressed.  There are several other open issues in the
post-finalization discussion archive, too.

====

The SRFI document states the following:

Monontonic (sic) time, in this implementation, is the same as TAI time;
differences between TAI and UTC are resolved through a leap second table.
According to the International Earth Rotation Service, there will be no leap
second in December, 2000. Thus, the leap second table is guaranteed to be
correct through June, 2000.

The documentation of the reference implementation states the following:

TAI and UTC date converters no longer look at leap seconds, which was an error.

Should this note in the document be removed?

Also, the implementation of time-tai->date contains the following conditional:

(if (tm:tai-before-leap-second? (time-second time)) ... ...)

This seems to violate the note that TAI date conversion no longer look at leap
seconds, which is an error.  Is the implementation or documentation incorrect?
  Whichever it is should be changed.

====

The issues section is supposed to be present only during the draft period
(although this convention has not been following closely in the past).  Since
the section is empty, I recommend removing it on the grounds of being a typo.

====

I would expect the following to return true, but returns false in the current
reference implementation.

(time=? (make-time time-monotonic 0 1000000000)
         (make-time time-monotonic 1 0))

There is no range specified on the nanosecond argument for the time
constructor, so I assume this is a valid program.

For the date constructor there is a range given on the nanosecond argument in
the SRFI document, namely "an integer between 0 and 9,999,999, inclusive."

There are 1,000,000,000 nanoseconds in a second.  Was this meant to be between
0 and 999,999,999 inclusive?

I recommend changing the range on the date constructor, which appears to be a
typo, and including the above expression in the test suite.

====

The SRFI document makes no requirement that a constant such as time-monotonic
is equal to the symbol 'time-monotonic, but rather requires only that
time-monotonic be bound to a symbol representation.   However, the test suite
is littered with expression such as (current-time 'time-tai), which may not
work on implementations taking a different implementation strategy than the
reference implementation takes.  I recommend all these quotes be removed from
the test suite.

====

There is a still a bug in the reference implementations handling of "~f"
format strings in date->string.  (This bug was supposedly fixed by replacing
split-real with tm:fractional-part).

In PLT Scheme, using the reference implementation and NOT the (lib "19.ss"
"srfi") module which has an alternate implementation, the following results in
an error:

(date->string (time-monotonic->date (make-time time-monotonic 1 0)) "~f")
=> +: expects type <number> as 1st argument, given: #f; other arguments were: 1

The bug is found in tm:fractional-part:

(define (tm:fractional-part r)
   (if (integer? r) "0"
       (let ((str (number->string (exact->inexact r))))
	(let ((ppos (tm:char-pos #\. str 0 (string-length str))))
	  (substring str  (+ ppos 1) (string-length str))))))

This code makes the assumption that a decimal will be found in the string
representation of an inexact number, which is not the case:

(number->string (exact->inexact 1e-09)) => "1e-09"

Thus (tm:char-pos #\. "1e-09" 0 (string-length "1e-09")) => #f and (+ #f 1) is
a type error.

I recommend looking at the procedure tm:decimal-expansion found in the PLT
implementation for a way of correcting this.

http://svn.plt-scheme.org/plt/trunk/collects/srfi/19/time.ss

David