Если вы разработчик программного обеспечения, скорее всего, вам приходилось иметь дело с часовыми поясами. Неприятные ошибки могут появляться, когда часовые пояса не управляются должным образом. Что еще более важно, неправильное управление часовыми поясами может поставить под угрозу целостность данных и привести к катастрофе.
В этой статье я хочу объяснить несколько фундаментальных концепций, которые, надеюсь, помогут относительно новым разработчикам лучше понять часовые пояса.
Дата — это просто число, и оно везде одно и то же.
Забудем на минуту о фактической дате. Date() в JavaScript (или во многих языках программирования, если на то пошло) представлен в Unix Time. Другими словами, Date() — это просто целое число, и это одно и то же целое число на всех компьютерах в один и тот же момент времени.
Дата () — это количество миллисекунд с начала 1 января 1970 года на нулевой долготе. Точнее, четверг, 01 января 1970 г., 00:00:00 по Гринвичу.
Чтобы убедиться в этом, введите в консоли JavaScript следующее:
new Date(0).toUTCString(); 'Thu, 01 Jan 1970 00:00:00 GMT'
Date(), созданный с одним целым числом, позволяет определить базовое представление в миллисекундах. Другими словами, Date(0) означает, что с момента начала отсчета прошло 0 миллисекунд.
Время течет с одинаковой скоростью повсюду на земле. Миллисекунда есть миллисекунда. Таким образом, базовое представление Date() точно такое же, независимо от того, находитесь ли вы в Нью-Йорке или в Мельбурне.
То, что мы знаем как дату/время, — это просто локальное представление числа.
Когда мы видим дату/время на экране компьютера, на самом деле это локальное представление количества миллисекунд после 1 января 1970 года по Гринвичу.
Например:
// Same result in both New York and Malborne new Date().getTime(); 1633963762367
Сообщает мне, что на данный момент с 1 января 1970 года по Гринвичу прошло 1633963762367 миллисекунд. Неважно, вызываю ли я эту функцию в Нью-Йорке или Мельбурне, это число точно такое же.
Однако, если я вызываю toLocaleString(), представление даты/времени зависит от того, где я нахожусь на земле. Когда я буду в Нью-Йорке, я получу:
// New York new Date().toLocaleString() '10/11/2021, 10:49:22 AM'
Когда я нахожусь в Мальборне, я получаю:
// Melborne new Date().toLocaleString() '10/12/2021, 1:49:22 AM'
Это связано с тем, что toLocaleString() отображает базовый номер даты таким образом, который имеет смысл для местной географии или режима.
Легко ошибиться при установке даты и времени
Распространенной ошибкой является предположение, что создание или установка объекта Date имеет одинаковый эффект везде на земле. Это, конечно, не так.
Дата создания или обновления относительно настройки часового пояса компьютера. Например, new Date(2021, 9, 11, 12) дает различные базовые представления времени в Нью-Йорке и Мельборне:
// New York new Date(2021, 9, 11, 12).getTime() 1633968000000 // Melbourne new Date(2021, 9, 11, 12).getTime() 1634022000000
Очень распространенный источник ошибок — когда клиентское приложение (т. е. веб-браузер или приложение) и сервер находятся в разных часовых поясах. Когда клиентское приложение дает указание серверу назначить встречу, скажем, на 12 часов дня 11 октября 2021 года, сервер сделает это в местном часовом поясе СЕРВЕРА. Итак, если клиентское приложение находится в Нью-Йорке, а сервер — в Мальборне, у нас серьезная проблема — надеюсь, пользователь из Нью-Йорка готов прийти на встречу ночью!
Чтобы решить эту проблему, разработчик должен убедиться, что каждая дата создается и сохраняется с предполагаемым часовым поясом или часовым смещением*, ИЛИ нормализует все даты в формате UTC, прежде чем передавать их на сервер.
*Ошибка новичка состоит в том, что предполагается, что разница часов между двумя часовыми поясами всегда одинакова. Это не в случае с переходом на летнее время и изменениями в правилах. Здесь может пригодиться такая библиотека, как moment.js, позволяющая устанавливать дату и время в определенном часовом поясе.
Дата в конце - это просто число
Я думаю, что часовые пояса становится намного легче понять, когда мы понимаем концепцию, что базовое представление Date — это просто целое число. Это одно и то же число во всем мире для ЭТОГО момента времени. Пока мы понимаем, что часовые пояса на самом деле являются просто локальными представлениями одного и того же числа, с ними становится меньше головной боли.
Finnovate.io — технологическая компания, помогающая организациям создавать уникальные цифровые возможности для Интернета, мобильных устройств и блокчейна. Finnovate.io предлагает услуги по разработке, обучению, консультированию, а также платформу, которая быстро превращает бумажный контент в цифровой интерактивный опыт.
