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.
Some quick responses to quick comments. > -----Original Message----- > From: Marc Feeley [mailto:feeley@xxxxxxxxxxxxxxxx] > Sent: Monday, March 13, 2000 12:24 PM > To: srfi-19@xxxxxxxxxxxxxxxxx > Subject: leap seconds > > > After a very quick look at SRFI-19 I have the following comments: > > 1) The interface assumes that there are exactly 86400 seconds in a > day. This is not true. There can be exactly 86399, 86400 and 86401 > seconds in a day, due to "leap seconds". Note that the point in time > where the leap seconds are added (or removed) is under the control of > a committee and there is no deterministic algorithm to determine in > advance where they occur (it all depends on the speed of rotation of > the earth which varies slightly, up and down, due to various factor). > So the "seconds" component should be in the range 0-60 inclusive. > According to "man ctime" under linux, the seconds field can go up to > 61, but I don't understand why that high. You should probably > research this a little more. Here are some interesting sources of > information: > > http://tycho.usno.navy.mil/leapsec.990505.html > http://www.naggum.no/lugm-time.html > It doesn't assume this many seconds in a year; it defines this many seconds in a year. One advantage is that you get a deterministic algorithm (as you say). Another important advantage is that you can treat time as a number, and use standard mathematical operators. The disadvantage is that drift from UTC, as you say. > 2) To be consistent with Scheme naming convention and practice, you > should rename "get-universal-time" to "current-time", > "current-universal-time", or "current-date". > Sorry, I missed the last Scheme Naming Convention--when was it held? Seriously, I don't have a problem changing the names, but perhaps you could point out a "here's how to name Scheme procedures" document; I'd appreciate it. > 3) Why limit the resolution of the time datatype to 1 second? > The resolution should be implementation dependent, and if you insist, > of at least 1 second resolution. This is so that an implementation > can use the time datatype for finer resolution timing (such > as a "(thread-sleep! wakeup-time)" procedure I am considering for > my thread SRFI). Otherwise, to do finer resolution timing you need > another time datatype, and this is rather clumsy. > The main reason is just that bug-a-boo of mine to be consistent with Common Lisp; I'll reconsider this. I've found the CL approach clumsy in just this way. > 4) I don't like the fact that the "year" component has a special > meaning between 0 and 99: > > Year, an integer representing the year C.E. (i.e., A.D.). If the > integer is between 0 and 99, however, it represents the current > year + the year (if it is less than 50) or the current year - the > year (if it is greater than or equal to 50). > > This is because the meaning of a date created with > encode-universal-time will depend on the time when that procedure was > called, and since there is no way to know precisely at what time it > was called there are (extreme) situations where the time meant is > not clear (i.e. meaning of year 50 at the turn of the year 2000 plus > or minus a few nanoseconds may be 1950 or 2050). > More Consistency With Common Lisp (CWCL). Still, I'm willing to drop this. > 5) Instead of the "multiple value" interface of decode-universal-time > I prefer single-value accessors of the kind: > > (universal-time-second ut) > (universal-time-minute ut) > ... > > and also (universal-time-second ut) would return a real, possibly > inexact. > Maybe. Perhaps you could give me reason beyond 'I prefer'? > 6) Why use 1-1-1900 as a base, why not 1-1-1970 which is the norm > under UNIX? I know this is a convention, but a closer base date gives > more implementation leaway... for example a 2 fixnum representation > (32 bit words, 3 tag bits) counting nanoseconds since 1-1-1900 will > wraparound in 1991 but if you count from 1-1-1970 it will wraparound > in 2061, which is probably reasonable for many applications. And if > you insist on 1-1-1900, please consider 1-1-2000 at least. > Again, CWCL. 1-1-2000 seems like a poor choice because time isn't defined before this number. 1-1-1970 might be fine. > 7) The time datatype should be abstract, i.e. it shouldn't be > a number. There should be conversion functions between time and > seconds since the base time: > > (universal-time->seconds ut) > (seconds->universal-time secs) > > Note again that the result of universal-time->seconds and the > argument of seconds->universal-time should be a real, possibly > inexact. > The main reason is insist that it be a number is one can use standard mathematical operators on them, without converting. You don't need a special time>, etc. > > [Useful implementation notes snipped] > > Marc > I think the most crucial question Marc's note raises is whether time (especially 'universal time') should be an abstract data type or a number; and, if a number, whether it should be a real or an integer. I'd be glad to hear others' ideas.