Fechas y zonas horarias en PySpark: conversiones sin errores en Microsoft Fabric

En cualquier arquitectura de datos profesional, la gestión del tiempo es uno de los puntos donde más errores se cometen. No hablo de errores sintácticos que detienen la ejecución, sino de errores lógicos: datos que se desplazan una hora arriba o abajo, ventas que caen en el día anterior al consolidar globalmente o informes de energía con duplicados durante el cambio de hora en octubre. En Microsoft Fabric, donde PySpark es el motor principal para el procesamiento masivo, entender cómo Spark maneja los timestamps es crítico para mantener la integridad de los datos.

El problema fundamental reside en que una fecha no es solo un valor; es un punto en el tiempo que depende de un contexto geográfico. Cuando trabajamos con Microsoft Fabric, los datos suelen viajar desde fuentes locales (un ERP en España, sensores en Texas o logs de servidores en UTC) hacia un Lakehouse. Si no establecemos una política clara de zonas horarias desde la ingesta, acabaremos con un problema de linaje imposible de resolver mediante parches en DAX.

En este artículo abordaremos cómo configurar tu entorno de Spark para que las conversiones sean predecibles, las diferencias entre los tipos de datos de tiempo disponibles y cómo manejar el siempre problemático horario de verano (DST) sin perder el rendimiento del clúster.

Timestamp frente a Date: ¿Cuándo usar cada uno?

Parece una decisión trivial, pero elegir entre DateType y TimestampType define la granularidad y la complejidad de tu modelo. Un campo de tipo fecha (Date) solo almacena año, mes y día. Spark lo trata internamente como el número de días transcurridos desde la época Unix (1 de enero de 1970). No tiene zona horaria asociada y, por tanto, es inmune a los desplazamientos horarios. Es ideal para dimensiones de calendario y tablas de hechos donde la hora exacta no aporta valor analítico.

El TimestampType, por el contrario, incluye microsegundos y está intrínsecamente ligado a la zona horaria de la sesión de Spark. Aquí es donde empiezan los problemas. Si guardas un timestamp en un archivo Parquet, Spark lo convierte a UTC internamente. Al leerlo, lo convertirá de nuevo a la zona horaria que tenga configurada la sesión que realiza la lectura. Si el ingeniero que cargó los datos estaba en ‘Europe/Madrid’ y el analista que los consulta tiene la sesión en ‘UTC’, las horas no coincidirán.

Recientemente, con Spark 3.4 (disponible en los entornos modernos de Fabric), ha aparecido el TimestampNTZType (No Time Zone). Este tipo de dato almacena el tiempo tal cual, ignorando cualquier configuración de zona horaria. Es la solución perfecta para logs de aplicaciones donde la hora local es lo único que importa y no queremos que Spark intente ser «inteligente» moviendo las horas.

Configuración de la zona horaria de la sesión

Antes de ejecutar cualquier transformación en un Notebook de Fabric, debes definir tu zona horaria de referencia. La recomendación de oro en arquitectura de datos es: trabaja siempre en UTC dentro del Lakehouse. La conversión a hora local debe ocurrir solo en la capa de visualización o en una capa Gold muy específica para el negocio. Para asegurar que tu sesión de PySpark es consistente, utiliza el siguiente código al inicio de tus procesos:

# Configurar la zona horaria de la sesión a UTC
spark.conf.set("spark.sql.session.timeZone", "UTC")

# Verificar la configuración actual
tz = spark.conf.get("spark.sql.session.timeZone")
print(f"Zona horaria actual de la sesión: {tz}")

# Ejemplo de creación de DataFrame con fechas
from pyspark.sql import functions as F

data = [("Venta_001", "2024-03-20 10:30:00"), ("Venta_002", "2024-10-27 02:30:00")]
df_ventas = spark.createDataFrame(data, ["ID_Venta", "Fecha_String"])

# Convertir string a timestamp asumiendo que la entrada es UTC
df_final = df_ventas.withColumn(
 "Fecha_Evento", 
 F.to_timestamp("Fecha_String")
)
df_final.show()

Si no estableces spark.sql.session.timeZone, Spark tomará por defecto la zona horaria del clúster o del sistema operativo, lo cual es peligroso en entornos de nube como Fabric donde los nodos pueden estar en regiones distintas o configurados de forma genérica. Al igual que ocurre al configurar la Seguridad en Microsoft Fabric, la consistencia en la configuración base ahorra horas de depuración técnica posterior.

El desafío del horario de verano (DST)

El cambio de hora estival es el enemigo número uno de los procesos de agregación. En España, en marzo perdemos una hora (a las 02:00 son las 03:00) y en octubre ganamos una (a las 03:00 vuelven a ser las 02:00). Si tus procesos ETL suman unidades vendidas por hora, el último domingo de octubre podrías tener duplicidad de datos si no manejas correctamente los offsets.

Para evitarlo, utiliza las funciones from_utc_timestamp y to_utc_timestamp. Estas funciones no solo suman o restan horas; consultan la base de datos de zonas horarias (TZDB) para aplicar el desplazamiento correcto según la fecha específica del registro. Esto es vital para proyectos en sectores como energía o industria, donde la precisión horaria define el coste de la materia prima.

# Supongamos que tenemos datos en UTC y queremos ver la hora local en Madrid
# teniendo en cuenta si es horario de verano o de invierno automáticamente.

df_local = df_final.withColumn(
 "Fecha_Madrid", 
 F.from_utc_timestamp(F.col("Fecha_Evento"), "Europe/Madrid")
)

# Si necesitamos devolver una hora local a UTC para guardarla de forma estándar
df_standard = df_local.withColumn(
 "Fecha_UTC_Normalizada", 
 F.to_utc_timestamp(F.col("Fecha_Madrid"), "Europe/Madrid")
)

Este enfoque es mucho más robusto que hacer un simple F.col("Fecha") + F.expr("INTERVAL 1 HOURS"). Al igual que cuando creamos Columnas condicionales y personalizadas en Power Query, delegar la lógica de negocio compleja (como el calendario de cambios de hora) en funciones nativas del motor es siempre la mejor opción para evitar errores de cálculo manual.

Rendimiento y tipos de datos en el Warehouse de Fabric

Cuando movemos datos desde un Lakehouse (archivos Parquet/Delta) hacia el SQL Analytics Endpoint o el Warehouse de Fabric, el motor de SQL debe interpretar esos tipos de datos. Spark y el motor de SQL de Fabric no siempre se comunican de forma idéntica respecto a los metadatos de tiempo. Si has realizado Pruebas de rendimiento en Fabric Warehouse, habrás notado que las consultas sobre columnas de tipo fecha son significativamente más rápidas si el tipo de datos está bien definido en la capa de almacenamiento.

Un error común es ingerir fechas como StringType y convertirlas al vuelo en cada consulta de Power BI. Esto destruye el rendimiento del informe. La conversión debe hacerse en el proceso de ingeniería de datos (PySpark) y persistirse como TimestampType o DateType. Si tu origen de datos es caótico, considera usar una tabla intermedia (Bronze) y realizar la limpieza de tipos antes de pasar a la capa Silver.

Errores frecuentes que he visto en proyectos reales

• Confiar en el formato de fecha del sistema: Muchos consultores asumen que ‘YYYY-MM-DD’ es universal, pero al procesar archivos CSV sin esquema definido, Spark puede interpretar mal meses y días si el locale no es el adecuado.
• Mezclar zonas horarias en la misma columna: He visto tablas de ventas donde algunos registros están en UTC y otros en hora local de la sucursal. Esto es un error crítico. Si no puedes normalizar a UTC, añade una columna extra con el offset o el nombre de la zona horaria original.
• No considerar el cambio de día al convertir: Una venta a las 23:30 en Madrid el día 10 de junio, es en realidad el día 11 de junio en UTC. Si el informe financiero se basa en la fecha UTC pero el negocio espera fecha local, las cifras no cuadrarán.
• Uso incorrecto de Unix Timestamps: Spark usa microsegundos por defecto en versiones recientes, mientras que muchos sistemas antiguos usan segundos. Un error de factor 1000 es muy común.

Recuerda que, al igual que al Unir y anexar consultas en Power Query, la forma en que estructuras los datos antes de la unión determina si el motor puede optimizar la operación (pushdown) o si tiene que cargar todo en memoria para resolver la discrepancia de tipos.

Conclusión y Checklist de implementación

Gestionar fechas en PySpark dentro de Microsoft Fabric no se trata de conocer todas las funciones, sino de establecer un estándar. La mayoría de los problemas de inconsistencia de datos que resolvemos en consultoría se habrían evitado con una política de «Solo UTC en el Lakehouse». Para asegurar el éxito en tu próxima implementación técnica, te recomiendo seguir este checklist:

• Establecer explícitamente spark.sql.session.timeZone a ‘UTC’ al inicio de cada notebook de producción.
• Usar TimestampNTZType para datos donde el desplazamiento horario no tenga sentido analítico (logs internos).
• Realizar todas las conversiones de zona horaria utilizando from_utc_timestamp para respetar el horario de verano.
• Validar que los tipos de datos en las tablas Delta coincidan con los esperados por el motor de Warehouse para evitar conversiones implícitas costosas.
• Asegurar que los procesos de carga (Ingestión) no alteren la fecha original si no es estrictamente necesario para la normalización.

Si sigues estas pautas, estarás preparado para manejar despliegues complejos como los comentados en la guía sobre Fabric September 2026, donde la optimización de modelos en producción es el eje central del éxito del proyecto.

Preguntas frecuentes

¿Por qué mis fechas cambian al mover datos entre Lakehouse y Warehouse?

Esto ocurre porque el SQL Analytics Endpoint del Lakehouse puede estar interpretando el TimestampType de Parquet aplicando la zona horaria del cliente (tu navegador o SQL Management Studio), mientras que los datos fueron escritos en UTC. Asegúrate de consultar siempre bajo la misma zona horaria de sesión.

¿Es mejor usar TimestampType o StringType para la ingesta de archivos CSV?

Siempre StringType inicialmente para evitar que Spark asuma formatos incorrectos durante la inferencia de esquema. Una vez cargado el DataFrame, aplica to_timestamp con el formato explícito (ej. ‘dd/MM/yyyy HH:mm:ss’) para asegurar una conversión precisa y controlada.

¿Cómo afecta la zona horaria a las funciones de agregación como sum() o count()?

No afecta al valor numérico en sí, pero sí afecta a la agrupación (GROUP BY). Si agrupas por una columna de fecha que se ha desplazado de día por un cambio de zona horaria, tus totales diarios serán incorrectos respecto a lo que espera el negocio local.