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

Ответ 1

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

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

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

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

Подведем итог выше:

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

Ответ 2

• UTC. Держите его простым.

• Используйте часовой пояс, наиболее подходящий для пользователя.

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

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

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

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

Ответ 3

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

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

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

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

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

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

Ответ 4

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

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

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

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

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

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

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

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

Ответ 5

Хорошо, у меня другой подход, чем у других:

Во-первых, я принял несколько вещей перед собой.

Лицо, у которого есть событие, имеет смартфон (если это браузер, мне не нужно делать эти предположения):

• GPS

• Возможности HTML5.

• Возможности Javascript

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

Решение: Очевидно, UTC, я наложил следующую процедуру:

Шаг 1. Используйте Геолокация пользователя с помощью 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, чтобы получить Локатор, преобразованный в Часовой пояс), чтобы получить часовой пояс пользователей.

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

Каждая таблица событий имеет Timezone, Event и поэтому также может иметь CityName Затем создайте другую таблицу базы данных с классификацией на основе CityName s. Итак, здесь пользователь будет иметь два столбца

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

Для UI

= > используйте API календаря Google или некоторые из API календаря

Связанные записи:

• Определите часовой пояс из широты/долготы без использования веб-сервисов, таких как Geonames.org

• Поиск по часовому поясу из долготы широты

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

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

Ответ 6

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

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

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

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

Ответ 7

• Как сохранить метки времени в базе данных

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

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

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

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

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