Първо, моля, имайте предвид, че в съвременната терминология трябва да кажете UTC вместо GMT. Те са предимно еквивалентни, с изключение на това, че UTC е по-точно дефинирано. Запазете термина GMT за обозначаване на частта от часовата зона в Обединеното кралство, която е в сила през зимните месеци с изместване UTC+0.
Сега към вашия въпрос. UTC не е непременно най-добрият начин за съхраняване на всички стойности за дата и час. Работи особено добре за минало събития или за бъдещи абсолютни събития, но не работи толкова добре за бъдещи местни събития - особено бъдещи повтарящи се събития.
Написах за това в друг отговор напоследък и е един от малкото изключения, при които местното време има по-голям смисъл от UTC. Основният аргумент е "проблемът с будилника". Ако настроите будилника си по UTC, ще се събудите един час по-рано или късно в деня на прехода на DST. Ето защо повечето хора настройват будилниците си по местно време.
Разбира се, не можете просто съхранявайте местно време, ако работите с данни от цял свят. Трябва да съхранявате няколко различни неща:
- Местното време на повтарящото се събитие, като например „08:00“
- Часовата зона, в която е изразено местното време, като например „Америка/Ню_Йорк“
- Моделът на повторение във всеки формат, който има смисъл за вашето приложение, като например всеки ден, две седмици или третия четвъртък от месеца и т.н.
- Следващият незабавен UTC дата и час еквивалентни, до най-доброто, което можете да проектирате.
- Може би, но не винаги, списък с дата и часове на бъдещите събития по UTC, проектирани за някакъв предварително определен период в бъдещето (може би седмица, може би 6 месеца, може би година или две, в зависимост от вашите нужди).
За последните две имайте предвид, че UTC еквивалентът на всяка местна дата/час може да се промени, ако правителството, отговорно за тази часова зона, реши да промени нещо. Тъй като всяка година има множество актуализации на база данни с часови зони, ще искате да имате план за абонирайте се за съобщения за актуализации и актуализирайте вашата база данни за часовите зони редовно. Всеки път, когато актуализирате данните си за часовата зона, ще трябва да преизчислите еквивалентните времена по UTC за всички бъдещи събития.
Наличието на еквиваленти на UTC е важно, ако планирате да показвате всякакъв вид списък със събития, обхващащи повече от една часова зона. Това са стойностите, които ще поискате, за да съставите този списък.
Друг момент, който трябва да имате предвид, е, че ако събитие е насрочено за местно време, което се случва по време на резервен преход за DST, ще трябва да решите дали събитието се случва на първия екземпляр (обикновено) или на втория (понякога), или и двете (рядко) и вградете в приложението си механизъм, за да гарантирате, че събитието няма да се задейства два пъти, освен ако не искате.
Ако сте търсили прост отговор - съжалявам, но няма такъв. Планирането на бъдещи събития в часовите зони е сложна задача.
Алтернативен подход
Няколко души ми показват техника, където правят използват UTC времето за планиране, което е, че избират начална дата в местно време, преобразуват я в UTC, за да се съхранят, и също така съхраняват идентификатора на часовата зона. След това по време на изпълнение те прилагат часовата зона, за да преобразуват първоначалното UTC време обратно в местно време, след което използват това местно време за изчисляване на другите повторения, сякаш това е първоначално съхраненото, както е по-горе.
Докато тази техника ще работи , недостатъците са:
-
Ако има актуализация на часовата зона, която променя местното време преди стартирането на първата инстанция, тя ще изхвърли целия график. Това може да бъде смекчено, като се избере минало време за „първа“ инстанция, така че втората инстанция наистина да е първата.
-
Ако времето наистина е "плаващо време", което трябва да следва потребителя наоколо (като например в будилник на мобилен телефон), все пак ще трябва да съхранявате информация за часовата зона за зоната, в която първоначално е създадена - дори ако това не е зоната, в която искате да бягате.
-
Това добавя допълнителна сложност без никаква полза. Бих запазил тази техника за ситуации, в които може да сте имали планировчик само за UTC, в който се опитвате да пренастроите поддръжката за часови зони.
