This page is part of the web mail archives of SRFI 19 from before July 7th, 2015. The new archives for SRFI 19 contain all messages, not just those from before July 7th, 2015.
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