Een fysiotherapeut plant online afspraken via haar website. Een patiënt boekt om 14:00 uur, de bevestiging zegt 13:00 uur en de praktijk ziet 12:00 uur in het beheer. Een webshop ziet bestellingen binnenkomen met een tijdstip dat twee uur afwijkt van de bank. Een blog plant een bericht in voor 09:00 uur en het staat om 08:00 uur al online. Allemaal kleine ergernissen, tot iemand een afspraak mist of een bestelling te laat wordt ingepakt.
In vrijwel al deze gevallen staat de WordPress tijdzone niet goed. WordPress bewaart tijden namelijk op twee manieren tegelijk, en als de instelling niet klopt, gaan die twee uit elkaar lopen. In dit artikel leest u hoe u de instelling controleert en goed zet, wat de valkuilen zijn, en welke plugins hun eigen tijdzone gebruiken zodat u die ook nakijkt.
Hoe WordPress met tijd omgaat
Elke server heeft een eigen klok, meestal ingesteld op UTC, de wereldstandaardtijd. WordPress slaat bij elk bericht, elke reactie en elke bestelling twee tijden op: de UTC-tijd en de “lokale” tijd, berekend met de tijdzone die u onder Instellingen heeft gekozen. Alles wat u op de site ziet, gebruikt de lokale tijd. Alles wat op de achtergrond gebeurt, zoals het publiceren van een gepland bericht, gebruikt de UTC-tijd.
Staat de tijdzone verkeerd, dan wijkt de lokale tijd af van wat uw klok zegt. Nederland loopt in de winter één uur en in de zomer twee uur voor op UTC. Als uw site nog op UTC staat, ziet u dus alles een of twee uur te vroeg. Staat er “UTC+1” in plaats van “Amsterdam”, dan klopt het in de winter maar niet in de zomer, omdat een vaste verschuiving niets weet van zomertijd.
De WordPress tijdzone goed instellen in drie stappen
- Ga naar Instellingen, Algemeen. Zoek het veld Tijdzone. Kies in de lijst een stad, en wel Amsterdam. Kies geen UTC-verschuiving zoals UTC+1 of UTC+2; die verandert niet mee met zomer- en wintertijd.
- Controleer de regel onder het veld. WordPress toont daar “Universele tijd is …” en “Lokale tijd is …”. De lokale tijd moet overeenkomen met de klok op uw telefoon. Klopt hij, dan is de instelling goed. Klopt hij niet, terwijl Amsterdam is gekozen, dan is de serverklok zelf fout en moet uw hostingpartij ernaar kijken.
- Stel het datum- en tijdformaat in op dezelfde pagina. Voor Nederland: datumformaat “j F Y” (bijvoorbeeld 7 september 2026) en tijdformaat “H:i” (14:30). Dat verandert niets aan de berekening, maar voorkomt dat bezoekers 2:30 PM zien.
Sla op en bekijk een recent bericht of een bestelling. De tijd zou nu moeten kloppen. Bestaande berichten die met de oude instelling zijn gepubliceerd, tonen nog de oude lokale tijd; dat is een cosmetische kwestie die u alleen hoeft te corrigeren als de datum ertoe doet.
De valkuilen na het aanpassen
Geplande berichten die in de war raken
Als u de tijdzone verandert terwijl er berichten ingepland staan, blijft de UTC-tijd van die berichten staan. Een bericht dat u had gepland voor 09:00 uur “oude lokale tijd” gaat nu af op 09:00 uur UTC, dus om 11:00 uur in de zomer. Loop na de wijziging alle geplande berichten na en zet de tijd opnieuw. Verschijnen berichten überhaupt niet op tijd, dan is niet de tijdzone maar de taakplanner de oorzaak, zoals we uitleggen in het artikel over WP-Cron die niet werkt.
Plugins met een eigen tijdzone-instelling
Niet alle plugins gebruiken de instelling van WordPress. Afsprakenplugins, boekingssystemen, evenementenkalenders en sommige formulierplugins hebben een eigen tijdzoneveld, vaak diep verstopt in hun instellingen. Staat dat op UTC of op een Amerikaanse tijdzone, dan kloppen de afspraken niet, ook al is WordPress zelf goed ingesteld. Controleer na het aanpassen van de tijdzone dus ook:
- uw afspraken- of boekingsplugin;
- een evenementenkalender;
- WooCommerce (Instellingen, Algemeen: winkeladres en de tijdzone volgt normaal WordPress, maar sommige verzend- en betaalplugins niet);
- nieuwsbriefkoppelingen die op een tijdstip versturen;
- back-upplugins die op een vast uur draaien.
Caching toont oude tijden
Als de site na het aanpassen nog steeds de oude tijd toont, is dat meestal de cache. Leeg de cacheplugin en eventueel de servercache van uw hostingpartij en kijk opnieuw.
Een verkeerde serverklok
Zelden, maar het komt voor: de klok van de server zelf loopt minuten of uren achter. Dan klopt geen enkele instelling. Dit merkt u aan de regel “Universele tijd is …” onder het tijdzoneveld, die dan afwijkt van de werkelijke UTC-tijd. Alleen uw hostingpartij kan dit corrigeren, en het kan ook problemen geven met certificaten en betalingen, dus meld het.
Praktijkvoorbeeld: een tandartspraktijk in Tilburg
Een tandartspraktijk in Tilburg gebruikte een online afsprakenmodule op de website. In maart, na de overgang naar zomertijd, kwamen patiënten opeens een uur te vroeg of te laat. De assistente had de WordPress-tijdzone gecontroleerd en die stond op “UTC+1”, ingesteld door de webbouwer jaren geleden. Ze veranderde dat naar Amsterdam, maar het probleem bleef.
De afsprakenplugin bleek een eigen tijdzoneveld te hebben, dat eveneens op een vaste UTC+1 stond. Na het aanpassen daarvan naar Amsterdam en het legen van de cache klopten alle nieuwe afspraken. De bestaande afspraken van die week hebben ze handmatig nagelopen. Een uur werk, en een les die de praktijk in het onderhoudsdossier heeft gezet: bij elke plugin die met tijd werkt, eerst de tijdzone controleren.
Wat u zelf doet en wanneer u hulp inschakelt
De instelling onder Instellingen, Algemeen is voor iedereen te doen. Het nalopen van plugins ook, al vraagt dat wat zoekwerk. Hulp is verstandig als de tijden na het aanpassen nog steeds niet kloppen, als er bestellingen of afspraken in een verkeerde tijdzone in de database staan die gecorrigeerd moeten worden, of als de serverklok zelf afwijkt. Dat is een korte klus voor wie WordPress-storingen oplost, en een goede aanleiding om meteen de overige instellingen van uw site te laten nakijken.
Samengevat
Kies Amsterdam als tijdzone, nooit een vaste UTC-verschuiving. Controleer de lokale tijd onder het veld, loop geplande berichten na, kijk in elke plugin die met tijd werkt en leeg de cache. Daarmee zijn verkeerde tijden op de site in de meeste gevallen binnen een kwartier verleden tijd.
