B.5.单位历史

SQL 标准指出:“在'datetimeLiterals'的定义中,'datetime 值'受根据公历的日期和时间的自然规则约束”。 PostgreSQL 遵循 SQL 标准,仅在公历中对日期进行计数,即使在使用该 calendar 之前也是如此。该规则被称为多久公历

朱利安历法由尤利乌斯·凯撒(Julius Caesar)于公元前 45 年引入。直到 1582 年,各国开始使用公历,它才在西方世界中广泛使用。在儒略历中,热带年份大约为 365 1/4 天= 365.25 天。这将在 128 年内产生大约 1 天的错误。

累积的 calendar 错误促使教皇格雷戈里十三世按照特伦特议会的指示对 calendar 进行了改革。在阳历中,热带年份大约为 365 97/400 天= 365.2425 天。因此,热带年份大约需要 3300 年才能相对于公历转换一天。

通过使用以下规则,每 400 年具有 97 个 leap 年,可以实现近似 365 97/400.

每年被 4 整除的年是 is 年。
但是,每年被 100 整除的年不是 not 年。
但是,每年被 400 整除的年毕竟是 a 年。

因此,1700、1800、1900、2100 和 2200 不是 leap 年。但是 1600 年,2000 年和 2400 年是 leap 年。相比之下,在较旧的儒略历中,所有被 4 整除的年份都是 are 年。

1582 年 2 月的教皇公牛宣布,从 1582 年 10 月起,应缩短 10 天的时间,以便 10 月 15 日紧随 10 月 4 日之后。在意大利,波兰,葡萄牙和西班牙观察到这种情况。此后不久,其他天主教国家紧随其后,但新教国家不愿改变,希腊东正教国家直到 20 世纪初才改变。 1752 年,英国及其辖区(包括现在的美国)进行了改革。因此 1752 年 9 月 2 日之后是 1752 年 9 月 14 日。这就是具有cal程序的 Unix 系统产生以下内容的原因:

$ cal 9 1752
   September 1752
 S  M Tu  W Th  F  S
       1  2 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30

但是,当然,该 calendar 仅适用于英国和自治领,不适用于其他地方。由于尝试跟踪在不同时间在各个地方使用的实际 calendar 会很困难且令人困惑,因此 PostgreSQL 不会尝试,而是遵循所有日期的公历规则,即使这种方法在历史上并不准确。

世界各地已开发出不同的 calendar,其中许多 calendar 早于公历系统。例如,中国 calendar 的开始可以 traceback 到公元前 14 世纪。传说黄帝在公元前 2637 年发明了该 calendar。中华人民共和国将公历用于公历。中文 calendar 用于确定节日。

  • Julian Date 系统是另一种 calendar,与 Juliancalendar 无关,尽管它的命名方式与该 calendar 类似,但令人困惑。朱利安日期系统是法国学者约瑟夫·贾斯图斯·斯卡利格(1540-1609)发明的,它的名字可能来自斯卡利杰的父亲意大利学者朱利叶斯·凯撒·斯卡利格(1484-1558)。在儒略日期系统中,每一天都有一个序列号,从 JD 0 开始(有时称为 the *儒略日期)。 JD 0 对应于儒略历中的公元前 4713 年 1 月 1 日,或公历前 4714 年 11 月 24 日。天文学家最常使用儒略历日期计数来标记其夜间观测值,因此日期从 UTC 中午到下一个 UTC,而不是从午夜到午夜:JD 0 表示从公元前 4714 年 11 月 24 日中午 UTC 开始。到公元前 4714 年 11 月 25 日 UTC 中午。

尽管 PostgreSQL 支持使用儒略日期表示法来 Importing 和输出日期(并且还使用儒略日期来进行一些内部日期时间计算),但是它没有观察到从正午到正午运行日期的好处。 PostgreSQL 将儒略日期视为从午夜运行至午夜。