为什么是1753年?他们有什么理由反对1752年?我的曾曾曾曾曾曾曾曾祖父会很生气。
使用1753年1月1日(1753-01-01)作为SQL Server中datetime的最小日期值的决定可以追溯到它的Sybase起源。
1753-01-01
然而,这个日期本身的意义可以归结于这个人。
菲利普·斯坦霍普,切斯特菲尔德伯爵第四世。谁引导英国议会通过了1750年《日历(新样式)法案》。这为英国及其当时的殖民地采用公历制定了法律。
在1752年的英国历法中有一些失踪天数(internet archive link),当时终于从儒略历调整出来。1752年9月3日至1752年9月13日失守。
Kalen Delaney 解释这样的选择
所以,失去了12天,你怎么能 计算日期?比如,怎么能 计算两者之间的天数 1492年10月12日,1776年7月4日?做 你把失踪的12天也算进去了吗?来 避免解决这个问题, 最初的Sybase SQL Server 开发者决定不允许日期 在1753年之前。你可以提前存储 日期使用字符字段,但是 你不能使用任何datetime函数 你储存的较早的日期 .字符字段
选择1753年似乎有点以英国为中心,因为在英国实施之前,欧洲已经使用了170年的日历(最初由于反对教堂旁边而推迟)。相反,许多国家直到1918年俄国才改革他们的历法。事实上,1917年十月革命是在公历的11月7日开始的。
datetime和乔的回答中提到的新datetime2数据类型都没有试图考虑这些局部差异,而是简单地使用公历。
datetime
datetime2
因此,datetime2的范围更大
SELECT CONVERT(VARCHAR, DATEADD(DAY,-5,CAST('1752-09-13' AS DATETIME2)),100)
返回
Sep 8 1752 12:00AM
关于datetime2数据类型的最后一点是,它使用了向后投影到它实际发明之前的预期的公历,因此在处理历史日期时用处有限。
这与其他软件实现形成对比,例如Java 公历类,默认遵循儒略日历的日期直到1582年10月4日,然后跳转到1582年10月15日的新公历。它正确地处理了闰年日期之前的朱利安模型和该日期之后的格里高利历模型。调用者可以通过调用setGregorianChange()来更改转换日期。
setGregorianChange()
这是一篇相当有趣的文章,讨论了日历可以在这里找到的一些特性。
1752年,英国从儒略历转向了公历。我相信1752年9月的两周从未发生过,这对该地区的日期有影响。
你的曾曾曾曾曾曾曾曾祖父应该升级到SQL Server 2008并使用DateTime2数据类型,该数据类型支持从0001-01-01到9999-12-31的日期范围。
顺便说一句,Windows不再知道如何正确地将过去几年的3月/ 4月或10月/ 11月的某些日期的UTC转换为美国当地时间。来自这些日期的基于utc的时间戳现在有些荒谬。对于操作系统来说,在美国政府最新的DST规则集之前拒绝处理任何时间戳是非常讨厌的,所以它只是处理了一些错误的时间戳。SQL Server拒绝处理1753年之前的日期,因为正确处理这些日期需要大量额外的特殊逻辑,而SQL Server不想错误地处理这些日期。
这是关于日期问题的整个故事,以及大型dbms如何处理这些问题。
从公元1年到今天,西方世界已经 实际上使用了两种主要的历法:凯撒大帝的儒略历 以及教皇格里高利十三世的公历。两种日历 不同之处只在于一条规则:决定什么是 闰年是。在儒略历中,所有能被4整除的年份都是 闰年。在公历中,所有能被4整除的年份都是 闰年,除了能被100整除的年份(但不能被100整除) 400)不是闰年。因此,1700年、1800年和1900年是闰年 年在儒略历,而不是在公历,而 1600年和2000年在两个历法中都是闰年 当教皇格里高利十三世在1582年推出他的日历时,他也 1582年10月4日至15日 应该跳过——也就是说,他说的10月4日后应该 10月15日。然而,许多国家推迟了改变。英格兰 她的殖民地也没有从儒略历转向格里高利历 直到1752年,所以对他们来说,跳过的日期是在9月4日之间 1752年9月14日。其他国家在其他时候也换了,但是 1582年和1752年是dbms的相关日期 讨论。< / p > 因此,当一个人回溯很多次时,就会出现两个关于日期算术的问题 年。首先是,闰年之前是否应该进行换算 根据儒略教还是格里高利教的规则?第二个问题是, 何时以及如何处理被跳过的日子?< / p > 以下是大型dbms处理这些问题的方法: 假装没有开关。这就是SQL标准的作用 要求,尽管标准文件不清楚:它只是说 的日期自然规则限制了日期 格里高利历”——不管“自然法则”是什么。这是选项 DB2选择的。当有人假装一本日历是 规则一直适用,甚至在没人听说过的时候 日历,专业术语是一种“前瞻性”日历 力。例如,我们可以说DB2遵循一个前景 公历。李< / > 完全避免这个问题。微软和Sybase 将它们的最小日期值设置为1753年1月1日,安全地超过了这个时间 美国改变了历法这是可以防御的,但从时间到 时间的抱怨浮出水面,这两个dbms缺乏一个有用的 其他dbms和SQL标准所具有的功能 需要。李< / > <李> 1582。这就是甲骨文所做的。Oracle用户会 发现日期算术表达式十月十五日1582减去十月 41582产生的值为1天(因为10月5-14日不存在)和 1300年2月29日是有效的(因为儒略历闰年 规则适用)。为什么Oracle要在SQL 标准似乎不需要?答案是用户可能会 需要它。历史学家和天文学家使用这种混合系统 未来的格里高利历。(这也是默认选项 Sun在实现gregoricalendar类时所选择的 java -尽管有这个名字,GregorianCalendar是一个混合日历。)
以下是大型dbms处理这些问题的方法:
源1和2
对于那些真正想要一个巨大的惊喜的人。
如果您是在基于Linux/Unix的系统上,您可以尝试以下命令,其中包含卡尔命令,(如果它本身被使用,它将显示今天的日期)
cal 9 1752 ; cal
在线Linux终端,点击这里