O PostgreSQL pode aceitar especificações
de zona horária escritas conforme as regras do padrão
POSIX para a variável de ambiente TZ.
As especificações de zona horária POSIX são
inadequadas para lidar com a complexidade do histórico de zona horária
do mundo real, mas às vezes há motivos para usá-las.
Uma especificação de zona horária POSIX tem a forma
STDdeslocamento[DST[dstoffset] [ ,regra] ]
(Para facilitar a leitura são mostrados espaços entre os campos, mas, na prática, os espaços não devem ser incluídos.) Os campos são:
STD é a abreviatura da zona horária a
ser usada para o horário padrão.
deslocamento é o deslocamento do horário
padrão da zona horária em relação ao UTC.
DST é a abreviatura da zona horária a
ser usada para o horário de verão.
Se este campo e os seguintes forem omitidos, a zona horária usará
um deslocamento do UTC fixo sem regra de horário de verão.
dstoffset é o deslocamento do horário
de verão em relação ao UTC.
Este campo é normalmente omitido, uma vez que o padrão é uma hora
a menos que o deslocamento padrão, que
é geralmente a coisa certa.
regra define a regra para quando o
horário de verão está em vigor, conforme descrito abaixo.
Nesta sintaxe, uma abreviatura da zona horária pode ser uma sequência
de letras, como EST, ou uma sequência arbitrária
entre colchetes angulares, como <UTC-05>.
Note que as abreviaturas de zona horária fornecidas aqui são usadas
apenas para saída e, mesmo assim, apenas em alguns formatos de saída
de carimbo de data e hora.
As abreviaturas de zona horária reconhecidas na entrada do carimbo de
data e hora são determinadas conforme explicado em
Arquivos de configuração de data e hora.
Os campos de deslocamento especificam as horas e, opcionalmente,
minutos e segundos, de diferença do UTC. Possuem o formato
hh[:mm[:ss]]
opcionalmente com sinal no início
(+ ou -).
O sinal positivo é usado para as zonas a oeste
de Greenwich. (Note ser o oposto da convenção de sinal da
ISO-8601 usada em outro lugar no PostgreSQL.)
hh pode ter um ou dois dígitos;
mm e ss
(se usados) devem ter dois dígitos.
A regra de transição para o horário de verão tem o formato
dstdate[/dsttime],stddate[/stdtime]
(Como antes, na prática, os espaços não devem ser incluídos.)
Os campos dstdate e
dsttime definem quando o horário de verão
começa, enquanto stddate e
stdtime definem quando o horário padrão
começa.
(Em alguns casos, principalmente nas zonas horárias ao sul do equador,
o primeiro pode ocorrer mais para o final do ano do que o último.)
Os campos de data têm um desses formatos:
nUm inteiro puro denotando o dia do ano, contando de zero a 364, ou até 365 em anos bissextos.
Jn
Nesta forma, n conta de 1 a 365,
e 29 de fevereiro não é contado, mesmo se estiver presente.
(Assim, uma transição ocorrendo em 29 de fevereiro não poderia
ser especificada dessa maneira.
No entanto, os dias após fevereiro têm os mesmos números,
seja um ano bissexto ou não, de modo que esta forma geralmente
é mais útil do que a forma de inteiro puro para transições em
datas fixas.)
Mm.n.d
Esta forma especifica uma transição que sempre acontece durante
o mesmo mês, e no mesmo dia da semana:
m identifica o mês, de 1 a 12;
n especifica a
n-ésima ocorrência do dia da semana
identificado por d;
n é um número entre 1 e 4, ou 5,
significando a última ocorrência daquele dia da semana no mês
(que pode ser o quarto ou o quinto);
d é um número entre 0 e 6, com 0
indicando domingo.
Por exemplo, M3.2.0 significa
“o segundo domingo de março”.
O formato M é suficiente para descrever muitas
leis comuns de transição de horário de verão.
Mas observe que nenhuma dessas variantes pode lidar com alterações
nas leis de horário de verão; portanto, na prática, os dados
históricos armazenados para as zonas horárias com nomes
(no banco de dados de zona horária da IANA) são necessários
interpretar corretamente carimbos de data e hora de tempos atrás.
Os campos de hora em uma regra de transição têm o mesmo formato dos
campos de deslocamento descritos anteriormente, exceto por não
poderem conter sinais.
Eles definem a hora local na qual a mudança ocorre.
Se omitido, o padrão é 02:00:00.
Se a abreviatura de horário de verão for fornecida, mas o campo
regra de transição for omitido, o
comportamento aplicado é usar a regra
M3.2.0,M11.1.0,
que corresponde a praticada nos EUA a partir de 2020
(ou seja, avançar a hora no segundo domingo de março, retroceder no
primeiro domingo de novembro, ambas as transições ocorrendo às 2h,
horário predominante).
Note que esta regra não fornece datas de transição corretas nos
EUA para anos anteriores a 2007.
Como exemplo, CET-1CEST,M3.5.0,M10.5.0/3 descreve
a prática de mudança da hora corrente (a partir de 2020) em Paris.
Esta especificação diz que o horário padrão tem a abreviatura
CET, e está uma hora à frente (leste) de UTC;
o horário de verão tem a abreviatura CEST, e está
implicitamente duas horas à frente do UTC; o horário de verão começa
no último domingo de março às 2h CET, e termina no último domingo de
outubro às 3h CEST.
Os quatro nomes de zona horária EST5EDT,
CST6CDT, MST7MDT e
PST8PDT parecem ser especificações de zona horária
POSIX.
Entretanto, na verdade, são tratados como zonas horárias com nome,
porque (por razões históricas) existem arquivos com estes nomes no
banco de dados de zonas horárias da IANA.
A implicação prática disso é que estes nomes de zona horária
produzem transições de horário de verão históricas válidas nos EUA,
mesmo onde uma especificação POSIX simples não produziria.
Deve-se ter cuidado com o fato de ser fácil escrever incorretamente
uma especificação de zona horária no estilo POSIX, por não haver
verificação da razoabilidade da(s) abreviatura(s) da(s) zona(s).
Por exemplo, SET TIMEZONE TO FOOBAR0 funciona,
deixando o sistema usando realmente uma abreviatura bastante
peculiar para UTC.