De todas las preguntas que se hace la dirección de TiendaVerde, la mayoría llevan una fecha dentro: ¿cuánto facturamos este mes?, ¿qué clientes no compran desde hace medio año?, ¿cuántos días tardó en llegar esa devolución?, ¿crecemos trimestre a trimestre? Hasta ahora solo sabías comparar fechas con >= y <. Esta lección convierte la columna fecha_pedido en una herramienta de análisis.

También salda la deuda de 04-05, donde EXTRACT apareció de pasada para agrupar por año y se dejó explicado "para el módulo 6". Y trae la pieza que faltaba para los informes: DATE_TRUNC, la función que convierte 20 pedidos sueltos en una serie mensual.

Nota sobre la reproducibilidad: los ejemplos que necesitan "hoy" usan la fecha fija DATE '2026-03-01' en lugar de CURRENT_DATE, para que los resultados que ves aquí coincidan con los tuyos. En producción usarías CURRENT_DATE.

1. Los tipos temporales, y por qué TiendaVerde usa DATE
2. El "ahora": CURRENT_DATE, NOW() y CLOCK_TIMESTAMP()
3. Aritmética de fechas, INTERVAL y AGE()
4. EXTRACT y DATE_PART
5. DATE_TRUNC: el patrón del informe temporal
6. Formatear con TO_CHAR, analizar con TO_DATE
7. Informes sin huecos con generate_series
8. Tabla comparativa por motor
9. Errores Comunes y Consejos
10. Ejercicios
11. Conclusión

TiendaVerde usa DATE en todas sus columnas temporales —fecha_pedido, fecha_registro, fecha_alta, fecha_contratacion, resenas.fecha, devoluciones.fecha— porque en este modelo son hechos de calendario: un pedido es "del 4 de marzo", no "de las 18:47:03 del 4 de marzo". Guardar una hora que nadie va a usar añade ambigüedad sin aportar información.

En una tienda real querrías la hora: para medir el tiempo de preparación, para saber a qué hora se compra más, para auditar quién cambió qué y cuándo. Y en cuanto añades la hora, aparece la zona horaria:

La recomendación profesional: en una aplicación real, TIMESTAMPTZ es casi siempre la elección correcta. TIMESTAMP sin zona parece más simple y es una trampa: guarda un número sin decir a qué reloj pertenece, y el día que tengas usuarios en dos países ya no hay forma de saberlo. TIMESTAMPTZ guarda internamente un instante en UTC y lo convierte a la zona de cada sesión al leerlo. Y DATE es correcto solo cuando el dato es de verdad una fecha de calendario: una fecha de nacimiento, un día de facturación, un vencimiento.

Ese es exactamente el criterio por el que TiendaVerde usa DATE, y por el que tu próxima aplicación probablemente no deba hacerlo.

La diferencia entre NOW() y CLOCK_TIMESTAMP() sorprende la primera vez. Si abres BEGIN;, ejecutas SELECT NOW(), CLOCK_TIMESTAMP();, esperas unos segundos y repites la consulta antes del COMMIT, la primera columna devuelve exactamente el mismo valor las dos veces y la segunda no. NOW() está congelada durante toda la transacción, y eso es una garantía deliberada: si un proceso inserta cien filas con NOW(), las cien comparten la misma marca y forman un lote identificable. Para medir cuánto tarda algo dentro de una transacción, NOW() no sirve: necesitas CLOCK_TIMESTAMP().

Consecuencia práctica: fecha_registro DATE NOT NULL DEFAULT CURRENT_DATE (el DEFAULT de clientes en 01-06) es estable y correcto. Un DEFAULT clock_timestamp() sería volátil y, como viste en 05-06, obligaría a reescribir la tabla entera al añadir la columna.

Dos trampas en esa tabla. date - date da un entero y timestamp - timestamp da un intervalo: el mismo signo - con dos semánticas, de modo que migrar una columna de DATE a TIMESTAMP cambia el tipo de todas tus restas en silencio. Y date + INTERVAL devuelve un TIMESTAMP, no un DATE; si necesitas una fecha, añade ::DATE.

Fíjate en la primera: 31 de enero + 1 mes = 28 de febrero, porque el 31 de febrero no existe y PostgreSQL ajusta al último día del mes. Un mes no es una cantidad fija de días: INTERVAL '1 month' e INTERVAL '30 days' son cosas distintas.

AGE no devuelve días: devuelve años, meses y días, como diría una persona.

Dos detalles: PostgreSQL omite los componentes que valen cero (Javier no muestra "0 mons"; Diego, ni meses ni días), y AGE es lo que quieres para mostrar a un humano mientras que la resta en días es lo que quieres para ordenar y comparar.

Las tres devoluciones de TiendaVerde: la del pedido cancelado se tramitó en 2 días y las dos por incidencia de producto, en 8. Con TIMESTAMP en lugar de DATE esta resta devolvería un INTERVAL como 8 days 03:12:00, más preciso y menos cómodo de agregar.

EXTRACT(campo FROM fecha) saca un componente. DATE_PART('campo', fecha) hace lo mismo con sintaxis de función; EXTRACT es el estándar SQL y es la forma preferible.

Tres avisos: DOW empieza en domingo con el 0 (convención de C, no europea); WEEK es la semana ISO, así que los primeros días de enero pueden pertenecer a la semana 52 o 53 del año anterior; y EXTRACT devuelve NUMERIC desde PostgreSQL 14. Y el de rendimiento, ya conocido: WHERE EXTRACT(YEAR FROM fecha_pedido) = 2025 funciona pero envuelve la columna en una función y no aprovecha el índice; la forma indexable es la de 02-03, WHERE fecha_pedido >= '2025-01-01' AND fecha_pedido < '2026-01-01'. Lo medirás en 08-03.

DATE_TRUNC(unidad, fecha) rebaja la fecha al inicio de la unidad pedida: el 22 de octubre truncado a mes es el 1 de octubre. Esa es toda la idea, y es la base de casi todo informe temporal.

Ojo al tipo: aunque le pases un DATE, DATE_TRUNC devuelve un TIMESTAMP y por eso ves el 00:00:00. Para que el informe muestre una fecha limpia, añade ::DATE.

12 meses, 20 pedidos, 47 líneas y 727,95 € sumando la última columna: la cifra canónica del módulo 4, ahora desglosada. Y los años cuadran: los diez primeros meses suman 603,52 € (2025) y los dos últimos, 124,43 € (2026). El mejor mes es octubre de 2025 con 97,20 €; el peor, noviembre de 2025 con 31,70 €.

DATE_TRUNC frente a EXTRACT para agrupar: las dos funcionan pero no son equivalentes. EXTRACT(MONTH FROM f) devuelve 3 para marzo de cualquier año, así que marzo de 2025 y de 2026 caerían en el mismo grupo; DATE_TRUNC('month', f) conserva el año y ordena cronológicamente sin trucos. EXTRACT para estacionalidad, DATE_TRUNC para series temporales.

TO_CHAR(fecha, patron) convierte una fecha en texto con el formato que quieras.

Para que la TM funcione en español hay que fijar la configuración regional de la sesión:

Regla de oro: formatea solo al presentar. TO_CHAR(f, 'DD/MM/YYYY') produce texto, y el texto se ordena alfabéticamente: '01/12/2025' iría antes que '04/03/2025'. Si necesitas ordenar o agrupar, hazlo por la fecha y formatea después. La única excepción segura es 'YYYY-MM', que sí ordena bien como texto porque es ISO.

TO_DATE(texto, patron) hace el camino inverso, y es donde vive la ambigüedad clásica:

El mismo texto, dos fechas distintas, ninguna de las dos incorrecta. Por eso el patrón es obligatorio y por eso el formato ISO AAAA-MM-DD es el único que no se malinterpreta nunca. Cuando importes un CSV, exige el formato en la especificación y no lo deduzcas de los datos: '03/04/2025' no te dirá cuál es.

Aquí se cobra la promesa de 03-06 y de 06-02. Un GROUP BY solo devuelve los grupos que existen en los datos: si en un mes no hubo ninguna alta, ese mes no aparece y el informe miente por omisión. Las altas de clientes por mes, tal cual salen del GROUP BY, dan 8 filas para 13 meses de historia. La solución es fabricar la serie completa de meses y unirla por la izquierda:

13 filas y 15 clientes. Ahora se ve lo que el GROUP BY escondía: TiendaVerde captó clientes con regularidad hasta junio de 2025 y se secó durante el segundo semestre —cinco meses con cero altas—. Esa es una conclusión de negocio que sencillamente no existía en el informe de 8 filas.

Tres detalles hacen que el patrón funcione: el LEFT JOIN va de la serie a los datos y nunca al revés; se cuenta COUNT(c.id) y no COUNT(*), porque COUNT(*) contaría la fila fabricada por el LEFT JOIN y daría 1 donde debe dar 0 (04-04); y generate_series con INTERVAL '1 month' genera timestamps, que el ::DATE limpia y el DATE_TRUNC del ON hace comparables. El mismo esquema sirve para días de la semana, trimestres o el eje horario de un panel: es el patrón de informe más reutilizable del curso.

Dos advertencias valen por toda la tabla. SQLite no tiene tipo de fecha: guarda texto, números julianos o segundos epoch, y todas sus funciones son STRFTIME sobre texto; funciona, pero nada impide meter '04/03/2025' en la misma columna. Y DATEDIFF de MySQL y de SQL Server llevan los argumentos en orden distinto —DATEDIFF(f2, f1) frente a DATEDIFF(day, f1, f2)—, así que una migración descuidada cambia el signo de todos los resultados.

Y el error que hay que evitar en cualquier motor: guardar fechas como texto. Una columna VARCHAR(10) con '2025-03-04' acepta '2025-13-45', no se puede sumar ni restar, se ordena mal en cuanto alguien escriba '4/3/2025' y no puede usar un índice de rango con eficacia. Si el dato es una fecha, el tipo es DATE.

• Guardar fechas como texto. El error raíz. DATE valida, ordena, resta e indexa; VARCHAR no hace nada de eso.
• Usar TIMESTAMP sin zona en una aplicación con usuarios en varios países. TIMESTAMPTZ es la elección por defecto.
• Esperar que date + INTERVAL '1 day' devuelva un DATE. Devuelve TIMESTAMP, igual que DATE_TRUNC: de ahí los 00:00:00 de los informes. Añade ::DATE.
• Creer que INTERVAL '1 month' son 30 días. 2025-01-31 + 1 mes es 2025-02-28. Y no confundas DOW (domingo = 0) con ISODOW (lunes = 1).
• Agrupar por EXTRACT(MONTH …) en una serie de varios años. Marzo de 2025 y marzo de 2026 caen en el mismo grupo. Para series temporales, DATE_TRUNC.
• Filtrar con EXTRACT(YEAR FROM f) = 2025. Correcto pero no indexable. Usa >= '2025-01-01' AND < '2026-01-01' (02-03).
• Ordenar por una fecha ya formateada con TO_CHAR. Se ordena como texto. Ordena por la fecha y formatea después; 'YYYY-MM' es la única excepción segura.
• Interpretar '03/04/2025' sin especificar el patrón. Son dos fechas distintas según el país.
• Contar con COUNT(*) en un informe con generate_series. Cuenta la fila fabricada por el LEFT JOIN; cuenta una columna de la tabla de datos.
• Consejo: prefiere >= inicio AND < fin a BETWEEN en fechas. Con DATE funcionan igual, pero el día que la columna pase a TIMESTAMP, BETWEEN perderá todo el último día salvo las 00:00.
• Consejo: guarda en UTC y convierte al presentar, y para depurar fija una fecha de referencia (DATE '2026-03-01') en vez de CURRENT_DATE: tus resultados serán reproducibles mañana.

Dirección quiere el informe mensual de 2025 completo. Para cada uno de los doce meses —aunque no haya nada— muestra el mes en formato YYYY-MM, el número de pedidos y la facturación de producto. Usa generate_series y explica por qué enero y febrero aparecen a cero.

Marketing quiere medir la velocidad de conversión: cuántos días pasan entre el registro de un cliente y su primer pedido. Para los clientes 1 a 8, muestra nombre completo, fecha_registro, fecha del primer pedido y días transcurridos, ordenado por días. (Pista: MIN(fecha_pedido) agrupando por cliente.)

Un compañero ha escrito este informe de estacionalidad y afirma que "marzo es nuestro mes más flojo":

1. ¿Qué está midiendo realmente y por qué la conclusión es frágil con los datos de TiendaVerde?
2. Escribe la versión con DATE_TRUNC que responde a "¿cómo evoluciona el negocio mes a mes?".
3. ¿En qué caso sí sería correcta la consulta original?

Solución 1

12 filas, 16 pedidos y 603,52 €: la facturación de 2025 del módulo 4. Enero y febrero salen a cero porque el primer pedido de TiendaVerde es del 4 de marzo de 2025: la tienda existía pero aún no vendía. Sin generate_series esos dos meses no aparecerían y un gráfico de líneas empezaría en marzo, dando a entender que no hay historia anterior. El COALESCE (06-04) convierte el NULL de SUM sobre un conjunto vacío en 0.00.

Solución 2

La lectura de negocio es incómoda: la conversión empeora conforme avanza el año, de 49 a 102 días. Y hay un sesgo que declarar: los clientes recientes han tenido menos tiempo para comprar. Con JOIN normal desaparecen además los clientes 13, 14 y 15, que no han pedido nunca; con LEFT JOIN aparecerían con NULL en las dos últimas columnas, que es la respuesta honesta.

Solución 3

1. EXTRACT(MONTH …) devuelve 3 tanto para marzo de 2025 como para marzo de 2026, así que mide estacionalidad, no evolución: agrupa todos los marzos de la historia. Con los datos de TiendaVerde la conclusión es frágil porque solo hay un marzo con datos y doce meses de historia, de modo que cada "mes del año" tiene entre uno y dos pedidos. Con 20 pedidos en 12 meses no hay estacionalidad que medir: hay ruido.

2. La serie temporal es la consulta de la sección 5, y su lectura es la contraria: meses buenos y malos alternos, máximo en octubre de 2025 (97,20 €) y mínimo en noviembre (31,70 €), sin tendencia clara.

3. Sería correcta si la pregunta fuera de verdad estacional —"¿en qué mes del año vendemos más, promediando varios años?"— y hubiera suficientes años para promediar. Lo incorrecto no es la función: es usarla para responder a una pregunta de evolución.

Ya sabes trabajar con el tiempo:

• Conoces los cinco tipos temporales y por qué TiendaVerde usa DATE, con la recomendación firme de que en una aplicación real TIMESTAMPTZ es casi siempre la elección correcta. Y distingues NOW() —congelada durante toda la transacción— de CLOCK_TIMESTAMP().
• Haces aritmética de fechas sabiendo que date - date da días enteros, que date + INTERVAL da TIMESTAMP y que INTERVAL '1 month' no son 30 días. Y usas AGE() cuando el destinatario es una persona.
• Sacas componentes con EXTRACT (DOW empieza en domingo, WEEK es ISO) y truncas con DATE_TRUNC, que convierte 20 pedidos en una serie mensual — la deuda de 04-05, saldada. Y sabes cuándo usar cada uno: EXTRACT para estacionalidad, DATE_TRUNC para evolución.
• Formateas con TO_CHAR (incluido TMMonth con lc_time) y analizas con TO_DATE, recordando que '03/04/2025' son dos fechas distintas y que ordenar texto no es ordenar fechas.
• Construyes informes sin huecos con generate_series + LEFT JOIN + COUNT(columna), y has visto lo que escondían: cinco meses seguidos sin una sola alta de cliente.

Queda un cabo suelto que has visto tres veces en esta lección y no has podido atar: en el informe de altas por mes hizo falta COUNT(c.id) en lugar de COUNT(*) para que saliera 0; en el de facturación mensual hizo falta un COALESCE para que un mes vacío no mostrara NULL; y en el listado de clientes sin pedidos, las columnas de fecha aparecerían vacías sin decir por qué. Los tres son el mismo problema —qué hacer cuando no hay valor— y la lección siguiente, conversión de tipos y manejo de NULL, lo resuelve definitivamente con CAST, COALESCE y NULLIF. Además cerrará otra cuenta pendiente: has estado escribiendo ::DATE, ::NUMERIC y ::TEXT durante tres lecciones sin que nadie te explicara qué son.