消失的11天

想着公历的准确，计算的容易，可是正想着公历算法的好呢，发现了一个问题，那就是以前公历不大完善的时候，也有问题。
比如这个，在linux下打入这个命令（windows限制时间范围是1980－2099，所以看不到这个现象）

crane@debian:~$ cal 9 1752
   September 1752
Su Mo Tu We Th Fr Sa
       1  2 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30

cal 9 1752就是查询1752年9月的日历，于是很跌眼镜的发现，2号后面就是14号，少了11天，怎么回事呢？
查了下资料，发现是因为历法调整的问题。
1582年2月，罗马教廷要求从1582 年10月中减去10天，因此1852 年10月4日后面紧跟着就是15日。在意大利、西班牙等国家都这样处理了。其他天主教国家也很快跟着这么做了，但是新教国家不愿意修改，而且希腊等东正教 国家直到20世纪初才修改，所以这个改革在英国及其殖民地（包括美国）在1752年9月才被执行。这样 1752 年9月2日后面跟着的就是1752 年9月14日。 这就是为什么cal会生成上面输出的原因了。
这里有个问题，上面说教廷说的是减去10天，但是刚才发现1752年9月减了11天，这是为什么呢？
这是历法转换的问题，现行公历叫格里历（Gregorian calendar），这是十六世纪的罗马教皇Gregorian XIII (格里十三世)针对当时使用的儒略历 (Julian calendar)进行修订后，于1582年10月开始实行的。所以就出现了上面的1582年10月调整10天的情况。但是由于写cal的是美国 人，cal是从AT&T的Unix中出来的，前面说到过，美国跟从英国的历法是从1752年才开始改的，所以不太一样，所以还牵涉了 1600－1800年的一些问题。
根本原因是因为1800年以前的闰年计算的问题，我们知道闰年是4年一闰，百年不闰，400年再闰，但是1800年以前(所以不包括1800年)没百年不闰，所以就出现了偏差，比如我们可以看一下

crane@debian:~$ cal 2 1700
   February 1700
Su Mo Tu We Th Fr Sa
             1  2  3
 4  5  6  7  8  9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29

crane@debian:~$ cal 2 1600
   February 1600
Su Mo Tu We Th Fr Sa
                1  2
 3  4  5  6  7  8  9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29

可以清楚地看到，1600和1700年2月都是29天，一眼看去，想当然的认为多算了17天，其实实际上多算了13天，因为 400，800，1200，1600是闰年，2月应该有29天。但是为什么调整的时候只少了11天呢，有个很纠结的原因，由于儒略历 (Julian calendar)公元前闰年的不规则，少算了2个闰年，从13天中去掉2天，所以在cal中看到的是少了11天。
话说回来，做万年历的时候这可是陷阱啊。