Several issues

[David Van Horn <dvanhorn@xxxxxxxxxxxxxxx>]

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