Jakie trzyliterowe identyfikatory stref czasowych nie są przestarzałe?

Question

Jest ostrzeżenie deprecation w Javadoc of TimeZone:

Dla zgodności z JDK 1.1.x, niektóre inne identyfikatory strefy czasowej trzyliterowe (takie jak „PST”, „CTT”, „AST”) są również utrzymany. Jednak ich użycie jest przestarzałe ...

Tutaj jest napisane "inne", ale nie widzę, gdzie określa się, które trzyliterowe identyfikatory są niezaakceptowane. Czy są one udokumentowane w dowolnym miejscu?

GMT jest wymieniony w dokumencie jako zabezpieczenie, więc można bezpiecznie założyć, że jest to jeden z nieoficjalnych identyfikatorów; ale:

• Czy UTC jest przestarzałe? Czy zamiast tego masz zamiar użyć Etc/UTC? A może powinieneś używać GMT? (TimeZone.getTimeZone("UTC").hasSameRules(TimeZone.getTimeZone("GMT") to prawda)

• Czy CET (czas środkowoeuropejski) jest przestarzały? Jeśli nie, to jaki identyfikator strefy czasowej ma zostać użyty? Według this demo, istnieje tylko jeden inny identyfikator zapewniający te same reguły, który jest MET (czas środkowoeuropejski).

  Istnieje kolejny identyfikator strefy czasowej, , który ma tę samą wyświetlaną nazwę co CET (czas środkowoeuropejski), ale który nie ma tych samych reguł (chyba różnią się one gdzieś w połowie lat 70.), który ma takie same zasady jak Europe/Paris. Ale ponieważ mają różne zasady, nie są wymienne.

Więc mój wniosek z tego jest to, że minimalny zestaw obsługiwanych identyfikatorów trzyliterowych jest GMT i CET; ale wydaje się dziwne, że nie jest udokumentowane. Jakieś pomysły?

---

Pragnę zauważyć ewentualne duplikat sugerowanego przez @shmosel: Is "GMT" an Abbreviation in Java TimeZone and if So is it OK to use it?. To częściowo pokrywa moje pytanie; ale zadaję bardziej ogólne pytanie "co jest obsługiwane (i skąd to wiemy)", a nie tylko "jest obsługiwane przez X".

Answer 1

pierwsze, aby odpowiedzieć na konkretne pytania:

1. Wszystko skrót oparte identyfikatory Shou Uważam się za przestarzałego. Nie są one wystarczające do zidentyfikowania określonej strefy czasowej z zachowaniem wszystkich szczegółów. Na przykład możesz zobaczyć wszystkie lokalizacje, które korzystają z czasu środkowoeuropejskiego here. Niektóre z nich używają przez cały rok CET, a niektóre z nich używają w zimie CET, ale w lecie są to CEST. Nie wszystkie z nich korzystają z tych samych dni przejściowych DST lub mają te same przesunięcia stref czasowych w swojej historii.Nie ma wystarczającej ilości informacji w CET, aby zdecydować, który zestaw reguł ma zostać użyty.

2. Stosunkowo bezpiecznie jest używać GMT lub UTC, ponieważ są one jednoznaczne. Jednak bardziej odpowiednie byłoby użycie Etc/GMT lub Etc/UTC. Jeśli miałbyś wybrać tylko jeden, IMHO powinno być Etc/UTC.

3. CET należy uznać za przestarzałe, podobnie jak inne skróty, o czym wspomniałem. Warto jednak zauważyć, że niektóre skróty (takie jak CET) pochodzą z bazy danych TZ, a niektóre (np. AST) pochodzą ze starszej wersji Java. To rozróżnienie jest ważne, ponieważ tylko te TZDB są użyteczne w danych, które mogą być transmitowane gdzie indziej i interpretowane przez systemy nie oparte na Javie.

   Na szczególną uwagę, uznają, że skróty US i CST są NIE w TZDB, choć MST i ESTsą.

4. Zamiast CET należy wybrać, która strefa czasowa oparta na lokalizacji jest odpowiednia dla danego scenariusza. Jeśli mówisz o Francji, użyj Europe/Paris. Jeśli mówisz o Polsce, użyj Europe/Warsaw itd.

Następnie zrozumieć, że pod spodem TZ Database posiada kilka rodzajów identyfikatorów, które są dopuszczalne do użycia:

• Lokalizacja opiera się w postaci Area/Locality

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

• Lokalizacja opiera się w postaci Area/Region/Locality

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

• administracyjne, w Etc nazw:

  • Ex: Etc/UTC, Etc/GMT+2, Etc/GMT-5
  • +/- są oparte na standardach POSIX, naprzeciwko zwykle oczekiwaną normą ISO
  • Powszechnie stosowane dla statków na morzu

Posiada również kilka form, które są artefaktem historii, i powinien NIE być montowane:

• Lokalizacja opiera się w postaci Country lub Country/StateOrRegion

  • Ex: US/Pacific, US/Hawaii, Brazil/East, Canada/Newfoundland, Egypt, Cuba

• identyfikatory POSIX w kontynentalnej części USA:

  • Ex: EST5EDT, CST6CDT, MST7MDT, PST8PDT

• Skróty - niektóre z nich i tak

  • Ex: EST, EET, PRC, WET

Dodatkowo Java wcześniej rozszerzyła te identyfikatory o dodatkowe skróty, które są NIE część bazy danych TZ.Udało mi się je znaleźć na liście here, jak linki do odpowiadających im TZ Database nowoczesnych identyfikatorów:

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 

Oczywiście, te odwzorowania może być lub nie być uparty - ale są podobno te używane przez TZUpdater narzędzia Java do przeniesienie obsługi starszych skrótów strefy czasowej Java.

Answer 2

Być może ZoneId może być używany jako odniesienie.

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

wyjście

GMT 
CET 
UTC 
ROK 
MET 
PRC 
WET 
UCT 
EET 

Jeśli zadzwonisz ZoneId.of("CST") rzuca

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