TimeZone.getTimeZone ("PST") против TimeZone.getTimeZone ("Америка / Los_Angeles") - PullRequest
Новая
       52

TimeZone.getTimeZone ("PST") против TimeZone.getTimeZone ("Америка / Los_Angeles")

4 голосов
/ 11 апреля 2019

Я использую Java 8,

Ранее в нашем коде мы использовали sdf.setTimeZone(TimeZone.getTimeZone("PDT")); для преобразования в Тихоокеанский регион США, который не был выполнен (не выдает никаких ошибок, но преобразован в часовой пояс по умолчанию), поскольку PDTневерный идентификатор зоны.

Итак, я ищу setTimeZone(TimeZone.getTimeZone("PST"));, который также недоступен в значениях TimeZone.getAvailableIDs().

Наконец я в конечном итоге использую sdf.setTimeZone(TimeZone.getTimeZone("America/Los_Angeles"));

Теперь один изнаши друзья используют setTimeZone(TimeZone.getTimeZone("PST")); для преобразования в часовой пояс США, и преобразование происходит должным образом.

Вопрос в том,

В чем разница между TimeZone.getTimeZone("PST"); и TimeZone.getTimeZone("America/Los_Angeles"); * 1020?*

Какой из них лучше использовать?

Ответы [ 4 ]

6 голосов
/ 11 апреля 2019

Цитирование документации для Ошибка проверки ThreeLetterTimeZoneID от Prone :

Согласно Javadoc java.util.TimeZone:

Для совместимости с JDK 1.1.x также поддерживаются некоторые другие трехбуквенные идентификаторы часовых поясов (такие как «PST», «CTT», «AST»).Однако их использование не рекомендуется, потому что одна и та же аббревиатура часто используется для нескольких часовых поясов (например, «CST» может быть «Центральное стандартное время США» и «Стандартное китайское время»), и тогда платформа Java может распознавать только одно изих.

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

DateTime.getTimeZone("PST") соблюдает летнее время;однако идентификатор подразумевает, что это стандартное тихоокеанское время, то есть летнее время не наблюдается.DateTime.getTimeZone("EST") (и "MST" и "HST") не соблюдают переход на летнее время.Однако это не согласуется с PST (и другими), поэтому вы можете полагать, что будет соблюдаться переход на летнее время.

Итак: используйте полный формат America/Los_Angeles, чтобы минимизировать неоднозначность в коде.

3 голосов
/ 11 апреля 2019

Согласно документации по часовому поясу Java 8 , PST не рекомендуется использовать, поскольку одно и то же сокращение часто используется для нескольких часовых поясов. Поэтому предпочтительнее использовать America/Los_Angeles

2 голосов
/ 11 апреля 2019

Лучше использовать «America / Los_Angeles», так как это действительный часовой пояс согласно базе данных TZ.См. LINK .

Для совместимости с JDK 1.1.x, некоторыми другими трехбуквенными идентификаторами часовых поясов (такими как «PST», «CTT», «AST»)также поддерживаются.Однако их использование не рекомендуется, потому что одна и та же аббревиатура часто используется для нескольких часовых поясов (например, «CST» может быть «Центральное стандартное время США» и «Стандартное китайское время»), и тогда платформа Java может распознавать только одно изони ..

См. ССЫЛКА

Вы также можете увидеть сообщение ЭТО ТА, которое показывает проблему с использованием трехбуквенного идентификатора часового пояса.

1 голос
/ 12 апреля 2019

TL; DR Не использовать PST.Используйте Америку / Los_Angeles.Также не используйте класс TimeZone.Используйте ZoneId.

  • PST может означать стандартное время на Питкэрне, тихоокеанское стандартное время или филиппинское стандартное время.
  • Если принять PST для обозначения тихоокеанского стандартного времени, то это не времязона, поскольку все места, которые используют его в качестве стандартного времени, в настоящее время и большую часть года используют тихоокеанское летнее время.
  • В то время как устаревший класс TimeZone интерпретирует PST так же, как America / Los_Angeles, какдругие уже давно сказали, что трехбуквенные сокращения не рекомендуются.Если TimeZone однажды (хотя и маловероятно) перестанет распознавать PST, он вместо этого даст вам GMT, что, конечно, не то, что вы хотите.

java.time

The *Класс 1019 * был плохо спроектирован и иногда сбивал с толку и, к счастью, давно устарел; его заменили на ZoneId из java.time, современного Java-API даты и времени, 5 лет назад.

Краткий пример кода, помогающийвы начинаете использовать современный API: 

    DateTimeFormatter formatter = DateTimeFormatter.ofLocalizedDateTime(FormatStyle.FULL)
            .withLocale(Locale.US);
    ZonedDateTime dateTime = ZonedDateTime.now(ZoneId.of("America/Los_Angeles"));
    System.out.println(dateTime.format(formatter));

Пятница, 12 апреля 2019 г., 8:14:09 по тихоокеанскому летнему времени

Одно преимущество ZoneId не позволяет легко использовать PST в качестве часового пояса: ZoneId.of("PST") выдает java.time.zone.ZoneRulesException: Unknown time-zone ID: PST (если вы настаиваете, есть обходной путь, но, как мы уже говорили, не следует).

Ссылки

...