Во-первых, я надеюсь, что это правильное место для этого вопроса.Поскольку я считаю, что это проблема конфигурации сервера, я не был уверен, что это должно происходить при сбое сервера.
Итак, у нас есть веб-приложение spring-mvc, работающее на серверах Tomcat и подключенное к базе данных Oracle.На одной из этих страниц пользователь может заполнить форму, где он может ввести набор дат.Когда я или другой разработчик запускаем веб-приложение локально на наших компьютерах для тестирования (все еще подключаясь к внешнему экземпляру Oracle), у нас нет проблем.Но теперь, когда веб-приложение было развернуто на двух разных внешних серверах Tomcat, мы заметили проблемы с датами.
Где-то между тем, когда данные передаются со страницы (проверено с помощью плагина TamperData Firefox) на контроллер икогда он вставлен в базу данных, все эти введенные пользователем даты теряют один день.Например, ввод 09.02.2010 будет вставлен в таблицу как 01.09.2010.Если мы отправляем 09/01/2010, он добавляется как 31.08.2010.Эти пользовательские даты никогда явно не изменяются в нашем коде.
Эти поля даты в наших бинах сущностей Spring помечаются следующим образом:
@Temporal(value = TemporalType.DATE)
@Column(name = "START_DATE", nullable = false, length = 7)
@DateTimeFormat(pattern="MM/dd/yyyy")
Кроме того, в какой-то момент во время обработки данных.мы устанавливаем поле с текущей датой:
obj.setActivityDate(new Date());
Эти даты активности не изменяются и всегда приходят с правильной датой при проверке базы данных.
Как я уже сказал, мы 'Мы не можем воспроизвести эту ошибку, когда мы запускаем приложение локально, поэтому мы (хотим) полагать, что проблема в одном из других серверов Tomcat, на которых мы развернули.Кто-нибудь когда-нибудь сталкивался с такой проблемой, или у вас есть какие-либо идеи о том, что может быть причиной этого?
ОБНОВЛЕНИЕ:
Итак, я воспользовался подсказками часового поясаи это отправило нас в правильном направлении, но мы все еще не там.Я вошел в компонент управления данными, изменил поле с java.util.Date на объект DateTime jodaTime, например:
@Column(name = "START_DATE", nullable = false, length = 7)
@DateTimeFormat(pattern="MM/dd/yyyy")
@Type(type = "org.joda.time.contrib.hibernate.PersistentDateTime")
private DateTime startDate;
После внесения изменений в новый тип, я выполнил еще несколько тестов, и мыТеперь можно увидеть, что дата 09.01.2010 вставляется в базу данных как 31.08.2010 8:00:00 вечера.Я думаю, что TemporalType = DATE, возможно, вызывал усечение где-то вдоль линии, поэтому мы раньше не видели метку времени.Вот настройки часового пояса, о которых я знаю (наш офис находится в Вирджине, США):
- Tomcat запускается с часовым поясом EST5EDT.
- Серверы Linux, которыедля хоста Tomcat установлено значение EST.
- Для сервера linux, на котором размещен экземпляр Oracle, установлено значение EST.
- Для часового пояса базы данных Oracle установлено значение UTC (+00: 00)
- Часовые пояса для пользовательских сессий в Oracle (в настоящее время) установлены на -04: 00.
Если бы это было все, что было, то я мог бы понять, почему дата ввода пользователя (сбез явного часового пояса) будет переведено в базу данных как -04: 00.Но мы все еще не можем воспроизвести проблему локально на наших собственных машинах (Windows 7 и Fedora, обе установлены на США / Восточная).Я пытался манипулировать датами для создания часового пояса, но он всегда приходит как 8:00 вечера.Вот вывод журнала из двух отдельных прогонов:
Storing date startDate: 2010-09-01T00:00:00.000
Storing date startDate: 2010-09-01T00:00:00.000-04:00
Каждая из этих дат отправлялась из Tomcat (с Spring / Hibernate) в базу данных как 31.08.2010 20:00 при запуске на внешнем Tomcatсерверы, но вставлены как 01.09.2010 12:00 при локальном запуске.Единственная хорошая вещь, которую можно извлечь из этого, - это то, что даты повторно переводятся, когда извлекаются из базы данных и отображаются пользователю на экране, чтобы они соответствовали тому, что они первоначально набрали.
ВДля того чтобы иметь возможность последовательно развиваться, нам необходимо знать, какие настройки нам могут отсутствовать на наших локальных машинах, что позволяет избежать этой проблемы.В настоящее время мы используем Tomcat 6.0.20 в комплекте с NetBeans для локального запуска.