Dimanche avait une heure de plus en Suisse. Cela compte pour comparer le trafic quotidien, pas seulement pour régler une horloge.
Le 25 octobre 2026, les horloges suisses sont revenues de 03:00 à 02:00. La journée civile locale a duré 25 heures écoulées. Un rapport portant sur cette date en UTC couvrait une autre fenêtre. Les deux définitions peuvent être valides sans produire les mêmes totaux.
Avant de qualifier une hausse quotidienne de croissance, vérifiez ce que signifie une journée dans le rapport.
Une date peut désigner deux fenêtres différentes
La date 2026-10-25 ne définit pas à elle seule une période complète. Il lui faut un fuseau horaire et des bornes.
Pour une journée métier en Europe/Zurich, partez de minuit local et terminez au minuit local suivant. Convertissez ces deux instants en UTC. Le décalage change pendant cet intervalle précis, qui ne dure donc pas 24 heures.
| Définition du rapport | Début UTC, inclus | Fin UTC, exclue | Heures écoulées |
|---|---|---|---|
| 25 octobre en Europe/Zurich | 2026-10-24 22:00 | 2026-10-25 23:00 | 25 |
| 25 octobre en UTC | 2026-10-25 00:00 | 2026-10-26 00:00 | 24 |
Un événement hypothétique à 2026-10-24T22:30:00Z appartient au 25 octobre à Zurich et au 24 octobre en UTC. L’événement n’a pas changé. La borne du rapport, si.
Le changement suisse est confirmé par le communiqué de METAS. Le tableau est un exemple calculé de bornes de rapport, pas du trafic client mesuré.
Calculer les bornes avant la durée
Pour une journée civile locale, construisez minuit à la date choisie et minuit le lendemain dans le même fuseau nommé. Convertissez les deux en UTC, puis soustrayez-les pour mesurer le temps écoulé. Ne remplacez pas la seconde borne par la première plus 86 400 secondes.
Cet exemple Python utilise zoneinfo et les données IANA disponibles sur la machine. Il nécessite Python 3.9 ou plus récent et des données de fuseaux installées. Si elles manquent, installez le paquet officiel tzdata plutôt que de substituer un décalage UTC fixe. La documentation Python décrit cette dépendance.
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()}")
La sortie est la suivante :
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 soustraction intervient volontairement après conversion en UTC. Les règles de soustraction datetime de Python utilisent une arithmétique d’heure locale lorsque deux objets conscients du fuseau partagent le même objet tzinfo. Ce n’est pas le calcul de temps écoulé présenté ici.
Les deux valeurs de fold désignent deux occurrences distinctes de 02:30 pendant l’heure répétée. Un libellé contenant seulement l’heure locale ne les distingue pas. Conservez l’instant réel de l’événement et affichez un décalage ou un autre identifiant non ambigu quand ces répétitions comptent.
C’est un calcul local. Il n’envoie aucune requête analytics, ne modifie aucun réglage de compte et ne démontre pas un sélecteur de fuseau dans un produit.
Distinguer journée civile et dernières 24 heures
Hier à Zurich et les dernières 24 heures répondent à des questions différentes. La première expression suit les bornes du calendrier d’une région nommée. La seconde décrit une durée écoulée se terminant à un instant.
Le rapport de la journée en cours est encore différent : il peut être partiel. Comparer aujourd’hui à 10:00 à toute la journée d’hier ajoute une différence d’exposition, même sans changement d’heure.
Conservez fuseau, début, fin et règle de regroupement avec un export ou une comparaison. Un libellé d’affichage ne suffit pas. Si un graphique affiche des heures locales, examinez sa représentation de l’heure répétée au lieu de supposer que 24 libellés visibles correspondent à 24 heures écoulées.
Pour une journée métier dans une autre région, calculez les bornes de cette région. Ne réutilisez pas les décalages de Zurich ailleurs et ne codez pas une variation d’une heure comme règle universelle.
Plus de temps peut produire plus d’événements sans taux plus élevé
Supposons qu’un système hypothétique enregistre exactement 10 événements par heure écoulée. Une fenêtre de 24 heures contient 240 événements ; une fenêtre de 25 heures en contient 250. Le total augmente d’environ 4,17 pour cent, mais le rythme horaire ne change pas.
C’est un calcul, pas une prévision du trafic réel. Les visites ne suivent pas un rythme constant. Jour de la semaine, campagnes et composition du public restent importants. Diviser par les heures peut aider à étudier l’intensité des événements, sans rendre automatiquement deux journées comparables.
Toutes les métriques ne doivent pas non plus être normalisées par les heures. Les visiteurs uniques ne sont pas un compteur additif d’événements. Un taux de conversion demande une population éligible et une fenêtre d’observation clairement définies, pas simplement une division supplémentaire par la durée du jour. Le dénominateur peut changer l’interprétation, même si le pourcentage affiché semble simple.
Présentez total et exposition lorsque cette distinction influence la décision. Séparez visiblement les exemples hypothétiques des résultats mesurés.
Intégrer la borne à la comparaison
Pour une nouvelle requête, un intervalle semi-ouvert est une convention utile : inclure les événements au début et exclure ceux à la borne suivante. Autrement dit, timestamp >= start AND timestamp < end. Deux intervalles adjacents partagent ainsi une borne sans compter deux fois l’événement qui s’y trouve.
Ne modifiez pas silencieusement le contrat d’un rapport existant pour adopter cette convention. Lors d’un rapprochement d’exports, vérifiez l’inclusion réelle de la fin, la précision des horodatages, les filtres, le traitement et l’unité de comptage. Une même date écrite ne prouve pas que ces règles concordent.
Un jeu de tests pratique comprend une journée locale ordinaire, les transitions de printemps et d’automne, un événement exactement à chaque borne et les deux occurrences d’une heure locale répétée. Conservez les instants UTC attendus à côté du test.
Le but n’est pas d’imposer un seul fuseau à tous les tableaux de bord. UTC peut être la bonne base opérationnelle ; la journée locale, la bonne base métier. Nommez celle que vous utilisez et comparez des fenêtres concordantes avant d’interpréter leur différence comme de la croissance.
