смещение часового пояса в отображении javascript

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

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

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

Однако это происходит даже на очень простом примере:

var date = '2013-02-05';

var newdate = new Date(date);

console.log(newdate); // Mon Feb 04 2013 16:00:00 GMT-0800 (PST) 

Похоже, что браузер использует переменную date как GMT, и когда я создаю из нее объект даты javascript, он преобразует это время по Гринвичу в мое местное время.

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

Это сбивает с толку, так как существует так много потенциальных ловушек - локаль PHP, локаль mysql или локаль браузера могут повлиять на это и испортить окончательную дату. Любые советы по обеспечению согласованного значения даты приветствуются!


person user101289    schedule 05.02.2013    source источник
comment
Мне пришлось реализовать решение для этого самостоятельно, что было не очень весело, однако я обнаружил, что у меня меньше головной боли: все время хранить все как UTC/GMT вместе с часовым поясом отдельно. Попробуйте привязать часовой пояс к любой дате, которую вы передаете в любом месте, которое не известно как UTC. Дайте пользователям раскрывающийся список для выбора часовых поясов вместо того, чтобы пытаться угадать, если что-то попытается угадать и установить раскрывающийся список часового пояса для предполагаемого пояса, если только они не могут явно установить его на какой-либо странице настроек пользователя или в регистрационной форме. Не совсем ответ, но я надеюсь, что это все равно поможет.   -  person dennmat    schedule 06.02.2013
comment
Любое решение по этому поводу?   -  person Braian Mellor    schedule 16.06.2016


Ответы (1)


Хороший вопрос, обработка часовых поясов - это беспорядок. К счастью, в Javascript есть варианты UTC для большинства своих методов. См. http://en.wikipedia.org/wiki/Coordinated_Universal_Time.

Я думаю, что лучше всего использовать даты UTC везде (кроме пользовательского интерфейса возможно). Убедитесь, что сервер использует и хранит даты UTC, и везде используйте методы javascript UTC. Это первый и самый важный шаг, чтобы вы знали, что даты совпадают.

То, как вы представляете даты в пользовательском интерфейсе, намного менее прямолинейно и отчасти зависит от целевой аудитории, характера приложения и т. д. Я думаю, что это скорее предмет обсуждения и отчасти без ответа в Stack Overflow (есть другие форумы для субъективных размышлений).

Я бы сказал, что не доверяйте браузеру или какой-либо геолокации для автоматического преобразования часовых поясов; он должен настраиваться пользователем или, возможно, для группы/проекта/установки. Некоторое программное обеспечение в основном используется внутри одного часового пояса, и попытка автоматического преобразования часовых поясов может сбивать с толку и раздражать пользователей, если они привыкли общаться в какое-то «стандартное» время. Должен ли пользователь видеть время в другом часовом поясе, если он или она путешествует? Иногда это имеет смысл, иногда нет, но, по крайней мере, убедитесь, что пользователь знает, какой логике вы следуете, как при чтении, так и при вводе времени.

Я разрабатываю программное обеспечение для управления проектами, где важно, чтобы эти вещи однозначно обрабатывались как приложением, так и пользователями (!). Мой подход заключается в том, чтобы всегда использовать UTC как для отображения, так и для ввода. Также в каждой дате четко видно, что это UTC. Работа с разными часовыми поясами быстро утомила бы меня, и я решил, что лучше этого не делать. У меня есть несколько помощников в частях пользовательского интерфейса, которые показывают ту же информацию в местном часовом поясе пользователей и т. Д. Мелким шрифтом. Существует настройка для всего проекта, чтобы «скрыть все вещи, связанные с часовым поясом, и принудительно указать часовой пояс x», который можно использовать в небольших проектах, которые, как известно, никогда не пересекают границы часового пояса, существует соглашение об использовании определенного пояса, или это просто данность, и лучше не беспокоить пользователей такой сложностью.

РЕДАКТИРОВАТЬ: я должен добавить, что в качестве примера того, насколько это может быть волосатым, иногда время - это только время. В некоторых контекстах событие в 15:00 может означать, что оно происходит в 15:00 в разных местах в соответствующих местных часовых поясах. Эээ....

person yaku    schedule 06.02.2013