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

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

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

在构建涉及来自不同时区的用户的应用程序时，正确处理日期可能很棘手。以 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(null, 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 是更好的选择的几个原因：

1. 跨环境的一致性：无论代码是在 node.js 还是浏览器（例如 chrome 控制台）中运行，luxon 都提供一致的行为。这消除了在不同环境中使用 date 对象所产生的差异。

2. 内置时区支持：luxon 可以轻松地在时区之间进行转换，而 date 对象不提供对时区操作的强大支持。

3. 简单的日期操作：设置用户本地时区的一天的开始或结束并将其转换为 utc 是全球应用程序中的常见任务。 luxon 通过其直观的 api 简化了此过程，而 date 则需要复杂的手动处理。

结论

正确处理日期和时区转换对于构建可靠、用户友好的应用程序至关重要。如果开发人员在过滤记录时未能考虑到时区差异，用户可能会错过重要数据，从而导致混乱和潜在的严重错误。

使用 luxon 代替原生 javascript date 对象 可提供一致性、更好的时区处理以及更轻松的日期操作。这使开发人员能够为跨时区的用户创建无缝体验，确保查询按预期工作，并且在过滤过程中不会遗漏任何记录。

在全球应用程序中，准确可靠的日期处理是为用户提供高质量体验的关键，无论用户位于哪个时区。

最后的想法

您是否遇到过类似的情况，即日期和时区处理导致您的应用程序出现意外结果？你是如何解决这个问题的？我很想听听您的经历、反馈或您可能有的任何问题或疑虑。欢迎在下面的评论部分分享它们。如果您觉得本文有帮助，请点赞并分享给可能从中受益的其他人！