เขตเวลาท้องถิ่นบนเซิร์ฟเวอร์ถือว่าอันตรายหรือไม่? [ปิด]

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

1. ใช้เสมอเสมอใช้ UTC
2. ใช้ทุกครั้งเสมอใช้เขตเวลาของทุกแห่งที่ฐานหลักอยู่
3. ใช้เวลาท้องถิ่นของผู้ที่กำลังจะบริหาร
4. ใช้เวลาท้องถิ่นของที่ตั้งเซิร์ฟเวอร์

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

คุณใช้อะไร คุณคิดว่าอะไรคือข้อดีและข้อเสียของแต่ละวิธี

• นาฬิกาฮาร์ดแวร์ควรเป็น UTC เสมอ.
• เขตเวลาในการตั้งค่าสามารถเป็นอะไรก็ได้ที่สะดวก มักจะ บางครั้งควรเป็น UTC

สาเหตุบางประการที่ UTC ดี:

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

ฉันชอบตัวเลือก 4 เป็นความรับผิดชอบของแอปพลิเคชันที่ทำงานบนเซิร์ฟเวอร์เพื่อตัดสินใจว่าจะเก็บค่า DateTime ใน UTC หรือไม่

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

ไม่ไม่ไม่กี่พันครั้ง

มีสองประเภทของโปรแกรมเมอร์ ... บรรดาผู้ที่เข้าใจ localtime ที่ควรจะใช้สำหรับการแสดงผล / การจัดรูปแบบวัตถุประสงค์เฉพาะและผู้ที่วาดภาพตัวเองในมุม ... และพวกเขาวาดภาพด้วยน้ำมันก๊าด

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

คิดว่ามันเหมือนกับการตรวจสอบมัวหมอง ... หากคุณแปลง timespec เป็น localtime แล้วทำทุกอย่างที่ไม่ปล่อยให้เป็น STDOUT โปรแกรมของคุณไม่ควรเพียงแค่ออกจากข้อผิดพลาดร้ายแรงเท่านั้น แต่ยังลบแหล่งข้อมูลของคุณเพื่อสอน คุณเป็นบทเรียน

เมื่อได้รับตัวเลือกฉันชอบเก็บนาฬิกา BIOS ไว้ใน UTC แต่เวลาเซิร์ฟเวอร์จริงเป็นเวลาท้องถิ่น เราไม่มีการปรากฏตัวของหลายเขตเวลาดังนั้นการลงเวลาบันทึกการทำงานแบบรวมจึงไม่เป็นปัญหาสำหรับ 3M

ใน บริษัท ของฉันเรามีเซิร์ฟเวอร์ทั้งหมดใน TZ เดียวจนถึงปีนี้ ตอนนี้เรามีเซิร์ฟเวอร์ใน 3 เขตเวลาใหม่ เซิร์ฟเวอร์ทั้งหมดทำงานด้วยเขตเวลาท้องถิ่นของเรา สิ่งนี้มีประโยชน์มากสำหรับการวิเคราะห์บันทึกโดยเฉพาะอย่างยิ่งเมื่อเรามีเว็บไซต์ที่เผยแพร่ในสามเขตเวลา

อย่างไรก็ตามในกรณีพิเศษหนึ่งกรณีเราได้ทิ้งเซิร์ฟเวอร์ไว้กับลูกค้า TZ ของเรา แอปพลิเคชันน่าจะเป็นเกือบตลอดทั้งวันและงานบำรุงรักษามักจะตั้งค่าให้ทำงานในช่วง "กลางคืน" ตอนแรกเราตั้งเซิร์ฟเวอร์ใน TZ ของเรา แต่งานบำรุงรักษาช้าลงมากเกินไปสำหรับคนที่เรารัก "เราทำงานเมื่อคุณหลับ" ลูกค้า ...

UTC เป็นตัวเลือกที่ดีมาก นอกเสียจากว่าผู้คนจะอ้างถึงเขตเวลาท้องถิ่นเสมอเมื่อดูบันทึก (ซึ่งเป็นกรณีในที่นี้)

ฉันใช้งานเซิร์ฟเวอร์ทั้งหมดของฉันใน UTC และฉันแปลงสิ่งใดก็ตามที่เข้ามาในการควบคุมของฉันโดยเร็วที่สุด

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