develooper Front page | perl.perl6.language.datetime | Postings from September 2000

Re: RFC 99 (v3) Standardize ALL Perl platforms on UNIX epoch

Thread Previous | Thread Next
From:
Chris Nandor
Date:
September 15, 2000 13:14
Subject:
Re: RFC 99 (v3) Standardize ALL Perl platforms on UNIX epoch
Message ID:
p05001917b5e83206ff94@[192.168.0.77]
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                      pudge@pobox.com    http://pudge.net/
Open Source Development Network    pudge@osdn.com     http://osdn.com/

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About