Web uygulamamda saat dilimlerini nasıl idare edebilirim?

Aşağıdaki kullanıcı öyküsünü daha iyi anlamak istiyorum:

John, Sidney'de çalışıyor. Sabah saat 9: 00'da, Zürih'teki bir sunucuda çalışan bir web uygulamasına bir etkinlik kaydediyor. Ertesi gün, olayın tartışılması gereken acil bir toplantı için New York'a gider. Toplantı sırasında olayı tarih ve saate göre arar.

Gördüğüm kadarıyla burada en az iki konu var:

1. Veritabanına zaman damgalarını nasıl kaydetmeliyim
2. Bunları kullanıcı arayüzünde nasıl sunmalıyım

John olayı aradığında, saat 9: 00'da olduğunu bilecek, ancak web tarayıcısına ne girmesi gerekiyor? Zaman damgası olarak "9:00" ı girdiğinde hiçbir şey bulamayacak çünkü bu Zürih veya New York saati olabilir (etkinlik bulunamadığından, uygulamanın Sidney'de olduğunu bilmesinin bir yolu yoktur, bu nedenle doğru zaman dilimini otomatik olarak seçemez).

Kullanıcıdan saat dilimini içerebilecek bir zaman damgası istemenin iyi bir yolu nedir?

İkinci konu, sonuçların nasıl görüntüleneceğidir. Dünyanın her yerinden ekiplerin olayı tartışması (ve ilgili olayları bulması gerekiyorsa, aynı anda tüm dünyadaki birkaç siteyi hedef alan bir korsan saldırısı düşünün).

Farklı bir saat diliminde oluşturulmuş olabilecek zaman damgalarını görüntülemek için iyi bir örnek nedir?

Not: Lütfen gereksinimin kullanılabilirliğine odaklanın. Veritabanı eşlemesini kendim çözebilirim. Şu anda iş akışından emin değilim. Gerekli bilgileri müdahaleci olmayan / sezgisel bir şekilde sormalı / sunmalıdır. Yapabiliyorsanız, bunu zaten çözen mevcut bir web uygulamasına bir bağlantı verin.

Zaman damgalarını saklama sorunu basittir: Bunları UTC'de saklayın.

Bunları göstermeye gelince, cihazın saat dilimi ayarını alıp mevcut saat dilimi olarak kullanmak mantıklı olacaktır. Bununla birlikte, "zaman girişi" kutusunun yanında, varsayılan olarak cihazın geçerli saat dilimine ayarlanan bir saat dilimi açılır menüsü olmalıdır, böylece kullanıcı gerekirse bunu değiştirebilir.

Kullanıcılarınızın çoğu muhtemelen saat dilimlerini çok fazla değiştirmeyecek veya hiç değiştirmeyecek. Çoğunlukla, özetlediğiniz durum nadirdir. Uygun bir varsayılana sahip bir açılır menü uygulayarak, etrafta dolaşanlar için işleri yeterince kolaylaştırabilmelisiniz (çünkü saat dilimlerini genellikle gezgin olmayanlara göre daha iyi anlarlar).

Aslında, daha da iyisi, uygulamanız ilk çalıştırıldığında cihazın ayarlandığı saat dilimini kaydetmek ve ardından değişip değişmediğine bakmaktır. Değişirse, kullanıcı muhtemelen bir yolcudur ve muhtemelen saat dilimi açılır menüsüne sahip olmaktan faydalanacaktır. Aksi takdirde, açılır menüyü ve varsayılanı cihaz saat dilimini göstermeyin (çünkü kullanıcının bunları bilmesine gerek yoktur). Her iki durumda da, uygulamada kullanıcının saat dilimi açılır menüsünü manuel olarak göstermesine / gizlemesine izin veren bir ayara sahip olun.

Yukarıdakileri özetlemek gerekirse:

• İlk çalıştırmada, cihazın ayarlandığı saat dilimini kaydedin.
• Bu saat dilimini varsayılan saat dilimi olarak kullanın. Her zaman bu saat dilimini varsayın.
• Cihazın saat dilimlerini değiştirmesi durumunda, etkinliğin hangi saat diliminde olacağını seçmek için bir açılır menü ekleyin, varsayılan olarak cihazın kendi saat dilimini ayarlayın.
• Bu saat dilimi açılır menüsünü manuel olarak göstermek / gizlemek için bir seçenek ekleyin.
• Zaman damgalarını her zaman UTC'de saklayın.

Uygulamalarımızda, forum sitelerinde sıklıkla görüldüğü gibi, genellikle ilk kayıt yaptığımızda kullanıcının saat dilimini saklıyoruz ve her zaman saat dilimi ile saati görüntülüyoruz .

Tarihleri ​​saklamaya gelince, UTC gitmenin yoludur. UTC'ye dönüştürün ve veritabanına yapıştırın. Alırken, saati kullanıcı için ayarlanan saat dilimine dönüştürmeniz yeterlidir.

"Yeni Yılınız Kutlu Olsun" gibi özelleştirilmiş bildirimlerin web uygulamasının tüm kullanıcılarına gönderilebileceği benzer bir kullanım örneğini çözmem gerekiyordu. Kullanıcılar dünya çapında dağıldığından, bildirimi saat dilimine göre görüntülememiz gerekiyordu. Zaman damgasını UTC'de saklamak, hıçkırık olmadan amacımıza güzel bir şekilde hizmet etti.

Sizin kullanım durumunuzda, kullanıcı saat dilimini bir yerde saklamıyorsanız, kullanıcı girişi istemeden arama sonuçlarınızı asla doğru bir şekilde döndüremezsiniz, eğer gmaps gibi bir tür konum algılamayı kullanmaya başlamazsanız, ama bu değil ' t güvenilir. Bu nedenle, kullanıcının web sitesine ne girdiğini bildiğinden emin olmak için her seferinde saat dilimini sormanız gerekir.

Saat dilimi bilginiz varsa, web uygulamasının tamamı saat dilimi ayarıyla çalıştırılmalıdır. Dolayısıyla, kullanıcı 9:00 araması yaptığında, Sydney saat dilimiyle arama yapacaktır. Öte yandan, New York'ta otururken bir etkinlik yaratırsa, Sydney saat dilimiyle bir etkinlik yaratacaktır. Bu tür durumları, tarihleri ​​görüntülerken daima saat dilimini göstererek çözüyoruz.

Umarım yardımcı olur! :)

1. UTC. Basit tutun.

2. Kullanıcıyla en alakalı saat dilimini kullanın.

   Kullanıcının etkinlik için Sidney'de olacağını veya Sidney'e gideceğini biliyorsanız, o zaman etkinliğe ulaşım ayarlarken o saat diliminde düşüneceklerdir . Şu anda New York'ta olmaları büyük ölçüde alakasız. Ve tabii ki, uygulamanız tarihleri ​​çeşitli saat dilimlerinde gösteriyorsa, saat dilimini her zaman tarihin yanında göstermelidir, ör. 09:00 EST .

   Arayüzünüzü çok fazla karıştırmazsa tarihleri ​​etkinlik saat diliminde ve yerel saat diliminde görüntüleyebilirsiniz, örneğin 2012-06-13 09:00 EST (2012-06-12 19:00 EDT) .

   Aramanın benzer bir sorun olduğunu iddia ediyorum, bir uyarı: yanlış pozitiflere tahammül edebiliriz (beklemediğimiz bir sonuç elde edebiliriz), ancak yanlış negatiflere dayanamayız (beklediğimiz bir sonucu alamıyoruz).

   Yine, kullanıcı için en alakalı saat dilimini aramaya odaklanırdım (ör. Etkinlik saat dilimi) ve bu sonuçlara arama sonuçlarında öncelik veririm, ancak kullanıcıyla alakalı diğer saat dilimlerinde eşleşen etkinlikleri de döndürebilirsiniz (ör. Yerel zaman). Bunu yaparsanız, özellikle eşleşen metni vurgularsanız, etkinlik tarihini eşleşen saat diliminde göstermelisiniz.

Burada, uygulama fizibilitesi hakkında çok fazla uğraşmadan en iyi kullanılabilirlik için önerilerde bulunuyorum.
1. Olayları db'de depolamanın ilk sayısı için, herkes bunu UTC'de saklamayı kabul eder.

2. En iyi kullanıcı deneyimini sağlamak için kullanıcının saat diliminin geçmişini kaydedin. Saat dilimi değişikliğinin zaman damgasını kaydedebilseydiniz, daha da iyisi. Bu, her seferinde açıkça saat dilimini belirtmeden kullanıcıya sorgulama özgürlüğü vermemizi sağlayacaktır.

Bu özelliklerle, John'un yalnızca "9.00" arama sorgusunun nasıl işleneceğini görelim:
Yukarıda belirtilen özelliklerle, John'un tarihe kadar 2 saat diliminde olduğunu biliyorum (veya belirtilen dönem için saat dilimleri listesini alın). Bu yüzden, 9.00'u Sydney saat diliminden UTC'ye çevireceğim, bir sorgu başlatacağım. Ayrıca 9.00'ı NewYork saat diliminden UTC'ye dönüştürün, bir sorgu çalıştırın. Sonuç olarak, John'a Sydney'de 9.00'da ve New York'ta 9.00'da yaptıklarını gösteren 2 satır göstereceğim. Bu durumda New York satırı boş kalacak, ancak yine de kullanıcıya gösterilmesi gerektiğini düşünüyorum, sadece bu saat dilimini de aradığımızı ona bildirmek için.

3. Kullanıcıdan saat dilimini içerebilecek bir zaman damgası istemenin iyi bir yolu nedir?

Saat dilimi yakın zamanda değiştirilmişse, uygulamada her oturum açtığında, varsayılan saat diliminizin yerel saat dilimine değiştirildiğine dair bir bildirim verilmelidir.
Etkinlik oluştururken, kullanıcının aşağı açılır menüden saat dilimini seçtiğini söyleyelim.Dünyanın tüm zaman dilimleri için seçenekler vererek kullanıcıya yük getirmesin. İlk açılır menü seçeneği, kullanıcının cihazının mevcut saat dilimi olmalıdır. daha sonra zaman dilimleri geçmişinden gelen saat dilimlerini, ardından UTC'yi ve ardından bugüne kadar hiç kullanmadığı kalan zaman dilimlerini.

4. Dünyanın her yerinden ekiplerin olayı tartışması gerekiyorsa sonuçlar nasıl görüntülenir:

Bu kullanım örneğini 2 veya 2'den fazla takım sayısına bölmek istiyorum.
Sadece 2 takım için, her takımın kendi yerel saat diliminde ve diğer takımın saat diliminde zaman damgasını görmesini tercih ederim. (Ben şahsen bir toplantı planlarken rahatlığı için diğer uçtaki kişinin zaman diliminde konuşmayı tercih ederim). 2'den fazla takım için, daha yaygın bir saat dilimini, yani UTC'yi düşünmek daha iyidir. Dolayısıyla bu durumda, her kullanıcı zaman damgasını 2 saat diliminde, UTC'de ve varsayılan saat diliminde görmelidir.

Bu öneriler, kullanıcının yerel saatinde herhangi bir hesaplama yapması gerekmediği, ancak aynı zamanda diğer kullanıcılarla tercih ettikleri saat diliminde akıcı bir şekilde iletişim kurabilmesi amacıyla verilmiştir.

Tamam, diğerlerinden farklı bir yaklaşımım var:

İlk olarak, önceden birkaç şeyi varsaydım.

Bir olayı listeleyen kişinin akıllı telefonu vardır (bu bir tarayıcıysa, bu varsayımları yapmak zorunda değilim):

1. Küresel Konumlama Sistemi

2. HTML5 yeteneği.

3. Javascript yeteneği

Zaman damgalarını veritabanına nasıl kaydetmeliyim?

Çözüm: Açıkçası UTC , aşağıdaki prosedürü ekledim:

1. Adım Geolocation API kullanarak kullanıcının Coğrafi Konumunu kullanın

    window.onload = getMyLocation;

    function getMyLocation() {
        if (navigator.geolocation) {
            navigator.geolocation.getCurrentPosition(displayLocation);
        } else {
            alert("Oops, no geolocation support");
        }
    }

    function displayLocation(position) {
        var latitude = position.coords.latitude;
        var longitude = position.coords.longitude;
        var div = document.getElementById("location");
        div.innerHTML = "You are at Latitude: " + latitude + ", Longitude: " + longitude;
    }

Adım 2. (Uzun, Enlem) ifadesini (Lat, Long) bazılarına (Lat, Long) Yahoo API gibi TimeZone API'sine verin Kullanıcıların saat dilimini almak için (Latitude'u Timezone'a dönüştürmek için Flag R'yi kullanın ( .

=> Kullanıcıların saat dilimi, kullanıcı girişi olmadan belirlenir (Bunu kullanıyorum çünkü kullanıcının yaşadığı yerin saat dilimini bildiğini varsayamazsınız, saat dilimimi ancak birkaç ay sonra veya oradaki bir şeyden sonra biliyordum: P, oldukça aptal! )

Her bir Event tablosunda Timezone, Event& bu nedenle, CityName ' CityNameye göre sınıflandırmayla başka bir veritabanı tablosu oluşturabilir . Yani burada kullanıcının iki sütunu olacak

|---------------------------------------|
|_____NewYork________|______Sydney______|
|                    |                  |
|Event 1             |  Event 2         |
|____________________|__________________| 

UI için

=> Google Takvim API'sini veya Takvim API'lerinden bazılarını kullanın

İlgili Okumalar:

1. Geonames.org gibi web hizmetlerini kullanmadan enlem / boylamdan saat dilimini belirleyin

2. Enlem boylamdan saat dilimi araması

Bunun sadece bu sorunun nasıl çözüleceğini göstermekle ilgili olduğunu biliyorum. Ancak, Saat dilimi cihaz API'leri kullanılarak belirlendiğinde kullanıcılar üzerinde ne kadar doğru ve hafif hale geldiğini görün

Umarım yardımcı olur!

Bu özel durum için hem yerel hem de UTC saatini kaydederdim. UTC biraz büyüktür ve zamanın senkronizasyonu ve mevcut saat dilimine dönüştürülmesi için kullanılır. Yerel, aşağıdakiler gibi aramalar ve ek bilgiler için kullanılır:

Bir toplantınız var:

12:00 Monday (UTC)
9:00 Monday (Sydney, creation local time)
11:00 Monday (Zurich, local time)

ya da böyle bir şey. Diğer yol, oluşturma saat dilimini depolamak ve çalışma zamanında dönüştürmektir (bu, kullanıcının toplantı saatini değiştirmesi durumunda özellikle daha iyidir). Her iki durumda da ana neden, orijinal oluşturma zamanını geri yükleyebilmektir, böylece kullanıcı buna bakabilir.

1. Veritabanına zaman damgalarını nasıl kaydetmeliyim

Etkinlik oluştururken, UTC saatini ve yerel saat dilimini (aka creation time zone) kaydederdim . UTC saatini yerel saate (aka creation time) dönüştürmek ve UTC saatiyle birlikte saklamak için sakladığım şeyi kullanırdım vecreation time zone .

NOT: Başlangıçtan itibaren yerel saati kaydedebilirim, ancak kullanıcı bir olay için arama yaptığında, yerel saate bir dönüşüm olmasını umuyorum. Ayrıca sunucunun istemcinin hangi saat diliminde olduğunu algılayacağını umuyorum.

1. Bunları kullanıcı arayüzünde nasıl sunmalıyım

"9:00" için arama yaptığında, ben UTC birinde "9:00" include etkinlikleri aramak ne zaman YA creation time YA yerel saat. Sonuçlar için, içinde bir sonuç tablosu görüntüleyecektim creation time(Bu, kullanıcının nerede olursa olsun ne zaman etkinlik oluşturduğunu aradığını varsaydığımız için, farklı bir saat diliminde oluşturulmuş olabilecek zaman damgalarını göstermeyi amaçlamaktadır.) ve ilgili sonuçları içeren ikinci bir sonuç tablosunu, belki de "Aradığınız bu değil mi? İlgili sonuçları görün" başlığıyla birlikte görüntüleyin (bunlara kalan UTC ve yerel saat sonuçları dahildir).

Genel olarak, UTC saatini, yerel saati, creation timeve creation time zone(yani, oluşturulduğu etkinliğin yerel saati ve zaman dilimi) UTC saatine göre sıralanmış şekilde görüntülenirim, böylece iki farklı durumda hangi olayın önce geldiğini görebilirsiniz. etkinlikler iki farklı saat diliminde 9:00 için planlandı.