При получении данных за выбранный диапазон дат мы заметили, что наши расчеты были с некоторым отклонением. Однако когда мы уменьшили дату на один день, данные точно совпали!

Хммм… Возможно, возникла проблема с обработкой даты в нашем коде. Возможно, часовой пояс обрабатывается неправильно — и да, я был прав!

При создании приложений, в которых участвуют пользователи из разных часовых поясов, правильная обработка дат может оказаться сложной задачей. Хранение дат в формате UTC — распространенная практика обеспечения согласованности, но все может усложниться, когда пользователи вводят даты в своем местном часовом поясе, особенно во время фильтрации и запросов.

Разработчики часто прибегают к встроенному объекту даты JavaScript для обработки этих преобразований. Однако этот подход может привести к несогласованности между средами, такими как Node.js и консолями браузера, такими как Chrome. В этой статье мы рассмотрим, почему правильная обработка преобразований даты и часового пояса имеет решающее значение, как Luxon может упростить этот процесс и почему использование встроенного объекта Date в JavaScript может привести к несоответствиям.

Проблема: хранилище UTC и фильтрация по местному времени

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

Давайте рассмотрим пример, где вводимые пользователем данные о местном времени могут привести к пропущенным записям, если их не обработать должным образом.

Пример сценария: пользователь в часовом поясе GMT-7

Представьте пользователя, находящегося в часовом поясе GMT-7 (тихоокеанское летнее время). 5 сентября 2024 г. они создают запись в 22:00 по местному времени. Вот что происходит за кулисами:

• 5 сентября 2024 г., 22:00 GMT-7 преобразуется в 6 сентября 2024 г., 05:00 UTC и сохраняется в базе данных как таковая.
• Однако пользователь считает, что он создал эту запись 5 сентября.

Несоответствие фильтров

Теперь предположим, что пользователь хочет запросить все записи, созданные 5 сентября. Они вводят дату 5 сентября 2024 г., ожидая получить свою запись. Однако, если система сравнивает введенную дату непосредственно с сохраненной датой UTC без поправки на разницу часовых поясов, пользователь пропустит запись. Почему?

• Запись сохранена в базе данных как 6 сентября (UTC).
• Пользователь фильтрует по 5 сентября (их местное время), но система сравнивает это время с временем UTC, в результате чего совпадений нет.

Объект даты в JavaScript: несоответствия в разных средах

В следующем примере кода демонстрируется распространенная проблема при использовании собственного объекта Date JavaScript для обработки преобразований даты и времени, особенно в различных средах, таких как Node.js и браузер (например, консоль Chrome).

Пример кода:

function convertToUtcStartOfDay(isoString) {
  // Step 1: Parse the ISO string into a Date object
  let localDate = new Date(isoString);

  // Step 2: Set the time to the start of the day (00:00:00) in local time zone
  localDate.setHours(0, 0, 0, 0);

  // Step 3: Get the UTC time using toISOString() – it converts local time to UTC
  let utcStartOfDay = localDate.toISOString();

  return utcStartOfDay; // This will be in UTC
}

// Example usage:
let frontendDate = "2023-08-22T00:00:00 05:30"; // ISO string with timezone offset
let startOfDayUtc = convertToUtcStartOfDay(frontendDate);

console.log(startOfDayUtc); // Expected output: "2023-08-21T18:30:00.000Z"

В этом примере пользователь вводит дату «2023-08-22T00:00:00 05:30» (из часового пояса GMT 5:30). Объект Date должен преобразовать его в начало дня в формате UTC, но при выполнении:

• В Node.js выходные данные: 2023-08-21T00:00:00.000Z - Неверно
• В консоли Chrome вывод: 2023-08-21T18:30:00.000Z - Правильно

Это несоответствие может привести к непредсказуемым результатам в зависимости от того, где выполняется код. Такое поведение делает объект Date ненадежным для согласованной обработки дат в разных средах.

Использование Luxon для точной обработки дат

Чтобы решить эту проблему, важно использовать такую ​​библиотеку, как Luxon, которая обеспечивает согласованное поведение в разных средах. Luxon помогает вам преобразовать локальный ввод пользователя в правильное начало и конец дня в его часовом поясе, а затем преобразовать это время в формат UTC для точных запросов к базе данных.

Вот пример использования Luxon для решения этой проблемы:

const { DateTime } = require('luxon');

// Example user input date in ISO string with timezone information from the frontend
const userInputDate = "2023-08-22T00:00:00 05:30"; // ISO string sent by frontend

// Step 1: Parse the ISO string to get the user's local time
const userLocalDate = DateTime.fromISO(userInputDate);

// Step 2: Convert this date to start of the day and end of the day in the user's local timezone
const startOfDayLocal = userLocalDate.startOf('day'); // start of the day in the user's timezone
const endOfDayLocal = userLocalDate.endOf('day'); // end of the day in the user's timezone

// Step 3: Convert these local start and end times to UTC
const startOfDayUtc = startOfDayLocal.toUTC().toJSDate(); // start of the day in UTC
const endOfDayUtc = endOfDayLocal.toUTC().toJSDate(); // end of the day in UTC

// Step 4: Query the database using the UTC range
db.records.find({
  createdAt: {
    $gte: startOfDayUtc,
    $lte: endOfDayUtc
  }
});

Почему Luxon лучше, чем объекты даты в JavaScript

Обработка преобразований даты и часового пояса непосредственно с помощью встроенного объекта даты JavaScript может привести к несоответствиям, подобным показанным выше. Вот несколько причин, почему Luxon — лучшая альтернатива:

1. Согласованность в разных средах: Luxon обеспечивает единообразное поведение независимо от того, выполняется ли код в Node.js или в браузере (например, консоль Chrome). Это устраняет несоответствия, возникающие при использовании объекта Date в разных средах.

2. Встроенная поддержка часовых поясов: Luxon позволяет легко конвертировать часовые пояса, в то время как объект Date не обеспечивает надежную поддержку манипулирования часовыми поясами.

3. Простое манипулирование датами: установка начала или конца дня в местном часовом поясе пользователя и преобразование его в формат UTC — обычная задача в глобальных приложениях. Luxon упрощает этот процесс благодаря интуитивно понятному API, тогда как Date требует сложной ручной обработки.

Заключение

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

Использование Luxon вместо собственного объекта даты JavaScript обеспечивает согласованность, лучшую обработку часовых поясов и упрощение манипулирования датами. Это позволяет разработчикам обеспечить удобство работы для пользователей в разных часовых поясах, гарантируя, что запросы работают должным образом и ни одна запись не будет пропущена во время фильтрации.

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

Заключительные мысли

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