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