Летнее время в java

Question

, пожалуйста, посмотрите, можете ли вы рассказать мне, как обращаться с проблемой DST в моем случае.

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

1.when пользователя приложение входа в системе, мы можем получить часовой пояс пользователя в соответствии с IP-адресом входа, но это просто смещение (я не помню этот термин), например «GMT + 08» (BeiJing) или «GMT-06» (Чикаго).

2.после того, как пользователь сохранит бронирование, нам необходимо установить местную локальную дату, так как я не могу получить прямую локальную дату пользователя. Так что я получу дату сервера (в моем случае это время BeiJing), затем рассчитать локальную дату в соответствии с датой сервера и часовым поясом пользователя, например, если часовой пояс пользователя «GMT-08», дата сервера - 2013-08-29 17:45:00. часовой пояс сервера - «GMT + 08», тогда я буду использовать дату сервера 8-8, и результат будет на 2013-08-29 01: 45: 00. но, поскольку я не рассматриваю DST, рассчитанная локальная дата будет быть отличным от фактического date.eg сейчас в Сан-Франциско, фактическая локальная дата будет раньше одного часа, чем результат, который я вычислил таким образом,

Я нашел java TimeZone уже рассмотрел проблему DST, но я необходимо создать «местоположение» (например, US/Alaska, Pacific/Apia) при построении TimeZone. в то время как в моем случае, что я могу получить, это просто смещение. Так вы можете сказать мне, как исправить проблему DST в моем случае?

Answer 1

Joda время может быть в состоянии решить вашу проблему:

http://joda-time.sourceforge.net/apidocs/org/joda/time/DateTimeZone.html

Answer 2

Это общий источник головной боли

1. По моему опыту, местоположение по IP-адресу не всегда надежны, например, когда люди используют корпоративные VPN.
2. Вы правы, региональные часовые пояса («Европа/Париж», «CET») предпочтительнее для правильной обработки DST.

Я решил аналогичную проблему со следующим подходом: Вы связываете точную часовую зону с каждым пользователем в своей серверной базе данных. Когда пользователь заполняет форму бронирования, вы показываете селектор TZ, предварительно заполненный его TZ по умолчанию. Поэтому он может дважды проверить его (IMHO гораздо безопаснее, чем угадывание по IP) и на стороне сервера, Даты могут быть безопасно преобразованы из локального сервера в серверное время и обратно.

Answer 3

Да, вы должны использовать либо Joda-Time, либо новый пакет java.time в Java 8 (вдохновленный Joda-Time).

Смещение - это число часов и минут от UTC (GMT), которое представлено определенным значением даты-времени. Западное побережье - -08: 00 (игнорирование ловкости летнего времени), что составляет 8 часов меньше, чем в UTC.

Остерегайтесь того, что java.time в своем первоначальном выпуске имеет небольшую ошибку, где он не может обрабатывать смещение всего часов (например, +08) без минут (например, +08:00).

time zone является смещением плюса правил о летнем время (DST), история изменений ДСТА, а также информации о других аномалиях.

Использовать надлежащим образом time zone names (в основном на континенте). Избегайте 3 или 4 буквенных кодов, таких как EST, которые не являются ни стандартизированными, ни уникальными.

У java.util.Date нет часового пояса, в то время как Joda-Time DateTime.

Чтобы получить часовой пояс веб-браузера, см. this question. Но часто это плохо работает. Как вы, наверное, видели, многие веб-сайты просят пользователя выбрать часовой пояс.

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

Обычно системные администраторы сохраняют свои серверные компьютеры в UTC (без смещения часового пояса). Если ваша ОС (например, Mac OS X) не предлагает UTC, используйте Reykjavik, так как Исландия использует UTC круглый год без летнего времени. Аналогично, базы данных почти всегда конвертируют значения даты и времени в UTC для хранения.

Joda-Time предлагает класс LocalDate, если вам действительно не нравится часовой пояс или время. Но часто лучше использовать дату-дату (экземпляр DateTime) и форматировать строку даты только по мере необходимости.

Пример кода в Joda-Time 2.3.

DateTimeZone timeZoneChina = DateTimeZone.forID("Asia/Shanghai"); 
DateTime dateTimeChina = new DateTime(2013, 8, 29, 17, 45, 00, timeZoneChina); 
DateTime dateTimeUtc = dateTimeChina.withZone(DateTimeZone.UTC); 
DateTime dateTimeParis = dateTimeChina.withZone(DateTimeZone.forID("Europe/Paris")); 

DateTimeZone timeZoneUsWestCoast = DateTimeZone.forID("America/Los_Angeles"); 
DateTime dateTimeUnitedStatesWestCoast = dateTimeChina.withZone(timeZoneUsWestCoast); 

DateTimeFormatter formatter = ISODateTimeFormat.date(); 
String outputDateOnlyForUnitedStatesWestCoast = formatter.withZone(timeZoneUsWestCoast).print(dateTimeUtc); 

самосвала утешать ...

System.out.println("dateTimeChina: " + dateTimeChina); 
System.out.println("dateTimeUtc: " + dateTimeUtc); 
System.out.println("dateTimeParis: " + dateTimeParis); 
System.out.println("dateTimeUnitedStatesWestCoast: " + dateTimeUnitedStatesWestCoast); 
System.out.println("outputDateOnlyForUnitedStatesWestCoast: " + outputDateOnlyForUnitedStatesWestCoast); 

При запуске ...

dateTimeChina: 2013-08-29T17:45:00.000+08:00 
dateTimeUtc: 2013-08-29T09:45:00.000Z 
dateTimeParis: 2013-08-29T11:45:00.000+02:00 
dateTimeUnitedStatesWestCoast: 2013-08-29T02:45:00.000-07:00 
outputDateOnlyForUnitedStatesWestCoast: 2013-08-29