Documentation PostgreSQL 15.15 » Annexes » Support de date/heure » Spécification POSIX des fuseaux horaires

Précédent | Niveau supérieur | Suivant
B.4. Fichiers de configuration date/heure | Sommaire | B.6. Histoire des unités

## B.5. Spécification POSIX des fuseaux horaires

PostgreSQL accepte les fuseaux horaires écrits suivant les règles du standard POSIX pour la variable d'environnement `TZ`. Les spécifications de fuseau horaire POSIX sont inadéquates pour gérer la complexité des fuseaux horaires du monde, mais il existe parfois des raisons pour les utiliser.

Une spécification POSIX de fuseau horaire a la forme suivante :

    STD decalage [ DST [ decalage_dst ] [ , regle ] ]

(Pour des raisons de lisibilité, nous affichons des espaces entre les champs mais les espaces ne doivent pas être utilisés.) Les champs correspondent à :

- `STD` est l'abréviation de fuseau horaire à utiliser.

- `decalage` est le décalage de l'heure standard par rapport à UTC.

- `DST` est l'abréviation de fuseau horaire à utiliser pour les changements d'heure. Si ce champ et les suivants sont soumis, le fuseau d'horaire utilise un décalage UTC fixé sans règle de changement d'heure.

- `dstoffset` est le décalage du changement d'heure à partir d'UTC. Ce champ est typiquement omis parce qu'il vaut par défaut une heure de moins que `decalage` par rapport à l'heure standard, ce qui est généralement la bonne valeur.

- `rule` définit la règle pour quand le changement d'heure est en effet, comme décrit ci-dessous.

Dans cette syntaxe, une abréviation de fuseau horaire peut être une chaîne de lettres, tel que `EST`, ou une chaîne arbitraire entourée par des crochets, tel que `<UTC-05>`. Notez que les abréviations de fuseau horaire sont seulement utilisées pour l'affichage, et même seulement pour certains formats de sortie. Les abréviations de fuseaux horaires reconnus dans une entrée d'un champ de type timestamp sont expliquées dans Section B.4.

Les champs de décalage spécifient les heures et, en option, les minutes et secondes, de différence par rapport à UTC. Ils ont comme format `hh`[`:``mm`[`:``ss`]] avec un option un signe au début (`+` ou `-`). Le signe positif est utilisé pour les fuseaux horaires à l'ouest de Greenwich. (Notez que c'est l'inverse de la convention prise par l'ISO-8601 utilisée ailleurs dans PostgreSQL.) `hh` peut avoir un ou deux chiffres ; `mm` et `ss` (s'ils sont utilisées) doivent en avoir deux.

La `règle` de transition de changement d'heure doit avoir le format

    dstdate [ / dsttime ] , stddate [ / stdtime ]

(Comme précédemment, les espaces ne doivent pas être inclus en pratique.) Les champs `dstdate` et `dsttime` définissent quand le changement d'heure commence alors que `stddate` et `stdtime` définissent quand l'heure standard commence. (Dans certains cas, notamment dans les régions au sud de l'équateur, le premier peut être plus tard dans l'année que le deuxième.) Les champs date doivent avoir un des formats suivants :

`n`

  Un entier dénote un jour de l'année, en comptant à partir de zéro et jusqu'à 364 ou 365 (ce dernier pour les années bissextiles).

`J` `n`

  Dans ce format, `n` va de 1 à 365, et le 29 février n'est pas compté même dans le cas d'une année bissextile. (Donc, une transition survenant le 29 février ne peut pas être décrite de cette façon. Néanmoins, les jours après février ont le même numéro qu'il s'agisse d'une année bissextile ou pas, donc cette forme est généralement plus utile que la forme entière standard pour les transitions sur des dates fixées.)

`M` `m``.``n``.``d`

  Ce format spécifie une transition qui se produit toujours au cours du même mois et le même jour de la semaine. `m` identifie le mois, de 1 à 12. `n` précise la `n`ième occurrence du jour de la semaine identifié par `d`. `n` est un nombre entre 1 et 4, ou 5 signifiant la dernière occurrence de ce jour de la semaine dans le mois (qui peut être le 4ème ou 5ème). `d` est un nombre entre 0 et 6, avec 0 indiquant dimanche. Par exemple, `M3.2.0` signifie « le deuxième dimanche de mars ».

### Note

Le format `M` est suffisant pour décrire les lois de transition de changement d'heure les plus communes. Mais notez qu'aucune de ces variantes ne peut gérer les changements d'heure, donc en pratique, les données historiques stockées pour les fuseaux horaires nommés (dans la base de données IANA des fuseaux horaires) est nécessaire pour interpréter correctement les anciennes dates et heures.

Les champs heure dans une règle de transition ont le même format que les champs de décalage décrits précédemment, sauf qu'elles ne peuvent pas contenir de signes. Ils définissent l'heure locale actuelle à laquelle le changement survient. En cas d'omission, la valeur par défaut est `02:00:00`.

Si une abréviation de changement d'heure est donné par que le champ `rule` de la transition est omis, le comportement de remplacement est d'utiliser la règle `M3.2.0,M11.1.0`, qui correspond à la pratique des États-Unis de 2020 (c'est-à-dire practice as of 2020 (that is, avancer au deuxième dimanche de Mars, retour au premier dimanche de novembre, les deux transitions se produisant à 2 heures du matin, heure courante). Notez que cette règle ne donne pas les bonnes dates de transition pour les États-Unis pour les années antérieures à 2007.

Comme exemple, `CET-1CEST,M3.5.0,M10.5.0/3` décrit la pratique de changement d'heure actuel (en 2020) à Paris. Cette spécification indique que l'heure standard a l'abréviation `CET` et est une heure avant (est) UTC ; le changement d'heure a pour abréviation `CEST` et est implicitement deux heures avant TC ; le DST commence le dernier dimanche de mars à 2 heures du matin, fuseau CET, et termine le dernier dimanche d'octobre à 3 heures du matin, fuseau CEST.

Les quatre noms de fuseau horaire `EST5EDT`, `CST6CDT`, `MST7MDT` et `PST8PDT` ressemblent beaucoup à des spécifications POSIX de fuseaux. Néanmoins, ils sont en fait traités comme des fuseaux horaires nommés parce que, pour des raisons historiques, il existe des fichiers avec ces noms dans la base de données IANA des fuseaux horaires. L'implication réelle de ceci est que ces noms de fuseaux horaires produiront des transactions valides historiques pour les changements d'heure, même quand une spécification POSIX pure ne le ferait pas.

Il est nécessaire de faire attention au fait qu'il est facile de mal orthographier une spécification POSIX de fuseau horaire car il n'y a pas de vérification sur le côté raisonnable des abréviations. Par exemple, `SET TIMEZONE TO FOOBAR0` fonctionnera, laissant le système utiliser réellement une abréviation spéciale pour UTC.