处理日期和时区转换：为什么正确的 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(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 offsetlet 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 frontendconst 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 timeconst userLocalDate = DateTime.fromISO(userInputDate);// Step 2: Convert this date to start of the day and end of the day in the user's local timezoneconst startOfDayLocal = userLocalDate.startOf('day'); // start of the day in the user's timezoneconst endOfDayLocal = userLocalDate.endOf('day'); // end of the day in the user's timezone// Step 3: Convert these local start and end times to UTCconst startOfDayUtc = startOfDayLocal.toUTC().toJSDate(); // start of the day in UTCconst endOfDayUtc = endOfDayLocal.toUTC().toJSDate(); // end of the day in UTC// Step 4: Query the database using the UTC rangedb.records.find({ createdAt: { $gte: startOfDayUtc, $lte: endOfDayUtc }});登录后复制 为什么 luxon 比 javascript 日期对象更好直接使用原生 javascript date 对象 处理日期和时区转换可能会导致像上面演示的那样的不一致。以下是为什么 luxon 是更好的选择的几个原因：跨环境的一致性：无论代码是在 node.js 还是浏览器（例如 chrome 控制台）中运行，luxon 都提供一致的行为。这消除了在不同环境中使用 date 对象所产生的差异。内置时区支持：luxon 可以轻松地在时区之间进行转换，而 date 对象不提供对时区操作的强大支持。简单的日期操作：设置用户本地时区的一天的开始或结束并将其转换为 utc 是全球应用程序中的常见任务。 luxon 通过其直观的 api 简化了此过程，而 date 则需要复杂的手动处理。 结论正确处理日期和时区转换对于构建可靠、用户友好的应用程序至关重要。如果开发人员在过滤记录时未能考虑到时区差异，用户可能会错过重要数据，从而导致混乱和潜在的严重错误。使用 luxon 代替原生 javascript date 对象 可提供一致性、更好的时区处理以及更轻松的日期操作。这使开发人员能够为跨时区的用户创建无缝体验，确保查询按预期工作，并且在过滤过程中不会遗漏任何记录。在全球应用程序中，准确可靠的日期处理是为用户提供高质量体验的关键，无论用户位于哪个时区。最后的想法您是否遇到过类似的情况，即日期和时区处理导致您的应用程序出现意外结果？你是如何解决这个问题的？我很想听听您的经历、反馈或您可能有的任何问题或疑虑。欢迎在下面的评论部分分享它们。如果您觉得本文有帮助，请点赞并分享给可能从中受益的其他人！ 以上就是处理日期和时区转换：为什么正确的 UTC 转换很重要的详细内容，更多请关注我的其它相关文章！