我被要求创建一个查询来从Informix数据库中提取近实时报告（我只选择访问权限，我无法创建SP）我感觉自己成功了很多，直到我意识到有日期时间字段中的差异。似乎填充数据库的程序是硬编码的，以UTC中的日期时间字段输入时间（距本地时间五小时。当时间是2:30时，它在数据库中输入一行说John Doe在7:30完成任务）。在我的报告中，我应该计算自用户完成任务以来的秒数（作为int）（字段是“completionTime”）并且我最初只是使用：
sysdate - completionTime interval seconds(9) to seconds cast to char then cast to int
当我在completionTime字段的时区中意识到错误时，我只是将偏移量减去整数（我已经将间隔转换为整数，所以我只是将答案调整了18000）。直到夏令时开始，这个工作正常。然后突然的当地时间是UTC的4小时（14400秒而不是18000）。
由于我只能从数据库中选择，我接下来尝试使用低效的case语句（我的查询从<0.5秒到3-5秒只有25行）。根据另一个论坛的建议，我将时间从unix时代改为整数秒，然后使用dbinfo（'utc_to_datetime'）sp将其转换回正确时区的日期时间。
这种方法有效，但计算对我来说很糟糕：
cast(cast(cast((sysdate - dbinfo("utc_to_datetime", cast(cast(cast((completionTime - TO_DATE('Friday January 1, 2010 0:00', '%A %B %d, %Y %R')) as interval second(9) to second) as char(10)) as int) +1262304000)) as interval second(9) to second) as char(10)) as int)
注意我正在计算从完成时间到1-1-2010然后增加120亿秒的时间长度（一直回到unix时期对于Informix的间隔秒（9）来说太大了，因此这两步）然后我可以将它插入dbinfo（“utc_to_datetime”）sp，将其转换回正确时区的日期时间，然后从sysdate中减去它。最糟糕的部分（除了六个演员表）是我正在处理的完成时间都在sysdate的24小时内，大多数都在10分钟之内，但我增加了120亿秒，这样我就可以使用唯一的功能了。发现在时区之间转换。
我的问题是，这真的是最好的方法吗？顺便说一句，这个工作非常快，我的查询回到合理的执行时间（<0.5秒），我只是看着这个查询并认为必须有更好的方法。
贾里德
答案 0 :(得分：0)
也许您可以使用sysdate代替DBINFO('utc_current')：
SELECT DBINFO('utc_current') - (completionTime interval seconds(9) to seconds) FROM ...