I have a number of comments on this SRFI.

The current draft has this text:

    Second, a real (potentially inexact) between 0 and 61, inclusive, (seconds
    greater than 59 are for describing rare leap seconds)

This has two errors, I think -- 61 is not a legal second value, and 59.1 is
a non-leap second. This text fixes these problems:

    Second, a real (potentially inexact) in the range [0,61), (seconds
    in the range [60,61) are for describing rare leap seconds)

In general, many of the bounds given in the procedure definitions do not
specify if they are open or closed bounds. This should be cleaned up.
Most are pretty clear, but the bounds for time zones are not. What are they?
[0,86400)? (-86400,86400)? [-43200,43200]?

I prefer time-comparison names without terminal question marks.
I think these
  (time= t1 t2)
  (time< t1 t2)
are clearer than these
  (time=? t1 t2)
  (time<? t1 t2)
The terminal ? is redundant, hence unnecessary clutter.

A time API that seems excellent to me is found at
    http://www.cl.cam.ac.uk/~mgk25/c-time/
It is designed by a guy that appears to be a time expert, and has
    - provisions for integer nanoseconds
        nanosecond field soaks up the leap seconds; seconds field stays
	in [0,60) range.

    - a timezone struct
      These structs contain more information about the timezone --
      a name, summer time changeover information.

    - UTC, TAI, monotonic, process & thread time
      These concepts are not in the current SRFI.

By "integer nanoseconds," I mean that a time is represented as an integer
number of seconds and an integer number of nanoseconds, not as a single real.
I provided both the real and the pair-of-ints functionality in scsh; see pages
69 and 70 of

    ftp://ftp-swiss.ai.mit.edu/pub/su/scsh/scsh-manual.ps

There's (TIME), which returns an integer, and the pair of procedures
(TIME+TICKS) & (TICKS/SEC), which gives sub-second precision. TIME+TICKS
returns two values: an integer number of seconds, and an integer number
of sub-second "ticks." The system's tick granularity is given by TICKS/SECOND.
This was done to allow TIME+TICKS to use very low-overhead implementations,
suitable for timing program events without the overhead of the time stamp
perturbing the measurements. (E.g., TIME+TICKS could be inlined as a couple
of special register fetches on a Pentium...)

You may wish to look at the scsh time spec, at the above URL. It has some
flaws, due to its close binding to the Posix API, but also has some
nice features. There are two time representations -- time (seconds), and
date (broken-out time -- y/m/d/h/m/s etc.) The API is quite simple:
     (date)         -> the current date (a struct)
     (date tm [tz]) -> the date for time TM in timezone TZ

     (time)         -> the current time (an integer)
     (time dt)      -> the time for date DT

The scsh API also provides date->string formatting functions that
allow for a range of possible formatting; this kind of functionality
should be added to this SRFI.

SRFI-19's time zones are too simple. A time-zone structure is needed that
packages up things like daylight-savings time specs, simple string names,
etc., that can be passed as a parameter to the SECONDS->TIME and TIME->SECONDS
conversion procedures.

I painfully worked out a css style sheet & layout for doing SRFI's when
I did SRFI-1. You might want to grab the HTML source for SRFI-1 and look
at the top of the file -- it's all there, documented and laid out clearly.

Also worth considering carefully is the Java spec for the date, calendar
and timezone classes, e.g. the very nice writeup at
   http://java.sun.com/products/jdk/1.2/docs/api/java/util/Date.html
Java standardisation is worth tracking; there are large resources being
poured into careful specification of the language.
    -Olin