Неверные данные с Coldfusion, SQL и Ingres с момента перехода на летнее время

Поскольку почти две недели назад здесь начали переходить на летнее время, мы заметили, что любые запросы на нашем новом сайте ColdFusion, которые ограничивают даты следующим образом, возвращают неверные данные (где StartDate находится в формате дд-ммм-гггг).

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 с подключением к базе данных Ingres через JDBC. Наш старый сервер ColdFusion 4.5, который использует соединение ODBC с базой данных Ingres, не страдает от этой проблемы, поэтому я предполагаю, что проблема, с которой мы сталкиваемся, должна быть каким-то образом связана либо с ColdFusion 10, либо с соединением JDBC, которое мы сейчас используем.

Любые идеи относительно того, почему это происходит? Почему нужно указывать чистую дату/время UTC (т. е. без корректировки времени), когда вы делаете что-то подобное, как показано в первом примере выше?

Спасибо.


sql jdbc coldfusion dst ingres
person jj2    schedule 18.10.2012    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Предполагая, что вы используете последнюю версию 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 не наблюдается.

person grantc    schedule 18.10.2012
comment
Привет Грант, спасибо за ваш ответ. Я пробовал играть с настройкой TZ в строке подключения JDBC, но, к сожалению, это не имеет никакого значения. На самом деле, кажется, я могу полностью отключить настройку TZ и по-прежнему получать те же данные, поэтому мне интересно, игнорируется ли она по какой-то причине. Я немного поиграю с настройкой II_TIMEZONE_NAME в Ingres и посмотрю, имеет ли это какое-то значение. - person jj2; 22.10.2012
comment
Что, если вы установите TZ на GMT? Вы получаете значения на 10 часов позже, чем они должны быть? - person grantc; 22.10.2012