On Wed, 13 Sep 2000, Michael G Schwern wrote:
> > 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?
There are potential problems either way.
1. (Perl5 way): If you store the time from within a perl program and
then read it with a perl program on another OS, then you might have a
problem.
2. (RFC 99 way): If you store the time from within a perl program and
then read it with a C program on the SAME OS, then you might have a
problem.
In my work, I encounter both situations. I work on the same data with
different languages. I also move that same data among different systems.
> (At which point the DBAs in the
> audience will say you should have used an SQL DATETIME type instead of
> an INTEGER.)
Exactly. (Or some suitable generalization if your "database" isn't
really a Database, but just a plain ol' file.)
Since either way can produce problems, I think we ought to stick with
the way that's the least work for perl -- namely doing nothing!
In my humble opinion, I think perl's time() ought to just call the C
library's time() function and not waste time mucking with the return
value. Instead, if the time is to be stored externally for later use by
another program, the programmer should be responsible for converting the
time into a suitably useful and portable format. Any unilateral choice
made by Perl6 in that regard isn't going to be of any help unless everyone
else (Java, Python, C, etc.) follows along.
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
