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. OK, here are my quick replies to your your quick responses to my quick comments. > It doesn't assume this many seconds in a year; Note: you mean "day" not "year" (i.e. a day is 86400 seconds roughly). You made this error in the SRFI also. > 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. This is not a disadvantage, it is a blatant error! If you call something "universal time" it better correspond to UTC. Common Lisp made a big mistake here. > 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. Just the R5RS and predecessors, with (current-input-port) et al. My model for the computer's clock is that there is an implicit parameter to the program that is updated continuously by the hardware. So in this respect it is very much like the implicit parameters that are the current input port, et al. > 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. But it would still be consistent if you specified that the resolution is at least 1 second, because you can always strip the fractional part if you don't want this (and your Common Lisp style accessors could do this by default). > > 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'? A multiple value interface is clumsy and slow because if you want a single component you have to extract them all (and there are many components) and this is a common case (get the day of the week, or the year). Moreover you have to remember all the components and their order. For 2 or 3 components that's doable, but I couldn't do it without the documentation for 9. Finally, the interface lacks modularity and upgradability. If as an implementor I'd like to add a component (such as microseconds) then to keep the multiple value interface I'd have to change all the code that calls decode-universal-time and that may not be possible. > Again, CWCL. 1-1-2000 seems like a poor choice because time isn't > defined before this number. 1-1-1970 might be fine. Now this is a major bug. I was born in 1961. I want to be able to represent my birthday to put in a database, etc or simply to figure out on which day of the week I was born. In fact, I'd like to do that for any point in time. Bignums, positive and negative, allow us to do this easily. What is the problem here? The SRFI doesn't say there is an upper limit, so you have to use bignums anyway, no? Once again Common Lisp got it wrong. > 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. I'm sure you are aware of all the advantages of abstract datatypes and all the disadvantages of concrete ones. The extra calls to the conversion functions are well worth it. Marc