A entrada de data e hora é aceita em praticamente qualquer formato razoável, incluindo ISO 8601, o formato compatível com o padrão SQL, o formato tradicional do POSTGRES, e outros. Para alguns formatos, a ordem de dia, mês e ano na entrada da data é ambíguo, e há suporte para especificar a ordem esperada destes campos. O parâmetro DateStyle deve ser configurado como MDY para selecionar a interpretação mês-dia-ano, como DMY para selecionar a interpretação dia-mês-ano, ou como YMD para selecionar a interpretação ano-mês-dia.

SELECT name, setting, short_desc
    FROM pg_settings
    WHERE name='DateStyle';

   name    | setting  |                        short_desc
-----------+----------+-----------------------------------------------------------
 DateStyle | ISO, DMY | Define o formato de exibição para valores de data e hora.
(1 linha)

O PostgreSQL é mais flexível no modo de tratar a entrada de data/hora do que o padrão SQL requer. Veja o Apêndice B para obter as regras exatas de análise de entrada de data/hora e os campos de texto reconhecidos, incluindo meses, dias da semana e zonas horárias. ^[43]

Lembre-se de que qualquer entrada literal de data ou hora precisa ser colocada entre apóstrofos, como as cadeias de caracteres de texto. Veja a Seção 4.1.2.7 para obter mais informações. O padrão SQL requer a seguinte sintaxe

tipo_de_dados [ (p) ] 'valor'

onde p é uma especificação de precisão opcional, que fornece o número de dígitos fracionários no campo de segundos. A precisão pode ser especificada para os tipos de dados time, timestamp e interval, podendo estar no intervalo de 0 a 6. Se nenhuma precisão for especificada na especificação da constante, o padrão será a precisão do valor literal (mas não mais de 6 dígitos).

1999-01-08 04:05:06

1999-01-08 04:05:06 -8:00

January 8 04:05:06 1999 PST

TIMESTAMP '2004-10-19 10:23:54'

TIMESTAMP '2004-10-19 10:23:54+02'

TIMESTAMP WITH TIME ZONE '2004-10-19 10:23:54+02'

BEGIN;

CREATE TEMPORARY TABLE t (
    c1 TEXT,
    c2 TIMESTAMP WITH TIME ZONE
) ON COMMIT DROP;

INSERT INTO t VALUES
    ('epoch', 'epoch'),
    ('infinity', 'infinity'),
    ('-infinity', '-infinity'),
    ('now', 'now'),
    ('today', 'today'),
    ('tomorrow', 'tomorrow'),
    ('yesterday', 'yesterday'),
    ('LOCALTIMESTAMP', LOCALTIMESTAMP);

SELECT pg_sleep(2); -- dormir por 2 segundos

INSERT INTO t VALUES
    ('CURRENT_TIMESTAMP', CURRENT_TIMESTAMP);

SELECT * FROM t;

        c1         |              c2
-------------------+-------------------------------
 epoch             | 1969-12-31 21:00:00-03
 infinity          | infinity
 -infinity         | -infinity
 now               | 2026-01-16 10:13:56.262454-03
 today             | 2026-01-16 00:00:00-03
 tomorrow          | 2026-01-17 00:00:00-03
 yesterday         | 2026-01-15 00:00:00-03
 LOCALTIMESTAMP    | 2026-01-16 10:13:56.262454-03
 CURRENT_TIMESTAMP | 2026-01-16 10:13:56.262454-03
(9 linhas)

COMMIT;

O formato de saída dos tipos de dados de data/hora pode ser definido como um destes quatro estilos: ISO 8601, SQL (Ingres), POSTGRES tradicional (formato date do Unix), ou German. O padrão é o formato ISO. (O padrão SQL requer o uso do formato ISO 8601. O nome do formato de saída “SQL” é um acidente histórico.) A Tabela 8.14 mostra um exemplo para cada estilo de saída. A saída dos tipos de dados date e time são geralmente apenas a parte da data ou da hora segundo os exemplos fornecidos. Entretanto, o estilo POSTGRES produz a saída de valores para apenas data no formato ISO. ^[44]

Nos estilos SQL e POSTGRES o dia aparece antes do mês, se tiver sido especificada a ordenação de campo DMY, caso contrário o mês aparece antes do dia. (Veja Seção 8.5.1 para saber como esta configuração também afeta a interpretação dos valores de entrada.) A Tabela 8.15 mostra exemplos.

No estilo ISO, a zona horária é sempre mostrada como um deslocamento numérico com sinal em relação a UTC, com sinal positivo usado para zonas a leste de Greenwich. O deslocamento é mostrado como hh (somente horas) se for um número inteiro de horas, senão como hh:mm se for um número inteiro de minutos, senão como hh:mm:ss. (O terceiro caso não é possível com nenhum padrão de zona horária moderno, mas pode aparecer ao se trabalhar com carimbos de data/hora anteriores à adoção de zonas horárias padronizadas.) Nos outros estilos de data, a zona horária é mostrada como abreviatura alfabética, se isto for de uso comum na zona corrente. Caso contrário, aparece como um deslocamento numérico com sinal no formato ISO 8601 básico (hh ou hhmm). As abreviações alfabéticas exibidas nestes estilos são extraídas da entrada do banco de dados de zona horária da IANA atualmente selecionada pelo parâmetro de tempo de execução TimeZone; elas não são afetadas pela definição de timezone_abbreviations.

O estilo de data/hora pode ser selecionado pelo usuário usando o comando SET datestyle, mudando o parâmetro DateStyle no arquivo de configuração postgresql.conf, ou usando a variável de ambiente PGDATESTYLE no servidor, ou no cliente.

A função de formatação to_char (veja a Seção 9.8) também está disponível como uma forma mais flexível para formatar a saída de data/hora.

BEGIN;

CREATE TEMPORARY TABLE t (
    c TIMESTAMP WITH TIME ZONE
) ON COMMIT DROP;

INSERT INTO t VALUES ('1997-12-17 07:37:16-08');

SET datestyle = 'ISO';

SELECT * FROM t;

           c
------------------------
 1997-12-17 13:37:16-02

COMMIT;

As zonas horárias e as convenções de zona horária são influenciadas por decisões políticas, não apenas pela geometria da Terra. As zonas horárias em todo o mundo tornaram-se um pouco padronizadas durante os anos 1900, mas continuam propensas a mudanças arbitrárias, principalmente no que diz respeito às regras de horário de verão. O PostgreSQL usa o banco de dados de zona horária IANA (Olson) amplamente utilizado para obter informações sobre as regras históricas de zona horária. ^[45] Para horas no futuro, supõe-se que as últimas regras conhecidas para uma determinada zona horária continuarão a ser observadas indefinidamente no futuro.

O PostgreSQL se esforça para ser compatível com as definições do padrão SQL para uso típico. Entretanto, o padrão SQL tem uma mistura estranha de tipos de dados e recursos de data e hora. Dois problemas óbvios são:

Para solucionar estas dificuldades, recomenda-se usar tipos de dados data/hora que contenham a data e a hora quando são usadas zonas horárias. Não é recomendado usar o tipo de dados time with time zone (embora seja aceito pelo PostgreSQL para aplicações legadas e para conformidade com o padrão SQL). O PostgreSQL assume a zona horária local para qualquer tipo de dados contendo apenas a data e a hora.

Todas as datas e horas com informação de zona horária são armazenadas internamente em UTC. Elas são convertidas para a hora local na zona especificada pelo parâmetro de configuração TimeZone antes de serem mostradas no cliente.

O PostgreSQL permite especificar as zonas horárias de três maneiras diferentes:

Em resumo, esta é a diferença entre abreviaturas e nomes completos: as abreviaturas representam um deslocamento UTC específico, enquanto muitos nomes completos implicam em uma regra de horário de verão local, portanto têm dois deslocamentos de UTC possíveis. Por exemplo, 2014-06-04 12:00 America/New_York representa meio-dia na hora local de Nova York, que para esta data em particular estava no horário de verão (Eastern Daylight Time = UTC-4). Portanto, 2014-06-04 12:00 EDT especifica este mesmo instante de hora. Mas 2014-06-04 12:00 EST especifica meio-dia no Horário Padrão da Costa Leste (Eastern Standard Time = UTC-5), independentemente do horário de verão estar em vigor nesta data ou não.

Para complicar as coisas, algumas jurisdições usaram a mesma abreviatura de zona horária para significar diferentes deslocamentos de UTC em horários diferentes; por exemplo, em Moscou MSK significa UTC+3 em alguns anos, e UTC+4 em outros. O PostgreSQL interpreta estas abreviaturas conforme o que elas significam (ou significaram mais recentemente) na data específica; mas como no exemplo de EST acima, esta não é necessariamente idêntica à hora civil nessa data.

Em todos os casos, os nomes e abreviaturas de zona horária são reconhecidos sem distinção entre letras maiúsculas e minúsculas. (Essa é uma mudança em relação às versões do PostgreSQL anteriores a 8.2, que faziam distinção entre letras maiúsculas e minúsculas em alguns contextos, enquanto em outros não.)

Nem os nomes das zonas horárias, nem as abreviaturas, estão codificados no servidor; estes são obtidos nos arquivos de configuração armazenados sob .../share/timezone/ e .../share/timezonesets/ do diretório de instalação (veja a Seção B.4).

O parâmetro de configuração TimeZone pode ser definido no arquivo postgresql.conf, ou de qualquer outra forma padrão descrita no Capítulo 19. Também existem algumas maneiras especiais para defini-lo:

$ # Linux Debian 12
$ timedatectl list-timezones | grep Brazil

Brazil/Acre
Brazil/DeNoronha
Brazil/East
Brazil/West

$ ls -l /usr/share/zoneinfo/Brazil/ | cut -c40-

Acre -> ../America/Rio_Branco
DeNoronha -> ../America/Noronha
East -> ../America/Sao_Paulo
West -> ../America/Manaus

-- PostgreSQL

SELECT * FROM pg_timezone_names
    WHERE name LIKE 'Brazil%'
    ORDER BY abbrev;

       name       | abbrev | utc_offset | is_dst
------------------+--------+------------+--------
 Brazil/DeNoronha | -02    | -02:00:00  | f
 Brazil/East      | -03    | -03:00:00  | f
 Brazil/West      | -04    | -04:00:00  | f
 Brazil/Acre      | -05    | -05:00:00  | f
(4 linhas)

Os valores de interval podem ser escritos usando a seguinte sintaxe detalhada:

[@] quantidade unidade [quantidade unidade...] [direção]

onde quantidade é um número (possivelmente com sinal); unidade é microsecond, millisecond, second, minute, hour, day, week, month, year, decade, century, millennium, ou abreviaturas, ou plurais dessas unidades; direção pode ser ago ou estar vazia. O sinal (@) é um ruído opcional. As quantidades das diferentes unidades são adicionadas implicitamente com a contabilização de sinais apropriada. ago nega todos os campos. Essa sintaxe também será usada na saída de intervalo, se IntervalStyle estiver definido como postgres_verbose.

Quantidades de dias, horas, minutos e segundos podem ser especificadas sem marcações de unidades explícitas. Por exemplo, '1 12:59:10' é lido da mesma forma que '1 day 12 hours 59 min 10 sec'. Além disso, uma combinação de anos e meses pode ser especificada com um traço; por exemplo, '200-10' é lido da mesma forma que '200 years 10 months'. (Estas formas mais curtas são de fato as únicas permitidas pelo padrão SQL, sendo usadas na saída quando IntervalStyle é definido como sql_standard.)

Os valores de intervalo também podem ser escritos como intervalos de tempo ISO 8601, usando o “formato com designadores” da seção 4.4.3.2 do padrão, ou o “formato alternativo” da seção 4.4.3.3. O formato com designadores se parece com:

P quantidade unidade [ quantidade unidade ...] [ T [ quantidade unidade ...]]

A cadeia de caracteres deve começar com a letra P, podendo incluir a letra T que introduz as unidades da hora do dia. As abreviaturas disponíveis estão listadas na Tabela 8.16. As unidades podem ser omitidas, podendo ser especificadas em qualquer ordem, mas as unidades menores que um dia devem aparecer depois do T. Em particular, o significado de M depende se está antes ou depois do T.

No formato alternativo

P [ anos-meses-dias ] [ T horas:minutos:segundos ]

a cadeia de caracteres deve começar com a letra P, e o T separa a parte da data e da hora do intervalo. Os valores são fornecidos como números semelhantes às datas ISO 8601.

Ao escrever uma constante de intervalo com uma especificação de campos, ou quando atribuir uma cadeia de caracteres a uma coluna de intervalo definida com a especificação de campos, a interpretação das quantidades não marcadas depende de campos. Por exemplo, INTERVAL '1' YEAR é lido como 1 ano, enquanto INTERVAL '1' significa 1 segundo. Também, os valores de campo “à direita” do campo menos significativo permitido pela especificação de campos são descartados em silêncio. Por exemplo, escrever INTERVAL '1 day 2:03:04' HOUR TO MINUTE resulta na eliminação do campo de segundos, mas não no campo de dia.

Segundo o padrão SQL, todos os campos de um valor de intervalo devem ter o mesmo sinal, então o sinal menos à esquerda se aplica a todos os campos; por exemplo, o sinal menos no literal de intervalo '-1 2:03:04' se aplica tanto aos dias quanto às horas/minutos/segundos. O PostgreSQL permite que os campos tenham sinais diferentes e, tradicionalmente, trata cada campo na representação textual como tendo sinais independentes, portanto a parte de hora/minuto/segundo é considerada positiva nesse exemplo. Se IntervalStyle estiver definido como sql_standard, então o sinal à esquerda é considerado como sendo aplicado a todos os campos (mas apenas se não aparecer nenhum sinal adicional). De outra forma, a interpretação tradicional do PostgreSQL é usada. Para evitar ambiguidade, é recomendável anexar um sinal explícito a cada campo se algum campo for negativo.

Internamente, os valores de interval são armazenados como três campos de números inteiros: meses, dias e microssegundos. Estes campos são mantidos em separado porque o número de dias em um mês varia, e um dia pode ter 23 ou 25 horas se houver mudança para o horário de verão. Uma cadeia de caracteres de entrada para intervalo que utiliza outras unidades é normalizada para este formato e, em seguida, reconstruída de forma padronizada para a saída, por exemplo:

SELECT '2 years 15 months 100 weeks 99 hours 123456789 milliseconds'::interval;

               interval
---------------------------------------
 3 years 3 mons 700 days 133:17:36.789

Aqui, as semanas, entendidas como tendo “7 dias”, foram mantidas em separado, enquanto as unidades de tempo menores e maiores foram combinadas e normalizadas.

Os valores dos campos de entrada podem conter partes fracionárias como, por exemplo, '1.5 weeks' ou '01:02:03.45'. Entretanto, como interval armazena internamente apenas campos de números inteiros, os valores fracionários devem ser convertidos em unidades menores. As partes fracionárias de unidades maiores que meses são arredondadas para um número inteiro de meses como, por exemplo, '1.5 years' se torna '1 year 6 mons'. As partes fracionárias de semanas e dias são calculadas como um número inteiro de dias e microssegundos, considerando 30 dias por mês e 24 horas por dia como, por exemplo, '1.75 months' se torna 1 mon 22 days 12:00:00. Apenas os segundos serão mostrados como frações na saída.

A Tabela 8.17 mostra alguns exemplos de entradas válidas para interval.

Exemplo:

SELECT '1-2' ::interval,
       '3 4:05:06' ::interval,
       '1 year 2 months 3 days 4 hours 5 minutes 6 seconds'::interval;

   interval    |    interval     |           interval
---------------+-----------------+-------------------------------
 1 year 2 mons | 3 days 04:05:06 | 1 year 2 mons 3 days 04:05:06
(1 linha)

Conforme mencionado anteriormente, o PostgreSQL armazena os valores do tipo de dados interval como meses, dias e microssegundos. Para a saída, o campo de meses é convertido em anos e meses dividindo por 12. O campo de dias é mostrado tal como está. O campo de microssegundos é convertido em horas, minutos, segundos e frações de segundo. Portanto, meses, minutos e segundos nunca serão mostrados excedendo os limites 0–11, 0–59 e 0–59, respectivamente, mas os campos mostrados com anos, dias e horas podem ser muito grandes. (As funções justify_days e justify_hours podem ser usadas se for desejado transpor valores grandes de dias ou horas para o campo imediatamente superior.)

O formato de saída do tipo de dados interval pode ser definido como sendo um destes quatro estilos: sql_standard, postgres, postgres_verbose, ou iso_8601, usando o comando SET intervalstyle. O padrão é o formato postgres. A Tabela 8.18 mostra exemplos de cada um destes quatro estilos de saída.

O estilo sql_standard produz uma saída em conformidade com a especificação do padrão SQL para literais de intervalo, se o valor do intervalo estiver de acordo com as restrições do padrão (somente ano e mês, ou somente hora do dia, sem mistura de componentes positivos e negativos). Caso contrário, a saída se parece com um literal de ano-mês padrão seguido por um literal de dia-hora, com sinais explícitos adicionados para desambiguar intervalos com sinais mistos.

A saída do estilo postgres corresponde à saída do PostgreSQL nas versões anteriores a 8.4 quando o parâmetro DateStyle estava definido como ISO.

A saída do estilo postgres_verbose corresponde à saída do PostgreSQL nas versões anteriores a 8.4 quando o parâmetro DateStyle estava definido como não-ISO.

A saída do estilo iso_8601 corresponde ao “formato com designadores” descrito na seção 4.4.3.2 do padrão ISO 8601.