如何让 PHP 和 PostgreSQL 就如何计算时间间隔达成一致？

如何解决如何让 PHP 和 PostgreSQL 就如何计算时间间隔达成一致？

我有这个 PostgreSQL 查询：

SELECT *,round(extract(epoch from ("last made" + "time span"::interval))) AS "next timestamp" FROM events ORDER BY "next timestamp" ASC NULLS LAST,"last made" DESC,"timestamp" DESC;

它返回一个事件列表，其中“下一个时间戳”指的是下一次发生的时间，基于时间戳列“上次发生”，指的是上次发生的时间，带有“时间跨度”（例如“1 个月”或“14 天”等）添加到其中。

我也有这个 PHP 代码：

function time_is_older_than($timestamp,$time_string)
{
    $d1 = new \DateTime($timestamp);
    $d1->setTimezone(new \DateTimeZone('UTC'));

    $d2 = new \DateTime();
    $d2->setTimezone(new \DateTimeZone('UTC'));
    $d2->modify('-' . $time_string);

    if ($d1 < $d2)
        return true;

    return false;
}

现在，大多数，这不会造成任何问题。但是，我现在发现了两个烦人的情况，即 PHP 代码认为事件已经“过期”（已经发生）但 PostgreSQL 查询的“下一个时间戳”仍在未来。它们相差几天或几个小时，所以它不能简单地是一个时区问题，这是我在真正深入研究这个烦人的问题之前首先假设的。

应该注意的是，PHP 代码花了我很长时间才“完成”，并进行了无数次重写，因为在此之前我一直在所有解决方案中发现错误。现在我也发现了这个问题！

也许这只是 PHP 和 PG 如何计算这种“时间间隔”的根本区别？自然，不用说我对 PG 和 PHP 使用相同的字符串；例如，两者都使用“1 个月”，而不是一个“1 个月”和另一个“30 天”。

我在 PHP 手册中找到了这个注释：

注意：相对月份值是根据它们经过的月份长度计算的。一个例子是“+2 月 2011-11-30”，它会产生“2012-01-30”。这是因为 11 月有 30 天，12 月有 31 天，总共有 61 天。

我在 PG 手册中找不到类似的解释，但这可能与我的问题有关吗？如果是这样，有没有办法让他们都以相同的方式计算，这样当他们不同意时我就不会得到这些烦人的“误报”？

另外，请注意，我经常需要在这个特定实例之外使用 PHP 函数，因此在 PG 查询中返回一个额外的“布尔值”列，说明它是否在未来并不能真正解决我的整体问题，除非在这种特殊情况下。所以请尽量避免这种解决方案。

解决方法

我看到的一个问题是，您似乎在使用 setTimezone() 而不是在 DateTime 构造函数中指定时区，例如：new DateTime('',new DateTimezone('UTC')); 这意味着如果您的服务器的默认时区是UTC 以外的任何内容都可能导致如下问题：

$string = "2021-04-01T12:00:00";
$utc = new DateTimezone('UTC');

$d1 = new DateTime($string);
$d2 = (clone $d1)->setTimezone($utc);
$d3 = new DateTime($string,$utc);

var_dump($d1,$d2,$d3);

输出：

object(DateTime)#2 (3) {
  ["date"]=>
  string(26) "2021-04-01 12:00:00.000000"
  ["timezone_type"]=>
  int(3)
  ["timezone"]=>
  string(16) "Europe/Amsterdam"
}
object(DateTime)#3 (3) {
  ["date"]=>
  string(26) "2021-04-01 10:00:00.000000"
  ["timezone_type"]=>
  int(3)
  ["timezone"]=>
  string(3) "UTC"
}
object(DateTime)#4 (3) {
  ["date"]=>
  string(26) "2021-04-01 12:00:00.000000"
  ["timezone_type"]=>
  int(3)
  ["timezone"]=>
  string(3) "UTC"
}

也就是说，任何给定的日期/时间库如何解释像 now + 1 month 这样的相对格式是相当随意的，并且没有我所知道的正式规范。 [在这种情况下，ISO8601 持续时间是否适用/工作？] 试图让两个这样的库彼此一致将是徒劳的。您最好的选择是选择其中一个并将所有逻辑转移到其中。在这种情况下，我会说它将是 Postgres。