Quando a gente começa a mexer com dados, quase sempre aparece alguma coisa relacionada a tempo. Pensa em horários de voos, prazos de pedidos ou a data em que o usuário se cadastrou no site. Tudo isso tem a ver com tempo. E pra trabalhar de boa com isso, precisa das ferramentas certas. No PostgreSQL tem tipos de dados especiais que mandam muito bem pra guardar e manipular datas e horários.
Dá até pra salvar uma data como string tipo "2023-10-12", mas isso é mais uma armadilha do que solução. String não sabe comparar datas, não faz ideia do que é “mais três dias” e nem sonha com fuso horário. Agora, os tipos de dados de tempo sabem tudo isso e mais um pouco. Com eles é mais fácil, seguro e rápido.
Tipo DATE
O tipo DATE serve pra guardar só a data do calendário, sem hora nenhuma. É perfeito quando você quer trabalhar com datas como coisas separadas, tipo data de nascimento, início do ano e por aí vai.
Exemplos de uso:
-- Exemplo de criação de tabela com tipo `DATE`
CREATE TABLE events (
event_name TEXT,
event_date DATE
);
-- Inserindo dados
INSERT INTO events (event_name, event_date)
VALUES ('Conferência PostgreSQL', '2023-12-01'),
('Aniversário', '2023-10-12');
-- Consulta
SELECT * FROM events;
Resultado:
| event_name | event_date |
|---|---|
| Conferência PostgreSQL | 2023-12-01 |
| Aniversário | 2023-10-12 |
Tipo TIME
O tipo TIME guarda SÓ o horário, ou seja, horas, minutos e segundos. Ele é ótimo pra coisas tipo horários de ônibus ou intervalos de funcionamento de lojas.
Exemplos:
-- Exemplo de criação de tabela com `TIME`
CREATE TABLE schedules (
schedule_name TEXT,
start_time TIME,
end_time TIME
);
-- Inserindo dados
INSERT INTO schedules (schedule_name, start_time, end_time)
VALUES ('Horário de trabalho', '09:00:00', '18:00:00'),
('Intervalo do almoço', '13:00:00', '14:00:00');
-- Consulta
SELECT schedule_name, start_time, end_time FROM schedules;
Resultado:
| schedule_name | start_time | end_time |
|---|---|---|
| Horário de trabalho | 09:00:00 | 18:00:00 |
| Intervalo do almoço | 13:00:00 | 14:00:00 |
Tipo TIMESTAMP
O tipo TIMESTAMP junta a data do calendário e o horário num valor só. Mas ele NÃO leva em conta o fuso horário. Isso pode dar confusão se os dados forem usados por gente de fusos diferentes.
Exemplos:
-- Exemplo de criação de tabela com `TIMESTAMP`
CREATE TABLE documents (
document_id SERIAL PRIMARY KEY,
created_at TIMESTAMP
);
-- Inserindo dados
INSERT INTO documents (created_at)
VALUES ('2023-10-12 15:30:00'),
('2023-12-01 08:45:15');
-- Consulta
SELECT document_id, created_at FROM documents;
Resultado:
| document_id | created_at |
|---|---|
| 1 | 2023-10-12 15:30:00 |
| 2 | 2023-12-01 08:45:15 |
Tipo TIMESTAMPTZ
O tipo TIMESTAMPTZ (onde TZ é "time zone", ou fuso horário) é parecido com o TIMESTAMP, mas ainda guarda a informação do fuso. Isso faz dele indispensável pra apps que têm usuários de vários países.
Exemplos:
-- Exemplo de criação de tabela com `TIMESTAMPTZ`
CREATE TABLE meetings (
meeting_id SERIAL PRIMARY KEY,
meeting_time TIMESTAMPTZ
);
-- Inserindo dados (PostgreSQL salva o fuso atual)
INSERT INTO meetings (meeting_time)
VALUES ('2023-10-12 15:30:00+03'),
('2023-12-01 08:45:15-05');
-- Consulta
SELECT meeting_id, meeting_time FROM meetings;
Resultado:
| meeting_id | meeting_time |
|---|---|
| 1 | 2023-10-12 15:30:00+03:00 |
| 2 | 2023-12-01 08:45:15-05:00 |
Repara que o PostgreSQL converte o horário automaticamente pro fuso do servidor.
Vantagens de usar tipos de dados próprios
Dados corretos. Tipos como DATE e TIMESTAMP não deixam você colocar coisa errada. Por exemplo, não dá pra salvar uma data que não existe, tipo "2023-02-30".
Facilidade de uso. Dá pra comparar datas, subtrair uma da outra, pegar a data de agora e até arredondar valores (a gente fala disso depois).
Performance. Tipos de tempo ocupam menos espaço na memória e nos índices do que strings, então as consultas rodam mais rápido.
Exemplo: criando uma tabela usando todos os tipos
Bora criar uma tabela mais completa pra guardar a agenda de eventos. Vamos usar vários tipos juntos: DATE, TIME, TIMESTAMP e TIMESTAMPTZ.
CREATE TABLE event_schedule (
event_id SERIAL PRIMARY KEY,
event_name TEXT NOT NULL,
event_date DATE NOT NULL,
start_time TIME NOT NULL,
end_time TIME NOT NULL,
full_start TIMESTAMP NOT NULL,
full_start_with_zone TIMESTAMPTZ NOT NULL
);
-- Inserindo dados
INSERT INTO event_schedule (
event_name, event_date, start_time, end_time, full_start, full_start_with_zone
)
VALUES
('Meetup da manhã', '2023-11-10', '10:00:00', '11:30:00', '2023-11-10 10:00:00', '2023-11-10 10:00:00+03'),
('Workshop da noite', '2023-11-11', '18:00:00', '20:00:00', '2023-11-11 18:00:00', '2023-11-11 18:00:00+03');
-- Conferindo os dados
SELECT * FROM event_schedule;
Resultado:
| event_id | event_name | event_date | start_time | end_time | full_start | fullstartwith_zone |
|---|---|---|---|---|---|---|
| 1 | Meetup da manhã | 2023-11-10 | 10:00:00 | 11:30:00 | 2023-11-10 10:00:00 | 2023-11-10 10:00:00+03:00 |
| 2 | Workshop da noite | 2023-11-11 | 18:00:00 | 20:00:00 | 2023-11-11 18:00:00 | 2023-11-11 18:00:00+03:00 |
Esse é um exemplo de banco real pra gerenciar agendas. Dá pra ver como os formatos de tempo se complementam, dependendo do que você precisa.
Espero que você tenha lembrado como usar os tipos DATE, TIME, TIMESTAMP e TIMESTAMPTZ no PostgreSQL. Nas próximas aulas a gente vai se aprofundar nas funções de tempo e aprender a extrair, formatar e manipular dados de tempo com SQL.
GO TO FULL VERSION