Erros comuns ao trabalhar com datas e horários

Hoje vamos falar de erros de novo. Porque mexer com datas e horários é tipo andar num campo minado: tá tudo de boa até você pisar no lugar errado.

Erros na escolha do tipo de dado

É aqui que geralmente começa a treta. Se você escolhe o tipo de dado errado, todo seu esforço pra lidar com datas e horários pode ir pro saco.

Situação 1: Usar DATE em vez de TIMESTAMP

Quando você registra um evento que tem não só a data, mas também o horário, usar só DATE pode te fazer perder informação importante.

CREATE TABLE orders (
    order_id SERIAL PRIMARY KEY,
    order_date DATE -- só a data
);

Com esse design, você não vai saber se dois pedidos foram feitos de manhã ou à noite. Pra quê perder a chance de tomar um café e olhar uns timestamps bonitos?

Situação 2: Esqueceu do timezone

Se seu app tem usuários do mundo todo, mas você salva data e hora só com TIMESTAMP, sem considerar o timezone, seus dados podem virar "sem teto". TIMESTAMPTZ resolve isso pra você.

CREATE TABLE events (
    event_time TIMESTAMP -- sem timezone
);

Ninguém quer confundir um evento à noite em Nova York com um de manhã em Tóquio. Usa TIMESTAMPTZ!

Erros ao usar funções

Situação 1: Formato errado no TO_CHAR()

O problema começa se você coloca o formato errado. Tipo assim:

SELECT TO_CHAR(NOW(), 'YYYY-DD-MM'); -- Opa, troquei mês e dia

Aqui, em vez do clássico ano-mês-dia, saiu ano-dia-mês. Isso pode gerar umas situações engraçadas (mas nem sempre legais) pros seus usuários. Sempre confere o formato.

Situação 2: Erros usando TO_DATE()

Ao contrário, se você tenta converter uma string pra data, mas o formato não bate, o PostgreSQL vai dar erro.

SELECT TO_DATE('10/31/2023', 'YYYY-MM-DD'); -- Erro! Formato não bate.

O formato da string tem que bater certinho com o que você colocou. Tipo assim:

SELECT TO_DATE('2023-10-31', 'YYYY-MM-DD'); -- Agora foi.

Erros com intervalos de tempo

Situação 1: Conversão de tipo implícita

Às vezes você esquece como funciona a conversão de tipos. Tipo assim:

SELECT NOW() + '1'; -- ERRO! O que é '1'?

O PostgreSQL não entende que você quer somar um dia. O jeito certo:

SELECT NOW() + INTERVAL '1 day';

Situação 2: Confusão ao subtrair intervalos

Fica esperto quando for somar ou subtrair intervalos:

SELECT NOW() - INTERVAL '-1 day'; -- Isso vai somar um dia, não subtrair!

Aqui o duplo negativo faz o efeito contrário. Melhor evitar essas maluquices.

Erros ao arredondar e cortar dados

Situação 1: Corte errado com DATE_TRUNC()

Quando você usa DATE_TRUNC() pra agrupar dados, sempre confere se escolheu o nível certo. Tipo assim:

SELECT DATE_TRUNC('hour', NOW()); -- Corta até o início da hora
SELECT DATE_TRUNC('minute', NOW()); -- Corta até o início do minuto

Se você esperava um resultado e veio outro, talvez escolheu o nível errado.

Situação 2: Esqueceu do timezone com DATE_TRUNC()

Se você trabalha com horários em vários timezones, o resultado pode ser estranho:

SELECT DATE_TRUNC('day', NOW() AT TIME ZONE 'UTC');

Confere se o timezone tá certo, senão você pode se perder no tempo (literalmente).

Unix time: segundos perdidos

Unix time (EPOCH) é prático, mas traiçoeiro. O erro mais comum é confundir segundos com milissegundos.

SELECT TO_TIMESTAMP(1680000000); -- Certo (segundos).
SELECT TO_TIMESTAMP(1680000000000); -- Erro! Zero demais.

Confere se seu timestamp tá em segundos ou milissegundos, pra não guardar um milhão de segundos a mais.

Erros com timezones

Situação 1: Timezones confusos

Quando você lida com usuários de vários fusos, os dados podem se misturar. Tipo assim:

SELECT TIMESTAMP '2023-10-01 10:00:00' AT TIME ZONE 'UTC';

Confere direitinho em que timezone estão seus dados.

Situação 2: Duplicando timezone

Salvar data e hora e depois tentar aplicar timezone de novo é furada:

SELECT TIMESTAMP '2023-10-01 10:00:00 UTC' AT TIME ZONE 'UTC'; -- Não faz isso!

Isso pode dar uns cálculos errados.

Dicas pra evitar esses erros

Escolhe o tipo de dado certo. Se você lida com dados de horário internacionais, usa TIMESTAMPTZ. Se só precisa da data, vai de DATE.

Testa suas queries. Vê se os resultados batem com o que você espera, principalmente se estiver mexendo com intervalos, formatos ou arredondamento.

Salva horários em UTC. É o melhor jeito de não se enrolar com timezone.

Confere os formatos. Garante que o formato no TO_CHAR() e TO_DATE() bate com seus dados.

Usa as funções com cuidado. Dá uma olhada na documentação do PostgreSQL sobre funções de data/hora pra não cair em pegadinha.

Mexer com datas e horários pode ser chato, mas com atenção e boas práticas tudo fica suave. Datas e horários são parte importante dos seus apps, e esquecer disso é tão perigoso quanto esquecer de colocar o despertador pra segunda de manhã!