Data blijven een amusante uitdaging in software. Ik kreeg een klacht van een klant dat ze een abonnement hebben gekocht om 18:00 uur hun tijd op 31 januari... maar een ontvangstbewijs kregen met de datum als 1 februari. Dit is verkeerd - en ze hebben gelijk! Maar vanuit het perspectief van de server is de datum juist!

Stel je voor dat je een systeem aan het bouwen bent: hoe bouw je het: - Om de tijdzone / tijdinstellingen van de klant te gebruiken - maar dit opent allerlei interessante uitdagingen (inclusief bijvoorbeeld verleden/toekomst data!) - Om de bon om te zetten naar de tijdzone van de klant: maar wat gebeurt er als dezelfde gebruiker bijvoorbeeld reist. Veranderen al hun bonnen van datum? - Om UTC te gebruiken (wat hier gebeurt): consistent maar dan verkeerd vanuit het perspectief van de klant Het is een moeilijk probleem!