Bagaimana cara menangani zona waktu di aplikasi web saya?

Saya mencari pemahaman yang lebih baik tentang kisah pengguna berikut:

John bekerja di Sidney. Pada pukul 9:00 pagi, dia mencatat peristiwa di aplikasi web yang berjalan di server di Zurich. Keesokan harinya, dia melakukan perjalanan ke New York untuk pertemuan darurat di mana acara tersebut harus dibahas. Selama pertemuan, dia mencari acara tersebut berdasarkan tanggal dan waktu.

Menurut saya, setidaknya ada dua masalah di sini:

1. Bagaimana cara menyimpan stempel waktu di database
2. Bagaimana cara menampilkannya di UI

Ketika John mencari acara tersebut, dia akan tahu bahwa itu terjadi pada jam 9:00 tetapi apa yang harus dia masukkan di browser web? Dia tidak akan menemukan apa pun ketika dia hanya memasukkan "9:00" sebagai cap waktu karena itu mungkin waktu Zurich atau New York (karena acara tersebut belum ditemukan, aplikasi tidak memiliki cara untuk mengetahui bahwa itu terjadi di Sidney, jadi tidak dapat secara otomatis memilih zona waktu yang benar).

Apa cara yang baik untuk meminta stempel waktu kepada pengguna yang mungkin menyertakan zona waktu?

Masalah kedua adalah bagaimana menampilkan hasilnya. Jika tim dari seluruh dunia perlu mendiskusikan acara tersebut (dan menemukan acara terkait, pikirkan serangan cracker yang menargetkan beberapa situs di seluruh dunia sekaligus).

Apa contoh yang baik untuk menampilkan stempel waktu yang mungkin telah dibuat di zona waktu yang berbeda?

Catatan: Harap berkonsentrasi pada kegunaan persyaratan. Saya bisa mengetahui sendiri pemetaan database. Saat ini, saya tidak yakin dengan alur kerjanya. Ini harus menanyakan / menyajikan informasi yang diperlukan dengan cara yang tidak mengganggu / intuitif. Jika Anda bisa, berikan tautan ke aplikasi web yang ada yang sudah menyelesaikan masalah ini.

Masalah menyimpan cap waktu sederhana: Simpan di UTC.

Untuk menampilkannya, sebaiknya gunakan pengaturan zona waktu perangkat dan gunakan sebagai zona waktu saat ini. Karena itu, harus ada tarik-turun zona waktu di sebelah kotak "masukan waktu", yang secara default ke zona waktu perangkat saat ini, sehingga pengguna dapat mengubahnya jika diperlukan.

Mayoritas pengguna Anda mungkin tidak akan banyak mengubah zona waktu, atau sama sekali. Sebagian besar, situasi yang Anda uraikan tidak umum. Dengan menerapkan tarik-turun dengan default yang sesuai, Anda seharusnya dapat mempermudah mereka yang bergerak (karena mereka biasanya memiliki pemahaman yang lebih baik tentang zona waktu daripada yang bukan wisatawan).

Bahkan, yang lebih baik adalah menyimpan zona waktu yang disetel perangkat saat aplikasi Anda pertama kali dijalankan, lalu melihat apakah itu pernah berubah. Jika memang berubah, maka pengguna mungkin seorang musafir dan mungkin akan mendapat manfaat dari tarik-turun zona waktu. Jika tidak, jangan tampilkan dropdown dan default ke zona waktu perangkat (karena pengguna tidak perlu mengetahuinya). Dalam kedua kasus tersebut, miliki setelan di aplikasi yang memungkinkan pengguna untuk secara manual menampilkan / menyembunyikan tarik-turun zona waktu.

Untuk meringkas di atas:

• Saat pertama kali dijalankan, simpan zona waktu perangkat yang disetel.
• Gunakan zona waktu itu sebagai zona waktu default. Selalu asumsikan zona waktu itu.
• Jika perangkat berganti zona waktu, tambahkan dropdown untuk memilih zona waktu acara, secara default ke zona waktu perangkat itu sendiri.
• Tambahkan opsi untuk menampilkan / menyembunyikan tarik-turun zona waktu ini secara manual.
• Selalu simpan stempel waktu dalam UTC.

Dalam aplikasi kami, kami biasanya menyimpan zona waktu pengguna ketika kami pertama kali mendaftar, seperti yang sering dilihat di situs forum, dan selalu menampilkan waktu dengan zona waktu .

Untuk menyimpan tanggal, UTC adalah cara yang tepat. Konversikan ke UTC dan tempelkan ke database. Saat mengambil, cukup ubah waktu ke zona waktu yang disetel untuk pengguna.

Saya harus menyelesaikan kasus penggunaan serupa, di mana pemberitahuan yang disesuaikan, seperti "Selamat Tahun Baru", dapat dikirim ke semua pengguna aplikasi web. Karena pengguna tersebar di seluruh dunia, kami perlu menampilkan notifikasi sesuai dengan zona waktu. Menyimpan stempel waktu di UTC dengan baik membantu tujuan kami, tanpa cegukan.

Dalam kasus penggunaan Anda, jika Anda tidak menyimpan zona waktu pengguna di suatu tempat, Anda tidak akan pernah dapat mengembalikan hasil pencarian Anda secara akurat tanpa meminta masukan pengguna, kecuali Anda mulai menggunakan semacam deteksi lokasi seperti yang dilakukan gmaps, tetapi itu tidak benar. t dapat diandalkan. Jadi, Anda harus menanyakan zona waktu setiap saat untuk memastikan pengguna mengetahui apa yang dia masukkan di situs web.

Jika Anda memiliki informasi zona waktu, seluruh aplikasi web harus dijalankan dengan pengaturan zona waktu. Karenanya, saat pengguna menelusuri pukul 9.00, dia akan menelusuri dengan zona waktu Sydney. Di sisi lain, jika dia membuat acara sambil duduk di New York, dia akan membuat acara dengan zona waktu Sydney. Kami menyelesaikan kasus seperti itu dengan selalu menampilkan zona waktu sambil menampilkan tanggal.

Semoga membantu! :)

1. UTC. Tetap sederhana.

2. Gunakan zona waktu yang paling relevan bagi pengguna.

   Jika Anda tahu pengguna akan masuk atau bepergian ke Sydney untuk acara tersebut, maka mereka akan berpikir di zona waktu tersebut saat mengatur transportasi ke acara tersebut. Fakta bahwa mereka saat ini di New York sebagian besar tidak relevan. Dan tentu saja, jika aplikasi Anda menampilkan tanggal dalam berbagai zona waktu, itu harus selalu menampilkan zona waktu di sebelah tanggal, misalnya 09:00 EST .

   Jika itu tidak terlalu mengacaukan antarmuka Anda, Anda dapat menampilkan tanggal dalam zona waktu acara dan zona waktu lokal, misalnya 2012-06-13 09:00 EST (2012-06-12 19:00 EDT) .

   Saya berpendapat bahwa pencarian adalah masalah yang serupa, dengan satu peringatan: kami dapat mentolerir positif palsu (mendapatkan hasil yang tidak kami harapkan), tetapi kami tidak tahan dengan negatif palsu (tidak mendapatkan hasil yang kami harapkan).

   Sekali lagi, saya akan fokus pada pencarian zona waktu yang paling relevan dengan pengguna (misalnya zona waktu acara), dan memberikan hasil ini prioritas dalam hasil pencarian, tetapi Anda juga dapat mengembalikan peristiwa yang cocok di zona waktu lain yang relevan dengan pengguna (mis. waktu lokal). Jika Anda melakukan ini, Anda harus menunjukkan tanggal acara di zona waktu yang cocok, terutama jika Anda menyorot teks yang cocok.

Di sini saya memberikan saran untuk kegunaan terbaik tanpa banyak repot tentang kelayakan implementasi.
1. Untuk edisi pertama menyimpan acara di db, semua orang setuju untuk menyimpannya di UTC

2. Untuk memberikan pengalaman pengguna terbaik, simpan riwayat zona waktu pengguna. Jika Anda dapat menyimpan stempel waktu perubahan zona waktu, lebih baik lagi. Ini akan memungkinkan kami memberikan kebebasan kepada pengguna untuk melakukan kueri tanpa menentukan zona waktu secara eksplisit setiap saat.

Jadi dengan fitur-fitur ini, mari kita lihat bagaimana permintaan pencarian hanya "9.00" oleh John akan ditangani:
Dengan fitur yang disebutkan di atas, sekarang saya tahu bahwa John telah berada di 2 zona waktu hingga tanggal (atau dapatkan daftar zona waktu untuk periode yang disebutkan). Jadi saya akan menyembunyikan 9.00 dari zona waktu Sydney ke UTC, aktifkan kueri. Juga ubah 9,00 dari zona waktu NewYork ke UTC, aktifkan kueri. Hasilnya saya akan menunjukkan 2 baris kepada John yang menunjukkan apa yang dia lakukan pada pukul 9.00 di sydney dan pukul 9.00 di new york. Dalam kasus ini, baris New york akan kosong, tetapi saya pikir masih harus ditampilkan kepada pengguna, hanya untuk memberi tahu dia bahwa kami juga mencari zona waktu ini.

3. Apa cara yang baik untuk menanyakan stempel waktu kepada pengguna yang mungkin menyertakan zona waktu?

Jika zona waktunya baru-baru ini diubah, setiap kali dia masuk ke aplikasi, pemberitahuan harus diberikan bahwa, zona waktu default Anda diubah ke zona waktu asli.
Saat membuat acara, katakanlah pengguna memilih zona waktu dari drop-down. Jangan membebani pengguna dengan memberikan opsi semua zona waktu dunia. Opsi drop-down pertama harus zona waktu perangkat pengguna saat ini. setelah zona waktu tersebut dari histori zona waktu, kemudian UTC dan zona waktu tersisa yang belum pernah ia gunakan hingga saat ini.

4. Bagaimana cara menampilkan hasil, jika tim dari seluruh dunia perlu mendiskusikan acara tersebut:

Saya ingin membagi kasus penggunaan ini antara jumlah tim 2 atau lebih dari 2.
Untuk hanya 2 tim, saya lebih suka setiap tim melihat stempel waktu dalam zona waktu lokalnya dan zona waktu tim lain. (Saya pribadi lebih suka berbicara dalam zona waktu orang di ujung lain untuk kenyamanannya saat menjadwalkan pertemuan). Untuk lebih dari 2 tim, lebih baik mempertimbangkan zona waktu yang lebih umum yaitu UTC. Jadi dalam kasus ini, setiap pengguna harus melihat stempel waktu dalam 2 zona waktu, dalam UTC dan dalam zona waktu default-nya.

Saran ini diberikan dengan maksud agar pengguna tidak perlu melakukan perhitungan dalam waktu lokalnya tetapi pada saat yang sama ia harus dapat berkomunikasi dengan pengguna lain dengan lancar di zona waktu pilihan mereka.

Ok saya mendapat pendekatan yang berbeda dari yang lain:

Pertama, saya mengasumsikan beberapa hal sebelumnya.

Orang yang mendaftarkan acara memiliki ponsel cerdas (jika itu adalah browser, saya tidak perlu membuat asumsi ini) dengan:

1. GPS

2. Kemampuan HTML5.

3. Kemampuan Javascript

Bagaimana cara menyimpan stempel waktu di database?

Solusi: Jelas UTC , saya melapisi prosedur di bawah ini:

Langkah 1. Gunakan Geolocation pengguna menggunakan Geolocation API

    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;
    }

Langkah 2. Berikan (Bujur, Lintang) sebagai argumen untuk beberapa api (Lintang, Bujur) ke TimeZone seperti Yahoo API (gunakan Bendera R untuk mengubah Latitude menjadi Zona Waktu) untuk mendapatkan zona waktu pengguna.

=> Zona waktu pengguna ditentukan tanpa input pengguna (Saya menggunakan ini karena Anda tidak bisa begitu saja berasumsi bahwa pengguna mengetahui zona waktu tempat dia tinggal, saya tahu zona waktu saya hanya setelah beberapa bulan atau sesuatu di tempat itu: P, sangat bodoh! )

Setiap tabel Peristiwa memiliki Timezone, Event& juga dapat memiliki CityName Kemudian membuat tabel database lain dengan klasifikasi berdasarkan CityNames. Jadi di sini pengguna akan memiliki dua kolom

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

Untuk UI

=> gunakan API Google Kalender atau beberapa API Kalender

Bacaan Terkait:

1. Tentukan zona waktu dari lintang / bujur tanpa menggunakan layanan web seperti Geonames.org

2. Pencarian zona waktu dari bujur lintang

Saya tahu ini hanya tentang menunjukkan beberapa ide bagaimana menyelesaikan masalah ini. Namun lihat seberapa akurat & ringannya pengguna saat Zona Waktu ditentukan dengan menggunakan API perangkat

Semoga membantu!

Untuk kasus khusus itu saya akan menyimpan keduanya waktu setempat dan UTC. UTC agak utama dan digunakan untuk sinkronisasi dan konversi waktu ke zona waktu saat ini. Lokal digunakan untuk pencarian dan info tambahan, seperti:

Anda ada rapat:

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

atau semacam itu. Cara lainnya adalah dengan menyimpan zona waktu pembuatan, dan mengonversi pada waktu proses (ini lebih baik jika pengguna akan mengubah waktu rapat). Apa pun alasannya, alasan utamanya adalah untuk dapat memulihkan waktu pembuatan asli sehingga pengguna dapat merujuknya.

1. Bagaimana cara menyimpan stempel waktu di database

Pada pembuatan acara, saya akan menyimpan waktu UTC dan zona waktu lokal (alias creation time zone). Saya akan menggunakan apa yang saya simpan untuk mengubah waktu UTC menjadi waktu lokal (alias creation time) dan menyimpannya bersama waktu UTC dancreation time zone .

CATATAN: Saya dapat menyimpan waktu lokal sejak awal, tetapi ketika pengguna melakukan pencarian untuk suatu acara, saya berharap ada konversi ke waktu lokal. Saya juga berharap server dapat mendeteksi di zona waktu mana klien berada.

1. Bagaimana cara menampilkannya di UI

Saat pengguna menelusuri "9:00", saya akan mencari acara yang menyertakan "9:00" baik dalam UTC ATAU creation time ATAU waktu lokal. Untuk hasilnya, saya akan menampilkan satu tabel hasil di creation time(Ini dimaksudkan untuk menampilkan stempel waktu yang mungkin telah dibuat di zona waktu yang berbeda, karena kami berasumsi pengguna mencari untuk jam berapa dia membuat acara di mana pun dia berada.) , dan tampilkan tabel hasil kedua di bawah dengan hasil terkait, mungkin dengan tajuk, "Bukan yang Anda cari? Lihat hasil terkait" (ini termasuk UTC dan hasil waktu lokal yang tersisa).

Secara keseluruhan, saya akan menampilkan waktu UTC, waktu lokal, itu creation time, dan creation time zone(yaitu waktu lokal dan zona waktu acara tempat acara itu dibuat) diurutkan berdasarkan waktu UTC, sehingga Anda dapat melihat acara mana yang lebih dulu, jika dua berbeda acara dijadwalkan pukul 9:00 di dua zona waktu berbeda.