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

>>>>> "CN" == Chris Nandor <[email protected]> writes:

>> 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.

CN> Why?  File::Spec is in the core.  So are multitudinous
CN> ExtUtils::MM_* modules.

Covers the platforms that have perl ports. Your problem requires solutions
for platforms that don't have a perl port. (yet :-)

>> If you don't like an envar, then something in Config.pm or its replacement
>> that is adjusted upon installation.

CN> Which is even more unreliable.

Come on now. Perl is only as reliable as its installation. Consider copying
a Config.pm from one machine to another.

>> One other possiblity, if Perl could determine the epoch by examination.
>> 
>> $unixepoch  = mktime( "1970...");
>> $machinepoch= mktime( "1970...");

CN> Huh?

Oops. The value that mktime for the unix epoch is the offset needed.

$unixepoch   = mktime( ..., 1970 );
@machinepoch = localtime(0);

Some combination of mktime, localtime(0), will yield how much the epoch
is shifted.

>> 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.

CN> If you want no change, then what are you offset from?  If time() remains
CN> system-dependent, then we have nothing against which to offset it.

Just a function/variable that would contain the offset from machine/os
system epoch to unix (or universal) epoch.

<chaim>
-- 
Chaim Frenkel					     Nonlinear Knowledge, Inc.
[email protected]				               +1-718-236-0183