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, Iy

Returns 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, Iy

returning 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
d...@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk