516

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

4

6 回答 6

887

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

日期本身的重要性虽然可以归因于这个人。

第四代切斯特菲尔德伯爵菲利普·斯坦霍普

菲利普·斯坦霍普，第四代切斯特菲尔德伯爵。谁在英国议会通过了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 日开始。

乔的回答中提到的两者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 日，然后在新的公历中跳转到 1582 年 10 月 15 日。它正确处理了该日期之前的闰年儒略模型和该日期之后的公历模型。调用者可以通过调用来更改截止日期setGregorianChange()。

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

于 2010-07-22T15:31:26.723 回答
107

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

于 2010-07-22T15:36:28.600 回答
28

1752 年是英国从儒略历改为公历的一年。我相信 1752 年 9 月的两个星期从未因此而发生，这对那个一般地区的日期有影响。

解释： http ://uneasysilence.com/archive/2007/08/12008/ （互联网存档版）

于 2010-07-22T15:34:26.037 回答
20

这就是日期问题以及大型 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。

因此，当一个回溯多年时，日期算术会出现两个问题。第一个是，转换前的闰年应该按照儒略规则还是公历规则计算？第二个问题是，应该何时以及如何处理跳过的天数？

这就是 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 日不存在）并且日期 1300 年 2 月 29 日是有效的（因为儒略闰-年规则适用）。当 SQL 标准似乎没有要求时，为什么 Oracle 还要额外麻烦？答案是用户可能需要它。历史学家和天文学家使用这种混合系统而不是预测的公历。（这也是 Sun 在为 Java 实现 GregorianCalendar 类时选择的默认选项——尽管名称如此，但 GregorianCalendar 是一个混合日历。）

来源1和2

于 2016-08-03T09:30:09.117 回答
8

顺便说一句，Windows 不再知道如何在过去几年的 3 月/4 月或 10 月/11 月的某些日期将 UTC 正确转换为美国当地时间。这些日期的基于 UTC 的时间戳现在有些荒谬。操作系统在美国政府最新的 DST 规则之前拒绝处理任何时间戳是非常讨厌的，因此它只是错误地处理了其中一些。SQL Server 拒绝处理 1753 年之前的日期，因为需要大量额外的特殊逻辑才能正确处理它们，并且它不想错误地处理它们。

于 2010-07-22T15:42:22.410 回答
0

对于那些真正想要以巨大的方式感到惊讶的人。

如果您在基于 Linux/Unix 的系统上，您可以尝试以下涉及cal命令的命令，（如果使用它本身，它会显示今天的日期）

cal 9 1752 ; cal

在此处输入图像描述

对于在线 Linux 终端，请单击此处。

于 2022-01-04T11:07:35.373 回答