Front page | perl.perl6.language.datetime |
Postings from September 2000
>>>>> "CN" == Chris Nandor <pudge@pobox.com> 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. chaimf@pobox.com +1-718-236-0183Thread Previous | Thread Next