Отображение даты и времени с учетом часового пояса в веб-приложениях?

Question

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

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

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

Вот пример:

1. Дата хранится в дБ: 1302790667 (Чт, 14 апреля 2011 14:17:47 GMT)
2. Дата конвертации, отображаемая для клиента в центральном часовом поясе: Чт, 14 апреля 09:17:47 2011
3. Дата, которую я действительно хочу отобразить, всегда в восточном часовом поясе: четверг, 14 апреля 10:17:47 2011

В приведенном выше примере легко получить время в формате UTC (# 1) или в текущем часовом поясе пользователя (#2) но получить №3 сложнее.Мои варианты выглядят так:

1. Сохранение смещений или часовых поясов в БД и выполнение расчетов на клиенте - это то, что мы делали в прошлом с .Net, но в клиенте это выглядит еще более беспорядочнымбоковой код - это путь, который мы сейчас пытаемся избежать.
2. Выполните преобразование на сервере и отправьте полную дату для отображения клиенту - клиент получает строку ("Чт, 14 апреля 10:17:472011" ).Это работает, но не очень гибко.
3. Выполните преобразование на сервере, разбейте его на части и отправьте их клиенту, а затем соедините.(«{DayOfWeek: чт, месяц: апрель, день: 14, час: 10, минута: 17}»).Это дает нам правильные данные и дает нам больше гибкости в форматировании даты, но кажется немного неправильным для этого сценария.

Есть другие варианты вариантов?Как другие справляются с подобными ситуациями?Спасибо.

Answer 1

Наши результаты:

1. Я опробовал несколько библиотек, таких как Datejs, MS Ajax и т. Д., И я никогда не был очень доволен ими.Datejs вообще не работал в некоторых из моих тестовых случаев, активно не поддерживается и, похоже, сосредоточился на синтаксическом сахаре, который нам не нужен (date.today (). First (). Thursday (),и т.д.)
2. Мы используем jQuery для базового анализа даты / времени.
3. Я сталкивался с множеством "хакерских" преобразований дат на стороне клиента, большинство из которых касалось только преобразования в UTC, начинал работать нормально, а затем со временем разваливался на некоторыхкрайний случай. Это было 90% решением для многих стандартных UTC-преобразований, но не решило нашу проблему с «произвольным часовым поясом».

Между сложностью кода и преобразованиемдобавив подпрограммы и ошибки, которые они, по-видимому, вызывали, мы решили избегать обработки данных на стороне клиента большую часть времени.Мы выполняем преобразование дат на сервере с нашими существующими процедурами обработки дат и передаем отформатированные даты или информацию в качестве свойств, которые будут использоваться представлением.Если нам нужна отдельная дата, мы просто добавляем другое свойство.Обычно есть только несколько свойств, которые нам нужны одновременно (например, EventDateUTC, EventDateLocal, EventDateAlwaysAustralia и EventDayOfWeek).

Answer 2

Я предлагаю вам заглянуть в библиотеку Datejs .Он предлагает множество расширений для базовых манипуляций с датами в JavaScript, включая метод setTimezone () и гибкие способы преобразования даты в форматированную строку для отображения.

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