为什么编程语言以及数据库要从1970年1月1日开始计算时
2013-03-28 17:57
399 查看
今天一时兴起想起了在SQL Server中使用DateTime.MinValue插入时间时报错的问题,原因就在于数据库的最小时间和.Net里的最小时间不一致导致的,网上查阅了些资料,找到如下结果
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
所以需要在数据库插入最小时间时不能使用DateTime.MinValue,需要使用
SqlDateTime.MinValue.Value。
好了到现在SQL Server数据库时间问题解决了,突然又想起了系统中有个啥1970年1月1日的时间。那这个时间又是啥来来历呢,怀着好奇宝宝的心理我有在网上查阅了一番得到如下解释:
1.可以简单的这样认为:UNIX系统认为1970年1月1日0点是时间纪元,所以我们常说的UNIX时间戳是以1970年1月1日0点为计时起点时间的。这个解释是懒人最爱^_^
2.这个比较科学
最初计算机操作系统是32位,而时间也是用32位表示。32位能表示的最大值是2147483647。另外1年365天的总秒数是31536000,2147483647/31536000 = 68.1,也就是说32位能表示的最长时间是68年,而实际上到2038年01月19日03时14分07秒,便会到达最大时间,过了这个时间点,所有32位操作系统时间便会变为10000000 00000000 00000000 00000000,也就是1901年12月13日20时45分52秒,这样便会出现时间回归的现象,很多软件便会运行异常了。
到这里,我想问题的答案已经出来了:因为用32位来表示时间的最大间隔是68年,而最早出现的UNIX操作系统考虑到计算机产生的年代和应用的时限综合取了1970年1月1日作为UNIX TIME的纪元时间(开始时间),至于时间回归的现象相信随着64为操作系统的产生逐渐得到解决,因为用64位操作系统可以表示到292,277,026,596年12月4日15时30分08秒,相信我们的N代子孙,哪怕地球毁灭那天都不用愁不够用了,因为这个时间已经是千亿年以后了。
附:另外文章
为什么这个时间会定义在1970年1月1日这个时候呢?
于是开始了Google,中文网页根本找不到答案。于是试着搜索英文关键字,在Sun java论坛总算找到准确的帖子:
http://forums.sun.com/thread.jspa?threadID=595140&start=15
其中有一个回复:
I suspect that Java was born and raised on a UNIX system.
UNIX considers the epoch (when did time begin) to be midnight, January 1, 1970.
是说java起源于UNIX系统,而UNIX认为1970年1月1日0点是时间纪元.
但这依然没很好的解释"为什么",出于好奇,继续Google,总算找到了答案:
http://en.wikipedia.org/wiki/Unix_time
这里的解释是:
最初计算机操作系统是32位,而时间也是用32位表示。
System.out.println(Integer.MAX_VALUE);
2147483647
Integer在JAVA内用32位表示,因此32位能表示的最大值是2147483647。另外1年365天的总秒数是31536000,
2147483647/31536000 = 68.1
也就是说32位能表示的最长时间是68年,而实际上到2038年01月19日03时14分07
秒,便会到达最大时间,过了这个时间点,所有32位操作系统时间便会变为
10000000 00000000 00000000 00000000
也就是1901年12月13日20时45分52秒,这样便会出现时间回归的现象,很多软件便会运行异常了。
到这里,我想问题的答案已经出来了:
因为用32位来表示时间的最大间隔是68年,而最早出现的UNIX操作系统考虑到计算
机产生的年代和应用的时限综合取了1970年1月1日作为UNIX TIME的纪元时间(开始
时间),而java自然也遵循了这一约束。
至于时间回归的现象相信随着64为操作系统的产生逐渐得到解决,因为用64位操作
系统可以表示到292,277,026,596年12月4日15时30分08秒,相信我们的N代子孙,哪
怕地球毁灭那天都不用愁不够用了,因为这个时间已经是千亿年以后了。
最后一个问题:上面System.out.println(new Date(0)),打印出来的时间是8点而非0点,
原因是存在系统时间和本地时间的问题,其实系统时间依然是0点,只不过我的电脑时区
设置为东8区,故打印的结果是8点。
我想以上问题如果作为面试题,也能难倒一批人了.
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
所以需要在数据库插入最小时间时不能使用DateTime.MinValue,需要使用
SqlDateTime.MinValue.Value。
好了到现在SQL Server数据库时间问题解决了,突然又想起了系统中有个啥1970年1月1日的时间。那这个时间又是啥来来历呢,怀着好奇宝宝的心理我有在网上查阅了一番得到如下解释:
1.可以简单的这样认为:UNIX系统认为1970年1月1日0点是时间纪元,所以我们常说的UNIX时间戳是以1970年1月1日0点为计时起点时间的。这个解释是懒人最爱^_^
2.这个比较科学
最初计算机操作系统是32位,而时间也是用32位表示。32位能表示的最大值是2147483647。另外1年365天的总秒数是31536000,2147483647/31536000 = 68.1,也就是说32位能表示的最长时间是68年,而实际上到2038年01月19日03时14分07秒,便会到达最大时间,过了这个时间点,所有32位操作系统时间便会变为10000000 00000000 00000000 00000000,也就是1901年12月13日20时45分52秒,这样便会出现时间回归的现象,很多软件便会运行异常了。
到这里,我想问题的答案已经出来了:因为用32位来表示时间的最大间隔是68年,而最早出现的UNIX操作系统考虑到计算机产生的年代和应用的时限综合取了1970年1月1日作为UNIX TIME的纪元时间(开始时间),至于时间回归的现象相信随着64为操作系统的产生逐渐得到解决,因为用64位操作系统可以表示到292,277,026,596年12月4日15时30分08秒,相信我们的N代子孙,哪怕地球毁灭那天都不用愁不够用了,因为这个时间已经是千亿年以后了。
附:另外文章
为什么这个时间会定义在1970年1月1日这个时候呢?
于是开始了Google,中文网页根本找不到答案。于是试着搜索英文关键字,在Sun java论坛总算找到准确的帖子:
http://forums.sun.com/thread.jspa?threadID=595140&start=15
其中有一个回复:
I suspect that Java was born and raised on a UNIX system.
UNIX considers the epoch (when did time begin) to be midnight, January 1, 1970.
是说java起源于UNIX系统,而UNIX认为1970年1月1日0点是时间纪元.
但这依然没很好的解释"为什么",出于好奇,继续Google,总算找到了答案:
http://en.wikipedia.org/wiki/Unix_time
这里的解释是:
最初计算机操作系统是32位,而时间也是用32位表示。
System.out.println(Integer.MAX_VALUE);
2147483647
Integer在JAVA内用32位表示,因此32位能表示的最大值是2147483647。另外1年365天的总秒数是31536000,
2147483647/31536000 = 68.1
也就是说32位能表示的最长时间是68年,而实际上到2038年01月19日03时14分07
秒,便会到达最大时间,过了这个时间点,所有32位操作系统时间便会变为
10000000 00000000 00000000 00000000
也就是1901年12月13日20时45分52秒,这样便会出现时间回归的现象,很多软件便会运行异常了。
到这里,我想问题的答案已经出来了:
因为用32位来表示时间的最大间隔是68年,而最早出现的UNIX操作系统考虑到计算
机产生的年代和应用的时限综合取了1970年1月1日作为UNIX TIME的纪元时间(开始
时间),而java自然也遵循了这一约束。
至于时间回归的现象相信随着64为操作系统的产生逐渐得到解决,因为用64位操作
系统可以表示到292,277,026,596年12月4日15时30分08秒,相信我们的N代子孙,哪
怕地球毁灭那天都不用愁不够用了,因为这个时间已经是千亿年以后了。
最后一个问题:上面System.out.println(new Date(0)),打印出来的时间是8点而非0点,
原因是存在系统时间和本地时间的问题,其实系统时间依然是0点,只不过我的电脑时区
设置为东8区,故打印的结果是8点。
我想以上问题如果作为面试题,也能难倒一批人了.
相关文章推荐
- 为什么编程语言以及数据库要从1970年1月1日开始计算时
- 为什么编程语言以及数据库要从1970年1月1日开始计算时
- 为什么编程语言以及数据库要从1970年1月1日开始计算时
- 为什么编程语言以及数据库要从1970年1月1日开始计算时间【转】
- 为什么编程语言以及数据库要从1970年1月1日开始计算时
- 为什么编程语言以及数据库要从1970年1月1日开始计算时间
- 为什么编程语言以及数据库要从1970年1月1日开始计算时
- 为什么编程语言以及数据库要从1970年1月1日开始计算时间
- 为什么编程语言以及数据库要从1970年1月1日开始计算时
- 为什么编程语言以及数据库要从1970年1月1日开始计算时
- 为什么编程语言以及数据库要从1970年1月1日开始计算时
- 为什么计算机时间和众多编程语言要从1970年1月1日开始算起
- java为什么计算时间从1970年1月1日开始
- 为什么计算机时间和众多编程语言要从1970年1月1日开始算起
- java为什么计算时间从1970年1月1日开始
- 为什么计算机时间和众多编程语言要从1970年1月1日开始算起
- 为什么开机时间(秒)要从1970年1月1日0时开始计算
- 为什么计算机时间和众多编程语言要从1970年1月1日开始算起
- 为什么计算机时间和众多编程语言要从1970年1月1日开始算起
- 1970年1月1日,这是编程语言和数据库开始记时日