ZoneId Classe

Définition

[Android.Runtime.Register("java/time/ZoneId", ApiSince=26, DoNotGenerateAcw=true)]
public abstract class ZoneId : Java.Lang.Object, IDisposable, Java.IO.ISerializable

[<Android.Runtime.Register("java/time/ZoneId", ApiSince=26, DoNotGenerateAcw=true)>]
type ZoneId = class
    inherit Object
    interface ISerializable
    interface IJavaObject
    interface IDisposable
    interface IJavaPeerable

Héritage

Object

JavaObject

Object

ZoneId

Dérivé

Java.Time.ZoneOffset

Attributs

RegisterAttribute

Implémente

IJavaObject IJavaPeerable ISerializable IDisposable

Remarques

ID de fuseau horaire, tel que Europe/Paris.

A ZoneId est utilisé pour identifier les règles utilisées pour effectuer la conversion entre un Instant et un LocalDateTime. Il existe deux types distincts d’ID : les décalages fixes ul<li : un décalage entièrement résolu à partir de UTC/Greenwich, qui utilise le même décalage pour toutes les régions géographiques li>date-times <locales , une zone où un ensemble spécifique de règles permettant de trouver le décalage à partir de UTC/Greenwich applique >/ul< Most fixed offsets sont représentés par >. <>ZoneOffset L’appel #normalized() sur n’importe quel ZoneId contrôle garantit qu’un ID de décalage fixe sera représenté sous la forme d’un ZoneOffset.

Les règles réelles, décrivant quand et comment le décalage change, sont définies par ZoneRules. Cette classe est simplement un ID utilisé pour obtenir les règles sous-jacentes. Cette approche est prise parce que les règles sont définies par les gouvernements et changent fréquemment, tandis que l’ID est stable.

La distinction a d’autres effets. La sérialisation ZoneId du fichier envoie uniquement l’ID, tandis que la sérialisation des règles envoie l’ensemble du jeu de données. De même, une comparaison de deux ID examine uniquement l’ID, tandis qu’une comparaison de deux règles examine l’ensemble du jeu de données.

<ID> de fuseau horaire h2</h2> L’ID est unique dans le système. Il existe trois types d’ID.

Le type d’ID le plus simple est celui de ZoneOffset. Il s’agit de « Z » et d’ID commençant par « + » ou « - ».

Le type suivant d’ID est des ID de style offset avec une forme de préfixe, par exemple « GMT+2 » ou « UTC+01:00 ». Les préfixes reconnus sont « UTC », « GMT » et « UT ». Le décalage est le suffixe et sera normalisé lors de la création. Ces ID peuvent être normalisés en ZoneOffset utilisant normalized().

Le troisième type d’ID est des ID basés sur une région. Un ID basé sur une région doit être de deux caractères ou plus, et ne doit pas commencer par « UTC », « GMT », « UT » « + » ou « - ». Les ID basés sur une région sont définis par configuration. La configuration se concentre sur la fourniture de la recherche de l’ID au sous-jacent ZoneRules.

Les règles de fuseau horaire sont définies par les gouvernements et changent fréquemment. Il existe un certain nombre d’organisations, appelées groupes, qui surveillent les modifications de fuseau horaire et les rassemblent. Le groupe par défaut est la base de données de fuseau horaire IANA (TZDB). D’autres organisations incluent IATA (l’organisme de l’industrie aérienne) et Microsoft.

Chaque groupe définit son propre format pour l’ID de région qu’il fournit. Le groupe TZDB définit des ID tels que « Europe/Londres » ou « America/New_York ». Les ID TZDB sont prioritaires sur d’autres groupes.

Il est fortement recommandé que le nom du groupe soit inclus dans tous les ID fournis par des groupes autres que TZDB pour éviter les conflits. Par exemple, les ID de zone horaire des compagnies aériennes IATA sont généralement identiques au code de l’aéroport de trois lettres. Toutefois, l’aéroport d’Utrecht a le code « UTC », ce qui est évidemment un conflit. Le format recommandé pour les ID de région provenant de groupes autres que TZDB est « group~region ». Ainsi, si des données IATA ont été définies, l’aéroport d’Amsterdam serait « IATA~UTC ».

<h2>Serialization</h2> Cette classe peut être sérialisée et stocke l’ID de zone de chaîne dans le formulaire externe. La ZoneOffset sous-classe utilise un format dédié qui stocke uniquement le décalage par rapport à UTC/Greenwich.

Un ZoneId peut être désérialisé dans un runtime Java où l’ID est inconnu. Par exemple, si un Java Runtime côté serveur a été mis à jour avec un nouvel ID de zone, mais que le runtime Java côté client n’a pas été mis à jour. Dans ce cas, l’objet ZoneId existe et peut être interrogé à l’aide getIdde , , equals, hashCode, toStringgetDisplayName et normalized. Toutefois, tout appel à getRules échouer avec ZoneRulesException. Cette approche est conçue pour permettre un ZonedDateTime chargement et une interrogation, mais pas modifiée, sur un runtime Java avec des informations de fuseau horaire incomplètes.

Ajouté dans la version 1.8.

Java documentation pour java.time.ZoneId.

Les parties de cette page sont des modifications basées sur le travail créé et partagé par Android Open Source et utilisées en fonction des termes décrits dans la Creative Commons 2.5 Attribution License.