Временная зона и боль

Что такое временная зона и почему с ней столько проблем. Дело даже не в том что в базе данных нужно хранить все даты с привязкой к единой зоне, например UTC+0 или UTC+3 (если вы живете в МСК)

чтобы все даты были в одном формате. Пока отменен переход с зимнего времени на летнее - всё будет спокойно. Если такое произойдет - некоторые события могут сбиться.

Если учесть зону при записи данных либо использовать TIMESTAMP - то таких проблем у вас быть не должно. Ведь получая число секунд с определенной даты - клиент сам представляет дату у себя в своей локальной временной зоне.

Если с сервером всё более менее просто. Один источник текущего времени. То взаимодействие с клиентом может усложниться. Клиент привязан к локальному времени и локальной временной зоне. Может быть ситуация когда на клиенте настроено кривое время (случайно или умышленно). 

Только не говорите что вы никогда не отматывали локальное время вперед на несколько лет чтобы запустить какую-нибудь триальную прогу на месяц чтобы потом вернуть время обратно и пользоваться триалом всё это время

В результате - локальное время на клиенте TIMESTAMP может отличаться от серверного. Но ваша задача - сделать чтобы при взаимодействии с сайтом всё было хорошо. Какие тут могут быть трудности?

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

Как мы выяснили локальное время может быть указано в другой временной зоне. По этому проблема решается если вы передадите с сервера время запуска вместе с временной зоной (date('r')) либо старый добрый timestamp.

В этом случае если у клиента настроена не правильная временная зона - этот вопрос решиться. Но если у клиента сбилось само время - нам это не поможет.

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

Для momentjs инициализация может выглядеть, например, так:

const offset = new Date(serverDate).getTime() - Date.now()
window.moment.now = function() {
  return offset + Date.now()
}

Окей. Кажется большую часть проблем победили

Какие дополнительные подводные камни ждут нас?

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

Тут уже всё индивидуально и общих советов дать не могу. Механизма регулирующего дефолтное время для даты вопреки глобальной временной зоны ОС не обнаружил. Если знаете такие способы - напишите в комментариях

  • Автор: kosmom
  • Рейтинг: 0
  • Просмотров: 556
  • Комментариев: 0
  • Создан: 07.08.2020 16:18

Комментарии (0)

Ваши предложения и пожелания пишите на pro@kosmom.ru

Теги

backup bootstrap core framework eloquent excel home project html ios javascript keep-alive kpi laravel legacy mvp orm php rip scroll timestamp undefined vue vuetify watch безопасность биометрический паспорт ваша любаша для путешествий загран на 10 лет загран паспорт загранпаспорт нового образца зимние книги как заполнить анкеты кеширование книги на новый год логирование мцф недвижимость новогодние книги образец заполнения антеты паспорт для путешествий паспорт нового поколения печать продукт проектирование прокси разработка ремонт ремонт в апартаментах ремонт нежилого помещения самокат сдача сколько стоил ремонт апартаментов спорт стандарты таблица финансы хостинг цена ремонта что почитать зимой юзабилити

Случайный пост

08.09.2015 09:55
Неделя 27 июля - 2 августа 2015 года