datetime - DB2 timestampdiff 函数返回意外结果

Question

我正在使用以下语法

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

哪里CREATED类型为 TIMESTAMP数据库是DB2。目的是将时间戳从纪元转换为毫秒。如果有更好的功能会更有帮助。

样本数据:
对于 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正如预期的那样，返回时间戳之间差异的估计值，而不是实际值。

来自 reference ，第 435 页(假设为 iSeries):

The following assumptions are used when converting the element values to the requested interval type:

• One year has 365 days.
• One year has 52 weeks.
• One year has 12 months.
• One quarter has 3 months.
• One month has 30 days.
• One week has 7 days.
• One day has 24 hours.
• One hour has 60 minutes.
• One minute has 60 seconds.
• One second has 1000000 microseconds.

实际使用的计算是:

seconds + (minutes + (hours + ((days + (months * 30) + (years * 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 游戏……