4

ここで夏時間がほぼ 2 週間前に開始されて以来、次の方法で日付を制限する新しい 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 に設定されています。

JDBC 経由で Ingres データベースに接続する ColdFusion 10 を使用しています。Ingres データベースへの ODBC 接続を使用する古い ColdFusion 4.5 サーバーはこの問題に悩まされていないため、ColdFusion 10 または現在使用している JDBC 接続のいずれかに何らかの形で関連しているに違いないと思います。

なぜこれが起こっているのかについてのアイデアはありますか? 上記の最初の例で示したようなことを行うときに、純粋な UTC 日付/時刻 (つまり、時刻調整なし) を指定する必要があるのはなぜですか?

ありがとう。

4

1 に答える 1

3

最新バージョンの 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 は観察されません。

于 2012-10-18T13:57:33.970 に答える