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:
Simple primitives are good.
My stuff dealing with dates is usually hand written based on top of the localtime
and gmtime calls in the standard Time:: module bundled with Perl anyway.
Anything fancier requiring a CPAN download rarely gets used on production
boxes because a lot of administrators don't mind installing a pre-built Perl
package, but they shy away from downloading and compiling a ton of
add-on modules (hey, they can't all be Perl-trained).
I know I've been on this soapbox in the past but...
I hope, with Parrot, people will get away from a common practice of writing Perl modules in C with a binary interface. Unless the module HAS to be in C for API interface (complex math computations or performance sensitive stuff like encryption and compression where 10% matters), I prefer a pure bytecode implementation for ease of deployment.
Some people write both pure Perl and C implementations of modules; to get around that, I hope we can provide a low level, optimizable "system" programming language for Parrot (or put enough hints in Perl6) so people can write fast implementations without requiring a real C compiler.
-Melvin
