>>>>> "CN" == Chris Nandor <[EMAIL PROTECTED]> writes:
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 :-)
CN> No, you misunderstabd. I am saying that we are not sure that we have the
CN> all the platforms covered that DO have perl ports. Only Mac and VMS and
CN> Unix users have spoken up, that I know of.
:-) No, you misunderstood. Your solution requires knowledge of non-port
target platforms.
>> Come on now. Perl is only as reliable as its installation. Consider copying
>> a Config.pm from one machine to another.
CN> I don't think you understand ... if you use $ENV{TZ}, at least it can be
CN> changed for each user, for when you change time zones, DST, etc. For
CN> Config.pm, you have to edit a global value. Ick.
But the OS's idea of the epoch is global!
>> Just a function/variable that would contain the offset from machine/os
>> system epoch to unix (or universal) epoch.
CN> But there is no universal epoch. And what makes Unix special?
The universal epoch for perl. Unix is not. It is simply one that is
well known. I really don't care what the offset is. We could even
have multiple. All that is required that a perl program be able
to determine portably what the difference between the syscall idea
of time and some 'universal' perl epoch.
Then all the programs would need to be able to translate from any
OS to any other OS would be the offsets between any system and
the perl epoch.
Perl would not have to maintain this table it would not have to go
out in CORE, one less thing to be maintained.
<chaim>
--
Chaim Frenkel Nonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
