Introducción
Dos veces al año, muchos países ajustan sus relojes para adoptar el horario de verano o volver al horario de invierno. Estos cambios generan días anómalos de 23 o 25 horas en lugar de las 24 habituales. Para modelos de datos en Power BI que analizan ventas u otras métricas desglosadas por horas, el horario de verano o invierno puede introducir complejidades importantes.
En primavera se “salta” una hora de la madrugada y, en otoño, una hora se repite. Si esto no se maneja correctamente, puede afectar a la calidad de los datos y a la precisión de los informes. A continuación, se describen los posibles problemas y se proponen buenas prácticas para mitigar sus efectos, incluyendo la gestión adecuada de zonas horarias, el uso de UTC y la configuración de los datos en Power Query.
En particular, en entornos donde la granularidad de la información está desglosada por hora, como puede suceder en análisis de ventas, métricas de uso o cualquier serie temporal que requiera precisión horaria, es fundamental anticipar los efectos que surgen de estos días atípicos en que el reloj “salta” hacia adelante y elimina una hora, o bien “retrocede” y la repite.
En Power BI, al modelar datos con desglose horario, es común trabajar con tablas de hechos que contienen registros marcados con fechas y horas. También es habitual contar con una tabla de calendario o dimensión de tiempo para segmentar esas ventas o eventos a lo largo del día. Cuando llega el día del cambio de hora, se pueden generar huecos (si el día dura 23 horas) o duplicaciones (si ese día dura 25). Esta alteración de la cronología estándar de 24 horas puede desordenar la línea temporal, producir errores de clave duplicada y afectar las agregaciones.
Efectos del cambio de hora en datos horarios
El cambio de hora altera la secuencia habitual de las horas de un día. Al adelantar el reloj en primavera, ese día tendrá 23 horas (una menos), mientras que al retrasarlo en otoño tendrá 25 (una duplicada). Esto genera varias situaciones:
- Duplicación de datos. En otoño, al retrasar el reloj, la franja horaria (por ejemplo, las 2:00 a.m.) ocurre dos veces. Si las ventas están registradas en hora local, pueden producirse marcas de tiempo idénticas (misma fecha y hora local) para dos transacciones distintas. Esto puede romper claves únicas o relaciones en Power BI si se pretendía usar esa columna como clave “uno” en el modelo.
- Huecos en la línea temporal. En primavera se suprime una hora (por ejemplo, de 2:00 a 3:00), de modo que ese día solo tiene 23 horas registradas. Puede parecer que faltan datos cuando en realidad esa hora simplemente no existió a efectos de hora local.
- Desfase en franjas horarias. Un suceso a la misma hora UTC puede quedar reflejado con horas locales distintas según la época del año. Al comparar periodos, es posible alinear incorrectamente ventas u otros eventos si no se tiene en cuenta la zona horaria y el cambio de hora.
- Agregaciones por hora o día incorrectas. Un día de 25 horas puede mostrar un total de ventas más alto de lo esperado y uno de 23 horas, uno más bajo. Además, en cálculos de promedios por hora, surge la duda de cómo tratar la hora duplicada o la que está ausente.
- Anomalías en visualizaciones. En gráficos por hora, el día del cambio puede presentar saltos o superposiciones: falta la franja en primavera o aparece dos veces en otoño. Si la etiqueta horaria se trata como una simple categoría (por ejemplo, “2:00”), es posible que dos horas reales distintas se sumen en la misma etiqueta en otoño, provocando confusiones.
Zonas horarias y diferencias según el origen de los datos
Cada origen de datos puede tratar las marcas de tiempo de forma distinta:
Bases de datos (SQL Server u otros)
Pueden almacenar la fecha en UTC, en hora local o con información de desfase. Si las fechas se guardan en UTC, no habrá duplicaciones por cambio de hora en la propia base; el problema surge al representar la información en hora local. Si se almacenan en hora local, puede haber duplicados el día del cambio de invierno.
Archivos Excel/CSV
Normalmente contienen fechas/horas sin información de zona horaria. Al importarlos, si esos datos se crearon bajo un horario local, pueden producirse duplicados en otoño o ausencias en primavera.
APIs y servicios web
Suelen devolver marcas de tiempo en formatos estándares (por ejemplo, con la terminación “Z” que indica UTC). Power BI Desktop a menudo convierte automáticamente esos valores a la zona local de la máquina de desarrollo. Esto puede generar un desfase si se mezcla con otras fuentes que ya estaban en local o se deseaba mantener todo en UTC.
Power BI Desktop vs Power BI Service
El servicio en la nube trabaja internamente en UTC, de modo que funciones como NOW() o TODAY() se evalúan en UTC al publicarse el informe. Sin un ajuste explícito, pueden darse desfases entre lo que se ve en el entorno Desktop (hora local) y lo que se ve en el Servicio (UTC). Las funciones DAX como NOW() y TODAY() devuelven la hora UTC en Power BI Service, lo que puede provocar diferencias respecto a Power BI Desktop, donde se evalúan según la hora local del equipo.
Para evitar inconsistencias, es importante ser explícito y coherente en el manejo de zonas horarias antes de unificar los datos en Power BI.
Buenas prácticas para evitar problemas de horario de verano/invierno en Power BI
Unificar la zona horaria de los datos (preferiblemente UTC)
Lo más recomendable es convertir todas las marcas de tiempo a UTC antes de analizarlas. En UTC no existe el cambio de hora, por lo que cada día cuenta siempre con 24 horas exactas. Una vez unificados todos los registros en UTC, se pueden hacer comparaciones y agregaciones sin el riesgo de duplicaciones o “horas perdidas”. Si se necesita mostrar la hora local, se hace la conversión al final, en la capa de presentación o en columnas/medidas adicionales.
Mantener, si es necesario, hora local y hora UTC
En ciertos escenarios, conviene guardar dos versiones del tiempo: una en UTC (para los cálculos) y otra en hora local (para presentaciones o análisis concretos). De esta manera, se conservan los datos sin ambigüedad, pero se facilita al usuario la lectura de la hora “civil”. Eso sí, manejar ambas versiones requiere mayor control para que siempre estén alineadas.
Realizar las conversiones de zona horaria en Power Query de forma controlada
Power Query dispone de funciones para etiquetar y cambiar zonas horarias. Se pueden anclar timestamps ingenuos (sin zona) a un offset determinado o convertir entre UTC y la hora local mediante funciones como DateTime.AddZone o DateTimeZone.SwitchZone.
Se recomienda especificar el offset de manera manual o con tablas auxiliares para reflejar con precisión cuándo empieza y acaba el horario de verano. Evita DateTimeZone.ToLocal si vas a publicar el informe, ya que depende de la configuración regional del entorno donde se ejecuta (Power BI Desktop o Power BI Service) y puede devolver resultados distintos según el país o la hora local del servidor.
En casos más complejos, se pueden usar tablas de conversión que indiquen el desfase horario por rangos de fechas, facilitando el mantenimiento para varios años y zonas geográficas. También existe la posibilidad de eliminar la zona en el momento de la ingesta si se desea conservar la hora UTC exacta sin conversiones automáticas.
Manejar las horas duplicadas y ausentes en el modelo de datos
Aunque se trabaje internamente en UTC, puede interesar mostrar o analizar los datos en hora local. En ese caso, hay que considerar:
- Distinguir la hora duplicada de otoño. Conviene disponer de un identificador que permita diferenciar la misma hora (por ejemplo, las 2:00 a.m.) en sus dos versiones. Una opción es concatenar la hora con un indicador adicional, como “(verano)” y “(invierno)” o el offset que corresponda.
- Evitar suponer siempre 24 horas en una tabla de tiempo. Un día puede tener 23, 24 o 25 horas según la fecha. Si se crea una tabla de horas rígida (24 filas por día), es posible que no represente bien la realidad de ciertos días. Hay diseños que permiten incluir esas variaciones, pero requieren una planificación más elaborada.
- Verificar totales diarios. No se debe “ajustar” o forzar a 24 horas un día que realmente tuvo 25 o 23, ya que los valores de ventas o métricas variarían artificiosamente. Lo ideal es dejar reflejado que los totales son mayores o menores según haya habido una hora extra o una hora menos.
- Alinear las medidas DAX. Al calcular promedios horarios u otras métricas, definir cómo se tratará la hora duplicada y la ausente. Cada caso de uso puede requerir una política distinta: excluir la hora repetida, contarla por separado, etc.
Ejemplo de ajuste de zona horaria con columnas calculadas y medidas
Imaginemos que se almacena todo en UTC en una columna FechaHoraUTC y se desea ver los datos en hora local de España peninsular. Podríamos:
- Incluir en una tabla de fechas una columna con el desfase horario aplicable según cada día (por ejemplo, +1 para invierno y +2 para verano).
- Crear en la tabla de hechos una columna calculada de hora local haciendo algo como:
FechaHoraLocal = Ventas[FechaHoraUTC] + (DimDate[OffsetHoras] / 24)Aquí, OffsetHoras se obtiene según la fecha, de modo que se sume la hora adicional solo en periodos de verano. Así, cada registro se mostrará con la hora civil correspondiente, pero internamente hemos conservado el orden cronológico estable de UTC para evitar duplicaciones.
Ejemplo práctico de tratamiento de la hora duplicada
Imaginemos una empresa de ventas en una zona que sigue la regla de adelantar el reloj en la última semana de marzo y retrasarlo en la última de octubre. Para recoger y analizar las ventas por hora en Power BI, la empresa decide crear una tabla de calendario con una fila por cada combinación de fecha y hora, de modo que haya 24 filas por cada día del año.
Sin embargo, en el día de marzo en que se adelanta la hora, la tabla no coincide con la realidad, porque ese día solo tuvo 23 horas locales. Y en el de octubre en que se retrasa, harían falta 25 filas para representar correctamente todas las horas que tuvieron lugar.
Si la tabla de calendario siempre forza 24 filas, se pierden la hora extra en otoño y se añade una hora ficticia en primavera. Esto provoca que los registros de ventas tengan referencias horarias no válidas. Para solventarlo, se podría generar una tabla de calendario que, en lugar de 24 filas diarias fijas, se alimente de una lógica que determine cuántas horas reales hubo cada día.
Así, el día de octubre con 25 horas se representaría con 25 filas, y el de marzo con 23. Este planteamiento supone un incremento en la complejidad, ya que se debe programar la detección de la fecha concreta del cambio de hora y cuántas horas se deben generar. Además, en los informes, el desarrollador deberá ser consciente de por qué un día muestra una fila más o una menos.
Otra estrategia es abandonar la tabla de calendario a nivel de hora y confiar en la tabla de hechos para obtener el desglose horario, a la vez que se conserva un ID interno único, como una marca en UTC. Por ejemplo, se podría tener la columna FechaHoraUTC con un ID que nunca se repite, y luego disponer de una columna FechaHoraLocal que sí puede contener duplicados en otoño.
Al representar el dato, se haría un recuento por la columna UTC, pero se mostraría la etiqueta de la hora local. Si se necesita diferenciar la hora duplicada en otoño, se añadirá un campo extra (por ejemplo, un sufijo o un offset). El resto de los días no usarán esa diferenciación. Esta aproximación facilita no romper la integridad del modelo, puesto que la clave en UTC siempre es única.
Tratamiento de agregaciones y medidas DAX
El cambio de hora no se reduce únicamente a gestionar duplicaciones o ausencias en la tabla de hechos. También influye en cómo se calculan ciertas medidas, sobre todo si se hacen promedios por hora.
Supongamos que se calcula la media de ventas por franja horaria y se desea obtener un valor representativo. ¿Se duplican las ventas de las 2:00 en otoño o se promedian a la mitad? Cada organización puede requerir criterios distintos. Algunas preferirán que las dos horas localmente idénticas se consideren por separado, pues son eventos reales en tiempos distintos; otras, que se unifiquen. Con la hora ausente en primavera también se plantea un dilema: un promedio que incluya un día sin esa franja puede marcar un descenso artificioso.
En DAX, una forma de solventar esto consiste en añadir banderas que identifiquen si una hora corresponde al tramo repetido o si es la hora inexistente en primavera. Dependiendo de la medida, se puede filtrar esa hora o tratarla de manera especial.
Por ejemplo, si se hace un recuento de transacciones, se pueden sumar ambas horas de otoño, pero si se busca un promedio por hora, tal vez se decida excluir una de ellas. Nada de esto se hace de manera automática; el modelador debe explicitar la lógica en las medidas, alineando la decisión con la política de negocio.
En los casos de informes que muestren datos diarios en lugar de horarios, la problemática se reduce un poco, pero sigue existiendo un día con 25 registros y uno con 23. Un directivo o analista que compare los totales diarios podría cuestionar por qué un día parece dispararse la cifra de ventas y al siguiente caer.
En realidad, no hay un error: el día con 25 horas tuvo, sencillamente, una hora extra para vender. Este hecho se vuelve irrelevante si se observan períodos más amplios, como la semana completa, pero puede ser un detalle importante en informes diarios. Conviene, por tanto, etiquetar o anotar el día del cambio para evitar malentendidos.
Conclusión
El cambio de hora puede complicar el análisis detallado de métricas por hora, pero es un desafío manejable si se planifica desde el diseño del modelo. Mantener consistencia en las zonas horarias (idealmente trabajando internamente con UTC), usar transformaciones controladas en Power Query y prever que algunos días pueden tener 23 o 25 horas son prácticas esenciales para que los informes no se vean afectados por duplicaciones o huecos temporales.
El objetivo no es “forzar” que todos los días tengan 24 horas, sino reflejar fielmente los datos y, si procede, mostrar la hora local exacta junto con su desfase. Con estos cuidados, la información seguirá siendo precisa incluso durante los cambios estacionales de hora en Power BI.
El cambio de hora no solo es un trámite estacional que altera la vida diaria, sino también un factor técnico significativo a la hora de diseñar y desplegar modelos de datos que operan con marcas temporales detalladas. En entornos donde las ventas, los accesos o cualquier métrica relevante se recopila a nivel de hora, se producen efectos como la duplicación de registros en otoño y la supresión de una hora en primavera.
Estos fenómenos pueden repercutir en la calidad y coherencia de los datos, pudiendo dañar la integridad del modelo de Power BI o distorsionar visualizaciones y medidas de negocio.
La clave para lidiar con este fenómeno reside en la coherencia: resulta fundamental documentar y homogenizar las zonas horarias de las distintas fuentes de datos. El uso de UTC como estándar suele ser la mejor estrategia para evitar incoherencias en el almacenaje, si bien puede ser necesario mantener una columna de hora local para propósitos analíticos o de presentación.
Power Query facilita el proceso de normalización a través de funciones de conversión de zona horaria, aunque es imprescindible definir correctamente los offsets para cada fecha. Además, al publicar en el servicio Power BI, se debe tener en cuenta que el entorno funciona en UTC y que las funciones DAX que obtienen la hora actual devolverán esa referencia horaria universal, y no la local del desarrollador.
Un modelo robusto ante el cambio de hora no se limita a evitar errores de duplicación, sino que también asume que existen días con 23 o 25 horas y muestra esos datos con transparencia, ya sea mediante anotaciones en los informes o marcadores específicos que identifiquen la hora duplicada. De ese modo, los usuarios comprenden por qué hay picos y valles en determinadas fechas, y no lo confunden con errores de recopilación. En este sentido, la comunicación clara a los usuarios es tan importante como la técnica para manipular los datos.
En definitiva, la gestión adecuada del cambio de hora en Power BI implica un conjunto de buenas prácticas que abarcan la ingesta y transformación de datos, la definición del modelo y la configuración de visualizaciones y medidas DAX. Aunque a primera vista puede parecer un problema menor, el no abordarlo convenientemente genera inconsistencias y confusiones que pueden minar la confianza en el informe.
Por el contrario, cuando se planifica desde el principio y se aplican las estrategias expuestas, se obtiene un modelo de datos sólido, capaz de integrarse con otras fuentes horarias y de ofrecer a los usuarios finales un análisis certero y exhaustivo, sin sorpresas en los días de cambio de hora. De esta manera, se consigue que la plataforma de reporting se mantenga alineada con la realidad temporal, reflejando con exactitud tanto los valores numéricos como la franja horaria real en la que acontecieron los sucesos, una condición esencial para el éxito de cualquier proyecto de inteligencia de negocio.
👉 Si te interesa profundizar en temas como este y mejorar tus habilidades en análisis y visualización de datos, te invito a seguir aprendiendo en namasdata.com, donde encontrarás formación práctica, actualizada y enfocada en el mundo real.
🧠 Además, puedes leer más artículos como este en formacionbi.com, el blog donde comparto ideas, consejos y buenas prácticas sobre Power BI, modelado de datos y certificaciones como la PL-300.
Deja un comentario