El domingo tuvo una hora extra en Suiza. Eso importa al comparar el tráfico diario, no solo al cambiar un reloj.
El 25 de octubre de 2026, los relojes suizos pasaron de las 03:00 a las 02:00. El día natural local duró 25 horas transcurridas. Un informe de esa fecha en UTC cubría otra ventana. Ambas definiciones pueden ser válidas sin que sus totales coincidan.
Antes de llamar crecimiento a un aumento diario, comprueba qué significa un día en el informe.
Una fecha puede describir dos ventanas distintas
La fecha 2026-10-25 no define un intervalo completo. Necesita una zona horaria y unos límites.
Para un día de negocio en Europe/Zurich, empieza a medianoche local y termina a la medianoche local siguiente. Convierte ambos instantes a UTC. El desplazamiento cambia dentro de este intervalo concreto, por lo que no dura 24 horas.
| Definición del informe | Inicio UTC, incluido | Fin UTC, excluido | Horas transcurridas |
|---|---|---|---|
| 25 de octubre en Europe/Zurich | 2026-10-24 22:00 | 2026-10-25 23:00 | 25 |
| 25 de octubre en UTC | 2026-10-25 00:00 | 2026-10-26 00:00 | 24 |
Un evento hipotético a las 2026-10-24T22:30:00Z pertenece al 25 de octubre en Zúrich y al 24 de octubre en UTC. El evento no cambió. El límite del informe sí.
El cambio suizo está confirmado en el comunicado de METAS. La tabla es un ejemplo calculado de límites, no tráfico medido de clientes.
Calcula los límites antes que la duración
Para un día natural local, construye la medianoche de la fecha elegida y la medianoche del día siguiente en la misma zona horaria con nombre. Convierte ambas a UTC y después réstalas para medir el tiempo transcurrido. No sustituyas el segundo límite por el primero más 86.400 segundos.
Este ejemplo de Python usa zoneinfo y los datos de zonas IANA disponibles en el ordenador. Requiere Python 3.9 o posterior y datos de zona horaria instalados. Si faltan, instala el paquete oficial tzdata en vez de sustituirlos por un desplazamiento UTC fijo. La documentación de Python explica esa dependencia.
from datetime import date, datetime, time, timedelta, timezone
from zoneinfo import ZoneInfo
zone = ZoneInfo("Europe/Zurich")
utc = timezone.utc
for day in (date(2026, 3, 29), date(2026, 10, 24), date(2026, 10, 25)):
start = datetime.combine(day, time.min, tzinfo=zone)
end = datetime.combine(day + timedelta(days=1), time.min, tzinfo=zone)
start_utc = start.astimezone(utc)
end_utc = end.astimezone(utc)
hours = (end_utc - start_utc).total_seconds() / 3600
print(f"{day}: {hours:g}h | {start_utc.isoformat()} to {end_utc.isoformat()}")
for fold in (0, 1):
local = datetime(2026, 10, 25, 2, 30, tzinfo=zone, fold=fold)
print(f"02:30 fold={fold}: {local.astimezone(utc).isoformat()}")
El resultado es:
2026-03-29: 23h | 2026-03-28T23:00:00+00:00 to 2026-03-29T22:00:00+00:00
2026-10-24: 24h | 2026-10-23T22:00:00+00:00 to 2026-10-24T22:00:00+00:00
2026-10-25: 25h | 2026-10-24T22:00:00+00:00 to 2026-10-25T23:00:00+00:00
02:30 fold=0: 2026-10-25T00:30:00+00:00
02:30 fold=1: 2026-10-25T01:30:00+00:00
La resta se realiza deliberadamente después de convertir a UTC. Las reglas de resta de datetime en Python usan aritmética de hora local cuando dos objetos conscientes de la zona comparten el mismo objeto tzinfo. Eso no es el cálculo de tiempo transcurrido que se muestra aquí.
Los dos valores de fold identifican apariciones distintas de las 02:30 durante la hora repetida. Una etiqueta que contenga solo la hora local no las distingue. Conserva el instante real del evento y muestra el desplazamiento u otro identificador inequívoco cuando esas repeticiones importen.
Es un cálculo local. No envía solicitudes de analytics, no cambia configuraciones de cuentas ni demuestra un selector de zona horaria de un producto.
Separa un día natural de las últimas 24 horas
Ayer en Zúrich y las últimas 24 horas responden a preguntas distintas. La primera expresión sigue los límites del calendario de una región concreta. La segunda es una duración transcurrida que termina en un instante.
El informe del día en curso es otro caso: puede estar incompleto. Comparar hoy a las 10:00 con todo el día de ayer añade una diferencia de exposición incluso sin cambio de hora.
Guarda la zona horaria, el inicio, el fin y el criterio de agrupación junto a una exportación o comparación. Una etiqueta visible no basta. Si un gráfico muestra horas locales, revisa cómo representa la hora repetida en vez de suponer que 24 etiquetas significan 24 horas transcurridas.
Para analizar un día de negocio en otra región, calcula sus propios límites. No traslades los desplazamientos de Zúrich a otro mercado ni fijes un cambio de una hora como regla universal.
Más tiempo puede producir más eventos sin una tasa mayor
Supongamos que un sistema hipotético registra exactamente 10 eventos por hora transcurrida. Una ventana de 24 horas contiene 240 eventos; una de 25 horas contiene 250. El total es aproximadamente un 4,17 por ciento mayor, aunque la tasa horaria no cambia.
Es aritmética, no una previsión de tráfico real. Las personas no visitan a un ritmo constante, y siguen importando el día de la semana, las campañas y la composición del público. Dividir por horas puede ayudar a estudiar la intensidad de eventos, pero no hace automáticamente comparables dos días.
Tampoco conviene normalizar cada métrica por horas. Los visitantes únicos no son un contador aditivo de eventos. Una tasa de conversión necesita una población elegible y una ventana de observación bien definidas, no simplemente otra división por la duración del día. El denominador puede cambiar la interpretación, aunque el porcentaje parezca sencillo.
Muestra el total y la exposición cuando la diferencia afecte a la decisión. Separa visiblemente los ejemplos hipotéticos de los resultados medidos.
Incluye los límites en la comparación
En una consulta nueva, un intervalo semiabierto es una convención útil: incluye los eventos del inicio y excluye los del siguiente límite. Es decir, timestamp >= start AND timestamp < end. Así, los intervalos adyacentes comparten un límite sin contar dos veces un evento situado exactamente en él.
No cambies en silencio el contrato de un informe existente para adoptar esta convención. Al conciliar exportaciones, comprueba la inclusión real del final, la precisión de las marcas de tiempo, los filtros, el estado de procesamiento y la unidad contada. La misma fecha escrita no demuestra que coincidan esas reglas.
Un conjunto de pruebas práctico incluye un día local normal, las transiciones de primavera y otoño, un evento exactamente en cada límite y las dos apariciones de una hora local repetida. Guarda junto a la prueba los instantes UTC esperados.
El objetivo no es imponer una única zona horaria a todos los paneles. UTC puede ser la base operativa adecuada; un día natural local, la base de negocio correcta. Indica cuál usas y compara ventanas equivalentes antes de interpretar una diferencia como crecimiento.
