PostgreSQL puede aceptar especificaciones de zona horaria escritas
de acuerdo con las reglas del estándar POSIX para la variable de entorno
TZ. Las especificaciones de zona horaria POSIX son insuficientes
para manejar la complejidad del historial de las zonas horarias del mundo real, pero a veces
existen razones para utilizarlas.
Una especificación de zona horaria POSIX tiene la forma:
STDdesfase[DST[desfase_dst] [ ,regla] ]
(Para mayor legibilidad, mostramos espacios entre los campos, pero en la práctica no deben usarse espacios). Los campos son:
STD es la abreviatura de zona que se utilizará para la hora estándar.
desfase es el desfase de la hora estándar de la zona respecto a UTC.
DST es la abreviatura de zona que se utilizará para el horario de verano.
Si este campo y los siguientes se omiten, la zona utiliza un desfase UTC fijo sin regla de horario de verano.
desfase_dst es el desfase del horario de verano respecto a UTC.
Este campo se suele omitir, ya que por defecto es una hora menos que el desfase
de la hora estándar, lo cual suele ser lo correcto.
regla define la regla para cuando el horario de verano está en vigor,
como se describe a continuación.
En esta sintaxis, una abreviatura de zona puede ser una cadena de letras, como EST,
o una cadena arbitraria rodeada por corchetes angulares, como <UTC-05>.
Ten en cuenta que las abreviaturas de zona proporcionadas aquí solo se utilizan para la salida y,
aún así, solo en algunos formatos de salida de marca de tiempo. Las abreviaturas de zona reconocidas
en la entrada de marca de tiempo se determinan como se explica en la Section B.4.
Los campos de desfase especifican la diferencia en horas, y opcionalmente minutos y segundos, respecto
a UTC. Tienen el formato hh[:mm[:ss]]
opcionalmente con un signo al principio (+ o -). El signo positivo
se utiliza para las zonas al oeste de Greenwich. (Ten en cuenta que esto es lo opuesto
a la convención de signos de ISO-8601 utilizada en otros lugares de PostgreSQL).
hh puede tener uno o dos dígitos; mm y
ss (si se usan) deben tener dos.
La regla de transición al horario de verano tiene el formato:
fecha_dst[/hora_dst],fecha_std[/hora_std]
(Como antes, en la práctica no deben incluirse espacios). Los campos fecha_dst
y hora_dst definen cuándo comienza el horario de verano, mientras que
fecha_std y hora_std definen cuándo comienza
la hora estándar. (En algunos casos, especialmente en zonas al sur del ecuador, el primero puede ser
más tarde en el año que el segundo). Los campos de fecha tienen uno de estos formatos:
nUn entero simple denota un día del año, contando desde cero hasta 364, o hasta 365 en años bisiestos.
Jn
En esta forma, n cuenta de 1 a 365, y el 29 de febrero no se cuenta
incluso si está presente. (Por lo tanto, una transición que ocurra el 29 de febrero no podría
especificarse de esta manera. Sin embargo, los días después de febrero tienen los mismos números, ya
sea un año bisiesto o no, por lo que esta forma suele ser más útil que la de entero simple para las
transiciones en fechas fijas).
Mm.n.d
Esta forma especifica una transición que siempre ocurre durante el mismo mes y en el mismo día
de la semana. m identifica al mes, del 1 al 12. n
especifica la n-ésima ocurrencia del día de la semana identificado por
d.
n es un número entre 1 y 4, o 5 que indica la última ocurrencia de ese
día de la semana en el mes (que podría ser la cuarta o la quinta). d es
un número entre 0 y 6, indicando 0 el domingo.
Por ejemplo, M3.2.0 significa “el segundo domingo de marzo”.
El formato M es suficiente para describir many leyes comunes de transición al
horario de verano. Pero ten en cuenta que ninguna de estas variantes puede manejar cambios en las leyes de
horario de verano, por lo que, en la práctica, los datos históricos almacenados para las zonas horarias
con nombre (en la base de datos de zonas horarias de la IANA) son necesarios para interpretar correctamente
las marcas de tiempo pasadas.
Los campos de hora en una regla de transición tienen el mismo formato que los campos de desfase descritos
anteriormente, excepto que no pueden contener signos. Definen la hora local actual en la que ocurre el
cambio a la otra hora. Si se omiten, se establece por defecto en 02:00:00.
Si se proporciona una abreviatura de horario de verano pero se omite el campo de regla
de transición, el comportamiento por defecto es utilizar la regla M3.2.0,M11.1.0, la cual
corresponde a la práctica de los EE. UU. a partir de 2020 (es decir, adelantar la hora el segundo domingo
de marzo, retrasarla el primer domingo de noviembre, ocurriendo ambas transiciones a las 2 AM hora local).
Ten en cuenta que esta regla no proporciona las fechas de transición correctas de los EE. UU. para los años
anteriores a 2007.
Como ejemplo, CET-1CEST,M3.5.0,M10.5.0/3 describe la práctica de mantenimiento de la hora
actual (a partir de 2020) en París. Esta especificación indica que la hora estándar tiene la abreviatura
CET y está una hora adelantada (este) respecto a UTC; el horario de verano tiene la
abreviatura CEST y está implícitamente dos horas adelantado respecto a UTC; el horario de
verano comienza el último domingo de marzo a las 2 AM CET y finaliza el último domingo de octubre a las
3 AM CEST.
Los cuatro nombres de zona horaria EST5EDT, CST6CDT,
MST7MDT y PST8PDT parecen ser especificaciones de zona POSIX.
Sin embargo, en realidad se tratan como zonas horarias con nombre porque (por razones históricas) existen
archivos con esos nombres en la base de datos de zonas horarias de la IANA. La implicación práctica de esto
es que estos nombres de zona producirán transiciones históricas de horario de verano válidas en los EE. UU.,
incluso cuando una especificación POSIX simple no lo haría.
Se debe tener cuidado, ya que es fácil escribir mal una especificación de zona horaria de estilo POSIX,
puesto que no se comprueba la validez de las abreviaturas de las zonas. Por ejemplo,
SET TIMEZONE TO FOOBAR0 funcionará, dejando al sistema utilizando efectivamente una
abreviatura bastante peculiar para UTC.