SqlDateTime.MinValue!= DateTime.MinValue,为什么？

Question

我想知道,为什么SqlDateTime.MinValue与DateTime.MinValue不一样？

Answer 1

我认为SQL和.NET的Date数据类型之间的区别源于SQL Server的日期时间数据类型,它的最小值和最大值以及它的精度比.NET的DateTime数据类型早得多.

随着.NET的出现,团队决定Datetime数据类型应该具有更自然的 最小值,并且01/01/0001似乎是一个相当合理的选择,当然从编程语言而不是数据库角度来看,这个值是更自然.

顺便提一下,在SQL Server 2008中,有许多新的基于日期的数据类型(Date,Time,DateTime2,DateTimeOffset)实际上确实提供了增加的范围和精度,并且紧密映射到.NET中的DateTime数据类型.例如,DateTime2数据类型的日期范围为0001-01-01到9999-12-31.

SQL Server的标准"datetime"数据类型的最小值始终为01/01/1753(实际上仍然有!).我必须承认,我也对这个价值的重要性感到好奇,所以做了一些挖掘......我发现如下:

在公元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 Eight 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是一个混合日历.)

以上引用取自以下链接:

SQL性能调优:SQL中的日期

Answer 2

因为,在SQL Server中,可以存储在datetime字段(1753/1/1)中的最小日期不等于DateTime .NET数据类型(0001/1/1)的MinValue.

Answer 3

1753 was the date of the first adopter of the Gregorian calendar (England). As to why this was chosen over 01/01/0001 - it is no doubt legacy from when SQL Server was Sybase back in the 1990s. They must've made the design decision early on and the Microsoft SQL team haven't seen a reason to change it.

Since the explosion of .NET and the integration of it into Sql Server, there is now the DateTime2 object for compatability. If you're an NHibernate user, you can provide this type in your type mappings to avoid DateTime.Min problems

.NET Dates cater for other calendars besides the Gregorian one:

• Calendar
  • ChineseLunisolarCalendar
  • EastAsianLunisolarCalendar
  • GregorianCalendar
  • HebrewCalendar
  • HijriCalendar
  • JapaneseCalendar
  • JapaneseLunisolarCalendar
  • JulianCalendar
  • KoreanCalendar
  • KoreanLunisolarCalendar
  • PersianCalendar
  • TaiwanCalendar
  • TaiwanLunisolarCalendar
  • ThaiBuddhistCalendar
  • UmAlQuraCalendar

The JulianCalendar infact pre-dates DateTime.MinValue

Answer 4

两个不同的小组决定了"最小"对日期/时间的意义.

Answer 5

SQL对DateTime使用不同的内部表示.