gpt4 book ai didi

mysql - Zend_Date 和 Cronjob 的异常行为

转载 作者:行者123 更新时间:2023-11-29 00:38:47 25 4
gpt4 key购买 nike

我们有一个 Cron-Script,它可以检测 - 如果某些用户被踢出了我们的应用程序。如果特定值为 1,我们可以检测到这一点 - 但在流中,没有设置新条目。脚本每小时运行一次。大多数未检测到。但自 2012-10-31 23:59:03 以来,每个用户都被检测到。如果我在我的本地机器上运行脚本,甚至在运行 cron 的同一台机器上运行脚本。一切都得到了应有的处理。首先,我们的脚本:

require_once ('cron_init.php');
ini_set('date.timezone', 'Europe/Berlin');
ini_set('max_execution_time', 30);
ini_set('memory_limit', -1);
error_reporting(E_ALL);
ini_set("display_errors", 1);

Zend_Date::setOptions(array('fix_dst' => true));

$userinfos = new Repricing_Dbservices_Userinfos();
$users = $userinfos->getUsersForRepricing();

$repricingstream = new Repricing_Dbservices_Repricingstream();
$error = new Repricing_Dbservices_Error();

if($users!==false AND count($users)>0){

$counter = 0;
$errCounter = 0;
$jetzt = new Zend_Date();
$jetzt->setTimezone('Europe/Berlin');
$jetzt = $jetzt->get(Zend_Date::TIMESTAMP);

foreach($users as $user){
$stream = $repricingstream->getStreamLimit($user);

$last = new Zend_Date($stream);
$last->setTimezone('Europe/Berlin');
$last = $last->get(Zend_Date::TIMESTAMP);

$diff = (($jetzt-$last)/60);

$error->setError(1, 'DIED', $diff, $user);

if($diff > 50 ){
$errCounter++;
$userinfos->setUserFree($user);
$error->setError(1, 'DIED', 'ANSTOSSEN', $user);
}

$counter++;
}
$error->setError(1, $errCounter, 'ANSTOSSEN_ALL', 'ALL');
}

通常 $diff >= 0 AND $diff <= 4但是,我们检测到 $diff总是围绕381595 .如果我们用 cron $diff 运行它是,因为它应该。我们还检测到 $jetzt现在(应该)只有$last更晚了。 381595之后。但那不应该。最后一个流日期是完全正常的。我们无法理解的这种行为。 Zend_Date 与 cron。贝弗 2012-10-21 23:59:03该脚本按原样运行了 2 周。我们无法解释,为什么会这样。可以吗?

最佳答案

考虑一下:

$right = new Zend_Date('2012-11-01 12:12:12', Zend_Date::ISO_8601);
var_dump( $right->getIso() ); // 2012-11-01T12:12:12+00:00
var_dump( $right->getTimestamp() ); // 1351771932

$wrong = new Zend_Date('2012-11-01 12:12:12', null, 'en_US');
var_dump( $wrong->getIso() ); // 2012-01-11T12:12:12+00:00
var_dump( $wrong->getTimestamp() ); // 1326283932

现在真正奇怪的部分是:在我的 PC 上它是默认的第二种行为 - 即,当没有额外的参数被赋予 Zend_Date 构造函数时。

重点是,Zend_Date 在尝试解析日期时间字符串时有点……太有用了。例如,它考虑了语言环境 - 但服务器和客户端的语言环境!如果字符串无法在此语言环境的规则中解析,它默默地放弃 - 并尝试使用另一个规则。

这就是为什么 2012-10-29 被解析为 10 月 29 日(尽管 区域设置建议的内容,因为没有第 29 个月) - 但是 2012-11-01 变成了 11 月 11 日 - 把你的脚本搞砸了。 )

关于mysql - Zend_Date 和 Cronjob 的异常行为,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/13198674/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com