Web sitemde düzenli olarak kullanıcı tarafından planlanan etkinlikler var. Şu anda sitedeki tüm etkinlikler için temel saat dilimi olarak saat dilimi EDT (veya EST) kullanıyoruz. Bunun 1) yanlış veya 2) çok kafa karıştırıcı olduğunu hissediyorum. Şu anda ABD ve Avrupa'nın her yerinde kullanıcılarımız var.
Zamanları müşterilerin saat dilimine göre yerelleştirmek için uygun yöntem var mı? UTC / GMT kullanılsın mı?
Teşekkürler
Yanıtlar:
Dürüst olmak gerekirse, bu, bir web sitesi birden fazla zaman dilimi tarafından kullanıldığında sık görülen bir sorundur. Savaşın üstesinden gelmenin uzun bir yolu var. Badp'i özetlemek gerekirse, farklı zaman dilimlerinin nasıl işlendiğine dair birçok katkıda bulunan faktör vardır.
Çoğu web sitesi bu sorunu çözmek için iki farklı çözümden birini seçer:
1) Tarih olarak UTC ile ilgili herhangi bir şeyi veritabanında saklayın ... ve web sitenizdeki kullanıcılar için hangi saat diliminde olduklarını seçmeleri için kullanıcı tanımlı bir ayara izin verin ... dünyanın neresinde olduklarını ve uygun zaman dilimini bulduklarını ... ve sonra tarihi her görüntülediğinizde ... yerelleştirme için gereken her fonksiyonu çağırdığınızdan emin olun. Neredeyse her programlama dilinde, belirli bir saat dilimini kullanarak tarihleri görüntülemek için bazı yöntemler vardır. Ayrıca, tarih ekleyen kullanıcılar için bunu tersine yapmanız gerekir. (yerel zaman ayırın ve DB depolama için UTC'ye dönün) Bu muhtemelen en yaygın yaklaşımdır. Bu aynı zamanda “tekerleği yeniden icat etmeye” çalışmaktan çok zaman kazandıracaktır. Anonim ziyaretçiler gittikçe ... A) EST / EDT (uygun şekilde görüntülemek için yerleşik işlev çağrılarını kullanarak) ile yapışabilir veya B) Geo-IP-Lookup öğesine geri dönebilir ve eğitimli bir tahmine dayanarak bir saat dilimi seçebilirsiniz. Ayrıca, tarih / saati görüntülediğiniz saat dilimini her zaman belirtmek de iyi bir fikirdir. Yani asla "12:00" deme ... "12:00 EDT" yazdığından emin olun.
veya 2) Şimdi ve gönderinin oluşturulma zamanı arasındaki farkı gösteren stackexchange modelini (ve diğer birçok model) izleyin. yani "x tarihinde yayınlanmıştır" yerine ... "x saat önce" veya "x gün x saat önce" vb ... ya da gelecek tarihler için ... "6 gün 14 saat içinde ..." birçok durumda hızla yaygınlaşıyor ... ancak takvim türü zamanlamalar için ideal değil.
Tabii ki ... hala ikisinin bir çeşit melezini benimseyebilirsiniz ... ve bir adım daha ileri gitmeniz ve tarihleri utc olarak depolamanız gerekebilir ... ama aynı zamanda bir etkinlik için belirli bir saat dilimini saklamanız gerekebilir. Sonuçta, karar sizin.
Sorun şu: AB ve ABD aynı zamanda DST'yi açmıyor ve kapatmıyor; bu martta bu olaylar arasında üç haftalık bir fark vardı.
İşte bu dönemde neler oluyor. Diyelim ki her gün aynı saatte bir etkinliğiniz var ve ABD merkezli olduğunuz için, ABD DST'yi kullanarak zamanları ayarlayacaksınız.
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
Tüm olasılıkları analiz edelim:
Saati global bir saat diliminde görüntüler ve bunu doğru bir şey gibi hissettiren UTC olarak adlandırırsanız , aynı duvar saati zamanı (dün 15:00, bugün 15:00) ve daha sonra yayınlanan zaman saati değişikliğini görmeyen ve henüz duvar saati etkinlik saatini değiştirmesi gereken AB tabanlı müşterileriniz .
Saati global bir saat diliminde görüntülerseniz ve GMT olarak adlandırırsanız ABD müşterilerini şaşırtmanın yanı sıra GMT'den BST'ye geçiş yapan İngiltere müşterilerini de karıştırırsınız. EDT 1500 ve EST 1400'ün aynı anda olduğunu anlamak mantıksızdır ; şimdi bunu BST / GMT'ye çevirin (ek sorunla sitenin herhangi bir bölümünde BST kez göstermeyeceksiniz).
Saat dilimini bir AB saat diliminde görüntülerseniz ( GMT / UTC karışıklığını önlemek için CET / CEST kullandım ), etkinlik zamanının iki kez ileriye doğru gittiğini ve henüz duvar görmediğini açıkça gören ABD müşterileriniz için bu kafa karıştırıcı olacaktır. saat zaman kendilerini değiştirmek. ABD'deki müşterileriniz ilk anahtara hazır olsa da (sonuçta aynı saatte duvar saatlerini değiştirmek zorunda kalıyorlar), ikincisi ise şaşıracak.
Saat dilimini ABD saat diliminde ( EST / EDT gibi ) görüntülerseniz, yukarıda tam olarak açıklanmış, ancak yansıtılmış olacaksınız!
Bu umutsuz bir durum gibi görünüyor! İşte bu teçhizattan dört yıl geçtikten sonra bunu ele almaya geldim (açıkça yılda iki kez): "saat dilimi oluştur."
Ben tam olarak yukarıdaki resimde, bu yüzden "NYT" (New York Timezone) uydurdum, böylece "1500 NYT" yazabilmek için "New York kullanıyor ne olursa olsun 15:00" anlamına gelir.
Bunun avantajı, kullanıcı DST waltzer'ın gerçekleştiğini bildiği sürece, kendi saat dilimine dönüş ve dönüş yapmak için çok basit bir yolu vardır: google " new york'ta saat " in NY'da ne zaman olduğunu görmek için , sonra oradan çalışın. Fantezi olabilir ve time.is/15:00_in_New_York gibi coğrafi konum tabanlı hizmetleri kullanabilirsiniz .
Eğer ederken, unutmayın olabilir time.is içinde zaman dilimi kısaltma adlarını kullanan onlar oldukça tüm bu konuda kafası karışır için ben, kendilerini öyle değil çağırıyorum: EST EDT aynı zamanı var ‽
Kullanıcılara yardımcı olmak için uygun bir zaman dönüşümü web servisine bağlantı vererek, kullanıcıları kısa bir bulanıklık ile DST hakkında bilgilendirebilirsiniz. İdeal olarak tüm zaman damgalarının yerel saate dönüştürülme seçeneği olmalıdır.
Her şey söylendiğinde ve bittiğinde, odadaki fili her zaman görmezden geldiğimi fark etmelisiniz ve bu zaten uyguladığınız "geri sayım" çözümüdür. "1 gün 2 saat 45 dakika 47 saniye" hakkında kafa karıştırıcı bir şey yoktur (ve bu kadar hassas olmaya ihtiyacınız olmadığını düşünüyorsanız tekrar düşünmek isteyebilirsiniz ).
Tabii, deneyimlerime göre, statik metin olmayan bir şeyin lüksüne hiç sahip olmadım, bu yüzden yukarıda gösterilen inanılmaz karışıklığı ele almak zorunda kaldım (ve bu sadece başlangıç ! , ancak kullanım durumunuz için en az karışıklık potansiyeli olan bir çözüm gibi geliyor. Yılda iki kez "23 saatte" ve "25 saatte" olayları sorarken normalde "24 saatte" geri sayar, ancak bu kadar.