在日期转化过程中,往往会出现一些认人匪夷所思的结果,比如下面这段代码:
declare @date datetime
set @date=2007-10-04
select @date
------
结果
1905-06-17 00:00:00.000
---------------
这和预期结果2007-10-04有很大差距,具体原因是为什么呢.原来,在这里SQL server处理@date的时候是把它作为了数字.因为没有找到单引号,所以就做了减法处理2007-10-4=1993.但1993怎么又变成1905-06-17呢?
大家都知道SQL server是以1900-01-01做为基础日期的.10月4日20时34分 存储的长度为八个字节,日期和日间各用四个字节存储,第一个四字节存储自1900-01-01之前或之后的天数,后四个字节存储以午夜00:00:00.000后的毫秒数.而此处呢?SQL server则把1993看做是在基础日期上加上1993天,即上面的结果.同样小数部分也可以换算.不过是换算成时间.比如在1993后面加上0.158即:1993.158.
1993转换为天,0.158不到一天,则可以换算出毫秒数:24*60*60*1000*0.158,即:13651200.000
select dateadd(ms,13651200,'00:00:00.000')
-------------
结果
1900-01-01 03:47:31.200
-------------
再对这个结果加上1993天
select dateadd(day,2007-10-04,dateadd(ms,24*60*60*1000*0.158,'00:00:00.000'))
------------
结果
1905-06-17 03:47:31.200
--------------
所以,在定义datetime类型的时候一定要注意加上界定符.另外,在dateadd(day,1.1,getdate())这种写法中,小数部分是无效的,也不会做四舍五入处理.当然用dateadd(ms,24*60*60*1000*1993.0158,getdate())也是行不通的.因为毫秒计算的最大数为:24天20小时31分23.647秒.用秒的说也只有68年,超过此值则会出错.
declare @date datetime
set @date=2007-10-04
select @date
------
结果
1905-06-17 00:00:00.000
---------------
这和预期结果2007-10-04有很大差距,具体原因是为什么呢.原来,在这里SQL server处理@date的时候是把它作为了数字.因为没有找到单引号,所以就做了减法处理2007-10-4=1993.但1993怎么又变成1905-06-17呢?
大家都知道SQL server是以1900-01-01做为基础日期的.10月4日20时34分 存储的长度为八个字节,日期和日间各用四个字节存储,第一个四字节存储自1900-01-01之前或之后的天数,后四个字节存储以午夜00:00:00.000后的毫秒数.而此处呢?SQL server则把1993看做是在基础日期上加上1993天,即上面的结果.同样小数部分也可以换算.不过是换算成时间.比如在1993后面加上0.158即:1993.158.
1993转换为天,0.158不到一天,则可以换算出毫秒数:24*60*60*1000*0.158,即:13651200.000
select dateadd(ms,13651200,'00:00:00.000')
-------------
结果
1900-01-01 03:47:31.200
-------------
再对这个结果加上1993天
select dateadd(day,2007-10-04,dateadd(ms,24*60*60*1000*0.158,'00:00:00.000'))
------------
结果
1905-06-17 03:47:31.200
--------------
所以,在定义datetime类型的时候一定要注意加上界定符.另外,在dateadd(day,1.1,getdate())这种写法中,小数部分是无效的,也不会做四舍五入处理.当然用dateadd(ms,24*60*60*1000*1993.0158,getdate())也是行不通的.因为毫秒计算的最大数为:24天20小时31分23.647秒.用秒的说也只有68年,超过此值则会出错.
本文转自 boyi55 51CTO博客，原文链接：http://blog.51cto.com/boyi55/45063，如需转载请自行联系原作者
