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

*To*: "Marc Feeley" <feeley@xxxxxxxxxxxxxxxx>, <srfi-19@xxxxxxxxxxxxxxxxx>*Subject*: RE: leap seconds*From*: "Will Fitzgerald" <fitzgerald@xxxxxxxxxxxx>*Date*: Tue, 14 Mar 2000 09:13:18 -0500*Importance*: Normal*In-reply-to*: <200003131724.MAA02614@xxxxxxxxxxxxxxxxxxxxx>*Reply-to*: <fitzgerald@xxxxxxxxxxxx>

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.

**Follow-Ups**:**Re: leap seconds***From:*Marc Feeley

**References**:**leap seconds***From:*Marc Feeley

- Prev by Date:
**leap seconds** - Next by Date:
**Re: leap seconds** - Previous by thread:
**leap seconds** - Next by thread:
**Re: leap seconds** - Index(es):