Надлежащее планирование будущих задач по местному времени с учетом часовых поясов и перехода на летнее время является очень сложной задачей. Я писал об этом раньше с точки зрения программирования на переполнение стека здесь и здесь .
Я подведу итог с точки зрения не программирования:
Определите ваши шаблоны повторения по местному времени, а не по UTC . Например, если вы установили ежедневный будильник, чтобы будить вас каждый день в 8:00, вы не хотите вставать на час раньше или на час позже после перехода на летнее время. Если я нахожусь в часовом поясе Тихоокеанского региона США, я не могу запланировать на 16:00 UTC, потому что после перехода он должен будет переключиться на 15:00 UTC, чтобы сохранить то же самое местное время в 8:00.
Определите часовой пояс, который представляет «местное» время. Не думайте, что локальный часовой пояс сервера - это тот же часовой пояс, который важен для конечного пользователя.
Спроектируйте местное время на дату и время UTC для каждого события, для которого вы хотите, чтобы событие сработало.
Вы почти всегда будете делать это для следующего немедленного вхождения, так что вы можете использовать часы UTC, чтобы определить реальный момент времени для запуска.
В некоторых случаях вы можете также спроецировать следующие несколько (или много) экземпляров, например, следующие 5 вхождений или все вхождения на следующий год. (Эта часть очень специфична для требований приложения.)
Имейте в наличии стратегию (фиксированную или настраиваемую), что делать для случаев, которые выпадают во время перехода на летнее время :
Для перехода «весна вперед» существует пропущенное местное время, когда вхождение может не существовать. Например, в тихоокеанском времени США ежедневное задание, запланированное на 2:00 утра по местному времени, не будет работать 9 марта 2014 года. В большинстве случаев вы хотите увеличить это время на сумму экономии (обычно 1 час). ), поэтому в этот день он будет работать в 3:00, но в следующий раз он снова будет работать в 2:00. (Однако вполне возможно, что вам понадобится другая стратегия для этого.)
Для перехода «откат» существует дублирование местного времени, когда вхождение может существовать дважды . Например, в тихоокеанском времени США ежедневное задание, запланированное на 1:00, будет иметь два возможных времени, на которые оно может быть выполнено 2 ноября 2014 года. В большинстве случаев вы захотите запустить его при первом появлении 1 : 00:00 по тихоокеанскому времени и пропустить следующее в 1:00 по тихоокеанскому времени той же даты. (Но, опять же, вы можете захотеть использовать другую стратегию, например, работать во втором случае или работать в обоих. YMMV)
Будьте готовы пересчитать все время вашего UTC, если вам когда-нибудь понадобится обновить данные часового пояса. В IANA / Olson TZDB тушит несколько обновлений каждый год , потому что правительства стран мира передумать все время о времени смещения зоны и перехода на летнее время правила. Вы не можете предполагать в течение какого-то определенного периода времени в будущем, что правила не изменятся .
Обязательно подпишитесь на анонсы выпусков данных о часовых поясах, и есть процесс для их применения в ваших системах и / или приложениях.
В традиционных корпоративных условиях ответственность за это должны выполнять сотрудники ИТ-отдела.
В зависимости от вашей среды вы можете получать эти данные через tzdataобновления пакетов linux, через Java JRE или tzupdater , или через любое количество других каналов. Иногда это зависит от конкретной среды, а иногда - от платформы программирования, такой как пакет PECL timezonedb для PHP и многие другие.
У Microsoft есть собственные данные о часовых поясах. В Windows, если вы используете TimeZoneInfoиз .NET (например), вы используете эти данные. Обновления поступают отсюда , а также автоматически выгружаются через Центр обновления Windows, поэтому вам следует следить за ними, чтобы вы знали, когда / если вам нужно пересчитать.
Со всем, что понял, там есть еще сценарий , в котором вы бы планировать только по Гринвичу, и что для АБСОЛЮТНЫХ будущих событий. Примеры:
Работа, которая выполняется каждые X часов или каждые X минут.
Время начала и окончания восхода солнца или другое астрономическое явление.
Чувствительное ко времени окно безопасности, например, при передаче конфиденциальной информации другой стороне в заранее установленное время.
Планировщик заданий Windows
Windows не обязательно делает правильные вещи. Обратите внимание на то, как вы определяете триггер:
Если вы установите флажок «Синхронизировать по часовым поясам», тогда задача будет запланирована только по UTC. (Время все еще отображается как местное время, но хранится как UTC.) Так что это для того, что я ранее назвал «абсолютным» событием.
Когда вы оставите этот флажок без отметки, он будет использовать местный часовой пояс компьютера, на котором выполняется код. Он не дает никакой возможности указать часовой пояс, так что это не очень хорошая реализация IMHO.
Я не совсем уверен, что такое поведение DST, но я поэкспериментирую и перезвоню вам. Это, вероятно, делает то, что я описал выше, но не обязательно.
Агент SQL
Планировщик агента SQL еще хуже: он позволяет использовать только время локального сервера. Опять же, нельзя указывать часовые пояса, и вы также не можете указать UTC.
Это было запрошено , но не принято.