【问题标题】:Is this a bug in PHP's gmstrftime() function?这是 PHP 的 gmstrftime() 函数中的错误吗?
【发布时间】:2012-09-25 12:06:02
【问题描述】:

我遇到了 PHP 的 gmstrftime() 函数的问题。 请看:

<?
$ts[]=1348573985; // '2012-09-25 13:53:05' (date returned from mysql's from_unixtime() function)
$ts[]=1233958620; // '2009-02-06 23:17:00' (date returned from mysql's from_unixtime() function)

foreach($ts as $t) {
    echo $t." => ".gmstrftime( "%d %B %Y - %H:%M", $t )."\n";
}
?>

输出将是:

1348573985 => 25 September 2012 - 11:53
1233958620 => 06 February 2009 - 22:17

如您所见,第一个时间戳是 2 小时(来自 mysql 的输出),由于时区设置,这是正常的。但是第二个只有 1 小时的休息时间,但我没有更改两个 gmstrftime() 调用之间的时区??

这是 PHP 的 gmstrftime() 函数中的错误,还是其他任何错误?

【问题讨论】:

    标签: php


    【解决方案1】:

    来自the manual for gmstrftime

    除了返回的时间是格林威治标准时间 (GMT) 之外,其行为与 strftime() 相同。

    格林威治标准时间全年相同。这与英国当地时间不同,英国当地时间在冬季设置为格林威治标准时间,而在夏季设置为“英国夏令时间”(GMT+1,即比格林威治标准时间提前一小时)。西欧也是如此,冬天是 GMT+1,而夏天是 GMT+2。

    您的 MySQL 数据库大概配置为欧洲本地时间,因此在转换夏季发生的 Unix 时间戳时,它会增加一个额外的小时以与夏季时间调整保持一致。

    在我看来,最好的策略是将所有系统设置为使用“UTC”(基本上与 GMT 相同),然后“在最后一分钟”转换为本地时区。您可以对其他时区进行标准化,但 UTC 可以作为调试的良好基准。

    【讨论】:

    • "最好的策略是将所有系统设置为使用 'UTC'" --- 就我个人而言,我总是在我更喜欢的时区(我居住的 TZ)中运行我的所有服务器并且它有效也没有问题。
    • @zerkms 只要您将其保留在设定的 UTC 偏移量处,那么可以。但是,如果您将其设置到某个位置并让它考虑夏季/夏令时调整,根据我的经验,事情可能会变得混乱。
    • 我个人的经验法则是:1) 使用任何系统时区 2) 始终使用正确的日期类型,并始终使用正确的工具处理日期。这总是对我有用 ;-) PS:rwec.co.uk --- 呃-哦 ;-)
    • @zerkms 很公平 :) 对所有事情都使用 UTC 是“最小公分母”方法——与其确保所有工具同步处理时区,不如假装世界都有一个时区。
    • @zerkms 部分取决于您使用的时间戳 - 对于用户向论坛提交的内容,尊重服务器的时区设置是无关紧要的。在我工作的旅游业中,飞行时间表示为“当地时间”,但我还没有看到一个 API 可以指示实际时区,因此使我们的代码完全感知时区是不可能的。 :| PS:感谢提醒 rwec.co.uk - 我怀疑是某种 Wordpress 漏洞 :(
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2010-09-23
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-04-27
    • 2013-05-04
    相关资源
    最近更新 更多