Penjadwalan tugas masa depan yang tepat berdasarkan waktu setempat, dengan mempertimbangkan zona waktu akun dan waktu musim panas, adalah subjek yang sangat kompleks. Saya telah menulis tentang ini sebelumnya dari perspektif pemrograman Stack Overflow di sini dan di sini .
Saya akan meringkas dari perspektif non-pemrograman:
Tentukan pola perulangan Anda menurut waktu setempat - bukan UTC . Misalnya, jika Anda mengatur jam alarm harian untuk membangunkan Anda pada jam 8:00 pagi setiap hari, Anda tidak ingin bangun satu jam lebih awal atau satu jam terlambat setelah transisi waktu musim panas. Jika saya berada di zona waktu AS Pasifik, saya tidak dapat menjadwalkan untuk pukul 16:00 UTC, karena setelah transisi itu harus beralih ke jam 3:00 UTC untuk menjaga waktu yang sama pukul 8:00 pagi waktu setempat.
Tetapkan zona waktu yang diwakili oleh waktu "lokal". Jangan berasumsi bahwa zona waktu lokal server adalah zona waktu yang sama yang penting bagi pengguna akhir.
Proyeksikan waktu setempat ke tanggal dan waktu UTC untuk setiap kejadian yang Anda inginkan untuk acara tersebut.
Anda hampir selalu melakukan ini untuk kejadian langsung berikutnya, sehingga Anda dapat menggunakan jam UTC untuk menentukan waktu instan yang sebenarnya untuk dijalankan.
Dalam beberapa kasus, Anda mungkin ingin juga memproyeksikan beberapa (atau banyak) kejadian berikutnya, seperti 5 kejadian berikutnya, atau semua kejadian untuk tahun berikutnya. (Bagian ini sangat spesifik untuk persyaratan aplikasi.)
Memiliki strategi di tempat (baik tetap atau dapat dikonfigurasi), apa yang harus dilakukan untuk kejadian yang jatuh pada saat transisi waktu musim panas :
Untuk transisi "lompatan maju", ada celah waktu lokal yang hilang ketika kejadian mungkin tidak ada. Misalnya, di Waktu Pasifik AS, tugas harian yang dijadwalkan berjalan pada pukul 02:00 waktu setempat tidak akan ada pada tanggal 9 Maret 2014. Dalam kebanyakan kasus, Anda akan ingin memajukan waktu itu dengan jumlah penghematan (biasanya 1 jam) ), jadi pada hari itu akan berjalan pada jam 3:00 pagi, tetapi akan kembali berjalan pada jam 2:00 pada contoh berikutnya. (Namun, sangat mungkin Anda menginginkan strategi yang berbeda untuk ini.)
Untuk transisi "mundur", ada tumpang tindih waktu lokal yang digandakan saat kejadian mungkin ada dua kali . Misalnya, di Waktu Pasifik AS, tugas harian yang dijadwalkan berjalan pada pukul 1:00 pagi akan memiliki dua waktu yang mungkin bisa dijalankan pada 2 November 2014. Dalam kebanyakan kasus, Anda akan ingin menjalankan pada kejadian pertama 1 : 00 AM PDT dan lewati kejadian berikutnya pukul 1:00 PST pada tanggal yang sama. (Tetapi sekali lagi, Anda mungkin menginginkan strategi yang berbeda, seperti menjalankan pada kejadian kedua, atau menjalankan keduanya. YMMV)
Bersiaplah untuk menghitung ulang semua kejadian UTC Anda jika Anda perlu memperbarui data zona waktu Anda. The IANA / Olson TZDB menempatkan keluar beberapa update setiap tahun karena pemerintah perubahan dunia pikiran mereka sepanjang waktu tentang mereka offset zona waktu dan daylight saving aturan waktu. Anda tidak dapat mengasumsikan untuk jangka waktu tertentu di masa depan bahwa aturan tidak akan berubah .
Pastikan untuk berlangganan pengumuman rilis data zona waktu, dan miliki proses untuk menerapkannya pada sistem dan / atau aplikasi Anda.
Dalam lingkungan perusahaan tradisional, ini harus menjadi tanggung jawab staf Operasi TI.
Tergantung pada lingkungan Anda, Anda mungkin mendapatkan data ini melalui tzdatapembaruan paket linux, melalui Java JRE atau tzupdater , atau sejumlah saluran lainnya. Terkadang khusus untuk lingkungan, dan terkadang khusus untuk platform pemrograman, seperti paket PECL timezonedb untuk PHP , dan banyak lainnya.
Microsoft memiliki data zona waktu sendiri. Di Windows, jika Anda menggunakan TimeZoneInfodari .NET (misalnya), Anda menggunakan data ini. Pembaruan datang dari sini , dan juga didorong keluar melalui Pembaruan Windows secara otomatis, jadi Anda harus mengawasi mereka sehingga Anda tahu kapan / jika Anda perlu menghitung ulang.
Dengan semua itu dipahami, ada adalah masih sebuah skenario di mana Anda akan menjadwalkan hanya dengan UTC, dan itu adalah untuk MUTLAK peristiwa masa depan. Contoh:
Pekerjaan yang dijalankan setiap X jam atau setiap X menit.
Waktu mulai dan berhenti matahari terbit, atau fenomena astronomi lainnya.
Jendela keamanan peka waktu, seperti ketika mengirimkan informasi sensitif ke pihak lain pada waktu yang telah diatur sebelumnya.
Penjadwal Tugas Windows
Windows tidak selalu melakukan hal yang benar. Perhatikan bagaimana Anda mendefinisikan pemicu:
Saat Anda mencentang kotak yang berlabel "Sinkronisasi lintas zona waktu", maka tugas dijadwalkan hanya oleh UTC. (Semua waktu masih ditampilkan sebagai waktu lokal, tetapi disimpan sebagai UTC.) Jadi ini untuk yang sebelumnya saya sebut sebagai acara "absolut".
Saat Anda membiarkan kotak itu tidak dicentang, kotak itu akan menggunakan zona waktu lokal di komputer tempat kode itu berjalan. Itu tidak memberi Anda opsi untuk menentukan zona waktu, jadi itu bukan IMHO implementasi yang sangat baik.
Saya tidak yakin dengan perilaku DST itu, tetapi saya akan bereksperimen dan menghubungi Anda mengenai hal itu. Mungkin melakukan apa yang saya jelaskan di atas, tetapi tidak harus.
Agen SQL
Penjadwal SQL Agent bahkan lebih buruk, karena hanya memungkinkan Anda menggunakan waktu server lokal. Sekali lagi, tidak ada zona waktu yang dapat ditentukan, dan Anda juga tidak dapat menentukan UTC.
Telah diminta , tetapi tidak diterima.