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 [EMAIL PROTECTED] http://pudge.net/
Open Source Development Network [EMAIL PROTECTED] http://osdn.com/
