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
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
niè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 ».
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
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.