Andy Dougherty <[EMAIL PROTECTED]> writes:
On Thu, 14 Sep 2000, Charles Lane wrote:
>> 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.
Run that program during a DST change on my system, and you'll get +-3600
instead of 5. Yes, more radical surgery IS required, and you can't just
take the C libraries "time()" function and expect it to be suitable for
Perl's time(). There's code to deal with this in Perl5's vms/vms.c.
>> 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.
Of course not, it was stating a preference for either of two (out of
many) possible alternatives. Of those two, I prefer Epoch=0.
If Perl5 on VMS just used the time() function from the C library we'd
have Epoch=14400 part of the year and Epoch=18000 the rest of the year.
Varying from year to year. Think this is a good way to do it? I don't.
>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.
Whenever you communicate outside of Perl and you use "low level" data
you have to deal with the possibility of mismatches in things like
formats and representations (number endianness, floating point binary
representations, and yes, times).
When you're writing code to port to other applications you *should*
be looking out for stuff like this.
The problems that I ran into with Epoch != 0 were purely internal
to Perl...NOT the place where you'd expect to have to mess around with
EpochOffsets. That's programmers get sloppy.
>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.
Agreed.
>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, those of us using Perl on VMS for some years have had both defaults.
So there is some experience with this.
I've been in the Epoch !=0 mode and it sucked. I vote for Epoch=0 as
the default.
--
Drexel University \V --Chuck Lane
======]---------->--------*------------<-------[===========
(215) 895-1545 _/ \ Particle Physics
FAX: (215) 895-5934 /\ /~~~~~~~~~~~ [EMAIL PROTECTED]
