Правильне планування майбутніх завдань за місцевим часом з урахуванням часових поясів та літнього часу - дуже складна тема. Я писав про це раніше з точки зору програмування на Stack Overflow тут і тут .
Я підсумую з точки зору непрограмування:
Визначте свої схеми повторення за місцевим часом - не за 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 AM PDT та пропустіть наступне виникнення о 1:00 ранку PST тієї ж дати. (Знову ж, вам може знадобитися інша стратегія, наприклад, запуск у другому випадку або запуск обох. 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 Agent ще гірший тим, що він дозволяє використовувати лише час на локальному сервері. Знову ж, не можна вказати часові пояси, і ви також не можете вказати UTC.
Надіслано запит , але його не прийнято.