Поддержка часового пояса клиентской стороны в GWT

Я работаю над приложением GWT, где мне нужно поддерживать следующий сценарий:
Сервер находится в часовом поясе A
Клиентский браузер настроен на часовой пояс B
Приложение GWT настроено на отображение даты/времени в часовом поясе C

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

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

Спасибо!

ОТВЕТЫ

Ответ 1

По моему опыту, следующая передовая практика значительно снижает сложность и путаницу при работе с датами и часовыми поясами в gwt:

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

Для вашего случая, когда вы создаете дату на сервере (часовой пояс A), конвертируйте его в миллисекунды с эпохи в GMT перед отправкой его клиенту. На клиенте используйте DateTimeFormat (или напишите свой собственный формат dateatter util), чтобы преобразовать его в любой часовой пояс B или часовой пояс C, если это необходимо.

Ответ 2

Вы не можете изменить часовой пояс GWT, поэтому весь java.util.Date имеет часовой пояс браузера. Вам нужно будет вручную отрегулировать текущий часовой пояс.

Я вижу 3 варианта:

  • Вы сами управляете преобразованием часового пояса.

  • Вы переопределяете сериализатор/десериализатор java.util.Date, например в этом сообщении. И, возможно, используя пользовательскую java.util.Date, которая переопределяет getTimezoneOffset(). Этот подход требует перекомпиляции API GWT!.

  • Вы реализуете свою собственную дату, либо расширяя java.util.Date (как в варианте 2), либо обертывая ее некоторый часовой пояс. В этом варианте CustomFieldSerializer может по-прежнему быть полезным, но нет необходимости перекомпилировать GWT API.

Я бы предпочел вариант 3. По крайней мере до тех пор, пока GWT RPC, возможно, когда-нибудь не поддержит отмену

CustomFieldSerializer <

Полезные подсказки для форматирования даты и времени

Ответ 3

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

UTCDateBox - обертка вокруг GWT DateBox и всегда выбирает дату в полночь в GMT и представляет значение как длинное, а не Дата.

UTCTimeBox - новый виджет, который всегда выбирает время в миллисекундах с полуночи, независимо от часового пояса, также представлен как Long.

UTCDateTimeUtils - Код на стороне сервера, который разбивает дату на 2 Длинные значения, соответствующие UTCDateBox и UTCTimeBox в заданном TimeZone и объединяет их назад в Дату в заданный TimeZone.

Ниже приведен пример даты использования элементов управления временем.

Статья в блоге, описывающая их реализацию.

Эти виджеты доступны в GitHub.

Ответ 4

Я предполагаю, что вы используете вызовы RPC для связи между сервером и клиентом. Также предполагая, что вам не нужен часовой пояс B, и вы знаете, на какой временной зоне C находится сервер.

У вас есть несколько вариантов:

  • Рассчитайте нужную дату на сервере (нет ограничений Java на то, что вы можете там сделать) и отправьте ее в String, который будет отображаться клиенту, поэтому вам больше не нужно делать преобразования на клиенте.

или

  • Рассчитать смещение между часовым поясом A и C на сервере, применить его ко всем объектам Date, которые вы передаете клиенту, и просто отобразить их на клиенте.

если по какой-то причине ни один из них не был действителен для вас

  • Рассчитать смещение, отправить его клиенту и применить его к любой дате, получаемой с сервера, путем преобразования в ms, добавления смещения и последующего создания объекта Date.

Ответ 6

Я создал GWT-совместимую версию Java jsTimezoneDetect Javascript library специально для этой цели. Это должно обеспечить (очень хорошее предположение) название часового пояса исключительно на стороне клиента. Не стесняйтесь попробовать и сообщить мне, работает ли это или не работает для вас.