我正在做一些大的时间戳列表迭代:将它们放入 tables with date-ranges ，并按范围对它们进行分组。
为了做到这一点，我找到了 strtotime()一个非常有用的功能，但我担心它的性能 .
例如，一个循环一周列表的函数(例如，第 49 周到第 5 周)并且必须决定一周的开始和一周结束的时间戳。一个有用的方法是:
foreach ($this->weeks($first, $amount) as $starts_at) {
$ends_at = strtotime('+1 week', $starts_at);
$groups[$week_key] = $this->slice($timestamps, $starts_at, $ends_at);
}
//$this->weeks returns a list of timestamps at which each week starts.
//$this->slice is a simple helper that returns only the timestamps within a range, from a list of timestamps.
而不是
strtotime() ，我可能会找出一周开始和结束之间的秒数，99% 的时间是 24 * 60 * 60 * 7 .但是在这些有 DST 开关的罕见情况下，24 应该是 23 或 25。解决这个问题的代码可能会比 strtotime() 慢很多。 ， 不是？我在年、月(月，非常不一致!)、天和小时的范围内使用相同的模式。只有几个小时，我才会怀疑只是添加
3600到时间戳更快。还有其他问题吗？有没有办法(不依赖于 PHP5.3!)为一致的、DST 和闰年安全日期范围提供更好的路线？
最佳答案
你为什么担心它的性能？您是否有证据表明它会减慢您的系统速度？如果没有，不要因为不必要的原因试图使解决方案过于复杂。请记住 premature optimization is the root of all evil .编写有意义的可读代码，并且只有在您知道这将是一个问题时才进行优化......
但要考虑的另一件事是它也是编译的 C 代码，因此它的功能应该非常有效。您可能能够在 PHP 领域构建代码的子集并使其更快，但这将是一项艰巨的工作(由于 PHP 代码中涉及的所有开销)。
就像我之前说的，使用它直到你证明这是一个问题，然后解决这个问题。不要忘记根据您的需要重新编写它也不是免费的。这需要时间并引入错误。如果增益很小(意味着它不是性能问题)，是否值得？所以不要费心去尝试微优化，除非你知道这是一个问题......
关于php - PHP strtotime() 的性能如何？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3907524/