On Wed, 13 Sep 2000, Chris Nandor wrote:
> At 14:30 -0400 2000.09.13, Andy Dougherty wrote:
> >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.
>
> That is what Time::Epoch should address, I hope.
Well sure, if the programmer is going to be responsible enough to use
Time::Epoch[*] (or any other suitable way of storing time information)
then either the perl5 way or the RFC99 way can be used just fine in
principle.
It goes both ways. No matter what perl6 does, there are real situations
where problems could arise. And, of course, there are workarounds to most
of those problems.[**]
The question is simply one of defaults, and I think the perl5 way is
better. Within a running program, it seems to make more sense to me to
stay consistent with the underlying system library call. After all, you
might access that library call in a variety of indirect ways, such as
stat() and through XS extensions.
When storing data to disk, of course you have to consider how that data
will subsequently used. That's a good time to think about epochs and the
whole broader question of appropriate date/time storage. But if you're
storing useful data to disk, you're probably storing more than just the
time. For every other piece of data you store, you still have to consider
how you want it stored. Standardizing on the epoch for just one piece of
data, namely the time, just doesn't seem to me to be all that useful.
> If we standardize on the Unix epoch (although possibly with 64 bits), this
> won't be an issue for the overwhelming majority of users.
Are you sure? Won't this affect Windows as well as Mac users? There are
an awful lot of Windows users.
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
[*] I'm guessing here, since I've never seen Time::Epoch described and
can't find it in the archives for this list.
[**] Aren't there systems which keep local time and for which the
conversion to UTC simply can't be figured out? Of course these issues are
likely to less-frequently encountered on such systems, so I suppose it
doesn't matter too much either way.
