DB2 timestampdiff函数返回意外结果

Question

我正在使用以下语法

TIMESTAMPDIFF(2, CHAR(CREATED - TIMESTAMP('1970-01-01 00:00:00'))

where CREATED是类型TIMESTAMP,数据库是DB2.内涵是将时间戳从epoch转换为millis.如果有更好的功能会更有帮助.

样本数据:
对于2011-10-04 13:54:50返回值,1316613290但实际值应为1317732890(来自http://www.epochconverter.com)

查询运行

SELECT TIMESTAMPDIFF(2, CHAR(TIMESTAMP('2011-10-04 13:54:50') - TIMESTAMP('1970-01-01 00:00:00'))) FROM  SYSIBM.SYSDUMMY1;

Answer 1

这是事实的结果,它TIMESTAMPDIFF返回时间戳之间差异的估计值,而不是预期的实际值.

从参考资料,第435页(假设为iSeries):

将元素值转换为请求的间隔类型时,将使用以下假设:

• 一年有365天.
• 一年有52周.
• 一年有12个月.
• 四分之一有3个月.
• 一个月有30天.
• 一周有7天.
• 一天有24小时.
• 一小时有60分钟.
• 一分钟有60秒.
• 一秒钟有1000000微秒.

实际使用的计算是:

秒+(分钟+(小时+((天+(月*30)+(年*365))*24))*60)*60

出于显而易见的原因,这是不准确的.没用.

这似乎是返回时间戳算术结果的直接结果.
那是;

SELECT                                                              
TIMESTAMP('1971-03-02 00:00:00') - TIMESTAMP('1970-01-01 00:00:00') 
FROM sysibm/sysdummy1        

收益:

10,201,000,000.000000         

Which can be divided into:

• 1 年
• 02 个月
• 01 天
• 00 小时
• 00 分钟
• 00 秒
• 000000 微秒

这是不精确的期间/持续时间信息.虽然有多种情况,其中这种类型的数据是有用的,这是不是其中之一.

简答:确切的答案无法在数据库中正确计算,实际上不应该.

答案很长:

计算是可能的,但相当复杂,并且绝对不适合数据库内计算.我不打算在这里重现它们(如果你感兴趣,请查看JodaTime,特别是各种Chronology子类).你最大的问题是几个月的长度不一样.此外,如果您的时间戳不是UTC,那么您将遇到重大问题 - 更具体地说,夏令时会对计算造成严重破坏.为什么？因为任何国家的抵消都可以随时改变.

也许你可以解释为什么你需要毫秒数？希望你使用Java(或能够这样做),并且可以使用java.time.但如果你在iSeries上,它可能是RPG ......