I'm really very sorry, but I won't be able to address these or other
SRFI 19 issues from some time due to various issues. If others want to
make changes to the reference implementation, I think I'd have time to
review it.

WF

On 7/18/05, David Van Horn <xxxxxx@cs.brandeis.edu> wrote:
> 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
>
>
>