Front page | perl.perl6.language.datetime |
Postings from September 2000
At 17:11 -0400 2000.09.15, Chaim Frenkel wrote:
>>>>>> "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 :-)
No, you misunderstabd. I am saying that we are not sure that we have the
all the platforms covered that DO have perl ports. Only Mac and VMS and
Unix users have spoken up, that I know of.
>>> 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.
I don't think you understand ... if you use $ENV{TZ}, at least it can be
changed for each user, for when you change time zones, DST, etc. For
Config.pm, you have to edit a global value. Ick.
>>> 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.
But there is no universal epoch. And what makes Unix special?
--
Chris Nandor pudge@pobox.com http://pudge.net/
Open Source Development Network pudge@osdn.com http://osdn.com/
Thread Previous
|
Thread Next