Malheureusement, PostgreSQL n'offre pas de type de données de fuseau horaire, vous devriez donc probablement utiliser text .
interval semble être une option logique à première vue, et c'est l'est adapté à certains usages. Cependant, il ne tient pas compte de l'heure d'été, ni du fait que différentes régions dans le même décalage UTC ont des règles d'heure d'été différentes.
Il n'y a pas de mappage 1:1 du décalage UTC vers le fuseau horaire.
Par exemple, le fuseau horaire de Australia/Sydney (Nouvelle-Galles du Sud) est UTC+10 (EST ), ou UTC+11 (EDT ) pendant l'heure d'été. Oui, c'est le même acronyme EST que les États-Unis utilisent ; les acronymes de fuseau horaire ne sont pas uniques dans la base de données tzdata, c'est pourquoi Pg a le timezone_abbreviations paramètre. Pire, Brisbane (Queensland) est à peu près à la même longitude et se trouve en UTC+10 EST ... mais n'a pas d'heure d'été, donc parfois c'est à -1 décalé vers la Nouvelle-Galles du Sud pendant l'heure d'été de NSW.
(Mettre à jour :Plus récemment, l'Australie a adopté un A préfixe, il utilise donc AEST comme l'acronyme TZ de ses états de l'Est, mais EST et WST restent d'usage courant).
Beaucoup de confusion ?
Si tout ce que vous avez besoin de stocker est un décalage UTC puis un interval est approprié. Si vous souhaitez enregistrer un fuseau horaire , stockez-le sous forme de text . C'est pénible à valider et à convertir en un décalage de fuseau horaire pour le moment, mais au moins, il fait face à l'heure d'été.
