# B.4\. 单位历史 该SQL标准指出"在一个'日期时间形式'定义中， '日期时间值'按照阳历 通过日期和时间的自然规则被限制"。 PostgreSQL遵循SQL标准通过阳历计算特定日期，甚至使用日历的几年前。 这条规则被称为_预期的阳历_。 儒略日是由Julius Caesar在公元前45年引入的，直到1582年开始使用公历之前， 西方国家一直使用儒略日。 在儒略日中，一年近似等于365+1/4=365.25天， 大约在128年的出现一个1天的错。 不断积累的历法错误促使教皇格里高利十三世(Gregory XIII)按照与 弥撒议会(Council of Trent)一致的精神改革了历法。在罗马历法里， 一年是近似365 + 97 / 400天= 365.2425天。 因此对应于罗马历法，大约要3300年，才会积累一天的误差。 近似的365+97/400是通过利用下面的规则，规定每400年有97个闰年实现的： | 每个可被4整除的年是一个闰年 | |:--- | | 不过，可被100整除的年不是闰年 | | 但是，可以被400整除的年还是闰年。 | 因此，1700,1800,1900,2100和2200年都不是闰年。而1600,2000,2400年是闰年。 相比而言，旧式的Julian历法里面只有能被4整除的年是闰年。 罗马教皇在1582年2月宣布从1582的10月中删除10天， 也就是10月15号紧跟在10月4号的后面。 信奉天主教的国家(意大利、波兰、葡萄牙、西班牙等) 很快就遵循了这个规定，但新教国家拒绝使用， 而希腊东正教国家却一直拖延到20世纪开始的时候才逐渐遵守这个规定。 大英帝国及其殖民地(包含今天的美国)在1752年开始引用使用， 也就是1752年9月2号之后紧跟着14号， 这就是为什么Unix系统上的`cal`程序会产生如下输出的原因： ``` $ <kbd class="literal">cal 9 1752</kbd> 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 ``` 但是，当然，这个日历对于英国领土是唯一有效的，不是其它地方。 因为尝试跟踪在不同的时间不同地方使用的实际日历是困难和混乱的， PostgreSQL不会尝试，而是遵循所有日期的阳历 规则，即使这种方法是历史上不准确的。 在世界的不同地方，发明了许多不同的历法，有许多比罗马历法系统还早。 例如，中国历法的最早应用可以追溯到公元前14世纪。 传说黄帝在公元前2637就发明了这个历法，也就是日历。 中华人民共和国使用罗马历法用于民用。 中国历法用于决定节日/节气。 _Julian Date_系统是日历的另一种类型， 跟Julian calendar无关，尽管与这个日历类似命名是令人费解的。 "Julian Date"系统是法国学者Joseph Justus Scaliger(1540-1609)发明的， 可能是取自Scaliger的父亲的名字， 意大利学者Julius Caesar Scaliger(1484-1558)。在Julian日期系统， 每天产生一个序列号，从JD0开始（有时被叫做the Julian日期）。 JD0在Julian日历中对应公元前4713年1月1日，在Gregorian日历中对应公元前4714年11月24日。 Julian日期计算经常在天文学家标注夜间观测时被用到， 因此一个日期就是从一个正午UTC到下一个正午UTC。 而不是从午夜到另一个午夜： JD0设计的24小时是从公元前4714年11月24日的正午UTC到公元前4714年11月25日的正午UTC。 尽管PostgreSQL在输入输出日期时支持Julian Date日期符号 （也用在一些内部的日期时间日历上）， 它不观察从正午到正午的精密运行。 PostgreSQL运行Julian Date日期系统从午夜到午夜。