Nivel 3 · Pedidos de marzo de 2024

Los filtros de fecha están en todas partes en analítica: el mes pasado, este trimestre, lo que va del año. También son el origen de muchos números equivocados sin que nadie se dé cuenta.

Fechas vs timestamps

signup_date en customers es un DATE: solo un día, como 2024-03-31. order_date en orders es un TIMESTAMP: un día más una hora, como 2024-03-31 18:42:10. Cuando comparas un timestamp con un literal de fecha como '2024-03-31', el literal se trata como la medianoche al inicio de ese día, 2024-03-31 00:00:00.

La trampa de BETWEEN

BETWEEN a AND b significa >= a AND <= b. Parece perfecto para “marzo”:

-- bug: misses almost all of March 31
WHERE order_date BETWEEN '2024-03-01' AND '2024-03-31'

El límite superior es 2024-03-31 00:00:00, así que un pedido a las 9 am del 31 de marzo queda excluido. La gente “lo arregla” con '2024-03-31 23:59:59', que aún pierde cualquier cosa del último segundo y se rompe cuando los timestamps tienen milisegundos.

El rango semiabierto

El patrón estándar de los analistas es: a partir del primer momento, inclusive, y estrictamente antes del primer momento del período siguiente.

WHERE order_date >= '2024-03-01'
  AND order_date <  '2024-04-01'

Funciona para fechas y timestamps, nunca cuenta dos veces un límite cuando apilas meses consecutivos, y deja que la base de datos use un índice sobre order_date.

También verás WHERE CAST(order_date AS DATE) BETWEEN '2024-03-01' AND '2024-03-31' o WHERE DATE_TRUNC('month', order_date) = '2024-03-01'. Ambos devuelven las filas correctas, pero envolver la columna en una función suele impedir el uso del índice, lo que importa en tablas grandes en Postgres y MySQL. Prefiere el rango semiabierto.

Notas por dialecto

• Postgres y DuckDB aceptan '2024-03-01' y lo convierten automáticamente. Puedes ser explícito con DATE '2024-03-01' o TIMESTAMP '2024-03-01 00:00:00'.
• BigQuery separa estrictamente DATE, DATETIME y TIMESTAMP y puede necesitar TIMESTAMP('2024-03-01').
• MySQL acepta la cadena entre comillas igual que Postgres.
• Zonas horarias: Harbor & Pine guarda los timestamps sin zona horaria. En almacenes de datos reales, comprueba si “marzo” significa UTC o la hora local del negocio. Cambia los números en los bordes.

Errores comunes

• BETWEEN con timestamps, como arriba.
• Usar <= '2024-03-31' con un timestamp, que es el mismo error de otra forma.
• Escribir fechas en un formato regional como '03/01/2024'. Usa siempre ISO YYYY-MM-DD.

En SQL Server

El rango semiabierto funciona sin cambios en columnas date y datetime, y la trampa de BETWEEN es la misma. También encontrarás YEAR() y MONTH() allí, y GETDATE() para “ahora” donde DuckDB usa now() o current_date:

WHERE order_date >= '2024-03-01' AND order_date < '2024-04-01'   -- index-friendly
WHERE YEAR(order_date) = 2024 AND MONTH(order_date) = 3          -- same rows, slower on big tables