Запланированные рабочие места в часы осенней смены времени

Правильное планирование будущих задач по местному времени с учетом часовых поясов и перехода на летнее время является очень сложной задачей. Я писал об этом раньше с точки зрения программирования на переполнение стека здесь и здесь.

Я подведу итог с точки зрения не программирования:

• Определите ваши шаблоны повторения по местному времени, а не по 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, поэтому вам следует следить за ними, чтобы вы знали, когда / если вам нужно пересчитать.

• После всего этого есть сценарий, в котором вы будете планировать только по UTC, и это для АБСОЛЮТНЫХ будущих событий. Примеры:

  • Работа, которая выполняется каждые X часов или каждые X минут.

  • Время начала и окончания восхода солнца или другое астрономическое явление.

  • Чувствительное ко времени окно безопасности, например, при передаче конфиденциальной информации другой стороне в заранее установленное время.

Планировщик заданий Windows

Windows не обязательно делает правильные вещи. Обратите внимание на то, как вы определяете триггер:

Если вы установите флажок "Синхронизировать по часовым поясам", тогда задача будет запланирована только по UTC. (Время по-прежнему отображается как местное время, но хранится как UTC.) Так что это для того, что я ранее назвал "абсолютным" событием.

Когда вы оставите этот флажок без отметки, он будет использовать местный часовой пояс компьютера, на котором выполняется код. Это не дает вам никакой возможности указать часовой пояс, так что это не очень хорошая реализация IMHO.

Я не совсем уверен, что такое поведение DST, но я поэкспериментирую и свяжусь с вами по этому поводу. Это вероятно делает то, что я описал выше, но не обязательно.

Агент SQL

Планировщик агента SQL еще хуже, поскольку он позволяет использовать только время локального сервера. Опять же, нельзя указывать часовые пояса, и вы также не можете указать UTC.

Это было запрошено, но не принято.