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

Several issues

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.