At 5:34 -0400 2000.09.13, Michael G Schwern wrote: >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.) It is rarely a problem, but I have run into it, where people want to store time() in a file and then use it on other platforms (Mac OS). >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) Yeah, at least 64 bits. Microseconds, well, I don't really know much about such things, nor do I care. I don't see any problem with implementing this in the core, as long as the current timezone is known (which could be a problem). And then we would need to be able to provide converstions to and from this "Perl" epoch and the system epoch. I've already started Time::Epoch to facilitate this. #!/usr/bin/perl -wl use Time::Epoch; my $perlsec = 966770660; # Sun Aug 20 07:24:21 2000 on my Mac OS my $epochsec = perl2epoch($perlsec, 'macos', '-0400'); my $perlsec2 = epoch2perl($epochsec, 'macos', '-0400'); print $perlsec; print $perlsec2; print $epochsec; # correct time on Unix: print scalar localtime $perlsec; # correct time on Mac OS (-0400): print scalar localtime $epochsec; I should put it up on CPAN. If anyone wants it, let me know. -- Chris Nandor pudge@pobox.com http://pudge.net/ Open Source Development Network pudge@osdn.com http://osdn.com/Thread Previous | Thread Next