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 :
STDdecalage[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 :
nUn 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).
Jn
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.)
Mm.n.d
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 ».
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.