Zaman dilimlerini ve gün ışığından yararlanma süresini de dikkate alarak gelecekteki görevlerin yerel saate göre uygun şekilde planlanması çok karmaşık bir konudur. Daha önce burada ve burada Stack Overflow üzerine bir programlama perspektifinden yazmıştım .
Programlama dışı bir perspektiften özetleyeceğim:
Yineleme kalıplarınızı UTC'ye değil yerel saate göre tanımlayın . Örneğin, sizi her gün sabah 8: 00'da uyandırmak için günlük bir çalar saat ayarlarsanız, gün ışığından yararlanma saati geçişinden bir saat erken veya bir saat geç uyanmak istemezsiniz. ABD Pasifik saat dilimindeysem, 16:00 UTC için zamanlama yapamıyorum, çünkü geçişten sonra aynı 8:00 AM yerel saatini tutmak için 3:00 PM UTC'ye geçmek zorunda kalacak.
"Yerel" zamanın temsil ettiği saat dilimini tanımlayın. Sunucunun yerel saat diliminin son kullanıcı için önemli olan aynı saat dilimi olduğunu varsaymayın.
Proje Eğer ateşe olayı istedikleri her bir oluşumda bir UTC tarih ve saate yerel saat.
Hemen hemen her zaman bir sonraki olay için yapacaksınız, böylece çalıştırmak için gerçek anı belirlemek için UTC saatini kullanabilirsiniz.
Gelen bazı durumlarda, ayrıca bu tür önümüzdeki 5 olaylar, ya da bir sonraki yıl için geçtiği tüm olarak önümüzdeki birkaç (veya birçok) örneklerini yansıtmak isteyebilir. (Bu bölüm, uygulamanın gereksinimlerine oldukça özeldir.)
Gün ışığından yararlanma saati geçişi sırasında meydana gelen olaylar için ne yapılacağına dair (sabit veya yapılandırılabilir) bir stratejiniz olsun :
"Yay ileri" geçişi için, oluşumun bulunmayabileceği yerel saat eksik bir boşluk vardır. Örneğin, ABD Pasifik Saati'nde yerel saatle 02: 00'da çalışması planlanan günlük bir görev 9 Mart 2014'te mevcut olmayacaktır. Çoğu durumda bu süreyi tasarruf tutarıyla (genellikle 1 saat) ilerletmek istersiniz. ), o gün 3: 00'da çalışır, ancak bir sonraki örnekte 2: 00'da tekrar çalışmaya başlar. (Bununla birlikte, bunun için farklı bir strateji istemeniz tamamen mümkündür.)
"Geri çekilme" geçişi için, oluşumun iki kez var olabileceği yinelenen yerel saatin çakışması vardır . Örneğin, ABD Pasifik Saati'nde, 1: 00'da çalışması planlanan günlük bir görev, 2 Kasım 2014'te çalıştırılabilecek iki olası süreye sahip olacaktır. Çoğu durumda, 1'in ilk tekrarında çalışmak isteyeceksiniz. : 00:00 PDT ve aynı tarihin 1:00 AM PST sonraki oluşumunu atlayın. (Ama yine, sen olabilir böyle ikinci bir oluşum üzerinde çalışan ya da her ikisini de çalışan olarak, farklı bir strateji istiyorum. YMMV)
Saat dilimi verilerinizi güncellemeniz gerekiyorsa, tüm UTC saatlerini tekrar hesaplamaya hazır olun . IANA / Olson TZDB birden güncellemeleri dışarı koyar her yıl nedeniyle saat dilimi uzaklıklar ve yaz saati kuralları hakkında Dünya değişikliği akıllarını her zaman hükümetleri. İleride kuralların değişmeyeceğini belirli bir süre boyunca kabul edemezsiniz .
Saat dilimi verileri sürümlerinin duyuruları için abone olduğunuzdan emin olun ve bunları sistemlerinize ve / veya uygulamalarınıza uygulamak için bir işlem gerçekleştirin.
Geleneksel bir kurumsal ortamda, bu BT Operasyonları personelinin sorumluluğunda olmalıdır.
Ortamınıza bağlı olarak, bu verileri tzdatalinux paket güncellemeleri, Java JRE veya tzupdater veya herhangi bir sayıda başka kanal aracılığıyla alabilirsiniz. Bazen ortama özgüdür ve bazen PHP için timezonedb PECL paketi ve diğerleri gibi programlama platformuna özgüdür .
Microsoft'un kendi saat dilimi verileri vardır. Windows'ta .NET'ten kullanıyorsanız TimeZoneInfo(örneğin), bu verileri kullanıyorsunuz. Güncellemeler buradan gelir ve ayrıca Windows Update aracılığıyla otomatik olarak dışarı itilir, bu yüzden bunları ne zaman yeniden hesaplamanız gerektiğini / bilmeniz gerektiğini bilmeniz gerekir.
Anlaşılan o her ile, orada olduğu hala UTC ile sadece zamanlama verecek bir senaryo ve bunun içindir MUTLAK gelecekteki olayların. Örnekler:
Her X saatte veya X dakikada bir çalışan bir iş.
Gündoğumu başlangıç ve bitiş saatleri veya diğer astronomik fenomen.
Önceden ayarlanmış bir zamanda hassas bilgileri başka bir tarafa iletirken olduğu gibi zamana duyarlı bir güvenlik penceresi.
Windows Görev Zamanlayıcı
Windows mutlaka doğru şeyi yapmıyor. Tetiği nasıl tanımladığınıza dikkat edin:
"Saat dilimleri arasında senkronize et" etiketli kutuyu işaretlediğinizde, görev yalnızca UTC tarafından zamanlanır. (Tüm saatler hala yerel saat olarak gösterilir, ancak UTC olarak saklanır .) Bu yüzden daha önce "mutlak" olay dediğim şey budur.
Bu kutuyu işaretlemeden bıraktığınızda, kodun çalıştığı bilgisayarın yerel saat dilimini kullanır. Size saat dilimini belirtmek için herhangi bir seçenek sunmaz, bu nedenle IMHO çok iyi bir uygulama değildir.
DST davranışından tam olarak emin değilim, ama deneyeceğim ve size bu konuda geri döneceğim. Muhtemelen yukarıda tarif ettiğim şeyi yapıyor, ama mutlaka değil.
SQL Aracısı
SQL Agent zamanlayıcı daha da kötüdür, çünkü sadece yerel sunucu zamanını kullanmanıza izin verir. Yine, hiçbir saat dilimi belirtilemez ve UTC de belirtemezsiniz.
Bu edilmiş istenen ancak kabul edilmedi.