将 PostgreSQL 间隔转换为秒会产生错误的值

Question

我正在使用 Postgresql 中的一些间隔，但我不确定我是否理解间隔的工作原理。

我想要做的是将间隔转换为秒。 所以我有以下价值观：

select extract ('epoch' from '1 year'::INTERVAL);

产生数字 31557600。如果我们将这个数字除以 (60*60*24)，即一天中的秒数，我们得到 365。
所以在 postgresql 间隔中的一年有 365天。

select extract ('epoch' from '1 month'::INTERVAL);

产生数字 2592000。如果我们将此数字除以 (60*60*24)，我们得到 30。
所以 postgresql 间隔中的一个月有 30 天。

所以按照这个逻辑，我试图计算以下间隔中的秒数：

select extract ('epoch' from '2 year 2 month 1 day 10 hour 5 minute'::INTERVAL);

我正在使用以下公式来计算上述查询的结果：

SELECT (years * 365 * 24 * 3600) + (months * 30 * 24 * 3600) + (days * 24 * 3600) + (hours * 3600) + (minutes * 60);

当我们用值替换变量时，表达式如下：

SELECT (2 * 365 * 24 * 3600) + (2 * 30 * 24 * 3600) + (1 * 24 * 3600) + (10 * 3600) + (5 * 60);

我遇到的问题是第一个查询的结果 (SELECT extract...) 产生结果 68421900 而来自上面公式的查询产生结果 68378700.
据我了解，结果应该是相同的，但结果之间存在 12 小时（43200 秒）的差异。为什么会这样？

重要的是要注意，如果我从间隔中删除年份，我会从两个查询中得到相同的结果，所以我想这与年份有关。

Answer 1

你的问题是整数算术。错误就在这里：

select extract ('epoch' from '1 year'::INTERVAL);

产生数字 31557600。如果我们将此数字除以 (60*60*24)，即一天中的秒数，我们得到 365。

你可能做的是

SELECT 31557600 / (60 * 60 * 24);

 ?column? 
----------
      365
(1 row)

但现实是：

SELECT extract (epoch FROM INTERVAL '1 year') / (60 * 60 * 24);

 ?column? 
----------
   365.25
(1 row)

所以 PostgreSQL 中一年的长度实际上是 365 天 6 小时。这是一个近似值（真实值略小），应该考虑闰年。

---

注意：这些值有点随意，因为对于“一个（日历）月有多长”或“一个（日历）年有多长”没有单一的正确答案 - 答案取决于单个月份或年份.

如果将interval 添加到timestamp with time zone，结果将始终正确，因为在这种情况下，确切的长度是明确的。

---

关于为什么假设一年有 365.25 天，而一个月有 30 天的问题，以下是消息来源在src/include/datatype/timestamp.h 中所说的：

/*
 * Assorted constants for datetime-related calculations
 */

#define DAYS_PER_YEAR   365.25  /* assumes leap year every four years */
#define MONTHS_PER_YEAR 12
/*
 *      DAYS_PER_MONTH is very imprecise.  The more accurate value is
 *      365.2425/12 = 30.436875, or '30 days 10:29:06'.  Right now we only
 *      return an integral number of days, but someday perhaps we should
 *      also return a 'time' value to be used as well.  ISO 8601 suggests
 *      30 days.
 */
#define DAYS_PER_MONTH  30              /* assumes exactly 30 days per month */
#define HOURS_PER_DAY   24              /* assume no daylight savings time changes */

/*
 *      This doesn't adjust for uneven daylight savings time intervals or leap
 *      seconds, and it crudely estimates leap years.  A more accurate value
 *      for days per years is 365.2422.
 */
#define SECS_PER_YEAR   (36525 * 864)   /* avoid floating-point computation */
#define SECS_PER_DAY    86400
#define SECS_PER_HOUR   3600
#define SECS_PER_MINUTE 60
#define MINS_PER_HOUR   60

所以我猜原因是 ISO 8601 规定一个月有 30 天。

Answer 2

我遇到了类似的问题，最终找到了可行的方法。

SELECT AVG( EXTRACT(EPOCH FROM (end_ts - start_ts)) )

产生了不正确的值。

SELECT AVG( EXTRACT(EPOCH FROM INTERVAL (end_ts - start_ts)) )

产生了语法错误。

从开始和结束时间戳中分别提取纪元，然后对它们进行数学运算。

SELECT AVG( ( EXTRACT(EPOCH FROM end_ts) - EXTRACT(EPOCH FROM start_ts) ) )

我添加了一些额外的数学来转换为小时数。

SELECT AVG( ( EXTRACT(EPOCH FROM end_ts) - EXTRACT(EPOCH FROM start_ts) )::FLOAT/86400 )

Answer 3

首先，你So a month in postgresql interval has 30 days.的说法是错误的：

janbet=> select '2019-01-01'::date + '1 month'::interval;
      ?column?
---------------------
 2019-02-01 00:00:00
(1 row)

janbet=> select '2019-02-01'::date + '1 month'::interval;
      ?column?
---------------------
 2019-03-01 00:00:00
(1 row)

如您在上面看到的，月份可能是 31 天或 28 天，具体取决于上下文。事实上，它是一个月，而月的长度不同。

同样适用于'2 year 2 month 1 day 10 hour 5 minute'::interval:

janbet=> select '2019-01-01'::date + '2 year 2 month 1 day 10 hour 5 minute'::interval - '2019-01-01'::date;
     ?column?
-------------------
 791 days 10:05:00
(1 row)

janbet=> select '2021-01-01'::date + '2 year 2 month 1 day 10 hour 5 minute'::interval - '2021-01-01'::date;
     ?column?
-------------------
 790 days 10:05:00
(1 row)

根据2 years 是否包含闰年，我们会得到不同的结果。

我对你的 12 小时的最佳猜测是 2 年在 50% 的情况下包括闰年，所以这是 one day * 1/2。事实上，如果你用“3 年”重复计算，你会得到 18 小时的差异，所以我敢肯定它是这样工作的。

我知道这可能令人惊讶，但我想不出与可变年/月长度一致的其他结果，这是所需的interval 行为。