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
