On Wed, Sep 13, 2000 at 07:10:30AM -0000, Perl6 RFC Librarian wrote:
> Currently, internal time in Perl is maintained via C<time>, which is
> highly system-dependent. On some systems, this is relative to the UNIX
> epoch, while others use their own epochs (MacPerl uses 1904, for
> example).
>
> All versions of Perl on all platforms should maintain time both
> internally and externally as seconds since the UNIX epoch (00:00:00 01
> Jan 1970 UTC).
Color me obvious, but could you discuss some of the practical
situations where this becomes a problem? My gut says you're very
right, but the only one I could think of is that of two Perl programs
on two different OS's with two different Epochs storing time() in a
database and sharing the info. (At which point the DBAs in the
audience will say you should have used an SQL DATETIME type instead of
an INTEGER.)
And if we're going to standardize on something, let's squeeze as much
out of this as possible. signed 64 bit integer and microseconds. (I
think that's another RFC)
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
But why? It's such a well designed cesspool of C++ code. Why wouldn't
you want to hack mozilla?
-- Ziggy
