strtotime()被认为有害吗？

Question

似乎很多人都在使用PHP中的日期/时间问题,并且不可避免地,许多公认的答案往往是" 以这种方式使用strtotime ".

这真的是引导人们处理日期问题的最佳方式吗？我开始觉得这strtotime是一种非常好的技巧,不一定依赖于重要的日期/时间计算,并且由于它采用任意字符串的性质,它似乎是一个潜在的马车来源,难以 - 预测行为.它无法区分MM/DD/YYYY和DD/MM/YYYY是一个大问题,不是吗？

StackOverflow通常非常善于推广良好实践(我很少看到mysql_real_escape_string没有人说"使用PDO" 的对话.)

但是,在PHP的日期问题上似乎没有一个公认的规范,很多人都回到了拐杖上strtotime.

那么,如果有的话,我们应该怎么做呢？是否有一个更好的规范,我们应该强制执行问题,如"我如何添加1周到X",或"如何将此日期格式转换为其他日期格式？"

什么是处理日期/时间问题的最佳,最可靠的方法,如strtotime尝试,但往往没有？

Answer 1

我首先要说的是,我是使用DateTime对象的大力倡导者,它允许您使用该DateTime::createFromFormat()函数.DateTime对象使代码更具可读性,并且无需使用60*60*24进行整个Unix时间戳修改以提前日期.

话虽如此,strtotime()所采用的任意字符串并不是很难预测.支持的日期和时间格式列出了支持的格式.

根据您无法区分MM/DD/YYYY和DD/MM/YYYY的示例,它会根据日期格式进行区分.使用斜杠的日期始终读为美国格式.因此格式为00/00/0000的日期将始终读为MM/DD/YYYY.或者使用短划线或句点将是DMY.例如,00-00-0000将始终读为DD-MM-YYYY.

这里有些例子:

<?php
$dates = array(
    // MM DD YYYY
    '11/12/2013' => strtotime('2013-11-12'),
    // Using 0 goes to the previous month
    '0/12/2013' => strtotime('2012-12-12'), 
    // 31st of November (30 days) goes to 1st December
    '11/31/2013' => strtotime('2013-12-01'), 
    // There isn't a 25th month... expect false
    '25/12/2013' => false,

    // DD MM YYYY
    '11-12-2013' => strtotime('2013-12-11'),
    '11.12.2013' => strtotime('2013-12-11'),
    '31.12.2013' => strtotime('2013-12-31'),
    // There isn't a 25th month expect false
    '12.25.2013' => false,
);

foreach($dates as $date => $expected) {
    assert(strtotime($date) == $expected);
}

你可以看到几个关键的例子25/12/2013,12.25.2013如果用相反的格式读取它们都是有效的,但是false根据被支持的日期和时间格式它们返回它们是无效的......

所以你可以看到这种行为是可以预测的.与往常一样,如果您从使用输入中收到日期,则应首先验证该输入.如果您没有先验证输入,则无法使用任何方法.

如果您想要非常具体地了解正在阅读的日期,或者您所提供的格式不是受支持的格式,那么我建议您使用DateTime::createFromFormat().

Answer 2

strtotime()建议因为它自v4.x天以来一直在PHP中,所以基本上保证可用.可用性胜过奇怪的时间(没有双关语意),它会转过来并用错误解析的日期咬你的屁股.

当前"正确"的日期数学方法是使用DateTime/DateInterval对象,但那些是PHP的最新增加(5.2/5.3,我认为),因此并不总是可用 - 那里有很多主机仍在4上.X.