Lập lịch trình thích hợp cho các nhiệm vụ trong tương lai theo giờ địa phương, có tính đến múi giờ và thời gian tiết kiệm ánh sáng ban ngày, là một chủ đề rất phức tạp. Tôi đã viết về nó trước đây từ góc độ lập trình trên Stack Overflow tại đây và đây .
Tôi sẽ tóm tắt từ góc độ không lập trình:
Xác định các mẫu tái phát của bạn theo giờ địa phương - không phải UTC . Ví dụ: nếu bạn đặt đồng hồ báo thức hàng ngày để đánh thức bạn dậy lúc 8:00 sáng mỗi ngày, bạn không muốn thức dậy sớm một giờ hoặc trễ một giờ sau khi chuyển đổi thời gian tiết kiệm ánh sáng ban ngày. Nếu tôi ở múi giờ Thái Bình Dương của Hoa Kỳ, tôi không thể lên lịch cho 4:00 PM UTC, vì sau khi chuyển đổi, nó sẽ phải chuyển sang 3:00 PM UTC để giữ nguyên 8:00 AM theo giờ địa phương.
Xác định múi giờ mà thời gian "cục bộ" đại diện. Đừng cho rằng múi giờ địa phương của máy chủ là cùng múi giờ quan trọng với người dùng cuối.
Chiếu giờ địa phương thành ngày và giờ UTC cho mỗi lần xảy ra mà bạn muốn sự kiện này được kích hoạt.
Bạn hầu như sẽ luôn làm điều này cho lần xuất hiện tiếp theo, như vậy bạn có thể sử dụng đồng hồ UTC để xác định thời gian thực tức thì để chạy.
Trong một số trường hợp, bạn cũng có thể muốn chiếu một vài (hoặc nhiều) trường hợp tiếp theo, chẳng hạn như 5 lần xuất hiện tiếp theo hoặc tất cả các lần xuất hiện trong năm tới. (Phần này đặc biệt cao đối với các yêu cầu của ứng dụng.)
Có một chiến lược tại chỗ (cố định hoặc có thể định cấu hình), về những việc cần làm đối với các sự cố rơi vào thời điểm chuyển đổi thời gian tiết kiệm ánh sáng ban ngày :
Đối với quá trình chuyển đổi "mùa xuân về phía trước", có một khoảng cách thiếu thời gian địa phương khi sự xuất hiện có thể không tồn tại. Ví dụ: trong Giờ Thái Bình Dương của Hoa Kỳ, một nhiệm vụ hàng ngày được lên kế hoạch chạy vào lúc 2:00 sáng giờ địa phương sẽ không tồn tại vào ngày 9 tháng 3 năm 2014. Trong hầu hết các trường hợp, bạn sẽ muốn tăng thời gian đó bằng số tiền tiết kiệm (thường là 1 giờ ), vì vậy vào ngày hôm đó, nó sẽ chạy vào lúc 3:00 sáng, nhưng sẽ trở lại chạy vào lúc 2:00 sáng trong trường hợp tiếp theo. (Tuy nhiên, bạn hoàn toàn có thể muốn có một chiến lược khác cho việc này.)
Đối với quá trình chuyển đổi "quay lại", có sự trùng lặp về thời gian cục bộ trùng lặp khi sự xuất hiện có thể tồn tại hai lần . Ví dụ: trong Giờ Thái Bình Dương của Hoa Kỳ, một nhiệm vụ hàng ngày được lên kế hoạch chạy vào lúc 1:00 sáng sẽ có hai lần có thể diễn ra vào ngày 2 tháng 11 năm 2014. Trong hầu hết các trường hợp, bạn sẽ muốn chạy ở lần xuất hiện đầu tiên là 1 : 00 AM PDT và bỏ qua lần xuất hiện tiếp theo của 1:00 AM PST cùng ngày. (Nhưng một lần nữa, bạn có thể muốn một chiến lược khác, chẳng hạn như chạy trên lần xuất hiện thứ hai hoặc chạy trong cả hai. YMMV)
Hãy chuẩn bị để tính toán lại tất cả các lần UTC xuất hiện của bạn nếu bạn cần cập nhật dữ liệu múi giờ của mình. Các IANA / Olson TZDB puts ra nhiều bản cập nhật mỗi năm vì các chính phủ về việc thay đổi thế giới tâm trí của họ mọi lúc về offsets múi giờ của họ và các quy tắc tiết kiệm thời gian ban ngày. Bạn không thể giả sử trong bất kỳ khoảng thời gian cụ thể nào trong tương lai rằng các quy tắc sẽ không thay đổi .
Hãy chắc chắn đăng ký nhận thông báo về việc phát hành dữ liệu múi giờ và có một quy trình để áp dụng chúng cho các hệ thống và / hoặc ứng dụng của bạn.
Trong môi trường doanh nghiệp truyền thống, đây phải là trách nhiệm của nhân viên Hoạt động CNTT.
Tùy thuộc vào môi trường của bạn, bạn có thể nhận được dữ liệu này thông qua các tzdatabản cập nhật gói linux, thông qua Java JRE hoặc tzupdater hoặc bất kỳ số lượng kênh nào khác. Đôi khi, đó là môi trường cụ thể và đôi khi là nền tảng lập trình cụ thể, chẳng hạn như gói PECL được chia thời gian cho PHP và nhiều gói khác.
Microsoft có dữ liệu múi giờ riêng. Trên Windows, nếu bạn đang sử dụng TimeZoneInfotừ .NET (ví dụ), bạn đang sử dụng dữ liệu này. Các bản cập nhật đến từ đây và cũng được tự động đẩy ra thông qua Windows Update, vì vậy bạn nên theo dõi những thông tin đó để bạn biết khi nào / nếu bạn cần tính toán lại.
Với tất cả điều đó hiểu, có là vẫn còn là một kịch bản mà bạn sẽ lên lịch chỉ bằng cách UTC, và đó là cho ABSOLUTE sự kiện trong tương lai. Ví dụ:
Một công việc chạy mỗi X giờ hoặc mỗi X phút.
Mặt trời mọc bắt đầu và thời gian dừng lại, hoặc hiện tượng thiên văn khác.
Một cửa sổ bảo mật nhạy cảm với thời gian, chẳng hạn như khi truyền thông tin nhạy cảm cho một bên khác tại một thời điểm được sắp xếp trước.
Bộ lập lịch tác vụ Windows
Windows không nhất thiết phải làm điều đúng đắn. Hãy chú ý đến cách bạn xác định kích hoạt:
Khi bạn chọn hộp có nhãn "Đồng bộ hóa giữa các múi giờ", thì tác vụ chỉ được lên lịch bởi UTC. (Tất cả thời gian vẫn được hiển thị là giờ địa phương, nhưng được lưu trữ dưới dạng UTC.) Vì vậy, đây là lần đầu tiên tôi gọi là sự kiện "tuyệt đối".
Khi bạn bỏ chọn hộp đó, nó sẽ sử dụng múi giờ địa phương của máy tính mà mã đang chạy. Nó không cung cấp cho bạn bất kỳ tùy chọn nào để chỉ định múi giờ, vì vậy đó không phải là một triển khai IMHO rất tốt.
Tôi không chắc chắn về hành vi DST của nó, nhưng tôi sẽ thử nghiệm và lấy lại cho bạn về điều đó. Nó có thể làm những gì tôi mô tả ở trên, nhưng không nhất thiết phải như vậy.
Tác nhân SQL
Bộ lập lịch tác nhân SQL thậm chí còn tệ hơn, ở chỗ nó chỉ cho phép bạn sử dụng thời gian máy chủ cục bộ. Một lần nữa, không có múi giờ nào có thể được chỉ định và bạn cũng không thể chỉ định UTC.
Nó đã được yêu cầu , nhưng không được chấp nhận.