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 :
Fichiers de configuration
date/heure
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, « Fichiers de configuration date/heure ».
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 :
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).
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.)
This form specifies a transition that always happens during the same month and on the same day of the week. m identifies the month, from 1 to 12. n specifies the n'th occurrence of the weekday identified by d. n is a number between 1 and 4, or 5 meaning the last occurrence of that weekday in the month (which could be the fourth or the fifth). d is a number between 0 and 6, with 0 indicating Sunday. For example, M3.2.0 means « the second Sunday in March ».
![[Note]](../images/note.png)
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, PostgreSQL™ tente de déterminer les heures de transitions en consultant le fichier posixrules dans le base de données IANA des fuseaux horaires. Ce fichier a le même format qu'une entrée de fuseau horaire complète, mais seules ses règles de transition pour le changement d'heure sont utilisées, et non pas les décalages UTC. Typiquement, ce fichier a le même contenu que le fichier US/Eastern, pour que les spécifications POSIX de fuseau horaire suivent les règles de changements d'heure des États-Unis. Si nécessaire, vous pouvez ajuster ce comportement en remplaçant le fichier posixrules.
La capacité à consulter un fichier posixrules a été rendu obsolète par IANA, et il est fortement possible que cela soit supprimé dans le futur. Un bug de cette fonctionnalité, qui a peu de chance d'être corrigé avant sa disparition, est qu'il échoue à appliquer les règle DST aux dates après 2038.
Si le fichier posixrules n'est pas présent, 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).
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 par manque d'un fichier posixrules convenable.
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.