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 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.