เซิร์ฟเวอร์ควรตั้งค่าเขตเวลาเป็น GMT / UTC หรือไม่ [ปิด]

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

อะไรคือข้อดีและข้อเสียที่มีทั้งหมด / ส่วนใหญ่ของเซิร์ฟเวอร์ของคุณใน UTC? แน่นอนว่ามันจะช่วยในการรายงานและการบันทึกจากส่วนกลาง นอกจากนี้ยังมีความสัมพันธ์ของเหตุการณ์สำหรับการแก้ไขปัญหาหรือตรวจสอบความปลอดภัย หนึ่งยังไม่ต้องกังวลมากเกี่ยวกับการเปลี่ยนแปลงเวลาออมแสง

ข้อเสียอย่างหนึ่งคือการตั้งเวลาเหตุการณ์อัตโนมัติ (เช่น cron) อาจใช้เวลาสักหน่อยหากคุณต้องการให้มันทำงานที่ "4:00" ในเวลาท้องถิ่นและภูมิศาสตร์ สำหรับเครื่อง Unix-y คุณยังคงมีผู้ใช้อยู่ในเขตเวลาท้องถิ่นโดยการตั้งค่า "TZ" ใน / etc / profile แต่สำหรับผู้ใช้ Windows ที่ RDesktop เป็นเซิร์ฟเวอร์ (ไม่ว่าด้วยเหตุผลใด) พวกเขาติดอยู่กับการดู UTC หรือไม่

เช่นเดียวกับสิ่งต่าง ๆ ส่วนใหญ่ "มันขึ้นอยู่กับ"

• ผู้ดูแลระบบ / ผู้ใช้ทั้งหมดของคุณอยู่ในเขตเวลาเดียวกันหรือไม่ บางที TZ ของพวกเขาน่าจะเหมาะสม
• เครื่องโต้ตอบกับสภาพแวดล้อมท้องถิ่นหรือไม่? Local TZ อาจดี
• บันทึกทั้งหมดถูกดึงไปยังตำแหน่งศูนย์กลางเพื่อการวิเคราะห์หรือไม่ UTC อาจช่วยได้
• เครื่องสื่อสารกันในเวลาที่สำคัญไหม? UTC อาจช่วยป้องกันปัญหาที่ไม่ตรงกันโง่ ๆ
• ผู้จำหน่ายระบบปฏิบัติการ (มีแนวโน้มมากขึ้นสำหรับอุปกรณ์เครือข่าย) มีข้อเสนอแนะหรือไม่? พิจารณาว่า
• DST จะรบกวนคุณหรือไม่ ใช้ UTC
• คุณคิดว่าอะไรจะทำให้ชีวิตของคุณง่ายขึ้น? ใช้มัน

ฉันได้ทำทุกอย่างของตัวเลือก (Local, UTC, ตามอำเภอใจ แต่สอดคล้องกัน) และชอบ "เวลาท้องถิ่นของโฮมออฟฟิศสำหรับเครื่องทั้งหมด" เนื่องจากเป็นที่ที่ sysadmins และผู้ใช้อยู่แม้ว่าเครื่องจะกระจัดกระจายไปทั่วโลก .

เราตั้งค่าทุกอย่างเป็น GMT มันทำให้ไฟล์บันทึกสัมพันธ์กันในระบบต่าง ๆ ง่ายขึ้น

แต่ฉันคิดว่าเราควรปล่อยเขตเวลาและใช้ GMT สำหรับทุกสิ่ง

อย่างที่คนอื่นพูดมันขึ้นอยู่กับว่า กลุ่มใหญ่มากที่มีประสบการณ์ยาวนานและกว้างขวางในเรื่องนี้ได้รับการชั่งน้ำหนักกลุ่มนี้เป็นกองกำลังทหารทั่วโลกและพวกเขาใช้ UTC (GMT)

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

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

อย่างที่คนอื่นพูดกันไม่มีคำตอบที่ถูกต้อง แต่นั่นเป็นวิธีที่เราใช้ :)

นโยบายที่นี่บอกว่าเครื่องทั้งหมดถูกตั้งเวลาให้กับเขตเวลาท้องถิ่น (เช่นตำแหน่งทางกายภาพ) สิ่งเดียวที่ยุ่งยากก็คือการสร้างความสัมพันธ์กับรายการบันทึกเหตุการณ์ (windows machiens) เนื่องจากเวลาให้ nlocal - logfiles อื่น ๆ ส่วนใหญ่เขียนเวลาใน UTC อย่างไรก็ตาม

แต่สำหรับผู้ใช้ Windows ที่ RDesktop เป็นเซิร์ฟเวอร์ (ไม่ว่าด้วยเหตุผลใด) พวกเขาติดอยู่กับการดู UTC หรือไม่?

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

เรามีเครื่องที่อยู่ในเขตเวลาเดียวที่ตั้งไว้ล่วงหน้า 3 ชั่วโมงเนื่องจากแอปพลิเคชันที่รองรับ

นอกจากนี้เรายังมีนักพัฒนาที่สร้างซอฟต์แวร์ที่คาดว่าจะซิงโครไนซ์ย่อยห้าวินาทีระหว่างเซิร์ฟเวอร์นักพัฒนาที่ใช้เวลาโฆษณา AD สำหรับการซิงค์โดยปริยายและผู้ที่ไม่อยากเขียนข้อผิดพลาดในการตรวจสอบ ความล้มเหลวที่ตามมานั้นเป็นความผิดของผู้ดูแลระบบที่ไม่ได้รักษาเวลาเครือข่ายตามมาตรฐานที่พวกเขาจินตนาการไว้

อย่าทำสิ่งที่เราทำ มันจะทำให้คุณขม

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

แอพ Yeller เผยแพร่บล็อกโพสต์เมื่อเร็ว ๆ นี้ให้คำแนะนำระบบดูแลระบบทั้งหมดให้ใช้ UTC นี่คือข้อความที่ตัดตอนมา:

Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC.

มันเป็นเรื่องตลกที่พูดกันโดยทั่วไปว่าการใช้งาน UTC เท่านั้นจะไม่รบกวนการปรับเวลาตามฤดูกาล (DST) และข้อผิดพลาดที่เกิดขึ้น