Lokale datums in PHP naar UTC migreren betekent niet simpelweg dat je de tijdzone van de server wijzigt of een vast aantal uren aftrekt. Voordat je gegevens aanpast, moet je bepalen wat elke waarde betekent, in welke tijdzone die werd geïnterpreteerd en of die een specifiek tijdstip of een civiele regel aanduidt. Als die antwoorden niet duidelijk zijn, kan een automatische conversie de gegevens weliswaar in een uniformer formaat zetten, maar nog steeds onjuist maken.
De veiligste strategie is geleidelijk: inventariseer de gegevens, definieer een beleid per gegevenstype, voeg een nieuw veld toe, converteer en verifieer in batches, en behoud de compatibiliteit voor lezen en schrijven zolang de overgang loopt. De interface kan de gebruikelijke tijden blijven tonen, terwijl de opslag voortaan tijdstippen op een consistente manier weergeeft.
De huidige datums en afhankelijkheden in kaart brengen
Begin met het opsporen van alle bronnen van datum- en tijdgegevens: databasekolommen, importbestanden, queues, API-integraties en waarden die in PHP worden gegenereerd. Controleer de typen en conventies: een DATETIME-kolom slaat doorgaans datum- en tijdcomponenten op zonder zelf de tijdzone te bewaren. Bij een TIMESTAMP kunnen tijdzoneconversies afhankelijk zijn van de database-engine en de sessie. Leid de betekenis niet uitsluitend af uit de naam van het type.
Zoek ook naar gemengde indelingen. Sommige records kunnen bijvoorbeeld lokale tijd vertegenwoordigen, andere UTC, en weer andere kunnen zijn geïmporteerd uit een bron waarvan de tijdzone onbekend is. Vergelijk voorbeelden met externe gebeurtenissen, de auditgeschiedenis of bedrijfsregels. Controleer de PHP-configuratie, de tijdzone van de databaseverbinding en aanroepen van date() of strtotime() die afhankelijk zijn van de standaardtijdzone.
Een risicosignaal is dat dezelfde waarde anders wordt weergegeven, afhankelijk van de server of het proces dat deze leest. Een ander signaal is een constant tijdsverschil dat per periode van het jaar verandert: dit kan erop wijzen dat lokale tijd en UTC door elkaar worden gebruikt en dat de zomertijd meespeelt.
Tijdstippen, civiele datums en terugkerende tijden onderscheiden
Een tijdstip is één uniek punt op de tijdlijn, zoals het moment waarop een betaling is bevestigd. Je kunt het normaliseren en opslaan in UTC; de tijdzone voor de weergave pas je toe wanneer je het toont. In PHP kun je met DateTimeImmutable en DateTimeZone de brontijdzone expliciet aangeven en het resultaat converteren:
$local = new DateTimeImmutable($waarde, new DateTimeZone('Europe/Madrid'));
$utc = $local->setTimezone(new DateTimeZone('UTC'));Dit voorbeeld is alleen geldig als de ingevoerde datum en tijd zijn gecontroleerd en een ondubbelzinnig tijdstip vertegenwoordigen. De constructor kan een niet-bestaande lokale tijd tijdens de overgang naar zomertijd stilzwijgend normaliseren. Bij een herhaald uur kan hij één van de twee voorkomens kiezen zonder dat de invoer aangeeft welk voorkomen bedoeld is. Controleer voordat je de waarde opslaat of de tijd bestaat en hanteer een expliciet beleid voor herhaalde tijden: los ze bijvoorbeeld op aan de hand van een offset of brongegevens, of markeer het record voor beoordeling. Als je het tijdstip niet betrouwbaar kunt bepalen, behoud de waarde dan als civiel gegeven of laat deze openstaan; ga er niet van uit dat de conversie geldig is alleen omdat PHP een object heeft teruggegeven.
Een civiele datum kan daarentegen “14 april” zijn, zonder tijd of tijdzone. Een verjaardag of een op de kalender gebaseerde vervaldatum mag je niet omzetten naar een UTC-tijdstip als de bedrijfslogica er geen specifiek tijdstip aan koppelt: daardoor kan de dag veranderen wanneer je de datum in een andere tijdzone weergeeft.
Een terugkerende tijd, zoals “de vergadering is elke maandag om 9.00 uur in Madrid”, drukt een regel uit in een civiele tijdzone. Dat is niet hetzelfde als elke week hetzelfde UTC-tijdstip herhalen, omdat de offset van de tijdzone kan veranderen. Bewaar de lokale tijd, de IANA-tijdzone en de herhalingsregel; bereken de volgende tijdstippen op basis van die voorwaarden.
De historische betekenis achterhalen voordat je converteert
Om een lokale datum te converteren, moet je weten welke tijdzone gold toen deze werd vastgelegd. Alleen de huidige tijdzone van de gebruiker of de huidige serverconfiguratie gebruiken is niet voldoende. De applicatie werkte misschien in één tijdzone, of de gegevens kunnen afkomstig zijn uit verschillende vestigingen. Zoek naar bewijs in historische configuraties, de herkomst van het record, het gekoppelde account en de regels die destijds van kracht waren.
Sommige lokale tijden verwijzen niet naar één uniek tijdstip. Wanneer de klok wordt teruggezet, kan een tijd twee keer voorkomen; wanneer de klok vooruit wordt gezet, bestaan bepaalde tijden niet. Er kunnen ook onvolledige waarden zijn, zoals een tijd zonder datum of een geïmporteerde datum zonder tijdzone. Converteer deze niet stilzwijgend op basis van een algemene aanname: classificeer ze als ambigu, niet-bestaand of zonder verifieerbare herkomst, en bepaal samen met het verantwoordelijke team een beleid.
Afhankelijk van de situatie kan het beleid voorschrijven dat je op basis van extern bewijs één van de voorkomens kiest, de oorspronkelijke waarde als civiel gegeven behoudt of het record ter beoordeling openlaat. Documenteer de beslissing en sla de IANA-tijdzone op, bijvoorbeeld Europe/Madrid, en niet alleen een afkorting zoals “CET”, waarvan de betekenis mogelijk onvoldoende is om historische regels te reconstrueren.
Een geleidelijke en compatibele migratie ontwerpen
Overschrijf niet meteen de enige beschikbare kolom. Voeg een nieuw veld toe voor het genormaliseerde tijdstip en, als het domein dat vereist, nog een veld voor de oorspronkelijke tijdzone of civiele tijd. Leg in het schema en de code vast wat elk veld voorstelt; een naam als starts_at_utc kan helpen, zolang de applicatie die conventie consequent hanteert.
Spreek tijdens de overgangsfase één enkele bron van waarheid af voor schrijfbewerkingen. Dual writes kunnen een overgang vergemakkelijken, maar brengen het risico met zich mee dat de velden uiteen gaan lopen als een bewerking het ene veld wel en het andere niet bijwerkt. Centraliseer die logica in één schrijfroute, gebruik waar nodig transacties en registreer fouten. Stel voor leesbewerkingen een expliciete prioriteit vast: gebruik het nieuwe veld zodra dat beschikbaar is en val alleen terug op het oude veld voor records die nog niet zijn gemigreerd.
Beperk de overgangsfase en bepaal hoe je de voortgang meet. Controleer welke applicaties, rapporten, exports en API-consumenten het oude veld nog lezen voordat je plant wanneer je het uitfaseert. Compatibiliteit behouden betekent niet dat je twee interpretaties voor onbepaalde tijd moet blijven ondersteunen.
In batches converteren en de transformatie verifiëren
Verwerk records in begrensde batches, met stabiele selectiecriteria en een markering waarmee je het werk kunt hervatten. De conversie moet herhaalbaar zijn: als een batch opnieuw wordt uitgevoerd, mag een al geconverteerde datum niet nogmaals verschuiven. Behoud de oorspronkelijke waarde tijdens de validatiefase en registreer de ID, de veronderstelde tijdzone, het resultaat en eventuele uitzonderingen. Vermijd daarbij onnodige persoonsgegevens in technische logs.
Bereken vóór het bijwerken van een batch een voorbeeldweergave en controleer representatieve gevallen. Vergelijk daarna de aantallen, waarden voor en na de conversie, null-records en de verdeling van fouten. Valideer ook de domeineigenschappen: controleer bijvoorbeeld of een reservering nog steeds gekoppeld is aan de verwachte civiele datum in de zakelijke tijdzone. Een tijdsverschil kan voor een tijdstip correct zijn en tegelijk een fout aan het licht brengen als de dag is veranderd van een datum die civiel had moeten blijven.
Stop het proces als het aantal uitzonderingen boven de afgesproken grens komt of als er waarden zonder duidelijke herkomst verschijnen. Pas de regel aan of zonder die records af voor beoordeling; dwing ze niet door dezelfde conversie als de verifieerbare gevallen.
Invoer, uitlezing en tests aanpassen
Interpreteer de datum aan de grenzen van de invoer met de tijdzone die bij de gebruiker of de bedrijfslogica hoort, en valideer het verwachte formaat. Converteer een tijdstip bij het opslaan naar UTC zodra de invoer de controles op bestaan en ambiguïteit heeft doorstaan die voor die tijdzone zijn vastgesteld. Zet het tijdstip bij uitvoer om naar de juiste tijdzone voor weergave. Spreek voor API's een ondubbelzinnig formaat af, zoals een tijdstempel met tijdzone-indicator, en documenteer of velden tijdstippen of civiele waarden voorstellen.
Tests moeten expliciete tijdzones en gevallen rond overgangen naar en uit de zomertijd omvatten: niet-bestaande en herhaalde tijden, middernacht, daggrenzen en conversies tussen tijdzones. Voeg round-trip-tests toe: interpreteer een invoer, sla het tijdstip op, geef het opnieuw weer in de oorspronkelijke tijdzone en controleer of de verwachte betekenis behouden blijft. Eis niet dat de tekstuele tekenreeks altijd identiek is als de uitvoer is genormaliseerd; controleer de componenten en de semantiek. Voeg ook tests toe die bevestigen dat een niet-bestaande tijd wordt afgewezen of volgens het beleid wordt afgehandeld, en dat een herhaalde tijd niet wordt opgelost zonder de voorgeschreven regel.
Checklist voor het uitfaseren van het oude veld
- Elk veld is geclassificeerd als tijdstip, civiele datum of herhalingsregel.
- De brontijdzone is gedocumenteerd en voor ambigue gevallen is een expliciet beleid vastgelegd.
- Nieuwe schrijfbewerkingen hanteren één bron van waarheid en voor compatibele leesbewerkingen is een uitfaseringsdatum vastgesteld.
- De batchconversie kan worden hervat en houdt uitzonderingen traceerbaar bij.
- De tests dekken tijdzoneovergangen, daggrenzen, API's en weergave in verschillende tijdzones.
- Rapporten, exports, geplande taken en integraties zijn niet langer afhankelijk van het oude veld.
Faseer het oude veld pas uit als de migratie is gevalideerd en er geen consumenten meer zijn die afhankelijk zijn van de interpretatie ervan. UTC gebruiken voor tijdstippen, IANA-tijdzones voor civiele regels en een duidelijke semantiek voor elk veld vermindert ambiguïteit zonder dat de interface interne details van de opslag hoeft te tonen.
