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