Right now we've got the capability of getting the current time in epoch seconds with the time op. This is good. However.... there's the issue of actually *doing* something with it.
I'm torn here as to what to do. On the one hand, it's supremely tempting to punt and not have parrot do a darned thing with the time and leave it to library code to handle it. On the other, CPAN is littered with the carcasses of time and date modules. On the third hand, at least some of the date handling stuff is provided by the underlying C runtime library (there's a lot of interesting stuff in the C89 spec) so it seems silly to reimplement something we're guaranteed to have around anyway.
What I'm thinking we may want to do is provide a minimal interface--turn the time integer into a string rep or split out into an array, something like:
localtime Sx, Iy
gmtime Sx, IyReturns a formatted string for either localtime or gmt in X, with the value in Y being the return from the time op, and:
localtime Px, Iy
gmtime Px, Iyreturning an array of sec/min/hour/day/month/year/weekday/yearday/isDST?/TZ/secsfromUTC in X from the time int in Y. Uear, in this case, being the actual real year--none of this year-1900 nonsense
And yeah, this is a simple wrapper around the C RTL routines.
FWIW, if we start getting into the "What should our base time for the epoch be" arguments, I'll warn you that the answer if I have to make one is probably Nov 17, 1858 at midnight, give or take a bad memory, and our time value'll be a 64-bit integer. So think carefully before you go there. :)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
