On Thu, 14 Sep 2000, Charles Lane wrote:
> From the perspective of a non-Unix user that has been fighting this battle
> for a few years now, you can't just take the C library time() on all systems.
Sorry, I don't know what that sentence means.
> On at least some non-Unix systems, the time() function is itself an attempt
> to emulate Posix functionality...note that I say "attempt". And also note
Do you mean that the following program might not print '5' (well, about 5,
given sleep's uncertaintites ...)
#include <stdio.h>
#include <sys/types.h>
#include <time.h> /* May need sys/time.h instead */
int main(void)
{
time_t start, stop;
start = time((time_t *) 0);
sleep(5);
stop = time((time_t *) 0);
return printf("The difference is %ld seconds.\n", stop - start);
}
If you mean the above program won't print '5', then I don't see how
changing the epoch could possibly help. More radical surgery is required.
If you mean the above program _will_ print '5', then I'd say the system
has a fine time() function, whatever epoch it uses, and I think perl
should use that time() function.
> I don't know how many places there's an implicit "Epoch=0" embedded
> deeply in Perl modules and apps, but I've run into plenty of them.
I agree those are portability bugs in those modules and apps. Just like
assumptions that '/' is the directory separator, and that integers are 32
bits long, and many of the other problems cited in perlport.pod.
> Adding a module to define epochs will sure help, but as long as the
> "default" is so simple, plenty of programmers will just assume Epoch=0
> and build it into their code.
Sadly true.
> So my suggestion is that either Epoch=0 for everyone, or make it
> distinctly non-zero for everyone so lazy programmers have to use
> $Perl::EpochOffset everywhere.
This is not a simple either-or. Suppose you are using a Mac and that
perl6 decides to use the Unix epoch. Suppose you want to communicate with
other Mac programs or library functions about time (e.g. perhaps by
calling things through the XS interface or by storing to a file). Since
the perl6 time() and C time() will now disagree about what time it is,
even the non-lazy programmer will have to use $Perl::EpochOffset
everywhere.
In sum, *either* approach works in some situations and fails in others.
There is no universal solution. Epoch=0 everywhere will *not* solve all
problems. Nor will Epoch=native. Neither is perfect. Each has problems.
So we have to pick a default. (Yes, I'm sure everyone agrees that making
it easy to make the other choice via some nice module is nice too.) But we
have to pick a default. And I vote for perl's time() simply calling the
system time().
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
