Какие трехбуквенные идентификаторы часовых поясов не устарели?

Question

Существует предупреждение устаревания в Javadoc of TimeZone:

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

Здесь говорится «другое», но я не вижу, где он определяет, какие трехбуквенные идентификаторы не устарели. Эти документы документированы где угодно?

GMT упоминается в документе как резерв, поэтому можно предположить, что это один из не устаревших идентификаторов; но:

• UTC не рекомендуется? Вы хотите использовать вместо этого Etc/UTC? Или вы должны использовать GMT? (TimeZone.getTimeZone("UTC").hasSameRules(TimeZone.getTimeZone("GMT") is true)

• CET (Центральноевропейское время) устарел? Если нет, то какой идентификатор часового пояса вы должны использовать вместо этого? Согласно this demo, существует только один другой идентификатор, который дает те же правила, что и MET (среднеевропейское время).

  Существует еще один идентификатор часового пояса, ECT, который имеет такое же отображаемое имя, как CET (Центральноевропейское время), но который не имеет одинаковых правил (я думаю, что они отличаются где-то в середине 1970-х годов), который имеет те же правила, что и Europe/Paris. Но, поскольку у них разные правила, они не взаимозаменяемы.

Итак, мой вывод из этого является то, что минимальный набор поддерживаемых идентификаторов три буквы является GMT и CET; но кажется странным, что не документировано. Есть идеи?

---

я отмечаю возможный дубликат, предложенный @shmosel: Is "GMT" an Abbreviation in Java TimeZone and if So is it OK to use it?. Это частично охватывает мой вопрос; но я задаю более общий вопрос: «что поддерживается (и как мы это знаем)», а не просто «поддерживается X».

Answer 1

Во-первых, чтобы ответить на ваши конкретные вопросы:

1. Все аббревиатуры на основе идентификаторов Shou ld считается устаревшим. Они недостаточны для идентификации определенного часового пояса с сохранением всех деталей. Например, вы можете увидеть все местоположения, использующие Центральноевропейское время here. Некоторые из них используют CET круглый год, а некоторые из них используют CET зимой, но летом CEST. Из них не все из них используют одни и те же дни перехода на летнее время или имеют одинаковые смещения часовых поясов на протяжении всей своей истории.В CET информации недостаточно, чтобы решить, какой набор правил использовать.

2. Относительно безопасно использовать GMT или UTC, так как они недвусмысленны. Однако было бы правильнее использовать Etc/GMT или Etc/UTC. Если бы вы выбрали только одну, ИМХО, она должна быть Etc/UTC.

3. CET следует считать устаревшим, наряду с другими сокращениями, как я уже упоминал. Тем не менее, стоит отметить, что некоторые аббревиатуры (например, CET) взяты из базы данных TZ, а некоторые (например, AST) - из наследия Java. Это различие имеет важное значение, поскольку только данные TZDB полезны в данных, которые могут передаваться в другом месте и интерпретируются системами, не основанными на Java.

   Особо следует отметить, признают, что американские сокращения и CST являются НЕ в TZDB, хотя MST и ESTявляются.

4. Вместо CET вы должны выбрать, какой местный часовой пояс относится к вашему сценарию. Если вы говорите о Франции, используйте Europe/Paris. Если вы говорите о Польше, используйте Europe/Warsaw и т. Д.

Далее понять, что лежащий в основе TZ Database имеет несколько типов идентификаторов, которые являются приемлемыми для использования:

• Расположение на основе, в виде Area/Locality

  • Ex: America/New_York, Europe/London, Pacific/Honolulu

• Расположение на основе, в виде Area/Region/Locality

  • Ex: America/Argentina/Buenos_Aires, America/Indiana/Knox

• Административные зоны, в Etc пространстве имен:

  • Ex: Etc/UTC, Etc/GMT+2, Etc/GMT-5
  • +/- основаны на стандартах POSIX, противоположна обычно ожидаемому стандарту ИСО
  • Обычно используется для судов в море

Он также имеет несколько форм, которые являются артефактом истории, и должны НЕ использовать больше:

• Расположение на основе, в виде Country или Country/StateOrRegion

  • Пример: US/Pacific, US/Hawaii, Brazil/East, Canada/Newfoundland, Egypt, Cuba

• POSIX идентификаторы в континентальной части США:

  • Ex: EST5EDT, CST6CDT, MST7MDT, PST8PDT

• Сокращения - некоторые из них так или иначе

  • Ex: EST, EET, PRC, WET

Кроме того, Java ранее расширили эти идентификаторы, чтобы включить дополнительные аббревиатуры, которые НЕ часть базы данных TZ.Я был в состоянии найти их в списке here, как ссылки на их соответствующие базы данных TZ современных идентификаторов:

Link Australia/Darwin ACT 
Link Australia/Sydney AET 
Link America/Argentina/Buenos_Aires AGT 
Link Africa/Cairo ART 
Link America/Anchorage AST 
Link America/Sao_Paulo BET 
Link Asia/Dhaka BST 
Link Africa/Harare CAT 
Link America/St_Johns CNT 
Link America/Chicago CST 
Link Asia/Shanghai CTT 
Link Africa/Addis_Ababa EAT 
Link Europe/Paris ECT 
Link America/New_York EST 
Link Pacific/Honolulu HST 
Link America/Indianapolis IET 
Link Asia/Calcutta IST 
Link Asia/Tokyo JST 
Link Pacific/Apia MIT 
Link America/Denver MST 
Link Asia/Yerevan NET 
Link Pacific/Auckland NST 
Link Asia/Karachi PLT 
Link America/Phoenix PNT 
Link America/Puerto_Rico PRT 
Link America/Los_Angeles PST 
Link Pacific/Guadalcanal SST 
Link Asia/Saigon VST 

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

Answer 2

Возможно, ZoneId может использоваться как ссылка.

ZoneId.getAvailableZoneIds().stream() 
     .filter(z -> z.length() == 3) 
     .forEach(System.out::println); 

выход

GMT 
CET 
UTC 
ROK 
MET 
PRC 
WET 
UCT 
EET 

Если вы звоните ZoneId.of("CST") он бросает

java.time.zone.ZoneRulesException: Unknown time-zone ID: CST