Errores típicos al trabajar con fechas y horas

Hoy otra vez vamos a hablar de errores. Porque trabajar con fechas y horas es como caminar por un campo de minas: todo va bien hasta que das el primer paso en falso.

Errores al elegir el tipo de dato

Aquí suele estar el origen de todos los males. Elegir mal el tipo de dato puede tirar por tierra todo tu esfuerzo con fechas y horas.

Situación 1: Usar DATE en vez de TIMESTAMP

Cuando registras un evento que tiene no solo fecha sino también hora, usar solo DATE puede hacerte perder info importante.

CREATE TABLE orders (
    order_id SERIAL PRIMARY KEY,
    order_date DATE -- solo fecha
);

Con este diseño no vas a saber si se hicieron dos pedidos por la mañana o por la tarde. ¿Para qué perder la oportunidad de tomarte un café y mirar timestamps bonitos?

Situación 2: Olvidar las zonas horarias

Si tu app tiene usuarios internacionales pero guardas fecha y hora solo con TIMESTAMP, sin tener en cuenta las zonas horarias, tus datos pueden quedar "sin hogar". TIMESTAMPTZ te salva de ese lío.

CREATE TABLE events (
    event_time TIMESTAMP -- sin zona horaria
);

Nadie quiere confundir un evento de la tarde en Nueva York con uno de la mañana en Tokio. ¡Usa TIMESTAMPTZ!

Errores al usar funciones

Situación 1: Formato incorrecto en TO_CHAR()

Los problemas empiezan si pones mal el formato. Por ejemplo:

SELECT TO_CHAR(NOW(), 'YYYY-DD-MM'); -- Uy, mezclé mes y día

Aquí en vez del típico año-mes-día, obtuvimos año-día-mes. Esto puede causar situaciones graciosas (pero no siempre agradables) para tus usuarios. Revisa siempre el formato.

Situación 2: Errores usando TO_DATE()

Al revés, si intentas convertir un string a fecha pero el formato no cuadra, PostgreSQL te va a dar error.

SELECT TO_DATE('10/31/2023', 'YYYY-MM-DD'); -- ¡Error! El formato no cuadra.

El formato del string tiene que coincidir exactamente con el que pusiste. Por ejemplo:

SELECT TO_DATE('2023-10-31', 'YYYY-MM-DD'); -- Todo correcto.

Errores con intervalos de tiempo

Situación 1: Conversión implícita de tipos

A veces se te puede olvidar cómo funciona la conversión de tipos. Por ejemplo:

SELECT NOW() + '1'; -- ¡ERROR! No está claro qué es '1'.

PostgreSQL no entiende que quieres sumar un día. La forma correcta:

SELECT NOW() + INTERVAL '1 day';

Situación 2: Líos al restar intervalos

Ten cuidado al sumar o restar intervalos:

SELECT NOW() - INTERVAL '-1 day'; -- ¡Esto suma un día en vez de restar!

Aquí el doble menos hace el efecto contrario. Mejor evita estas construcciones.

Errores al redondear y recortar datos

Situación 1: Recorte incorrecto con DATE_TRUNC()

Cuando usas DATE_TRUNC() para agrupar datos, revisa que elegiste el nivel correcto. Por ejemplo:

SELECT DATE_TRUNC('hour', NOW()); -- Recorta al inicio de la hora
SELECT DATE_TRUNC('minute', NOW()); -- Recorta al inicio del minuto

Si esperabas un resultado y obtuviste otro, puede que elegiste mal el nivel.

Situación 2: Olvidar las zonas horarias con DATE_TRUNC()

Si trabajas con horas en distintas zonas, el resultado puede ser inesperado:

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

Asegúrate de que la zona horaria está bien puesta, si no puedes perderte en el tiempo (literalmente).

Unix time: segundos perdidos

Unix time (EPOCH) es muy útil, pero tramposo. El error más común es confundir segundos con milisegundos.

SELECT TO_TIMESTAMP(1680000000); -- Esto está bien (segundos).
SELECT TO_TIMESTAMP(1680000000000); -- ¡Esto es un error! Demasiados ceros.

Revisa en qué unidad está tu timestamp para no guardar un millón de segundos de más.

Errores con zonas horarias

Situación 1: Zonas horarias confusas

Cuando trabajas con usuarios de diferentes zonas, los datos pueden mezclarse. Por ejemplo:

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

Asegúrate de tener claro en qué zona horaria están tus datos.

Situación 2: Duplicar zonas horarias

Guardar fecha y hora y luego intentar volver a aplicar zonas horarias es mala idea:

SELECT TIMESTAMP '2023-10-01 10:00:00 UTC' AT TIME ZONE 'UTC'; -- ¡No hagas esto!

Esto puede llevar a cálculos incorrectos.

Recomendaciones para evitar errores

Elige el tipo de dato adecuado. Si trabajas con datos de tiempo internacionales, usa TIMESTAMPTZ. Si solo necesitas la fecha, quédate con DATE.

Prueba tus consultas. Asegúrate de que los resultados son los que esperas, sobre todo si trabajas con intervalos, formatos o redondeos.

Guarda los datos de tiempo en UTC. Es la mejor forma de evitar líos con las zonas horarias.

Revisa los formatos. Asegúrate de que el formato en TO_CHAR() y TO_DATE() coincide con tus datos.

Usa las funciones con cuidado. Lee bien la documentación de PostgreSQL sobre funciones de tiempo para evitar sorpresas raras.

Trabajar con datos de tiempo puede ser complicado, pero con el enfoque correcto y atención al detalle todo va a ir sobre ruedas. Las fechas y horas son una parte clave de tus apps, y olvidarlo es tan peligroso como olvidarte de poner la alarma el lunes por la mañana!