По какъвто и начин да го направите, той ще се провали по различни начини в зависимост от това какво се променя.
-
Ако съхранявате времеви отпечатъци в съответната часова зона като
2013-12-29 12:34:56 America/New_York, това ще се провали, ако, да речем, Бронкс внезапно започне своя собствена часова зонаAmerica/New_York_Bronxс различен офсет и събитието ви се е случило в Бронкс.Решете колко вероятно е това и колко лош би бил провалът.
-
Ако съхранявате времеви печати в UTC и часовата зона, в която се случва събитието, предефинира тяхното отместване (например изместване на DST датите наоколо или изцяло изместване към различно отместване), времето на събитието може да се различава от действителното време на стенен часовник на това място. Ако съхранявате
2013-12-29 12:34:56 UTCза събитие в 13:34:56 в Берлин, Германия и Берлин сменя своето DST,2013-12-29 12:34:56 UTCвече може да съответства на 14:34:56 местно време в Берлин, докато събитието все още се случва в 13:34 местно време.Решете колко вероятно е това и колко лош би бил провалът.
-
Ако съхраните времевата марка за UTC и го свържете с физическо местоположение, което след това свържете с часова зона, можете да противодействате и на двата проблема. Но за това ще трябва да съхраните точното физическо местоположение, а не само „Ню Йорк“, в противен случай имате просто случай 1. с още една междинна стъпка. Ако съхранявате точното физическо местоположение и имате точен начин да разрешите това местоположение до часова зона и поддържате базата данни за часовите зони актуална, можете да се справите с почти всички сценарии за промяна.
Решете колко практично е това и колко струва тази допълнителна прецизност за вас.
