处理日期和时区转换：为什么正确的 UTC 转换很重要

php中文网 2024-10-15 11:46:50

在检索选定日期范围内的数据时，我们注意到我们的计算存在一定偏差。然而，当我们将日期减少一天时，数据完全匹配！

嗯……我们的代码中处理日期的方式可能存在问题。也许时区处理不正确——是的，我是对的！

在构建涉及来自不同时区的用户的应用程序时，正确处理日期可能很棘手。以 utc 存储日期是确保一致性的常见最佳实践，但当用户在本地时区输入日期时，尤其是在过滤和查询期间，事情可能会变得复杂。

开发人员经常求助于本机 javascript date 对象 来处理这些转换。然而，这种方法可能会导致跨环境的不一致，例如 node.js 与 chrome 等浏览器控制台。在本文中，我们将探讨为什么正确处理日期和时区转换至关重要，luxon 如何使此过程变得更容易，以及为什么依赖本机 javascript date 对象会导致不一致。

问题：utc 存储与本地时间过滤

当日期以 utc 格式存储时，它们代表了一个全球标准，可以消除时区引起的歧义。然而，用户通常会根据他们的本地时区进行思考。当用户尝试使用本地时间输入按日期过滤记录时，这种差异变得明显。

让我们看一个示例，如果处理不当，用户的当地时间输入可能会导致丢失记录。

示例场景：gmt-7 时区的用户

想象一下位于gmt-7 时区（太平洋夏令时间） 的用户。 2024 年 9 月 5 日，他们在当地时间晚上 10:00 创建了记录。以下是幕后发生的事情：

2024 年 9 月 5 日，晚上 10:00 gmt-7 转换为 2024 年 9 月 6 日，05:00 am utc 并按原样存储在数据库中。
但是，用户认为他们是在9 月 5 日创建了此记录。

过滤器不匹配

现在，假设用户想要查询 9 月 5 日 创建的所有记录。他们输入日期2024年9月5日，期望检索他们的记录。但是，如果系统直接将输入日期与存储的utc日期进行比较，而不调整时区差异，则用户将错过记录。为什么？

该记录已保存在数据库中，时间为9 月 6 日 (utc)。
用户过滤了9 月 5 日（他们的当地时间），但系统将此与 utc 进行比较，导致不匹配。

javascript 日期对象：跨环境的不一致

以下示例代码演示了使用本机 javascript date 对象处理日期和时间转换时的常见问题，特别是在 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 date 对象 处理日期和时区转换可能会导致像上面演示的那样的不一致。以下是为什么 luxon 是更好的选择的几个原因：

跨环境的一致性：无论代码是在 node.js 还是浏览器（例如 chrome 控制台）中运行，luxon 都提供一致的行为。这消除了在不同环境中使用 date 对象所产生的差异。
内置时区支持：luxon 可以轻松地在时区之间进行转换，而 date 对象不提供对时区操作的强大支持。
简单的日期操作：设置用户本地时区的一天的开始或结束并将其转换为 utc 是全球应用程序中的常见任务。 luxon 通过其直观的 api 简化了此过程，而 date 则需要复杂的手动处理。