Как я могу обрабатывать часовые пояса в моем webapp?

Question

Я ищу лучшее понимание следующей истории пользователей:

Джон работает в Сиднее. В 9:00 утра он регистрирует событие в веб-приложении, которое выполняется на сервере в Цюрихе. На следующий день он отправляется в Нью-Йорк на экстренное совещание, на котором следует обсудить это событие. Во время встречи он ищет событие по дате и времени.

Как я вижу, есть, по крайней мере, две проблемы:

1. Как я должен сохранить временные метки в базе данных
2. Как я должен представить их в пользовательском интерфейсе

Когда Джон будет искать событие, он узнает, что это произошло в 9:00, но что он должен войти в веб-браузер? Он ничего не найдет, когда он просто вводит «9:00» в качестве отметки времени, потому что это может быть Цюрих или Нью-Йорк (поскольку событие не было найдено, приложение не имеет никакого способа узнать, что это произошло в Сиднее, поэтому он не может автоматически выбрать правильный часовой пояс).

Что такое хороший способ задать пользователю временную метку, которая может включать часовой пояс?

Вторая проблема заключается в том, как отображать результаты. Если команды со всего мира должны обсудить это событие (и найти связанные события, подумайте об атаке взломщика, которая сразу нацеливается на несколько сайтов по всему миру).

Что является хорошим примером для отображения временных меток, которые могли быть созданы в другом часовом поясе?

Примечание: Пожалуйста, сосредоточьтесь на удобстве использования. Я могу выяснить, что такое база данных. В настоящее время я не уверен в работе. Он должен запросить/представить необходимую информацию неинтрузивным/интуитивным способом. Если можно, укажите ссылку на существующее веб-приложение, которое уже решает это.

Answer 1

Проблема хранения временных меток проста: храните их в UTC.

Что касается отображения их, имеет смысл принять настройку часового пояса устройства и использовать его в качестве текущего часового пояса. Тем не менее, рядом с полем «время ввода» должно быть разброс по часовой пояс, который по умолчанию соответствует текущему часовому поясу устройства, поэтому пользователь может его изменить, если это необходимо.

Большинство пользователей, вероятно, не изменят слишком много времени или вообще не будут. По большей части ситуация, о которой вы указали, необычна. Внедряя раскрывающийся список с подходящим значением по умолчанию, вы должны быть в состоянии сделать все достаточно просто для тех, кто перемещается (потому что они, как правило, лучше понимают часовые пояса, чем не-путешественник).

На самом деле еще лучше было бы сохранить часовой пояс, на котором было установлено устройство, когда ваше приложение было впервые запущено, а затем посмотреть, не изменилось ли оно. Если он изменится, тогда пользователь, вероятно, будет путешественником и, вероятно, выиграет от разброса часовой пояс. В противном случае просто не показывайте раскрывающийся список и по умолчанию не указывайте часовой пояс устройства (потому что пользователю не нужно знать о них). В любом случае, у вас есть настройка в приложении, которая позволяет пользователю вручную отображать/скрывать выпадающий список часовых поясов.

---

Резюмируя выше:

• При первом запуске, за исключением того, что часовой пояс устройства установлен в положение.
• Используйте этот часовой пояс как часовой пояс по умолчанию. Всегда предполагайте, что часовой пояс.
• Если устройство переключает часовые пояса, добавьте выпадающий список, чтобы выбрать, в каком временном интервале находится событие, в соответствии с собственным часовым поясом устройства.
• Добавить параметр, чтобы отобразить или скрыть этот временной пояс вручную.
• Всегда сохраняйте временные метки в UTC.

Answer 2

В наших приложениях мы обычно хранить часовой пояс пользователя, когда мы первые регистры, как это часто видели на сайтах форума, и всегда отображают время с часовым поясом.

Что касается хранения дат, UTC - это путь. Преобразуйте в UTC и вставьте его в базу данных. При извлечении просто преобразуйте время в часовой пояс, установленный для пользователя.

Мне пришлось решить аналогичный случай использования, когда настраиваемые уведомления, такие как «С Новым годом», могут быть отправлены всем пользователям веб-приложения. Поскольку пользователи распространяются по всему миру, нам необходимо отобразить уведомление в соответствии с часовым поясом. Хранение временной отметки в UTC прекрасно служило нашей цели, без икоты.

В вашем случае использования, если вы не храните часовой пояс пользователя где-либо, вы никогда не сможете точно вернуть результаты поиска, не запрашивая ввода пользователя, если вы не начнете использовать какое-то определение местоположения, например gmaps, но это ненадежно. Поэтому вам нужно каждый раз запрашивать часовой пояс, чтобы убедиться, что пользователь знает, что он вводит на веб-сайте.

Если у вас есть информация о часовом поясе, все веб-приложение должно запускаться с настройкой часового пояса. Следовательно, когда пользователь выполняет поиск в 9:00, он будет искать часовой пояс в Сиднее. С другой стороны, если он создаст событие, сидя в Нью-Йорке, он создаст событие с часовым поясом Сиднея. Мы решаем такие случаи, всегда отображая часовой пояс при отображении дат.

Надеюсь, это поможет! :)

Answer 3

Для этого конкретного случая я бы поставил как местный, так и UTC. UTC является несколько крупным и используется для синхронизации и преобразования времени в текущий часовой пояс. Локальный используется для поиска и для получения дополнительной информации, как:

У вас есть встреча:

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

или что-то подобное. Другой способ - сохранить часовой пояс создания и преобразовать во время выполнения (это особенно лучше, если тогда пользователь изменит время встречи). В любом случае основная причина заключается в том, чтобы восстановить исходное время создания, чтобы пользователь мог ссылаться на него.

Answer 4

1. Как я должен сохранить временные метки в базе данных

При создании события, я бы хранить UTC время и часовой пояс (ака creation time zone).Я использовал бы то, что я хранил, чтобы преобразовать время UTC в местное время (aka creation time) и сохранить его вместе с временем UTC и creation time zone.

ПРИМЕЧАНИЕ. Я могу сохранить местное время с момента выхода, но когда пользователь выполняет поиск события, я надеюсь, что переход к местному времени существует. Я также надеюсь, что сервер может определить, какой часовой пояс клиент находится в.

1. Как я должен представить их в пользовательском интерфейсе

Когда пользователь ищет «9:00», Я бы искал события, которые включают «9:00» в UTC ORcreation timeOR по местному времени. Для результатов я бы отобразил одну таблицу результатов в creation time (Это предназначено для отображения временных меток, которые могли быть созданы в другом часовом поясе, так как мы предполагаем, что пользователь ищет, во сколько он создал событие, где бы он ни находился.) и отобразить вторую таблицу результатов ниже с соответствующими результатами, возможно, с заголовком: «Не то, что вы ищете? См. соответствующие результаты» (сюда относятся оставшиеся UTC и результаты местного времени).

В целом, я показал бы UTC время, местное время, creation time и creation time zone (т.е. местное время и часовой пояс события, где она была создана) отсортированный по времени UTC, так что вы можете увидеть приходит какое событие во-первых, в случае, если два разных события были запланированы на 9:00 в двух разных часовых поясах.

Answer 5

Здесь я даю советы по наилучшему использованию, не беспокоясь о возможности реализации.
1. Для первого выпуска хранения событий в db все согласны с его сохранением в UTC

2. Чтобы обеспечить наилучший пользовательский опыт, сохраните историю часового пояса пользователя. Если бы вы могли сохранить временную метку изменения часового пояса, еще лучше. Это позволит нам предоставить пользователю возможность запрашивать информацию без явного указания часового пояса каждый раз.

Так с этими функциями, давайте посмотрим, как поисковый запрос просто «9,00» по Джон будет обработан:
С упомянутых выше функций, теперь я знаю , что Джон был в 2 часовых поясов до даты (или получить список временных зон для указанный период). Поэтому я буду скрывать 9.00 от часового пояса Сиднея до UTC, запросить огонь. Также конвертируйте 9.00 из часового пояса NewYork в UTC, запустите запрос . В результате я покажу 2 строки Джону, показывающим, что он сделал в 9.00 в Сидней и в 9.00 в Нью-Йорке. В этом случае строка New york будет пуста, но я думаю, что ее еще нужно показать пользователю, просто чтобы сообщить ему, что мы также искали этот часовой пояс.

3.Что хороший способ запросить у пользователя отметку времени, которая может включать часовой пояс?

Если его часовой пояс недавно изменился, когда он входит в приложении, уведомления следует, что ваш часовой пояс по умолчанию изменяется в родной часовой пояс.
При создании события, скажем, пользователь выбирает часовой пояс из раскрывающегося списка. Позволяет не нагружать пользователя, задавая параметры всех часовых поясов мира.Первым вариантом выпадающего списка должно быть текущее время зона пользовательского устройства. после этого timezones из его истории timezones, затем UTC, а затем остальные часовые пояса, которые он никогда не использовал , используемый до даты.

4.How для отображения результатов, если команды со всего земного шара необходимо обсудить событие:

Я хотел бы разделить этот случай использования между числом команд 2 или более чем 2.
Всего за 2 команды я бы предпочел, чтобы каждая команда увидела timestamp в своем локальном часовом поясе и в часовом поясе другой команды. (I лично предпочитает говорить в часовом поясе человека на другом конце своего удобства при планировании встречи). Для более чем 2 команд, его лучше рассмотреть более общий часовой пояс, то есть UTC. Таким образом, в этом случае каждый пользователь должен видеть временную метку в 2 часовых пояса, в формате UTC и в своем часовом поясе по умолчанию .

Данное предложение дается с намерением, что пользователю не нужно делать расчеты в свое местное время, но при этом он должен свободно общаться с другими пользователями в предпочитаемом вами часовом поясе.

Answer 6

1. UTC. Будь проще.

2. Используйте часовой пояс, который наиболее важен для пользователя.

   Если вы знаете, что пользователь будет находиться в Сиднее или отправиться в него, то они будут мышлением в этот часовой пояс при организации транспортировки к мероприятию. Тот факт, что они в настоящее время находятся в Нью-Йорке, в значительной степени не имеет значения. И, конечно, если ваше приложение показывает даты в разных часовых поясах, оно всегда должно показывать часовой пояс рядом с датой, например. 09:00 EST.

   Если это не слишком сильно мешает вашему интерфейсу, вы можете отображать даты в часовом поясе события и местном часовом поясе, например. 2012-06-13 09:00 EST (2012-06-12 19:00 EDT).

   Я бы сказал, что поиск похож на проблему, с одной оговоркой: мы можем терпеть ложные срабатывания (получить результат, которого мы не ожидали), но мы не можем терпеть ложные негативы (не получив результата, которого мы ожидали).

   Опять же, я бы сосредоточился на поиске наиболее подходящего часового пояса для пользователя (например, часовом поясе) и придавал этим результатам приоритет в результатах поиска, но вы также можете возвращать события, которые соответствуют другим часовым поясам, которые имеют отношение к пользователь (например, местное время). Если вы это сделаете, вы должны показать дату события в соответствующем часовом поясе, особенно если вы выделите соответствующий текст.

Answer 7

Ok я получил другой подход, чем другие:

Во-первых, я предполагал несколько вещей, прежде чем руки.

Человек, который перечисляет событие имеет смартфон (если это браузер, я не должен делать эти предположения) с:

1. GPS

2. возможностей HTML5.

3. Javascript возможность

Как я должен сохранить временные метки в базе данных?

Решение: Очевидно UTC, я обложил порядок ниже:

Шаг 1. С помощью геолокации пользователя с помощью 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; 
    } 

Шаг 2. Раздайте (Long, Lat) в качестве аргументов некоторым из (Lat, Long) для TimeZone api, как Yahoo API (используйте Flag R, чтобы получить Локатор, преобразованный в Timezon e) для получения часового пояса пользователей.

=>пользователей временная зона определяется без ввода данных пользователя (я использую это, потому что вы не можете просто предположить, что пользователь знает часовой пояс места он живет, я знал, что мой часовой пояс только после нескольких месяцев или что-то в том месте, : P, довольно тупой)

каждой таблицы событий имеет Timezone, Event & так же может иметь CityName Затем создать еще одну таблицу базы данных с классификацией, основанной на CityName с. Таким образом, здесь пользователь будет иметь две колонки

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

Для UI

=> использовать Google Calendar API или некоторые из

Связанные чтения Календарь API::

1. Determine timezone from latitude/longitude without using web services like Geonames.org

2. Timezone lookup from latitude longitude

Я знаю его только о показе некоторое представление о том, как решить эту проблему. Но посмотрите, насколько точный & легкий вес становится для пользователей, когда часовой пояс определяется с помощью API устройств

Надеюсь, это поможет!