Re: Dates and times again
Dan Sugalski [EMAIL PROTECTED] writes: In an attempt to drain the swamp... So far as I can see, we need, in descending order of importance (and speed) (And if there's stuff missing, add them): 1) A timestamp value 2) A way to chop the timestamp to pieces 3) A way to turn the timestamp into a string 4) A way to turn pieces to a timestamp 5) A way to turn the string into a timestamp All of which is confounded by the joys of timezones and platform limitations. As far as I can tell, the only thing we can absolutely count on are: asctime, ctime, difftime, gmtime, localtime, mktime, strftime Everything gives you a ticks of size ? since ? hook or three. In most places the ticks are less than second. All the stringify and human/planet-izing seems to be library fodder. gettimeofday() is widely available or fakeable. (Tk uses it.) Seems $^T could start based on time(2) and then get deltas using something finer. Perhaps aspire to clock_gettime() and fake that interface where not available? We can't even count on timegm, unfortunately. Neither can we count on getting fractional time. (Or even really count on getting a GMT time that's actually GMT, as far as that goes, but that's user-misconfiguration and there's a limit to what I'm willing to care about) Nor strptime for time parsing, though a case could be made there that we could do our own. (Cases to be made for that should be accompanied by unencumbered source to do the parsing ;) Can't even count on the full range of output when splitting the time up--if you check the CVS logs you'll see I yanked out a few elements because they're not C89 and there wasn't any way to synthesize them easily that I know of. That means we can't convert to TAI, since that needs leap second info we don't have, so base time can't be TAI. From what I can tell from the interfaces and long painful experience we can't convert to and from anything other than the current system timezone. (Maybe. I'm not 100% sure that's reliable either) Right now, you can get a black-box integer timestamp that's fixed to GMT time, and you can disassemble that timestamp into day/month/year pieces. I adjusted the year to be a real year, but I haven't adjusted the month. We can do that, though. We can easily: *) Give a float timestamp *) Adjust the timestamp to various base dates (I've already made my preferences clear :) My general rule-of-thumb for ops is that they must: *) Be something we want to guarantee behaviour on everywhere *) Require C code *) Have a fixed signature Being primitive isn't necessary as such, but doesn't hurt. Having to be required present at all times isn't necessary either, though we should nail down lexical oplibs if we want to start talking about secondary libraries of this stuff. Anyway, given the restrictions on what we have to work with, the first question is: *) Is what we're providing correct *) What *aren't* we providing that we must to allow full and proper date processing in modules without much pain?
Re: Dates and times again
Larry Wall [EMAIL PROTECTED] writes: That would seem like good future proofing. Someday every computer will have decentish subsecond timing. I hope to see it in my lifetime... It isn't having the sub-second time in the computer it is the API to get at it... My guess is that eventually they'll decide to put a moratorium on leap seconds, with the recommendation that the problem be revisited just before 2100, on the assumption that we'll add all of a century's leap seconds at once at the end of each century. That would let civil time drift by at most a minute or two before being hauled back to astronomical time. Given that most people live more than an minute or two from their civil-time meridian who will notice? (Says me about 8 minutes west of GMT.) I'd say what's missing are the error bars. I don't mind if the timestamp comes back integral on machines that can't support subsecond timing, but I darn well better *know* that I can't sleep(.25), or strange things are gonna happen. But you can fake sleep() with select() or whatever.
Re: Dates and times again
Nick Ing-Simmons [EMAIL PROTECTED] wrote: Larry Wall [EMAIL PROTECTED] writes: ..., but I darn well better *know* that I can't sleep(.25), or strange things are gonna happen. But you can fake sleep() with select() or whatever. $ cat sl.pasm sleep 0.1 end $ time parrot sl.pasm real0m0.116s user0m0.010s sys 0m0.000s leo
Dates and times again
In an attempt to drain the swamp... So far as I can see, we need, in descending order of importance (and speed) (And if there's stuff missing, add them): 1) A timestamp value 2) A way to chop the timestamp to pieces 3) A way to turn the timestamp into a string 4) A way to turn pieces to a timestamp 5) A way to turn the string into a timestamp All of which is confounded by the joys of timezones and platform limitations. As far as I can tell, the only thing we can absolutely count on are: asctime, ctime, difftime, gmtime, localtime, mktime, strftime We can't even count on timegm, unfortunately. Neither can we count on getting fractional time. (Or even really count on getting a GMT time that's actually GMT, as far as that goes, but that's user-misconfiguration and there's a limit to what I'm willing to care about) Nor strptime for time parsing, though a case could be made there that we could do our own. (Cases to be made for that should be accompanied by unencumbered source to do the parsing ;) Can't even count on the full range of output when splitting the time up--if you check the CVS logs you'll see I yanked out a few elements because they're not C89 and there wasn't any way to synthesize them easily that I know of. That means we can't convert to TAI, since that needs leap second info we don't have, so base time can't be TAI. From what I can tell from the interfaces and long painful experience we can't convert to and from anything other than the current system timezone. (Maybe. I'm not 100% sure that's reliable either) Right now, you can get a black-box integer timestamp that's fixed to GMT time, and you can disassemble that timestamp into day/month/year pieces. I adjusted the year to be a real year, but I haven't adjusted the month. We can do that, though. We can easily: *) Give a float timestamp *) Adjust the timestamp to various base dates (I've already made my preferences clear :) My general rule-of-thumb for ops is that they must: *) Be something we want to guarantee behaviour on everywhere *) Require C code *) Have a fixed signature Being primitive isn't necessary as such, but doesn't hurt. Having to be required present at all times isn't necessary either, though we should nail down lexical oplibs if we want to start talking about secondary libraries of this stuff. Anyway, given the restrictions on what we have to work with, the first question is: *) Is what we're providing correct *) What *aren't* we providing that we must to allow full and proper date processing in modules without much pain? -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Dates and times again
On Wed, Mar 10, 2004 at 09:59:32AM -0500, Dan Sugalski wrote: : That means we can't convert to TAI, since that needs leap second info : we don't have, so base time can't be TAI. That part is only half true. Or maybe less than half, if UTC decides to cut loose from astronomical time and ends up tracking TAI exactly from now on. But we *do* know the mappings in the past. (Well, for the recent past, anyway. :-) : Right now, you can get a black-box integer timestamp that's fixed to : GMT time, and you can disassemble that timestamp into day/month/year : pieces. I adjusted the year to be a real year, but I haven't adjusted : the month. We can do that, though. We can easily: : : *) Give a float timestamp That would seem like good future proofing. Someday every computer will have decentish subsecond timing. I hope to see it in my lifetime... : *) Adjust the timestamp to various base dates (I've already made my :preferences clear :) 0 on 1/1/2000 works out very well if it turns out we don't do UTC leaps seconds any more. Then TAI and UTC only go nonlinear before 2000, and so far that's in the past, which is generally easier to predict afterwards, given enough historical evidence. And if they do add leaps to UTC in the future, then at least TAI and GMT always march in lockstep, and we'll be no worse off than we are now. :-) It will be very good if the fate of leap seconds is decided well before POSIX has to consider how to store time after that date in 2038. --http://www.ucolick.org/~sla/leapsecs/onlinebib.html My guess is that eventually they'll decide to put a moratorium on leap seconds, with the recommendation that the problem be revisited just before 2100, on the assumption that we'll add all of a century's leap seconds at once at the end of each century. That would let civil time drift by at most a minute or two before being hauled back to astronomical time. More to the point, it would put the problem off till another day (not to mention another generation). So that's my prediction. But then, I'm terrible at time estimation... : *) Is what we're providing correct I'd say what's missing are the error bars. I don't mind if the timestamp comes back integral on machines that can't support subsecond timing, but I darn well better *know* that I can't sleep(.25), or strange things are gonna happen. : *) What *aren't* we providing that we must to allow full and :proper date processing in modules without much pain? Snap-to-grid semantics for when the clock inevitably gets off by a second or two from somebody's idea of the correct time. (But that should be solved in your levels two through five, not in the timestamp.) The basic idea is I can add 86400 seconds to yesterday and I get the same time today, even if there was a leap second. One would have to request such a snap explicitly, I expect, because you'd have to communicate to it that you don't actually care about sub-minute times, or whatever your grid specifies. But that's how graphics programmers solve the mouse jitter problem, and I think we can learn from them. Larry
