>>>>> "CN" == Chris Nandor <[EMAIL PROTECTED]> writes:
>> my_time_in_local_epoc
>> + current_os_epoch_offset
>> - timezone_ofset_in_seconds
>> = time_in_unix_epoch_seconds
CN> But again, I don't know what you are trying to say. Are you saying we
CN> should have some global "constant"? If so, you still have problems:
Sure, we have plenty of global constants. It could either be an UPPERCASE
or something in the Perl:: namespace.
CN> * We do not know if it will always be this simple for every platform
Hard to see how the three variables wouldn't cover the spectrum.
CN> * You might need to convert from an epoch other than your native
CN> one, whether it is a different time zone, or a different epoch
CN> entirely; with a function, you can easily take care of these
CN> problems * Global variables suck
That is beyond the scope of this problem. How to get a machine specific
integral epoch seconds to a unix (or other) epoch seconds.
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> TZ is unreliable. We should never offer a solution that is going to rely
CN> on TZ without knowing the exact details. We need to identify platforms
CN> that have problems and what neeeds to be done with them.
In what way is it unreliable? If the user/sysadmin sets it wrong, they
will learn adjust. If you mean that people play with this to get some
effects, then we should have a PERL6TZ that is the user/sysadmin's
method of telling perl how the sysadmin has set the machines
clock.
If you don't like an envar, then something in Config.pm or its replacement
that is adjusted upon installation.
One other possiblity, if Perl could determine the epoch by examination.
$unixepoch = mktime( "1970...");
$machinepoch= mktime( "1970...");
then none of this is necessary.
CN> You can only avoid breakage with current scripts if you make no changes to
CN> the current facilities (which is what Andy proposed). My proposal of a
CN> separate module for handing epoch differentials will work pretty much the
CN> same whether we change time() to return native or Perl epoch.
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.
>> No TZ, no adjustment
>> current code works properly. TZ set, perl will do an adjustment.
CN> What adjustment? You were not before talking about doing any adjustment,
CN> were you? Maybe you could state exactly what you propose, because I don't
CN> know what it is.
Disregard this. I was indicating that _IF_ p6 would honor a TZ variable
the lack of a TZ variable could leave the results unchanged for old
scripts. Just a way of maintaining backward compatiblity.
<chaim>
--
Chaim Frenkel Nonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
