In de nacht van 24 op 25 oktober 2026 gaat de klok in België terug. Om 03.00 uur wordt het opnieuw 02.00 uur. Voor een wachtdienst lijkt dat een klein verschil, maar één lokaal uur komt daardoor tweemaal voor.
Dat hoeft geen probleem te zijn. Het is wel een goed moment om te controleren of alarmen, tijdstempels, wachtdienstplanning en overdracht dezelfde tijdslogica gebruiken. Zo blijft ook tijdens de uurwisseling duidelijk welke melding eerst kwam en welke actie erop volgde.
Eén lokaal uur, twee verschillende momenten
Volgens het Jaarboek 2026 van de Koninklijke Sterrenwacht van België begint de wintertijd op 25 oktober om 01.00 uur UTC. De correctie tegenover UTC verandert dan van twee uur naar één uur. In lokale tijd springt de klok daardoor van 03.00 uur terug naar 02.00 uur.
Een notitie als “alarm ontvangen om 02.17 uur” wijst die nacht dus niet vanzelf naar één uniek moment. Was dat vóór of na het terugzetten van de klok? Voor een operator, technieker of klant die later de tijdlijn leest, is dat onderscheid belangrijk.
Bewaar de originele tijdstempel en zijn context
Een inkomende melding kan een tijdstempel van het bronsysteem bevatten. Bewaar die waarde ongewijzigd naast het ontvangsttijdstip van uw eigen platform. Voeg waar mogelijk de tijdzone of UTC-offset toe, zodat het geregistreerde moment eenduidig blijft.
RFC 3339, een internetstandaard voor tijdstempels, koppelt een datum en tijd aan UTC of een numerieke offset. Dat maakt niet ieder systeem automatisch foutloos, maar het voorkomt dat een kaal lokaal tijdstip alle context moet dragen.
Controleer ook de wachtdienstplanning
Niet alleen technische logs gebruiken tijd. Ook een wachtdienst kan om een bepaald uur van technieker, team of regio wisselen. Leg daarom vooraf vast wie tijdens het herhaalde uur verantwoordelijk is en welk systeem daarbij leidend is.
Een eenvoudige controle volstaat vaak: staat de juiste persoon in de planning, kent de operator het wisselmoment en is er een fallback wanneer de eerste contactpersoon niet reageert? Zo voorkomt u dat twee plausibele interpretaties naast elkaar blijven bestaan.
Geplande regels verdienen een gerichte test
Automatische meldregels kunnen afhangen van een tijdsvenster: ’s nachts naar de wachtdienst, overdag naar de servicedesk, of na een bepaalde duur naar een tweede lijn. Controleer vóór de uurwisseling of de gebruikte tijdzone en planning bij elkaar passen.
Test daarbij niet alleen of een signaal binnenkomt. Kijk ook welke route wordt gekozen, hoe het tijdstip wordt weergegeven en wat er gebeurt wanneer dezelfde lokale kloktijd nogmaals voorkomt. Op de pagina over API- en HTTP(S)-monitoring leest u hoe technische meldingen aan menselijke controle en escalatie kunnen worden gekoppeld.
Fictief voorbeeld: tweemaal 02.17 uur
Een fictief alarmsysteem stuurt om 02.17 uur lokale zomertijd een waarschuwing. De operator registreert ontvangst, controleert de bron en activeert volgens afspraak de eerste wachttechnieker. Na de klokwissel komt opnieuw een melding binnen die lokaal eveneens 02.17 uur toont.
Omdat beide meldingen hun oorspronkelijke bron-ID, tijdstempel en offset behouden, ziet de operator dat het om twee verschillende gebeurtenissen gaat. In dit fictieve protocol wordt de tweede melding niet automatisch weggefilterd als duplicaat. Tegelijk blijft in de tijdlijn zichtbaar wanneer elke oproep, reactie en overdracht plaatsvond.
Een dubbele melding is niet vanzelf hetzelfde incident
Monitoringplatformen kunnen herhaalde signalen groeperen op basis van bron, type of tijdsvenster. Tijdens het herhaalde uur verdient die logica extra aandacht. Twee dezelfde lokale tijdsaanduidingen bewijzen niet dat het om één melding gaat, maar evenmin dat er twee afzonderlijke storingen zijn.
De afgesproken kenmerken blijven leidend: bron-ID, installatie, meldingstype, unieke event-ID en technische tijdstempel. Een operator kan die informatie samenbrengen in één overzicht zonder oorspronkelijke signalen te wissen. Voor die aanpak vindt u een praktisch voorbeeld in Tien alarmmeldingen, één incident.
Maak ook de menselijke tijdlijn controleerbaar
De opvolging bestaat uit meer dan de oorspronkelijke melding. Noteer afzonderlijk wanneer de operator het signaal zag, wie werd gecontacteerd, wanneer iemand reageerde en wanneer de opdracht werd overgedragen. Gebruik daarbij dezelfde tijdsconventie of toon de offset consequent.
Dat helpt de collega die later overneemt en maakt de rapportage begrijpelijker. Het voorkomt ook formuleringen als “dat was rond de eerste of de tweede 02.30 uur”, die voor een incidentoverzicht weinig bruikbaar zijn.
Zeven controles vóór de klok teruggaat
Loop vóór de uurwisseling deze korte lijst na:
- controleer tijdzone en automatische klokinstelling van de gebruikte systemen;
- bewaar bron-ID, oorspronkelijke tijdstempel en eventuele UTC-offset;
- test de routering van minstens één melding in een nachtelijk tijdsvenster;
- bevestig wie tijdens het herhaalde uur wachtdienst heeft;
- leg vast welk signaal een succesvolle overdracht bevestigt;
- controleer de fallback wanneer de eerste contactpersoon niet reageert;
- voorzie een eenvoudige handmatige route wanneer een automatisering onverwacht reageert.
Deze controle past binnen een bredere aanpak voor kwaliteit en continuïteit. Niet elk systeem of iedere klantomgeving werkt hetzelfde; daarom worden koppelingen, tijdsvelden en fallback vooraf per werking bekeken.
Een rustige nacht begint vóór de uurwisseling
De omschakeling naar het winteruur is geen reden tot onrust. Ze is wel een concreet testmoment voor de afspraken achter uw alarmopvolging: hoe wordt tijd vastgelegd, wie heeft dienst, wanneer is een melding overgedragen en wat gebeurt er als een systeem anders reageert dan verwacht?
TeleDispatch kan meldingen aannemen, bronnen en tijdstempels registreren en de afgesproken wachtdienst activeren. Op onze pagina over storingspermanentie voor IT-bedrijven leest u hoe intake, contactcascade en rapportage op uw eigen omgeving kunnen aansluiten.