php - strtotime() 被认为是有害的？

Question

似乎很多人都在为 PHP 中的日期/时间问题而苦恼，而且不可避免地，许多被接受的答案往往是“Use strtotime in this way”。

这真的是指导人们处理约会问题的最佳方式吗？我开始觉得 strtotime 是一种巧妙的技巧，在重要的日期/时间计算中不一定要依赖它，而且根据它采用任意字符串的性质，它看起来像是一个错误的、难以预测的行为的潜在来源。它无法区分 MM/DD/YYYY 和 DD/MM/YYYY 有点大问题，不是吗？

StackOverflow 通常非常擅长推广良好实践(我很少看到没有人说“使用 PDO 代替”的 mysql_real_escape_string 对话。)

但是在 PHP 中似乎没有关于日期问题的公认规范，许多人求助于 strtotime。

那么，如果有的话，我们应该怎么做呢？对于提出“如何将 1 周加到 X”或“如何将此日期格式转换为其他日期格式？”等问题的人，我们是否应该执行更好的规范？

处理像 strtotime 这样的日期/时间问题的最好、最可靠的方法是什么，但往往失败了？

Answer 1

首先我会说我是使用 DateTime 对象的大力倡导者，它允许您使用 DateTime::createFromFormat() 功能。 DateTime 对象使代码更具可读性，并且避免了使用 60 * 60 * 24 进行整个 Unix 时间戳修改来提前日期天数的需要。

也就是说，strtotime() 采用的任意字符串并不难预测。 Supported Date and Time Formats列出支持的格式。

根据您无法区分 MM/DD/YYYY 和 DD/MM/YYYY 的示例，它确实根据 Date Formats 进行了区分。 .使用斜杠的日期始终以美国格式读取。因此格式为 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() .