今天一時(shí)興起想起了在SQL Server中使用DateTime.MinValue插入時(shí)間時(shí)報(bào)錯(cuò)的問題，原因就在于數(shù)據(jù)庫的最小時(shí)間和.Net里的最小時(shí)間不一致導(dǎo)致的，網(wǎng)上查閱了些資料，找到如下結(jié)果
Net Framewrok 中，
DateTime.MinValue => 0001/01/01 00:00:00
SqlDateTime.MinValue.Value => 1753/01/01 00:00:00
SQL Server 2005 中，
DateTime 最小值 => 1753/01/01 00:00:00
SmallDateTime 最小值 => 1900/01/01 00:00:00
Net Framewrok 中，
DateTime.MaxValue => 9999/12/31 23:59:59.999
SqlDateTime.MaxValue.Value => 9999/12/31 23:59:59.997
SQL Server 2005 中，
DateTime 最大值 => 9999/12/31 23:59:59.997
SmallDateTime 最大值 =>2079.6.6 |
所以需要在數(shù)據(jù)庫插入最小時(shí)間時(shí)不能使用DateTime.MinValue，需要使用
SqlDateTime.MinValue.Value。
好了到現(xiàn)在SQL Server數(shù)據(jù)庫時(shí)間問題解決了，突然又想起了系統(tǒng)中有個(gè)啥1970年1月1日的時(shí)間。那這個(gè)時(shí)間又是啥來來歷呢，懷著好奇寶寶的心理我有在網(wǎng)上查閱了一番得到如下解釋：
1.可以簡單的這樣認(rèn)為：UNIX系統(tǒng)認(rèn)為1970年1月1日0點(diǎn)是時(shí)間紀(jì)元，所以我們常說的UNIX時(shí)間戳是以1970年1月1日0點(diǎn)為計(jì)時(shí)起點(diǎn)時(shí)間的。這個(gè)解釋是懶人最愛^_^
2.這個(gè)比較科學(xué)
最初計(jì)算機(jī)操作系統(tǒng)是32位，而時(shí)間也是用32位表示。32位能表示的最大值是2147483647。另外1年365天的總秒數(shù)是31536000，2147483647/31536000 = 68.1，也就是說32位能表示的最長時(shí)間是68年，而實(shí)際上到2038年01月19日03時(shí)14分07秒，便會到達(dá)最大時(shí)間，過了這個(gè)時(shí)間點(diǎn)，所有32位操作系統(tǒng)時(shí)間便會變?yōu)?0000000 00000000 00000000 00000000，也就是1901年12月13日20時(shí)45分52秒，這樣便會出現(xiàn)時(shí)間回歸的現(xiàn)象，很多軟件便會運(yùn)行異常了。
到這里，我想問題的答案已經(jīng)出來了:因?yàn)橛?2位來表示時(shí)間的最大間隔是68年，而最早出現(xiàn)的UNIX操作系統(tǒng)考慮到計(jì)算機(jī)產(chǎn)生的年代和應(yīng)用的時(shí)限綜合取了1970年1月1日作為UNIX TIME的紀(jì)元時(shí)間(開始時(shí)間)，至于時(shí)間回歸的現(xiàn)象相信隨著64為操作系統(tǒng)的產(chǎn)生逐漸得到解決，因?yàn)橛?4位操作系統(tǒng)可以表示到292,277,026,596年12月4日15時(shí)30分08秒，相信我們的N代子孫，哪怕地球毀滅那天都不用愁不夠用了，因?yàn)檫@個(gè)時(shí)間已經(jīng)是千億年以后了。