At 15:55 -0400 2000.09.15, Chaim Frenkel wrote:
>CN> * We do not know if it will always be this simple for every platform
>
>Hard to see how the three variables wouldn't cover the spectrum.
Very hard to see, until we know what the disparate platforms might require. :)
>CN> * You might need to convert from an epoch other than your native
>CN> one, whether it is a different time zone, or a different epoch
>CN> entirely; with a function, you can easily take care of these
>CN> problems * Global variables suck
>
>That is beyond the scope of this problem.
Depending on the solution. If we keep the situation as it is now, that
time() is always system-dependent, then it is very much part of the scope
of this problem, because we need to have ways for people to convert to and
from other epochs. If we standardize on an epoch, then perhaps it isn't
part of the problem.
>This new module to cover your feature would require that it know every
>known epoch and timesystem (or at least the useful ones.) Something
>this domain knowledgable shouldn't be in CORE.
Why? File::Spec is in the core. So are multitudinous ExtUtils::MM_* modules.
>If you don't like an envar, then something in Config.pm or its replacement
>that is adjusted upon installation.
Which is even more unreliable.
>One other possiblity, if Perl could determine the epoch by examination.
>
> $unixepoch = mktime( "1970...");
> $machinepoch= mktime( "1970...");
Huh?
>CN> You can only avoid breakage with current scripts if you make no changes to
>CN> the current facilities (which is what Andy proposed). My proposal of a
>CN> separate module for handing epoch differentials will work pretty much the
>CN> same whether we change time() to return native or Perl epoch.
>
>I'm on the side of no change. Just enough that a user can determine how
>to offset the return from time, to pass to other data sinks.
If you want no change, then what are you offset from? If time() remains
system-dependent, then we have nothing against which to offset it.
--
Chris Nandor [EMAIL PROTECTED] http://pudge.net/
Open Source Development Network [EMAIL PROTECTED] http://osdn.com/
