Trang web của tôi có các sự kiện thường xuyên theo lịch trình của người dùng. Ngay bây giờ chúng tôi đang sử dụng múi giờ EDT (hoặc EST) của chúng tôi làm múi giờ cơ sở cho tất cả các sự kiện trên trang web. Tôi cảm thấy như thế này là 1) sai, hoặc 2) rất khó hiểu. Hiện tại, chúng tôi có người dùng trên khắp Hoa Kỳ và Châu Âu.
Là phương pháp thích hợp để bản địa hóa thời gian dựa trên múi giờ của khách hàng? sử dụng UTC / GMT?
Cảm ơn
Câu trả lời:
Thành thật mà nói, đây là một vấn đề thường thấy khi có một trang web được sử dụng bởi nhiều múi giờ. Có một danh sách dài các cách để vượt qua trận chiến. Để tóm tắt badp, có rất nhiều yếu tố góp phần vào cách xử lý các múi giờ khác nhau.
Hầu hết các trang web chọn một trong hai giải pháp khác nhau để giải quyết vấn đề này:
1) Lưu trữ bất cứ thứ gì liên quan đến một ngày như UTC trong cơ sở dữ liệu ... và cho phép cài đặt do người dùng xác định cho người dùng trên trang web của bạn để chọn múi giờ họ đang ở ... hoặc thực hiện một số phép thuật tìm kiếm địa lý để tìm hiểu họ đang ở đâu trên thế giới và tìm múi giờ thích hợp ... và sau đó mỗi khi bạn hiển thị ngày ... hãy đảm bảo gọi bất kỳ chức năng nào cần thiết để bản địa hóa. Gần như mọi ngôn ngữ lập trình đều có một số phương pháp để hiển thị ngày bằng cách sử dụng múi giờ được chỉ định. Bạn cũng sẽ phải làm điều này ngược lại cho người dùng chèn ngày. (lấy giờ địa phương & chuyển đổi trở lại UTC để lưu trữ DB) Đây có lẽ là cách tiếp cận phổ biến nhất. Điều này cũng sẽ giúp bạn tiết kiệm rất nhiều thời gian từ việc cố gắng "phát minh lại bánh xe". Theo như du khách ẩn danh đi ... bạn có thể A) gắn bó với EST / EDT (sử dụng các lệnh gọi hàm tích hợp để hiển thị khi thích hợp) hoặc B) trở lại điều tra cứu Geo-IP & chọn múi giờ dựa trên phỏng đoán có giáo dục. Bạn cũng nên luôn chỉ định múi giờ bạn đang hiển thị ngày / giờ. Tức là không bao giờ nói "12:00" ... đảm bảo rằng nó ghi "12:00 EDT"
hoặc 2) Theo mô hình của stackexchange (và nhiều người khác) về việc hiển thị sự khác biệt giữa bây giờ và khi bài đăng được tạo. tức là thay vì "đăng vào ngày x" ... bạn sẽ làm "x giờ trước" hoặc "x ngày x giờ trước" vv ... hoặc cho những ngày trong tương lai ... "trong 6 ngày 14 giờ ..." Điều này đang nhanh chóng trở nên phổ biến hơn trong nhiều tình huống ... nhưng không lý tưởng cho lịch trình kiểu lịch.
Tất nhiên ... bạn vẫn có thể áp dụng một số loại lai của cả hai ... và bạn thậm chí có thể cần phải tiến thêm một bước và lưu trữ ngày dưới dạng utc ... nhưng cũng lưu trữ múi giờ cụ thể cho một sự kiện. Cuối cùng, quyết định là của bạn.
Đây là vấn đề: EU và Hoa Kỳ không bật và tắt DST cùng một lúc; Tháng ba này, có một sự khác biệt ba tuần giữa các sự kiện này.
Đây là những gì xảy ra trong giai đoạn này. Giả sử bạn có một sự kiện mỗi ngày vào cùng một thời điểm và, vì bạn có trụ sở tại Hoa Kỳ, bạn sẽ điều chỉnh thời gian bằng cách sử dụng DST của Hoa Kỳ.
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
Hãy phân tích tất cả các khả năng:
Nếu bạn hiển thị thời gian theo múi giờ toàn cầu và gọi đó là UTC , cảm giác đó là điều đúng đắn, bạn sẽ nhầm lẫn khách hàng Mỹ của mình, những người sẽ thấy các thời điểm UTC khác nhau (8 giờ tối hôm nay, 7 giờ tối hôm nay) cho cùng giờ đồng hồ treo tường (hôm qua 3 giờ chiều, hôm nay lại 3 giờ chiều), và sau đó khách hàng ở EU của bạn, những người không thấy đồng hồ thời gian đã đăng thay đổi và phải thay đổi thời gian sự kiện đồng hồ treo tường của họ.
Nếu bạn hiển thị thời gian theo múi giờ toàn cầu và gọi nó là GMT , ngoài việc khiến khách hàng Mỹ bối rối, bạn cũng sẽ nhầm lẫn khách hàng ở Vương quốc Anh chuyển từ GMT sang BST. Thật là phản trực giác khi hiểu rằng EDT 1500 và EST 1400 là cùng một thời điểm; hiện dịch nó thành BST / GMT (với vấn đề bổ sung là bạn sẽ không hiển thị thời gian BST ở bất kỳ phần nào của trang web).
Nếu bạn hiển thị múi giờ theo múi giờ EU (tôi đã sử dụng CET / CEST để tránh nhầm lẫn GMT / UTC), điều đó rõ ràng sẽ gây nhầm lẫn cho khách hàng Mỹ của bạn, những người nhìn thấy thời gian sự kiện chuyển đổi qua lại hai lần và không gặp phải sự cố nào đồng hồ thời gian tự thay đổi. Mặc dù khách hàng ở Mỹ của bạn có thể được chuẩn bị cho công tắc đầu tiên (sau tất cả những gì họ phải thay đổi đồng hồ treo tường vào cùng một ngày), họ sẽ ngạc nhiên về việc sau.
Nếu bạn hiển thị múi giờ theo múi giờ của Hoa Kỳ (như EST / EDT ), bạn sẽ có tình huống chính xác được giải thích ở trên, nhưng được nhân đôi!
Đây dường như là một tình huống vô vọng! Đây là cách tôi đến để giải quyết nó sau bốn năm trải qua sự khắc nghiệt này (rõ ràng là hai lần một năm): "tạo nên một múi giờ".
Tôi chính xác là tình huống trong hình trên, vì vậy tôi đã tạo ra "NYT" (Múi giờ New York) để tôi có thể viết "1500 NYT" có nghĩa là "3 giờ chiều trong bất kỳ múi giờ nào mà New York đang sử dụng."
Điều này có lợi thế là, miễn là người dùng biết rằng máy tạo nhịp DST đang diễn ra, anh ta có một cách rất đơn giản để chuyển đổi qua lại theo múi giờ của riêng họ: google " time in new york " để xem giờ nào ở NY , sau đó làm việc từ đó. Bạn thậm chí có thể nhận được ưa thích và sử dụng các dịch vụ dựa trên vị trí địa lý như time.is/15:00_in_New_York .
Lưu ý rằng, trong khi bạn có thể sử dụng tên viết tắt múi giờ trong time.is, tôi yêu cầu ông đừng, vì họ đang khá bối rối về nó tất cả bản thân: EST có thời gian giống như EDT ‽
Bạn có thể thông báo cho người dùng về DST với một số lời giới thiệu ngắn, liên kết đến một dịch vụ web chuyển đổi thời gian thích hợp để giúp mọi người. Lý tưởng nhất là tất cả các dấu thời gian nên có một tùy chọn để được chuyển đổi thành giờ địa phương.
Khi tất cả đã nói và làm xong, bạn sẽ nhận ra rằng tôi đã bỏ qua con voi trong phòng từ lâu và đó là giải pháp "đếm ngược" mà bạn đã thực hiện. Không có gì khó hiểu về "trong 1 ngày 2 giờ 45 phút 47 giây" (và nếu bạn tin rằng bạn không cần chính xác đến mức bạn có thể muốn nghĩ lại ).
Chắc chắn, theo kinh nghiệm của tôi, tôi chưa bao giờ có sự xa xỉ của bất cứ thứ gì không phải là văn bản tĩnh, vì vậy tôi phải xử lý mớ hỗn độn đáng kinh ngạc ở trên (và đó chỉ là khởi đầu của nó! Làm thế nào về phía nam, DST có ngược không?) , nhưng đối với trường hợp sử dụng của bạn, nó có vẻ như là giải pháp ít gây nhầm lẫn nhất. Bạn có thể nhận được hai luồng một năm hỏi về các sự kiện "trong 23 giờ" và "trong 25 giờ" trong khi nó thường đếm ngược từ "trong 24 giờ", nhưng đó là điều đó.