Op welke manier je het ook doet, het zal op verschillende manieren mislukken, afhankelijk van wat er verandert.
-
Als u tijdstempels opslaat in de overeenkomstige tijdzone als
2013-12-29 12:34:56 America/New_York
, zal dit mislukken als bijvoorbeeld de Bronx plotseling hun eigen tijdzone begintAmerica/New_York_Bronx
met een andere offset en je evenement was toevallig in de Bronx.Bepaal hoe waarschijnlijk dit is en hoe erg een mislukking zou zijn.
-
Als u tijdstempels opslaat in UTC en de tijdzone waarin de gebeurtenis plaatsvindt, hun verschuiving herdefinieert (bijv. het verschuiven van de DST-datums rond, of volledig verschuiven naar een andere verschuiving), kan de tijd van de gebeurtenis verschillen van de werkelijke tijd van de wandklok op die locatie. Als u
2013-12-29 12:34:56 UTC
. opslaat voor een evenement om 13:34:56 in Berlijn, Duitsland, en Berlijn verschuift hun DST rond,2013-12-29 12:34:56 UTC
kan nu overeenkomen met 14:34:56 lokale tijd in Berlijn, terwijl het evenement nog steeds plaatsvindt om 13:34 lokale tijd.Bepaal hoe waarschijnlijk dit is en hoe erg een mislukking zou zijn.
-
Als je de UTC-tijdstempel opslaat en koppelt aan een fysieke locatie die je vervolgens aan een tijdzone koppelt, kun je beide problemen tegengaan. Maar hiervoor moet je de exacte fysieke locatie opslaan, niet alleen "New York", anders heb je alleen geval 1. met nog een tussenstap. Als je de exacte fysieke locatie opslaat en een precieze manier hebt om deze locatie naar een tijdzone te herleiden en je houdt je tijdzonedatabase up-to-date, dan kun je vrijwel alle wijzigingsscenario's aan.
Bepaal hoe praktisch dit is en hoeveel deze extra precisie je waard is.