Il existe un avertissement de dépréciation dans le Javadoc de {{X0 }}:

Pour la compatibilité avec JDK 1.1.x, certains autres ID de fuseau horaire à trois lettres (tels que "PST", "CTT", "AST") sont également pris en charge. Cependant, leur utilisation est déconseillée ...

Il dit «autre» ici, mais je ne peux pas voir où il définit quels ID à trois lettres ne sont pas obsolètes. Sont-ils documentés quelque part?

GMT est mentionné dans le document comme solution de secours, il est donc prudent de supposer que c'est l'un des ID non obsolètes; mais:

  • UTC est-il obsolète? Êtes-vous censé utiliser Etc/UTC à la place? Ou devriez-vous utiliser GMT? (TimeZone.getTimeZone("UTC").hasSameRules(TimeZone.getTimeZone("GMT") est vrai)
  • CET (heure d'Europe centrale) est-il obsolète? Sinon, quel identifiant de fuseau horaire êtes-vous censé utiliser à la place? Selon cette démo, il n'existe qu'un seul autre identifiant donnant les mêmes règles, à savoir MET ( Heure d'Europe centrale).

    Il existe un autre identifiant de fuseau horaire, ECT, qui porte le même nom d'affichage que CET (heure d'Europe centrale), mais qui n'a pas les mêmes règles (je pense qu'elles diffèrent quelque part au milieu des années 1970) , qui a les mêmes règles que Europe/Paris. Mais, comme ils ont des règles différentes, les deux ne sont pas interchangeables.

Donc, ma conclusion à partir de ceci est que l'ensemble minimal d'ID à trois lettres pris en charge est GMT et CET; mais il semble étrange que ce ne soit pas documenté. Des idées?


Je note l'éventuel doublon suggéré par @shmosel: Est-ce que" GMT "est une abréviation dans Java TimeZone et si oui, est-ce possible de l'utiliser?. Cela couvre en partie ma question; mais je pose la question plus générale "ce qui est pris en charge (et comment le savons-nous)", plutôt que simplement "X est-il pris en charge".

8
Andy Turner 16 janv. 2017 à 12:12

2 réponses

Meilleure réponse

Tout d'abord, pour répondre à vos questions spécifiques:

  1. Tous les identifiants basés sur des abréviations doivent être considérés comme obsolètes. Ils ne sont pas suffisants pour identifier un fuseau horaire particulier avec tous les détails conservés. Par exemple, vous pouvez voir tous les emplacements utilisant l'heure d'Europe centrale ici. Certains d'entre eux utilisent CET toute l'année, et certains d'entre eux utilisent CET en hiver mais CEST en été. Parmi ceux-ci, tous n'utilisent pas les mêmes jours de transition DST ou n'ont pas les mêmes décalages de fuseau horaire tout au long de leur historique. Il n'y a tout simplement pas assez d'informations dans CET pour décider quel ensemble de règles utiliser.

  2. Il est relativement sûr d'utiliser GMT ou UTC, car ils ne sont pas ambigus. Cependant, il serait plus correct d'utiliser Etc/GMT ou Etc/UTC. Si vous deviez en choisir un seul, à mon humble avis, ce devrait être Etc/UTC.

  3. CET doit être considéré comme obsolète, avec d'autres abréviations, comme je l'ai mentionné. Cependant, il convient de noter que certaines abréviations (comme CET) proviennent de la base de données TZ, et certaines (comme AST) proviennent de l'héritage de Java. Cette distinction est importante, car seuls les TZDB sont utiles dans les données qui peuvent être transmises ailleurs et interprétées par des systèmes non basés sur Java.

    Il convient de noter en particulier que les abréviations américaines PST et CST ne sont PAS dans la TZDB, même si MST et EST sont .

  4. Au lieu de CET, vous devez choisir le fuseau horaire basé sur la localité qui correspond à votre scénario. Si vous parlez de la France, utilisez Europe/Paris. Si vous parlez de la Pologne, utilisez Europe/Warsaw, etc.

Ensuite, sachez que la base de données TZ contient plusieurs types d'identifiants acceptables à utiliser:

  • Basé sur l'emplacement, sous la forme de Area/Locality

    • Ex: America/New_York, Europe/London, Pacific/Honolulu
  • Basé sur l'emplacement, sous la forme de Area/Region/Locality

    • Ex: America/Argentina/Buenos_Aires, America/Indiana/Knox
  • Zones administratives, dans l'espace de noms Etc:

    • Ex: Etc/UTC, Etc/GMT+2, Etc/GMT-5
    • +/- sont basés sur les normes POSIX, à l'opposé de la norme ISO généralement attendue
    • Couramment utilisé pour les navires en mer

Il a également plusieurs formes qui sont un artefact de l'histoire, et ne devraient PAS être utilisés:

  • Basé sur l'emplacement, sous la forme de Country ou Country/StateOrRegion

    • Ex: US/Pacific, US/Hawaii, Brazil/East, Canada/Newfoundland, Egypt, Cuba
  • Identifiants POSIX aux États-Unis continentaux:

    • Ex: EST5EDT, CST6CDT, MST7MDT, PST8PDT
  • Abréviations - certaines d'entre elles quand même

    • Ex: EST, EET, PRC, WET

De plus, Java avait précédemment étendu ces identifiants pour inclure des abréviations supplémentaires qui ne font PAS partie de la base de données TZ. J'ai pu les trouver ici, en tant que liens vers leur base de données TZ correspondante identificateurs modernes:

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 

Bien sûr, ces mappages peuvent ou non être avisés - mais ils seraient ceux utilisés par l'outil Java TZUpdater pour transférer la prise en charge de ces anciennes abréviations de fuseau horaire Java.

5
Community 20 juin 2020 à 09:12

Peut-être que ZoneId pourrait être utilisé comme référence.

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

Production

GMT
CET
UTC
ROK
MET
PRC
WET
UCT
EET

Si vous appelez ZoneId.of("CST"), il jette

java.time.zone.ZoneRulesException: Unknown time-zone ID: CST
1
Andy Turner 16 janv. 2017 à 11:47