เว็บไซต์ของฉันมีกิจกรรมที่กำหนดโดยผู้ใช้เป็นประจำ ตอนนี้เรากำลังใช้เขตเวลา EDT (หรือ EST) ของเราเป็นเขตเวลาพื้นฐานสำหรับกิจกรรมทั้งหมดในไซต์ ฉันรู้สึกว่านี่เป็น 1) ผิดหรือ 2) สับสนมาก ขณะนี้เรามีผู้ใช้งานอยู่ทั่วสหรัฐอเมริกาและยุโรป
วิธีการที่เหมาะสมในการแปลเวลาตามโซนเวลาของลูกค้าหรือไม่ ใช้ UTC / GMT?
ขอบคุณ
คำตอบ:
สุจริตนี่เป็นปัญหาหนึ่งที่พบเห็นบ่อยครั้งเมื่อมีเว็บไซต์ที่ใช้ในหลายเขตเวลา มีหลายวิธีในการเอาชนะการต่อสู้ เพื่อสรุป badp มีปัจจัยหลายอย่างที่สนับสนุนการดำเนินการกับเขตเวลาที่แตกต่างกัน
เว็บไซต์ส่วนใหญ่เลือกใช้หนึ่งในสองวิธีแก้ไขเพื่อแก้ไขปัญหานี้:
1) เก็บทุกอย่างที่เกี่ยวข้องกับวันที่เป็น UTC ในฐานข้อมูล ... และอนุญาตการตั้งค่าที่ผู้ใช้กำหนดสำหรับผู้ใช้บนเว็บไซต์ของคุณเพื่อเลือกเขตเวลาที่พวกเขาอยู่ใน ... หรือใช้เวทมนตร์ทางภูมิศาสตร์เพื่อค้นหา พวกเขาอยู่ที่ไหนในโลกและค้นหาเขตเวลาที่เหมาะสม ... จากนั้นทุกครั้งที่คุณแสดงวันที่ ... ต้องแน่ใจว่าได้เรียกฟังก์ชั่นที่จำเป็นสำหรับการแปล เกือบทุกภาษาการเขียนโปรแกรมมีวิธีการบางอย่างสำหรับการแสดงวันที่โดยใช้เขตเวลาที่กำหนด คุณจะต้องทำเช่นนี้ย้อนกลับสำหรับผู้ใช้แทรกวันที่ (ใช้เวลาท้องถิ่นและแปลงกลับเป็น UTC สำหรับการจัดเก็บฐานข้อมูล) นี่อาจเป็นวิธีการทั่วไป สิ่งนี้จะช่วยให้คุณประหยัดเวลาได้มากจากการพยายาม "คิดค้นล้อใหม่" เท่าที่ผู้เข้าชมที่ไม่ระบุชื่อไป ... คุณสามารถ A) ติดกับ EST / EDT (โดยใช้ฟังก์ชั่นการโทรในตัวสำหรับการแสดงตามความเหมาะสม) หรือ B) เปลี่ยนกลับเป็น Geo-IP-Lookup สิ่ง & เลือกเขตเวลาตามการคาดเดาที่มีการศึกษา เป็นความคิดที่ดีที่จะระบุเขตเวลาที่คุณแสดงวันที่ / เวลาเสมอเช่นไม่เคยพูดว่า "12:00" ... ตรวจสอบให้แน่ใจว่าได้ระบุว่า "12:00 EDT"
หรือ 2) ติดตามโมเดลของ stackexchange (และอื่น ๆ อีกมากมาย) เพื่อแสดงความแตกต่างระหว่างตอนนี้ & เมื่อโพสต์ถูกสร้างขึ้น ie แทน "โพสต์ในวันที่ x" ... คุณจะทำ "x ชั่วโมงก่อน" หรือ "x วัน x ชั่วโมงที่ผ่านมา" ฯลฯ ... หรือสำหรับวันที่ในอนาคต ... "ใน 6 วัน 14 ชั่วโมง ... " สิ่งนี้ กำลังกลายเป็นเรื่องธรรมดาไปอย่างรวดเร็วในหลาย ๆ สถานการณ์ ... แต่ไม่เหมาะสำหรับกำหนดการประเภทปฏิทิน
แน่นอน ... คุณยังคงสามารถใช้ไฮบริดของทั้งสองได้ ... และคุณอาจจำเป็นต้องก้าวต่อไปอีกขั้นและเก็บวันที่เป็น utc ... แต่ยังเก็บโซนเวลาเฉพาะสำหรับเหตุการณ์ ในที่สุดการตัดสินใจเป็นของคุณ
นี่คือปัญหา: สหภาพยุโรปและสหรัฐอเมริกาไม่เปิดและปิด DST ในเวลาเดียวกัน มีนาคมนี้มีความแตกต่างสามสัปดาห์ระหว่างเหตุการณ์เหล่านี้
นี่คือสิ่งที่เกิดขึ้นในช่วงเวลานี้ สมมติว่าคุณมีกิจกรรมทุกวันในเวลาเดียวกันและเนื่องจากคุณอยู่ในสหรัฐอเมริกาคุณจะปรับเวลาโดยใช้ US DST
Day (2001) United States Europe United Kingdom Global Time delta
March 5th EST 1500 CET 2100 GMT 2000 GMT 2000 +23h
March 6th EDT 1500 CET 2000 GMT 1900 GMT 1900 +24h
March 7th EDT 1500 CET 2000 GMT 1900 GMT 1900 +24h
..............................................................................
March 26th EDT 1500 CET 2000 GMT 1900 GMT 1900 +24h
March 27th EDT 1500 CEST 2100 BST 2000 GMT 1900 +24h
ลองวิเคราะห์ความเป็นไปได้ทั้งหมด:
หากคุณแสดงเวลาในเขตเวลาทั่วโลกและเรียกว่าUTCซึ่งรู้สึกว่าถูกต้องคุณจะสับสนกับลูกค้าชาวอเมริกันที่กำลังดูเวลา UTC ที่ต่างกัน (เมื่อวานนี้เวลา 20.00 น. วันนี้เวลา 19.00 น.) เวลานาฬิกาแขวนที่เหมือนกัน (เมื่อวานนี้เวลา 15.00 น. วันนี้เวลา 15.00 น. อีกครั้ง) จากนั้นลูกค้าจากสหภาพยุโรปของคุณที่ไม่เห็นการเปลี่ยนแปลงเวลานาฬิกาที่โพสต์และยังต้องเปลี่ยนเวลากิจกรรมนาฬิกาแขวนของพวกเขา
หากคุณแสดงเวลาในเขตเวลาทั่วโลกและเรียกว่าGMTนอกจากจะทำให้ลูกค้าในสหรัฐฯสับสนแล้วคุณยังจะสับสนกับลูกค้าชาวอังกฤษที่เปลี่ยนจาก GMT เป็น BST เป็นเรื่องง่ายที่จะเข้าใจว่า EDT 1500 และ EST 1400 เป็นช่วงเวลาเดียวกัน ตอนนี้แปลเป็น BST / GMT (ด้วยปัญหาเพิ่มเติมที่คุณจะไม่แสดง BST ครั้งในส่วนใดส่วนหนึ่งของเว็บไซต์)
หากคุณแสดงเขตเวลาในเขตเวลาของสหภาพยุโรป (ฉันใช้CET / CESTเพื่อหลีกเลี่ยงความสับสนในเวลา GMT / UTC) เห็นได้ชัดว่ามันจะสร้างความสับสนอย่างมากให้กับลูกค้าในสหรัฐอเมริกาของคุณที่เห็นเหตุการณ์เปลี่ยนไปมาสองครั้ง เวลาของนาฬิกาเปลี่ยนไปเอง ในขณะที่ลูกค้าในสหรัฐอเมริกาของคุณอาจเตรียมพร้อมที่จะเปลี่ยนครั้งแรก (หลังจากพวกเขาต้องเปลี่ยนนาฬิกาแขวนผนังในวันเดียวกัน) พวกเขาจะต้องประหลาดใจในตอนหลัง
หากคุณแสดงเขตเวลาในเขตเวลาของสหรัฐอเมริกา (เช่นEST / EDT ) คุณจะต้องอธิบายสถานการณ์ที่ถูกต้องข้างต้น แต่สะท้อนให้เห็น!
ดูเหมือนว่าจะเป็นสถานการณ์ที่สิ้นหวัง! นี่คือวิธีที่ฉันพูดถึงหลังจากผ่านไปสี่ปีที่จะผ่านแท่นขุดเจาะนี้ (สองครั้งต่อปีอย่างชัดเจน): "สร้างเขตเวลา"
ฉันอยู่ในสถานการณ์ที่เป็นภาพด้านบนดังนั้นฉันจึงสร้าง "NYT" (New York Timezone) เพื่อให้ฉันสามารถเขียน "1500 NYT" เพื่อหมายถึง "15.00 น. ในเขตเวลาใดก็ตามที่นิวยอร์กกำลังใช้งานอยู่"
นี่เป็นข้อได้เปรียบที่ตราบใดที่ผู้ใช้รู้ว่าเวลา DST กำลังเกิดขึ้นเขามีวิธีที่ง่ายมากในการแปลงไปมาในเขตเวลาของตนเอง: google " เวลาในนิวยอร์ก " เพื่อดูเวลาที่อยู่ในนิวยอร์ก จากนั้นทำงานจากที่นั่น คุณสามารถได้รับแฟนซีและการใช้บริการตำแหน่งทางภูมิศาสตร์ที่ใช้เช่นtime.is/15:00_in_New_York
โปรดทราบว่าในขณะที่คุณสามารถใช้ชื่อตัวย่อของเขตเวลาใน time.is ฉันขอแนะนำให้คุณทำเพราะพวกเขาค่อนข้างสับสนเกี่ยวกับมันทั้งหมด: EST มีเวลาเดียวกับ EDT ‽
คุณสามารถแจ้งผู้ใช้เกี่ยวกับ DST ด้วยการแจ้งเตือนสั้น ๆ โดยเชื่อมโยงไปยังเว็บเซอร์แปลงเวลาที่เหมาะสมเพื่อช่วยเหลือผู้คน เป็นการดีที่การประทับเวลาทั้งหมดควรมีตัวเลือกที่จะแปลงเป็นเวลาท้องถิ่น
เมื่อทุกคนพูดและทำเสร็จแล้วคุณควรตระหนักว่าฉันไม่สนใจช้างในห้องตลอดเวลาและนั่นคือทางออก "นับถอยหลัง" ที่คุณได้ทำไปแล้ว ไม่มีอะไรสับสนเกี่ยวกับ "ใน 1 วัน 2 ชั่วโมง 45 นาที 47 วินาที" (และถ้าคุณเชื่อว่าคุณไม่ต้องการความแม่นยำมากคุณอาจต้องคิดอีกครั้ง )
แน่นอนว่าจากประสบการณ์ของฉันฉันไม่เคยมีความหรูหราของสิ่งที่ไม่ใช่ข้อความคงที่ดังนั้นฉันต้องจัดการกับระเบียบที่ไม่น่าเชื่อดังที่กล่าวไว้ข้างต้น (และนั่นเป็นเพียงจุดเริ่มต้นของมัน! แต่สำหรับกรณีการใช้งานของคุณดูเหมือนว่าโซลูชันจะมีความสับสนน้อยที่สุด คุณอาจได้รับสองกระทู้ต่อปีถามเกี่ยวกับเหตุการณ์ "ใน 23 ชั่วโมง" และ "ใน 25 ชั่วโมง" ในขณะที่ปกติจะนับจาก "ใน 24 ชั่วโมง" แต่นั่นก็เป็น