Problemen met tijdzones in agenda's zien er vaak hetzelfde uit. Jij ziet een vergadering om 09:00, terwijl de genodigde 15:00 ziet. Dat kan een normaal verschil in lokale tijd zijn, maar het kan ook betekenen dat de uitnodigingen verschillende begintijdstippen aangeven. Of alles klopt wekenlang, totdat de vergadering na het verzetten van de klok een uur verschuift. Of de herinnering komt terwijl je slaapt.
De oorzaak zit vaak niet in de weergave. De afspraak is simpelweg opgeslagen als ‘9 uur’, zonder vast te leggen in welke tijdzone die 9 uur bedoeld is. Onderdelen die de gegevens verwerken, vullen de ontbrekende informatie zelf in en komen niet altijd tot dezelfde uitkomst.
Hier lees je hoe agenda's tijdzones verwerken, waarom een fout pas weken later zichtbaar kan worden en wat er verandert als de tijdzone samen met de afspraaktijd wordt opgeslagen.
Het probleem van een tijd zonder tijdzone
Stel dat een agenda de begintijd opslaat als 2026-09-14 09:00, zonder verdere informatie. Voor een gezamenlijke vergadering is dat niet eenduidig: verschillende onderdelen kunnen de waarde anders uitleggen.
Het browserformulier verstuurt de ingevoerde tijd. Een CalDAV-client voegt een tijdzone-identificatie toe, maar als de server die negeert, blijft alleen de lokale kloktijd over. Bij het exporteren kan die waarde ten onrechte als UTC worden gemarkeerd, omdat het formaat een bepaalde tijdnotatie verwacht. De herinneringsdienst vergelijkt de opgeslagen waarde ondertussen met de huidige UTC-tijd.
Vier onderdelen, vier interpretaties van dezelfde waarde. Als iedereen UTC gebruikt, blijft het probleem mogelijk onopgemerkt. Voeg iemand uit Berlijn toe en sommige afspraken worden anders verwerkt, zonder foutmelding.
Deze fout is gemakkelijk te missen als tests maar één tijdzone gebruiken. Tests met gebruikers uit verschillende regio's helpen haar eerder te vinden. Anders wordt ze pas zichtbaar tijdens een reis, na het verzetten van de klok of zodra iemand uit een andere tijdzone wordt uitgenodigd.
Drie manieren om tijd in een agenda vast te leggen
De iCalendar-standaard, die veel agenda's voor het uitwisselen van afspraken gebruiken, onderscheidt verschillende notaties voor datum en tijd. Voor afspraken met een specifieke tijd zijn dit de belangrijkste vormen.| Vorm | Voorbeeld | Betekenis | Geschikt voor |
|---|---|---|---|
| UTC | 20260914T070000Z | Eén bepaald tijdstip, overal hetzelfde | Vergaderingen met mensen uit verschillende regio's |
| Tijd met tijdzone | TZID=Europe/Berlin:20260914T090000 | 9 uur in Berlijn, omgerekend voor anderen | Een afspraak die aan een locatie is gekoppeld |
| Tijd zonder tijdzone | 20260914T090000 | 9 uur volgens de lokale klok van iedere gebruiker | Persoonlijke herinneringen die de lokale tijd moeten volgen |
Een tijd zonder tijdzone, ook ‘floating time’ genoemd, is geldig als dat gedrag de bedoeling is. Een verjaardag, bijvoorbeeld op de 14e, wordt meestal als datum vastgelegd en niet als zo'n kloktijd. Bij een gezamenlijke vergadering kunnen gelijke lokale tijden juist verschillende werkelijke tijdstippen betekenen.
Afspraken voor de hele dag worden als datums opgeslagen, zonder omrekening tussen tijdzones. Als je een feestdag eerst omzet naar een UTC-tijdstip en daarna terugrekent, kan hij ten westen van Greenwich op de vorige avond verschijnen. Behandel een datum daarom niet als de begintijd van een vergadering.
Waarom het verzetten van de klok fouten blootlegt
Tijdzones zouden eenvoudiger zijn als hun verschil met UTC altijd gelijk bleef. In veel regio's verandert dat verschil, en de overgang maakt eerder verborgen fouten zichtbaar.
Berlijn gebruikt UTC+1 in de winter en UTC+2 in de zomer. Als een terugkerende vergadering op een vaste UTC-tijd wordt berekend, verschuift ze na de overgang op de lokale klok. Het tijdstip is duidelijk, maar het is niet meer de vergadering van 9 uur. Om een reeks met Europe/Berlin op 9 uur te houden, moeten ook de herhalingen in die tijdzone worden berekend. Alleen de naam van de tijdzone opslaan is niet voldoende.
Met deelnemers uit verschillende landen wordt het lastiger. Europa en Noord-Amerika verzetten de klok op andere datums. Tussen die overgangen wijkt het gebruikelijke tijdverschil tussen Londen en New York een uur af. Hoelang die periode duurt, hangt af van het seizoen en het jaar; het is geen vaste duur. Een vergadering kan daardoor tijdelijk op een andere lokale tijd vallen voor één kant, terwijl de agenda correct werkt.
Een andere standaardtijdzone kiezen lost dat verschil niet op. ‘Hetzelfde tijdstip’ en ‘Dezelfde lokale tijd’ zijn verschillende eisen. Bepaal welk gedrag de reeks moet hebben en controleer of de berekening van herhalingen en de uitwisseling met clients dat behouden.
UTC en de tijdzone samen opslaan
Voor een afspraak met een specifieke tijd is het nuttig beide gegevens te bewaren: het exacte UTC-tijdstip en de tijdzone waarin de lokale tijd is ingevoerd. Bij een terugkerende reeks telt ook hoe de herhalingen worden berekend.
UTC maakt het vergelijken van tijdstippen, sorteren van afspraken en vinden van overlappingen eenduidig. De tijdzone verklaart de oorspronkelijke lokale tijd. Maar een opgeslagen tijdzoneveld garandeert niet dat iedere export alle eigenschappen van een reeks doorgeeft. Controleer het gegenereerde formaat en de verwerking door de client apart.
In de praktijk betekent dit:
- Een afspraak maken in webmail verstuurt de browsertijdzone samen met de ingevoerde tijd. De server rekent de tijd om naar UTC en bewaart de tijdzone. Staat de browser op Berlijn ingesteld, dan wordt Berlijn vastgelegd.
- De afspraak elders bekijken rekent UTC om naar de lokale browsertijd. Op de datum uit het voorbeeld toont Berlijn 09:00 en San Francisco 00:00. Beide tijden wijzen hetzelfde tijdstip aan; in andere periodes kunnen de verschillen anders zijn.
- Herinneringen krijgen een eenduidig tijdstip om mee te vergelijken. De tijdzone veroorzaakt dan niet meer deze onduidelijkheid, maar de bezorging blijft afhangen van de taakplanner en de meldingskanalen.
- Bij het bewerken verschijnt de tijd in de tijdzone van de huidige browser, niet noodzakelijk in de oorspronkelijke tijdzone van de afspraak. Controleer vóór het opslaan de tijd en de apparaatinstellingen, vooral na een reis.
Wat er met oudere afspraken gebeurt
Oudere afspraken hebben mogelijk geen opgeslagen tijdzone. Ze worden niet automatisch opnieuw geïnterpreteerd: de webinterface behoudt de oude weergave. Zo verschuiven bestaande afspraken niet onverwacht.
Dat is een bewuste keuze. Achteraf een tijdzone toewijzen is een gok, en een verkeerde gok verplaatst afspraken zonder overleg. Als een afspraak al twee jaar 14:00 toont, hoort een automatische correctie daar geen andere tijd van te maken. Ga bij een handmatige controle eerst na wat die 14:00 oorspronkelijk betekende.
Je kunt een oude afspraak bij het bewerken van een tijdzone voorzien. Bij het opslaan van een afspraak met een tijd verstuurt webmail de browsertijdzone. Controleer daarom eerst de lokale tijd en de apparaatinstellingen. Alleen de beschrijving aanpassen via de API, zonder tijdzoneparameter, voegt die informatie niet toe. Ongewijzigde afspraken behouden hun oude gedrag.
Als een oude terugkerende vergadering bij buitenlandse deelnemers verkeerd verschijnt, controleer dan de oorspronkelijke tijd en tijdzone en sla de correctie op. Bekijk daarna de herhalingen vóór en na het verzetten van de klok. Opnieuw opslaan garandeert op zichzelf geen correcte berekening van de hele reeks.
CalDAV, ICS en andere agenda's
Een agenda moet niet alleen in zijn webinterface werken. Apple Calendar, Thunderbird en compatibele mobiele apps kunnen via CalDAV verbinding maken. Maar Google Agenda op een apparaat hebben betekent niet dat je daarmee iedere CalDAV-server kunt aansluiten. Controleer de integratiemethode en de compatibiliteit.
Als een afspraak via CalDAV binnenkomt, gebruikt de server de tijdzone-identificatie om het bijbehorende UTC-tijdstip op te slaan. Het ontvangen agendadocument kan ongewijzigd worden teruggestuurd; voor afspraken uit webmail genereert de server UTC-waarden. Niet alle antwoorden gebruiken dus dezelfde notatie. Afspraken voor de hele dag worden als datums uitgewisseld. Controleer bij terugkerende reeksen ook of de uitwisseling de lokale tijd van de herhalingen behoudt.
Compatibele clients kunnen hetzelfde tijdstip tonen: bijvoorbeeld voor een afspraak die op een iPhone in Berlijn is gemaakt, in webmail op een laptop in Lissabon is bewerkt en in Thunderbird in New York is geopend. De lokale tijden verschillen daarbij. Daarvoor moeten clients en apparaten correct zijn ingesteld; de tijdzonenamen komen uit de IANA-tijdzonedatabase.
Bekijk de installatiehandleidingen voor Apple Calendar op macOS, iPhone en iPad, Android met DAVx⁵ en Thunderbird. Outlook heeft voor CalDAV doorgaans een invoegtoepassing van een andere leverancier nodig; beperkingen per versie staan in de handleiding voor Outlook.
Zo voorkom je tijdzonefouten
Zet de tijdzone in de titel van internationale vergaderingen. ‘Wekelijks overleg (09:00 CET)’ kan helpen als een mailprogramma de uitnodiging verkeerd weergeeft. Maar CET verwijst naar de wintertijd; Berlijn gebruikt in de zomer CEST. Kies de juiste afkorting voor de datum of noem een herkenbare stad, in plaats van het hele jaar CET te gebruiken.
Koppel de reeks aan de tijdzone die het tijdschema bepaalt. Moet het overleg de klok van het kantoor in Berlijn volgen, gebruik dan die tijdzone en controleer of de herhalingen daarin worden berekend. Voor deelnemers in andere landen kan de lokale tijd tijdens de overgangen veranderen. Dat betekent niet noodzakelijk dat de vergadering is verplaatst; het verschil tussen de regio's kan zijn veranderd.
Controleer belangrijke vergaderingen rond het verzetten van de klok opnieuw. Europa en Noord-Amerika doen dat op verschillende datums, waardoor het gebruikelijke verschil tijdelijk verandert. Controleer de concrete datum en bevestig de tijd voor beide kanten schriftelijk.
Gebruik afspraken voor de hele dag als alleen de datum telt. Dat is geschikt om de dag van een conferentie te markeren. Moeten deelnemers op een specifieke tijd aanwezig zijn, maak dan een afspraak met tijd en tijdzone, niet alleen een datum. Geef ook geen willekeurige begintijd aan een afspraak die er geen nodig heeft.
Controleer oudere reeksen en sla zo nodig de juiste tijd en tijdzone op. Een ontbrekende tijdzone in een oud record bewijst niet dat het een correct gedefinieerde lokale tijd zonder tijdzone is. Houd bij het opslaan in webmail rekening met de browserinstellingen. Controleer die ook bij gepland verzenden, waarbij de ingevoerde verzendtijd afhangt van de tijdzone van het apparaat.Veelgestelde vragen
Waarom verschijnt mijn vergadering op een andere tijd in andere tijdzones?
Verschillende lokale tijden vertegenwoordigen meestal hetzelfde tijdstip. Er is een probleem als deelnemers werkelijk verschillende begintijdstippen hebben ontvangen. Controleer dan de tijdzone van de afspraak en de clientinstellingen. Ontbrak de tijdzone, stel dan de oorspronkelijke tijd vast, sla de juiste tijdzone op en controleer het resultaat met de deelnemers.
Waarom is mijn terugkerende vergadering een uur verschoven?
Dat kan door de overgang tussen zomer- en wintertijd komen. Een reeks met een vaste UTC-tijd behoudt die tijd, maar verandert op de lokale klok. Een reeks die in een lokale tijdzone wordt berekend, behoudt de lokale tijd en kan voor andere regio's verschuiven. Het gewenste gedrag hangt af van jullie afspraak; controleer de berekening en export van de reeks.
Welke tijdzone wordt gebruikt als ik een afspraak in webmail maak?
Webmail herkent de browsertijdzone en verstuurt die voor afspraken met een tijd. De server bewaart het UTC-tijdstip en de tijdzone. Controleer vooraf de apparaatinstellingen, vooral als de vergadering een andere tijdzone moet volgen dan die van je huidige locatie.
Worden afspraken voor de hele dag omgerekend?
Nee. Ze worden als datums opgeslagen, niet als tijdstippen. Omrekenen via UTC kan de datum voor gebruikers in andere tijdzones op de vorige of volgende dag laten vallen.
Wat gebeurt er met afspraken die vóór het opslaan van tijdzones zijn gemaakt?
Ze behouden hun oude gedrag, zonder automatische toewijzing van een tijdzone. Webmail voegt bij het opslaan van een afspraak met een tijd de browsertijdzone toe. Controleer eerst de tijd en de apparaatinstellingen. Bij een API-update zonder expliciete tijdzoneparameter blijft een oud record zonder tijdzone.
Werken tijdzones goed met Apple Calendar en Google Agenda?
Een compatibele, goed ingestelde CalDAV-client kan de afspraaktijd correct omrekenen. Voor Apple Calendar is er een verbindingshandleiding. Controleer bij Google Agenda de beschikbare integratiemethode: een verbinding met iedere externe CalDAV-server is niet gegarandeerd. Controleer ook herhalingen en de overgang tussen zomer- en wintertijd.
Kan ik de tijdzone expliciet instellen via de API?
Ja. De REST-API voor het maken en bijwerken van afspraken accepteert een tijdzoneparameter. Controleer bij MCP het hulpmiddelschema en verstuur het veld als het wordt ondersteund. Zonder dat veld kan het systeem de gewenste tijdzone niet altijd bepalen.
Waarom komen herinneringen voor oude afspraken op de verkeerde tijd?
Als de tijd zonder tijdzone is opgeslagen, kan de vergelijking met het huidige tijdstip een verkeerd resultaat geven. Stel de oorspronkelijke tijd vast, sla de passende tijdzone op en test de herinnering. Blijft het probleem bestaan, controleer dan ook de meldingsinstellingen en de werking van de taakplanner.
