【问题标题】:Incorrect data with Coldfusion, SQL and Ingres since commencement of daylight saving time自夏令时开始以来,Coldfusion、SQL 和 Ingres 的数据不正确
【发布时间】:2012-10-08 11:57:18
【问题描述】:

自从大约两周前在这里开始夏令时以来,我们注意到在我们的新 ColdFusion 网站上以下列方式限制日期的任何查询都返回了不正确的数据(其中 StartDate 的格式为 dd-mmm-yyyy)。

select ...
from ...
where ...
  and o.booking_date >= date('#StartDate#')
  and o.booking_date < date('#StartDate#') + date('1 day') 

我们发现如果 StartDate 改变如下,则返回正确的数据:

and booking_date >= '#DateFormat(DateAdd("d",-1,StartDate), "dd-mmm-yyyy")# 13:00'
and booking_date < '#DateFormat(StartDate, "dd-mmm-yyyy")# 13:00'

我们的 CF 服务器上的时间是正确的,并且设置为 UTC+10:00,并启用了夏令时的自动调整。 Ingres II Visual Manager (II_TIMEZONE_NAME) 中的时间设置设置为 AUSTRALIA-VICTORIA。

我们使用 ColdFusion 10 通过 JDBC 连接到 Ingres 数据库。我们使用 ODBC 连接到 Ingres 数据库的旧 ColdFusion 4.5 服务器不会遇到此问题,因此我认为我们遇到的问题一定与 ColdFusion 10 或我们现在使用的 JDBC 连接有关。

关于为什么会发生这种情况的任何想法?为什么在执行上述第一个示例中所示的操作时需要指定纯 UTC 日期/时间(即没有时间调整)?

谢谢。

【问题讨论】:

    标签: sql jdbc coldfusion dst ingres


    【解决方案1】:

    假设您使用的是最新版本的 Ingres(9.x 及更高版本),您可能必须将时区指定为连接属性/属性。例如可以将连接URL属性TZ设置为AUSTRALIA-VICTORIA,即

    jdbc:ingres://..../mydb;TZ=AUSTRALIA-VICTORIA

    如果 Coldfusion 支持 JDBC 属性,则属性名称为 timezone,则 TZ/II_TIMEZONE_NAME 的值相同。

    虽然 ODBC 和 JDBC 最终都通过相同的接口连接到 Ingres,但 JDBC 不知道服务器环境,因此不会观察到 II_TIMEZONE_NAME。

    【讨论】:

    • 您好,格兰特,感谢您的回复。我曾尝试在 JDBC 连接字符串中使用 TZ 设置,但不幸的是,它似乎没有任何区别。事实上,我似乎能够完全放弃 TZ 设置并仍然获得相同的数据,所以我想知道它是否由于某种原因被忽略了。我将在 Ingres 中使用 II_TIMEZONE_NAME 设置,看看是否有什么不同。
    • 如果将 TZ 设置为 GMT 会怎样?你得到的值比它们应该的值晚 10 小时吗?
    猜你喜欢
    • 2015-03-20
    • 2011-11-14
    • 2014-12-29
    • 1970-01-01
    • 2013-11-13
    • 1970-01-01
    • 2013-09-24
    • 2013-11-17
    • 2020-10-25
    相关资源
    最近更新 更多