SQL Server中1/1/1753的重要性是什么？

Question

为什么1753？他们对1752有什么看法？我伟大伟大伟大曾伟大的曾祖父会非常生气.

Answer 1

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

日期本身的重要性可以归结为这个人.

菲利普斯坦霍普,切斯特菲尔德的第四伯爵.谁通过英国议会指导1750日历(新式)法案.立法通过了英国及其当时殖民地的公历.

在1752年英国历法中有一些失踪的日子,最后调整是从朱利安历法.1752年9月3日至1752年9月13日失踪.

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

所以,失去了12天,你怎么能计算日期？例如,如何计算1776年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类)形成对比,后者默认遵循Julian日历的日期,直到1582年10月4日,然后在新的公历中跳至1582年10月15日.它正确处理该日期之前的闰年Julian模型和该日期之后的Gregorian模型.调用者可以通过调用来更改切换日期setGregorianChange().

在这里可以找到一篇相当有趣的文章,讨论采用日历的一些更多特点.

Answer 2

你伟大伟大伟大曾祖父应该升级到SQL Server 2008并使用DateTime2数据类型,它支持的范围是:0001-01-01到9999-12-31.

Answer 3

1752年是英国从朱利安转向格里高利历的一年.我相信1752年9月的两个星期从未发生过,这对该地区的日期有影响.

解释:http: //uneasysilence.com/archive/2007/08/12008/(互联网档案版)

Answer 4

这就是日期问题是如何以及大DBMS如何处理这些问题的全部故事.

在公元1世纪到今天,西方世界实际上使用了两个主要日历:朱利叶斯·凯撒的朱利安历法和教皇格里高利十三世的格里高利历.这两个日历只有一个规则不同:决定闰年的规则.在朱利安历法中,所有可被四整除的年份都是闰年.在格里高利历中,所有可被4整除的年份都是闰年,除了可被100整除(但不能被400整除)的年份不是闰年.因此,1700年,1800年和1900年是儒略历中的闰年,而不是公历中的闰年,而1600和2000年是两个日历中的闰年.

当教皇格雷戈里十三世在1582年介绍他的历法时,他还指示应该跳过1582年10月4日和1582年10月15日之间的日子 - 也就是说,他说10月4日之后的日子应该是10月15日.许多国家但是,延迟转换.英格兰和她的殖民地直到1752年才从朱利安改为格列高利计算,因此对于他们来说,跳过的日期是在1752年9月4日到9月14日之间.其他国家在其他时间转换,但1582年和1752年是相关的日期.我们正在讨论的DBMS.

因此,当一个人回溯多年时,日期算术会出现两个问题.首先,应该根据Julian或Gregorian规则计算开关之前的几年？第二个问题是,何时以及如何处理跳过的日子？

这就是Big DBMS处理这些问题的方式:

• 假装没有开关.这就是SQL标准似乎要求的,尽管标准文档不清楚:它只是说日期"受到使用公历的日期的自然规则的限制" - 无论"自然规则"是什么.这是DB2选择的选项.当假定单个日历的规则始终适用于没有人听说过日历的时候,技术术语是"有效"的日历生效.因此,举例来说,我们可以说DB2遵循一个公历的格里高利历.
• 完全避免这个问题.Microsoft和Sybase在1753年1月1日设置了最小日期值,安全地超过了美国切换日历的时间.这是可以辩护的,但有时候投诉表明这两个DBMS缺乏其他DBMS所具有的有用功能以及SQL标准所要求的功能.
• 选择1582.这就是Oracle所做的.Oracle用户会发现1582年10月15日减去1582年10月4日的日期算术表达式产生1天的值(因为10月5日至14日不存在)并且2月29日的日期有效(因为Julian leap-年规则适用).当SQL标准似乎不需要时,为什么Oracle会遇到额外的麻烦？答案是用户可能需要它.历史学家和天文学家使用这种混合系统而不是一个普通的格里高利历.(这也是Sun在为Java实现GregorianCalendar类时选择的默认选项 - 尽管名称,GregorianCalendar是一个混合日历.)

来源1和2

Answer 5

顺便提一下,Windows不再知道如何在过去几年的三月/四月或十月/十一月的某些日期正确地将UTC转换为美国当地时间.这些日期的基于UTC的时间戳现在有点荒谬.操作系统在美国政府最新的DST规则之前简单地拒绝处理任何时间戳是非常棘手的,因此它只是处理其中一些错误.SQL Server拒绝在1753年之前处理日期,因为需要许多额外的特殊逻辑来正确处理它们并且它不想错误地处理它们.