1/1/1753在SQL Server中的意义是什么?


Answers:


831

1753-01-01在SQL Server中使用1753年1月1日()作为日期时间的最小日期值的决定可以追溯到Sybase的起源

日期本身的意义虽然可以归因于这个人。

菲利普·斯坦霍普,切斯特菲尔德四世伯爵

切斯特菲尔德第四伯爵菲利普·斯坦霍普(Philip Stanhope)。谁通过英国议会领导了1750年日历(新样式)法》。这是通过英国和当时殖民地公历的法律。

最终从儒略历开始进行调整的1752年,英国日历中有一些遗失的日子(互联网档案链接)。1752年9月3日至1752年9月13日失踪。

Kalen Delaney 用这种方式解释了选择

那么,如果损失了12天,如何计算日期?例如,如何计算1492年10月12日至1776年7月4日之间的天数?您是否包括缺少的12天?为避免解决此问题,原始的Sybase SQL Server开发人员决定不允许日期在1753年之前。您可以使用字符字段存储更早的日期,但不能将任何日期时间函数与字符中存储的更早日期一起使用领域。

1753年的选择确实有些英国中心,但是由于欧洲许多天主教国家在英国实施该日历之前已有170年的历史(最初由于教堂的反对推迟)。相反,许多国家直到1918年俄国才对日历进行改革。的确,1917年十月革命于公历下于11月7日开始。

Joe的答案中提到的这两种数据类型datetime和新datetime2数据类型均未尝试解决这些局部差异,而只是使用公历。

因此,随着范围的扩大 datetime2

SELECT CONVERT(VARCHAR, DATEADD(DAY,-5,CAST('1752-09-13' AS DATETIME2)),100)

退货

Sep  8 1752 12:00AM

datetime2数据类型的最后一点是,它使用了向后投射到实际发明之前的向后投射的多格勒公历,因此在处理历史日期时用途有限。

这与其他软件实现(例如Java Gregorian Calendar类)形成对比,该类默认遵循儒略历,直到1582年10月4日为止,然后在新的Gregorian日历中跳至1582年10月15日。它可以正确处理该日期之前的leap年的朱利安模型和该日期之后的公历模型。呼叫者可以通过致电更改转换日期setGregorianChange()

可以在这里找到一篇颇具娱乐性的文章,其中讨论了采用日历的更多特性。


68
+1代表未冒犯的曾祖父的伟大肖像。此答案还有其他亮点。
Smandoli

83
+1为既是技术性的又是历史性的答案。在沉重的左脑干经常光顾的黑板上,这是一个令人愉快的阅读。是的,我确实去了一所文理学院。
Matt Hamsmith 2011年

1
关于此链接:假设某人于1712年2月30日出生在瑞典-他们永远不会老!:P另外,立陶宛和拉脱维亚在那段时间一直在做什么!
艾萨克·里夫曼

链接“ 缺少的日子 ”已损坏。
Venkat

1
@Venkat-现在已修复,并带有互联网存档链接
Martin Smith

99

您的曾曾曾曾祖父应升级到SQL Server 2008并使用DateTime2数据类型,该数据类型支持范围为0001-01-01至9999-12-31的日期。


40
@CRMay:告诉他您计划在5000-01-02星期四开始进行Y10K合规性工作;这使您不到5千年就可以修复它。
乔纳森·莱夫勒

8
-我猜是有人错过了实际问题的答案:为什么一直都是1753年?
sehe 2011年

7
...而问题是
V4仇杀队2011年

1
是的....但是请尝试在一家拥有庞大的SQL Server数据库基础的公司中通过这种数据类型的更改,并且在可怕的敌人CHANGE的防御线要比美国在俄罗斯最高的ICBM时要多的防御线冷战...
SebTHU

1
我认为这是一个更好的答案,简洁明了,告诉解决方案而不是历史记录,请问您使用历史记录还是数据类型进行查询
Abdul qayyum


19

这是整个故事,日期问题是如何发生的,以及大型DBMS如何处理这些问题。

在公元1日到今天之间,西方世界实际上使用了两个主要日历:朱利叶斯·凯撒的儒略历和教皇格里高利十三世的公历。两个日历的区别仅在于一条规则:确定:年是什么的规则。在儒略历中,所有可以被四整除的年份是leap年。在公历中,所有可被4整除的年份都是years年,但不能被100整除(但不能被400整除)的年份不是leap年。因此,年份1700、1800和1900是儒略历中的leap年,但不是公历,而1600和2000是两个历法中的leap年。

当教皇格里高利十三世在1582年提出日历时,他还指示应该跳过1582年10月4日至1582年10月15日之间的日期,也就是说,他说10月4日之后的第二天应该是10月15日。许多国家但是,延迟了转换。英格兰和她的殖民地直到1752年才从朱利安转向格里高利安,因此对于他们来说,跳过的日期是在1752年9月4日至9月14日之间。其他国家/地区则在其他时间转换,但1582和1752年是该日期的相关日期。我们正在讨论的DBMS。

因此,当日期追溯到很多年时,日期算术会出现两个问题。首先是,应该根据朱利安规则或格里高利规则计算转换之前的leap年吗?第二个问题是,何时以及如何处理跳过的日子?

大型DBMS就是这样处理以下问题的:

  • 假装没有开关。尽管标准文件尚不清楚,但这似乎是SQL标准的要求:它只是说日期“受公历使用日期的自然规则约束”,无论“自然规则”是什么。这是DB2选择的选项。如果假装单个日历的规则即使在没有人听说过日历的情况下也始终适用,则技术术语是“多用”日历有效。因此,例如,我们可以说DB2遵循一个多事的公历。
  • 完全避免该问题。Microsoft和Sybase将其最小日期值设置为1753年1月1日,这已经超过了America转换日历的时间。这是可以辩护的,但有时会抱怨说这两个DBMS缺乏其他DBMS所具有的有用功能以及SQL Standard所要求的。
  • 选择1582。这就是Oracle所做的。Oracle用户会发现日期算术表达式1582年10月15日减去1582年10月4日得出的值是1天(因为10月5-14日不存在),并且日期1300年2月29日有效(因为朱利安飞跃式-年份规则适用)。当SQL Standard似乎不需要Oracle时,为什么会给它带来更多麻烦呢?答案是用户可能需要它。历史学家和天文学家使用这种混合系统代替了多事的格里高利历。(这也是Sun在为Java实现GregorianCalendar类时选择的默认选项-尽管名称为GregorianCalendar,但它是一个混合日历。)

来源12


8

顺便说一句,Windows不再知道如何在过去的3月/ 4月或10月/ 11月的某些日期正确将UTC转换为美国本地时间。从这些日期开始,基于UTC的时间戳现在有点荒谬。对于OS而言,仅拒绝处理美国政府最新的DST规则之前的任何时间戳记将非常棘手,因此它只是处理其中一些错误。SQL Server拒绝处理1753年之前的日期,因为需要大量额外的特殊逻辑来正确处理它们,并且它不想错误地处理它们。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.