2015-02-11 3 views
2

Мое веб-приложение работает на Apache Tomcat 7.0. Мы вызываем календарь java util для получения даты сервера. Проблема в том, что, если системный часовой пояс изменен, календарь java продолжает работать с датой «старого» часового пояса.os изменение часового пояса tomcat необходимо перезагрузить

JDK используется Tomcat является - JDk1.6

Не могли бы вы рассказать нам, почему нужно перезапустить Tomcat, чтобы отразить новый часовой пояс?

+0

Похоже на: [* Изменение 1.7.1 в летнее время не распознается *] (https://stackoverflow.com/q/29383690/642706) –

+0

Похоже на: [* Handle Daylight Saving в Tomcat без перезапуска сервера *] (https://stackoverflow.com/q/49113219/642706) –

ответ

1

Лучший способ - указать часовой пояс, когда вы используете даты на Java. Или укажите в котом с параметром

-Duser.timezone = GMT

. Другой способ Tomcat с загрузкой часового пояса из системы при запуске.

0

Я предполагаю, что причиной необходимости перезагрузки является то, что никто не обслуживает серверы, которые путешествуют по разным часовым поясам, пока они активно работают и подключены к Интернету. Интересная утилита. Очевидно, редко. Очень редкий.

Установите ваш сервер на UTC, запустите tomcat с помощью UTC, затем настройте приложение для форматирования времени в любой часовой пояс, в котором вы заинтересованы в данный момент - проблема решена.

1

tl; dr

Работайте в UTC по возможности.

Instant.now() // Capture current moment in UTC. 

Никогда не зависеть от текущих настроек часового пояса вашего ОС хоста, вашей JVM или вашей базы данных. Укажите желаемый/ожидаемый часовой пояс явно.

ZoneId z = ZoneId.of("Africa/Tunis") ; 
ZonedDateTime zdt = instant.atZone(z) ; // Same moment, same point on the timeline, different wall-clock time. 

Никогда не зависит от часового пояса сервера настройки

Реальная проблема заключается в том, что у вас есть код в зависимости от аспекта, над которыми вы не имеете никакого контроля, и которые могут быть изменены в любой момент: текущее время виртуальная машина по умолчанию зона.

Вы никогда не должны писать код, который зависит от часового пояса системы по умолчанию. Вместо этого всегда указывайте желаемый/ожидаемый часовой пояс явно как необязательный аргумент, переданный соответствующим классам.

Проблема заключается в изменении системного часового пояса, календарь java продолжает работать с датой «старого» часового пояса.

Операционная система хоста (ОС) имеет собственную текущую настройку часового пояса по умолчанию и ее собственное определение часового пояса (tzdata). То же самое для вашего сервера базы данных; если он сложен при обработке данных на дату, например Postgres, он может иметь свой собственный tzdata. И ваша JVM тоже имеет свой текущий текущий часовой пояс и его собственное определение часового пояса (tzdata). Когда определение изменится для интересующих часовых поясов, вы должны обновить tzdata во всех трех местах либо с помощью обновления версии программного продукта, либо с помощью обновления для tzdata.

Все реализации JVM. Я знаю, что по умолчанию при запуске устанавливается собственный текущий часовой пояс по умолчанию для ОС хоста.После запуска JVM изменение настройки часового пояса хоста не должно влиять на ваш JVM, по крайней мере, не в реализациях Oracle и OpenJDK, которые я видел.

Мы используем календарь java util для получения даты сервера.

Никогда не используйте проблемные старый устаревшие классы даты и время, такие как Date & Calendar. Они были полностью вытеснены классами java.time.

Не могли бы вы рассказать нам, почему tomcat необходимо перезапустить, чтобы отразить новый часовой пояс?

Я бы предположил, что ваше веб-приложение ненадлежащим образом кэширует смещение-от-UTC, а не всегда использует часовой пояс. Смещение-от-UTC - это всего лишь несколько часов-минут-секунд смещения с UTC. Часовой пояс - это гораздо больше, история прошлых, настоящих и будущих изменений в смещении, используемом людьми определенного региона. Поэтому всегда используйте часовой пояс, а не просто смещение. См. my Answer к аналогичному Вопросу для более подробной информации.

Указать proper time zone name в формате continent/region, такие как America/Montreal, Africa/Casablanca или Pacific/Auckland. Никогда не используйте аббревиатуру 3-4 буквы, такую ​​как EST или IST, так как они не настоящие часовые пояса, не стандартизированные, и даже не уникальные (!).

ZoneId z = ZoneId.of("America/Montreal") ; 
ZonedDateTime zdt = ZonedDateTime.now(z) ; 

Если вы хотите использовать часовой пояс JVM по умолчанию, запросите его и передайте в качестве аргумента. Если этот параметр опущен, текущее значение JVM применяется неявно. Лучше быть явным, поскольку значение по умолчанию может быть изменено в любой момент во время выполнения любым кодом в любом потоке любого приложения в JVM.

ZoneId z = ZoneId.systemDefault() ; // Get JVM’s current default time zone. 

UTC

Вообще лучше всегда работать в UTC, если зона не требуется бизнес-логики или пользовательского интерфейса. Вы должны научиться думать, работать, регистрировать, хранить и обмениваться данными в UTC. Забудьте о своем собственном ограниченном часовом поясе, работая программистом или администратором.

Класс Instant представляет собой момент на временной шкале в UTC с разрешением nanoseconds (до девяти (9) цифр десятичной дроби).

Instant instant = Instant.now() ; // Capture current moment in UTC. 

О java.time

java.time каркас встроен в Java 8 и более поздних версий. Эти классы вытесняют неприятные старые legacy классы времени, такие как java.util.Date, Calendar, & SimpleDateFormat.

Проект Joda-Time, в настоящее время в maintenance mode, советует перейти на классы java.time.

Чтобы узнать больше, см. Oracle Tutorial. И поиск Stack Overflow для многих примеров и объяснений. Спецификация: JSR 310.

Вы можете обмениваться java.time объекты непосредственно у вашей базы данных. Используйте JDBC driver, соответствующий JDBC 4.2 или более поздней версии. Нет необходимости в строках, нет необходимости в классах java.sql.*.

Где получить классы java.time?

  • Java SE 8, Java SE 9, а затем
    • Встроенный.
    • Часть стандартного Java API с объединенной реализацией.
    • Java 9 добавляет некоторые незначительные функции и исправления.
  • Java SE 6 и Java SE 7
    • Большая часть функциональности java.time будет обратно портирован на Java 6 & 7 в ThreeTen-Backport.
  • Android
    • Более поздние версии Android реализаций пачке классов java.time.
    • Для более ранних Android (< 26) проект ThreeTenABP адаптируется ThreeTen-Backport (упомянутый выше). См. How to use ThreeTenABP….

ThreeTen-Extra Проект расширяет java.time с дополнительными классами. Этот проект является доказательством возможных будущих дополнений к java.time. Здесь вы можете найти полезные классы, такие как Interval, YearWeek, YearQuarter и more.

Смежные вопросы