งานที่กำหนดเวลาไว้ในช่วงเวลาของการเปลี่ยนแปลงเวลาฤดูใบไม้ร่วง

ฉันสงสัยว่าคนอื่นจัดการกับสถานการณ์นี้อย่างไร

จะเป็นอย่างไรถ้าคุณมีงานที่กำหนดให้ทำงานในเวลา 1:30 น. ในฤดูใบไม้ร่วงเมื่อเวลามีการเปลี่ยนแปลงชั่วโมง 1:00:00 ถึง 1:59:59 นจะทำซ้ำตัวเองและเพื่อให้งานทำงานสองครั้ง

อาจเป็น Windows Task Scheduler, SQL Agent หรือเครื่องมือการตั้งเวลาอื่น ๆ เครื่องมือเหล่านี้ส่วนใหญ่ดูเหมือนจะขึ้นอยู่กับเวลาของเครื่องไม่ใช่เวลา UTC ถ้าฉันบอกให้ทำงานในเวลา UTC ในแต่ละคืนฉันจะไม่ได้รับปัญหาซ้ำซ้อน

การกำหนดเวลาที่เหมาะสมของงานในอนาคตตามเวลาท้องถิ่นโดยคำนึงถึงเขตเวลาของบัญชีและการปรับเวลาตามฤดูกาลเป็นเรื่องที่ซับซ้อนมาก ผมเคยเขียนเกี่ยวกับเรื่องนี้ก่อนที่จะจากมุมมองของการเขียนโปรแกรมบนกองมากเกินที่นี่และที่นี่

ฉันจะสรุปจากมุมมองที่ไม่ใช่การเขียนโปรแกรม:

• กำหนดรูปแบบการเกิดซ้ำของคุณโดยท้องถิ่นเวลา - ไม่ UTC ตัวอย่างเช่นหากคุณตั้งนาฬิกาปลุกรายวันเพื่อปลุกคุณเวลา 8:00 น. ทุกวันคุณไม่ต้องการตื่นนอนหนึ่งชั่วโมง แต่เช้าหรือหนึ่งชั่วโมงหลังจากการเปลี่ยนเวลาตามฤดูกาล ถ้าฉันอยู่ในโซนเวลาของสหรัฐอเมริกาในแปซิฟิกฉันไม่สามารถกำหนดเวลาเป็นเวลา 4:00 PM UTC ได้เพราะหลังจากการเปลี่ยนแปลงจะต้องเปลี่ยนเป็น 3:00 PM UTC เพื่อให้เวลาท้องถิ่น 8:00 น. เหมือนเดิม

• กำหนดเขตเวลาที่เวลา "ท้องถิ่น" แทน อย่าคิดว่าเขตเวลาท้องถิ่นของเซิร์ฟเวอร์เป็นเขตเวลาเดียวกันกับผู้ใช้ปลายทาง

• ฉายเวลาท้องถิ่นเป็นวันที่และเวลา UTC สำหรับแต่ละเหตุการณ์ที่คุณต้องการให้เหตุการณ์ดำเนินการ

  • คุณจะทำสิ่งนี้เกือบจะทันทีสำหรับการเกิดขึ้นทันทีถัดไปเช่นคุณสามารถใช้นาฬิกา UTC เพื่อกำหนดเวลาจริงทันทีในการทำงาน

  • ในบางกรณีคุณอาจต้องการฉายอินสแตนซ์ (หรือหลายรายการ) ถัดไปเช่นเหตุการณ์ 5 รายการถัดไปหรือเหตุการณ์ทั้งหมดสำหรับปีถัดไป (ส่วนนี้มีความเฉพาะเจาะจงกับข้อกำหนดของแอปพลิเคชัน)

• มีกลยุทธ์ในสถานที่ (ไม่ว่าจะเป็นแบบคงที่หรือกำหนดค่าได้) สิ่งที่ต้องทำสำหรับสิ่งที่เกิดขึ้นในช่วงเวลาของการเปลี่ยนเวลาตามฤดูกาล :

  • สำหรับการเปลี่ยนแปลง "spring forward" มีช่องว่างของเวลาท้องถิ่นที่ขาดหายไปเมื่อไม่มีเหตุการณ์เกิดขึ้น ตัวอย่างเช่นใน US Pacific Time งานประจำวันที่กำหนดให้ทำงานเวลา 2:00 น. ตามเวลาท้องถิ่นจะไม่มีอยู่ในวันที่ 9 มีนาคม 2014 ในกรณีส่วนใหญ่คุณจะต้องเลื่อนเวลานั้นด้วยจำนวนเงินที่ประหยัด (ปกติ 1 ชั่วโมง ) ดังนั้นในวันนั้นจะทำงานเวลา 3:00 น. แต่จะกลับมาทำงานในเวลา 2:00 น. ในอินสแตนซ์ถัดไป (อย่างไรก็ตามเป็นไปได้ทั้งหมดที่คุณจะต้องการกลยุทธ์ที่แตกต่างสำหรับเรื่องนี้)

  • สำหรับทางด้าน "ถอยกลับ" การเปลี่ยนแปลงมีการทับซ้อนของเวลาท้องถิ่นซ้ำเมื่อเกิดขึ้นอาจจะมีอยู่สองครั้ง ตัวอย่างเช่นใน US Pacific Time งานรายวันที่กำหนดให้ทำงานเวลา 1:00 น. จะมีสองครั้งที่เป็นไปได้ที่จะสามารถทำงานได้ในวันที่ 2 พฤศจิกายน 2014 โดยส่วนใหญ่คุณจะต้องทำงานที่เกิดขึ้นครั้งแรกที่ 1 : 00:00 PDT และข้ามการเกิดครั้งถัดไปที่ 1:00 น. PST ของวันเดียวกัน (แต่อีกครั้งคุณอาจต้องการกลยุทธ์ที่แตกต่างกันเช่นทำงานในเหตุการณ์ที่สองหรือทำงานทั้งสองอย่าง YMMV)

• เตรียมพร้อมที่จะคำนวณเวลา UTC ที่เกิดขึ้นใหม่ทั้งหมดของคุณหากคุณจำเป็นต้องอัปเดตข้อมูลเขตเวลาของคุณ IANA / โอลสัน TZDBทำให้ออกการปรับปรุงหลายทุกปีเพราะรัฐบาลของการเปลี่ยนแปลงโลกจิตใจของพวกเขาตลอดเวลาเกี่ยวกับการชดเชยโซนเวลาของพวกเขาและกฎระเบียบประหยัดเวลากลางวัน คุณไม่สามารถสรุปได้ในช่วงระยะเวลาที่เฉพาะเจาะจงใด ๆ ของเวลาในอนาคตว่ากฎจะไม่เปลี่ยนแปลง

  • ต้องแน่ใจว่าได้สมัครรับการประกาศข้อมูลเขตเวลาและมีกระบวนการนำไปใช้กับระบบและ / หรือแอปพลิเคชันของคุณ

  • ในสภาพแวดล้อมดั้งเดิมขององค์กรนี่เป็นความรับผิดชอบของเจ้าหน้าที่ฝ่ายปฏิบัติการด้านไอที

  • คุณอาจได้รับข้อมูลนี้ผ่านtzdataการอัพเดตแพ็คเกจ linux ผ่านJava JRE หรือ tzupdaterหรือช่องทางอื่น ๆทั้งนี้ขึ้นอยู่กับสภาพแวดล้อมของคุณ บางครั้งมันเป็นสภาพแวดล้อมที่เฉพาะเจาะจงและบางครั้งก็เป็นแพลตฟอร์มการเขียนโปรแกรมที่เฉพาะเจาะจงเช่นแพคเกจ timezonedb PECL สำหรับ PHPและอื่น ๆ อีกมากมาย

  • Microsoft มีข้อมูลเขตเวลาของตัวเอง บน Windows ถ้าคุณใช้TimeZoneInfoจาก. NET (ตัวอย่าง) คุณกำลังใช้ข้อมูลนี้ การอัปเดตมาจากที่นี่และจะถูกส่งออกไปทาง Windows Update โดยอัตโนมัติดังนั้นคุณควรจับตามองสิ่งเหล่านั้นเพื่อที่คุณจะได้รู้ว่าเมื่อใด / หากคุณต้องการคำนวณใหม่

• ด้วยความเข้าใจทั้งหมดนี้ยังมีสถานการณ์ที่คุณจะกำหนดเวลาโดย UTC และนั่นเป็นเหตุการณ์ในอนาคตของABSOLUTE ตัวอย่าง:

  • งานที่รันทุก ๆ X ชั่วโมงหรือทุก ๆ X นาที

  • พระอาทิตย์ขึ้นเริ่มต้นและหยุดเวลาหรือปรากฏการณ์ทางดาราศาสตร์อื่น ๆ

  • หน้าต่างความปลอดภัยที่คำนึงถึงเวลาเช่นเมื่อส่งข้อมูลที่ละเอียดอ่อนไปยังบุคคลอื่นตามเวลาที่กำหนดไว้ล่วงหน้า

Windows Task Scheduler

Windows ไม่จำเป็นต้องทำสิ่งที่ถูกต้อง ให้ความสนใจกับวิธีการกำหนดทริกเกอร์:

เมื่อคุณทำเครื่องหมายในช่องที่มีข้อความ "ซิงโครไนซ์ข้ามโซนเวลา" งานจะถูกกำหนดเวลาโดย UTC เท่านั้น (เวลาทั้งหมดยังคงแสดงเป็นเวลาท้องถิ่น แต่ถูกเก็บเป็น UTC) นี่คือสิ่งที่ฉันเรียกว่าเหตุการณ์ "สัมบูรณ์" ก่อนหน้านี้

เมื่อคุณไม่ทำเครื่องหมายในช่องนั้นจะเป็นการใช้เขตเวลาท้องถิ่นของคอมพิวเตอร์ที่มีการเรียกใช้รหัส ไม่ได้ให้ตัวเลือกใด ๆ แก่คุณในการระบุเขตเวลาดังนั้นนั่นจึงไม่ใช่การดำเนินการที่ดีมาก IMHO

ฉันไม่แน่ใจว่ามันเป็นพฤติกรรมของเวลาหรือไม่ แต่ฉันจะทดลองและกลับไปหาคุณในเรื่องนั้น มันอาจเป็นสิ่งที่ฉันอธิบายไว้ข้างต้น แต่ไม่จำเป็น

ตัวแทน SQL

กำหนดการตัวแทนของ SQL จะเลวร้ายยิ่งในการที่จะเพียงช่วยให้คุณใช้เวลาของเซิร์ฟเวอร์ในท้องถิ่น ไม่สามารถระบุโซนเวลาได้อีกและคุณไม่สามารถระบุ UTC ได้

มันได้รับการร้องขอแต่ไม่ได้รับการยอมรับ

โดยไม่ใส่ใจโดยทั่วไป

ถามคำถาม "แล้วจะทำอย่างไรถ้างานรันสองครั้ง"

โดยทั่วไปมันจะไม่สำคัญดังนั้นคุณไม่จำเป็นต้องทำอะไรเลย หากเป็นเรื่องสำคัญทางออกที่ง่ายที่สุดคือการย้ายงานออกจากชั่วโมงที่ได้รับผลกระทบจากการเปลี่ยนเวลาออมแสง

ดังที่คุณได้กล่าวไว้ชั่วโมงระหว่าง 1AM ถึง 2AM เกิดซ้ำเมื่อสิ้นสุดเวลา DST เมื่อการเปลี่ยนแปลงย้อนกลับเกิดขึ้น (จุดเริ่มต้นของ DST) เวลาระหว่าง 2AM ถึง 3AM จะไม่เกิดขึ้น (และงานของคุณจะไม่ทำงาน) ตัวเลือกที่ดีที่สุดของคุณกำลังจะเป็น

• เรียกใช้กำหนดการงานเพื่อ UTC
• เรียกใช้งานในเวลานอกการเปลี่ยนแปลง (12:59 AM หรือ 3AM)