На моєму веб-сайті регулярно проводяться заплановані користувачем заходи. Зараз ми використовуємо наш часовий пояс EDT (або EST) як базовий часовий пояс для всіх подій на сайті. Я відчуваю, що це або 1) неправильно, або 2) дуже заплутано. Наразі у нас є користувачі по всьому США та Європі.
Чи є правильним методом локалізації часу на основі часового поясу клієнтів? використовувати UTC / GMT?
Спасибі
Відповіді:
Чесно кажучи, це одне питання, яке часто спостерігається, коли веб-сайт використовується у кількох часових поясах. Існує довгий перелік способів подолання битви. Підсумовуючи Badp, існує багато факторів, що сприяють, як обробляються різні часові пояси.
Більшість веб-сайтів вирішують цю проблему в одному з двох різних рішень:
1) Зберігайте в базі даних що-небудь, пов’язане з датою, як UTC, і дозвольте користувачеві на вашому веб-сайті налаштування, яке визначає користувач, вибирати, в якому часовому поясі вони перебувають ... або виконувати магію гео-ip-пошуку, щоб дізнатися де вони знаходяться у світі, і знайдіть відповідний часовий пояс ..., а потім кожного разу, коли ви показуєте дату ..., переконайтесь, щоб зателефонувати будь-якій функції, необхідній для локалізації. Майже в кожній мові програмування є певний метод відображення дат за допомогою визначеного часового поясу. Ви також повинні зробити це в зворотному порядку для користувачів, які вставляють дати. (візьміть місцевий час і перетворіть назад на UTC для зберігання БД) Це, мабуть, найбільш поширений підхід. Це також заощадить вам багато часу від спроб "переосмислити колесо". Що стосується анонімних відвідувачів ... Ви можете або A) дотримуватися EST / EDT (використовуючи вбудовані виклики функцій для відображення у відповідних випадках), або B) повернутися до речі Geo-IP-Lookup і вибрати часовий пояс на основі освіченої здогадки. Це також гарна ідея завжди вказувати часовий пояс, у якому відображаються дата / час, тобто ніколи не кажіть "12:00" ... переконайтеся, що на ньому написано "12:00 EDT"
або 2) Дотримуйтесь моделі stackexchange (та багатьох інших), щоб відобразити різницю між тепер і коли створено повідомлення. тобто замість "розміщено на x дата" ... ви зробите "x годин тому" або "x днів x годин тому" тощо) або для майбутніх дат ... "за 6 днів 14 годин ..." Це швидко стає більш поширеним для багатьох ситуацій ... але не є ідеальним для графіків типу календаря.
Звичайно ... ви все одно можете прийняти якийсь гібрид із двох ... і вам може знадобитися навіть піти на крок далі і зберігати дати як utc ..., але також зберігати певний часовий пояс для події. Зрештою, рішення за вами.
Ось проблема: ЄС та США не вмикають та вимикають DST одночасно; цього березня між цими подіями була різниця в три тижні.
Ось що відбувається в цей період. Скажімо, у вас щодня відбувається подія в один і той же час, і, оскільки ви знаходитесь у США, ви збираєтесь коригувати час, використовуючи американський 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, сьогодні 7:00) той самий настінний годинник (вчора 15:00, сьогодні знову 15:00), а потім клієнти, які базуються в ЄС, які не бачать зміни розміщених годин і все ж повинні змінити час настінного годинника.
Якщо ви показуєте час у глобальному часовому поясі і називаєте його GMT , окрім того, що заплутати клієнтів у США, ви також заплутаєте клієнтів Великобританії, які переходять із GMT на BST. Суперечливо розуміти, що EDT 1500 і EST 1400 - це однаковий момент часу; тепер перекладіть це на BST / GMT (з додатковою проблемою, що ви не збираєтеся показувати BST раз у будь-якій частині сайту).
Якщо ви відображаєте часовий пояс у часовому поясі ЄС (я використовував CET / CEST, щоб уникнути плутанини GMT / UTC), це, очевидно, буде дуже заплутаним для ваших клієнтів у США, які бачать час події перемикання вперед та назад двічі, але все ще не мають жодної стіни годинний час змінюють себе. Незважаючи на те, що ваші клієнти в США можуть бути готові до першого перемикання (адже вони повинні змінити свої настінні годинники в той же день), вони здивуються останнім.
Якщо ви відображаєте часовий пояс у часовому поясі США (наприклад, EST / EDT ), точна ситуація буде пояснена вище, але відображена!
Це здається безнадійною ситуацією! Ось як я вирішив вирішити це питання через чотири роки перегляду цього ригмаролу (очевидно, двічі на рік): "складай часовий пояс".
Я перебуваю саме в зображеній вище ситуації, тому я склав "NYT" (нью-йоркський часовий пояс), щоб я міг написати "1500 NYT", щоб означати "3pm у будь-який часовий пояс, який у Нью-Йорку використовується".
Ця перевага полягає в тому, що, поки користувач знає, що вальцер DST відбувається, у нього є дуже простий спосіб перетворення туди-сюди до власного часового поясу: google " час у Нью-Йорку ", щоб побачити, який час у Нью-Йорку , тоді працюйте звідти. Ви навіть можете захоплюватися та користуватися послугами на основі геолокації, наприклад time.is/15:00_in_New_York .
Зауважте, що, хоча ви можете використовувати назви абревіатури часових поясів у time.is, я закликаю вас цього не робити, тому що вони самі досить сильно плутають це: EST має той самий час, що й EDT‽
Ви можете сповістити користувачів про DST за допомогою короткого розмиття, посилаючись на відповідну веб-службу перетворення часу, щоб допомогти людям вийти. В ідеалі всі часові позначки повинні мати можливість перетворення на місцевий час.
Коли все буде сказано і зроблено, ви повинні зрозуміти, що я весь час ігнорую слона в кімнаті, і це рішення, яке ви вже реалізували. Немає нічого заплутаного в тому, що "за 1 день 2 години 45 хвилин 47 секунд" (і якщо ви вважаєте, що вам не потрібна така точність, ви можете подумати ще раз ).
Звичайно, в моєму досвіді я ніколи не мав розкоші нічого, що не було статичним текстом, тому мені довелося впоратися з неймовірним безладом, зображеним вище (і це лише початок цього! Як щодо південної емісії, що робить DST назад?) , але для Вашого випадку це виглядає як рішення з найменшим потенціалом для плутанини. Ви можете отримувати дві теми на рік, запитуючи про події "за 23 години" та "за 25 годин", а це нормально відраховується від "через 24 години", але це все.