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?
