On Sun, Nov 28, 2010 at 9:07 AM, John Cowan <[email protected]> wrote:
> Thomas Bushnell, BSG scripsit: > > > The time functions should return a NUMBER. I'm disgusted (sorry) with the > > retreat from Scheme's excellent numeric system. Implementations can > return > > whichever format number suits them best. Let the interface declare the > > accuracy of the returned value as well--as a number. > > Nobody disputes that the representation of an instant of time should be > a number, and a rational number at that. But instants aren't sufficient > for dealing with all cases of time. Back in the middle Devonian, an > instant (whether second or millisecond) is much too precise -- indeed, > a day is much too precise, as we know only roughly how many days per year > there were then. Less exotically, a government bond might fall due on > "March 31, 2031, 5 P.M. Washington D.C. time". What instant is that? > We don't know, because Congress might change the rules for Daylight > Saving Time again. > So what I heard was that you wanted to represent an instant of time as an integer, with some determinate resolution, and then the predictable fight about whether the integer should be denominated in milliseconds, microseconds, or nanoseconds. This is insanity. An instant should be a *number *without any mandated statement of just what kind of number it is. And, as I said, an interface that answers questions like "what time is it now" has an accuracy as well, which should be returned (and which is *not* the same thing as the precision of some determinate resolution). There is no worry about precision at all if you just return a number, and an accuracy value. I have no objection to conforming to the Posix rules for timezones. This is an operating system issue, after all, and we have once again decided to have language designers do operating systems work in a vacuum. The answer to your conundrum is that the system needs to have time zone files which will need to be updated when the law changes. This is something that every operating system now pays attention to, and it not something for programming languages to do more than offer a sensible interface. Indeed, before Posix declared it impossible, we had no trouble keeping track of leap seconds and handling them in the zoneinfo files too, but then Posix decided that leap seconds were impossible, and now we have the confusing rule that the epoch changes every time a leap second is issued. Ah, well, but at this point we're stuck with that bad decision, and it would be best if Scheme conformed to it. > So there has to be a way of representing and dealing with broken-out > dates and times, since those are what matter in the Real World. Yes, but that's irrelevant to the question I was speaking to, which was the insane question of what the resolution of the clock should be. *That's an operating system question. *The language should be adaptable to *any *resolution the operating system provides, and since Scheme already has an excellent numeric tower, we can use it. The separate question of what broken-out times should look like is one which I think we should handle by simply aping the Posix rules, which is pretty much what the proposal on the table looks like. It is the sub-second resolution question that I am crying shenanigans about. Thomas
_______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
