Nivel 4 · ¿Cuánto tardan en volver los artículos?

El tiempo entre dos eventos es una métrica central para los analistas: días hasta el envío, días hasta la devolución, días desde el registro hasta la primera compra, tiempo para resolver un ticket. También es una de las partes menos portables de SQL.

Restar fechas

En DuckDB y Postgres, date - date devuelve un número entero de días:

SELECT DATE '2025-03-20' - DATE '2025-03-01';   -- 19

returned_on es un DATE pero order_date es un TIMESTAMP. Restar un timestamp da un intervalo como 18 days 09:12:00, que no puedes promediar como un número simple con tanta facilidad. Convierte el timestamp a fecha primero, para que ambos lados sean días de calendario:

r.returned_on - CAST(o.order_date AS DATE) AS days_to_return

Convertir responde a “cuántos días de calendario después”, que es como se escriben los plazos de devolución en una política. Si necesitaras horas (por ejemplo, el tiempo hasta la primera respuesta en un ticket de soporte), conservarías los timestamps y usarías una diferencia de epoch en su lugar.

Las formas con función

base de datos	días entre start y end
DuckDB	end - start, o DATE_DIFF('day', start, end)
Postgres	end - start (fechas); EXTRACT(EPOCH FROM end - start) / 86400 para timestamps
MySQL	DATEDIFF(end, start)
BigQuery	DATE_DIFF(end, start, DAY)
Snowflake, SQL Server	DATEDIFF(day, start, end)

Ojo con el orden de los argumentos: MySQL y BigQuery ponen el fin primero, DuckDB y Snowflake ponen el inicio primero. Equivocarse invierte el signo, algo fácil de pasar por alto cuando solo miras un promedio. Un MIN() rápido que sale negativo es la señal.

Sumar tiempo

Para ir en el otro sentido, suma un intervalo: order_date + INTERVAL 30 DAY funciona en DuckDB, MySQL y BigQuery (como DATE_ADD en BigQuery), y Postgres escribe INTERVAL '30 days'. Así señalarías las devoluciones que llegaron después de un plazo de 30 días:

WHERE r.returned_on > CAST(o.order_date AS DATE) + INTERVAL 30 DAY

El promedio y el máximo cuentan historias distintas

El promedio le dice a Rachel lo que es típico. El máximo le habla de la cola: si las devoluciones tardías llegan con regularidad a 40 días, un plazo de 30 días convertiría algunas de las devoluciones aceptadas hoy en rechazadas. En el trabajo también mirarías un percentil, por ejemplo QUANTILE_CONT(days, 0.9) en DuckDB o PERCENTILE_CONT(0.9) WITHIN GROUP (ORDER BY days) en Postgres, y reportarías “el 90 % de las devoluciones llega en N días”. Esa frase es mucho más útil para una decisión de política que un promedio.

Errores comunes

• Mezclar DATE y TIMESTAMP sin convertir, y luego promediar intervalos.
• Intercambiar el orden de los argumentos en funciones tipo DATEDIFF entre dialectos.
• Promediar sobre el grano equivocado. Aquí una fila es una devolución, que es lo que pidió Rachel.

En SQL Server

DATEDIFF(day, o.order_date, r.returned_on) cuenta las medianoches cruzadas, así que un pedido a las 23:59 y una devolución a la mañana siguiente son 1 día. Suma tiempo con DATEADD(day, 30, order_date). Restar dos valores date con - es un error allí.