本文旨在解决将特定日期和时间字符串直接解析到目标时区而非从本地时区转换的常见问题。文章将解释 `moment-timezone` 在此场景下的局限性，并详细演示如何使用 `luxon` 库，通过 `datetime.fromformat` 或 `datetime.fromobject` 配合 `zone` 选项，实现精确的时区感知时间对象创建，确保时间组件（如小时、分钟）在目标时区保持不变。
在现代应用程序开发中，处理多时区的日期和时间是一个普遍且复杂的挑战。一个常见的需求是，用户选择了一个日期和时间（例如，“07:00 AM”），并希望将这个时间直接理解为特定时区（例如，“澳大利亚/悉尼”）的“07:00 AM”，而不是将其视为本地时区的“07:00 AM”再转换到目标时区。这种需求被称为“在特定时区解析时间字符串”，它与标准的时区转换有所不同。
Moment.js/moment-timezone的挑战
许多开发者在处理日期时间时会选择 Moment.js 及其 moment-timezone 插件。然而，对于上述“直接在目标时区解析”的需求，moment-timezone 的默认行为可能会导致混淆。
当我们使用 moment(${date} ${time}).tz(timezone).format() 这样的语法时，moment 会首先尝试将 "${date} ${time}" 这个字符串解析为当前运行环境的本地时间。然后，tz(timezone) 方法会将这个已解析的本地时间点（一个绝对的时间戳）转换到指定的目标时区，并以该时区的时间表示形式输出。
考虑以下示例，假设本地系统时区为巴基斯坦时间 (PKT, UTC+5)，用户希望将 "06/13/2023 07:00" 理解为澳大利亚/悉尼时间 (AEST, UTC+10) 的 07:00 AM：
const moment = require('moment-timezone');
const time = "07:00";
const date = "06/13/2023";
const timezone = "Australian/Sydney"; // 目标时区
// 尝试使用 moment-timezone 进行解析
// 1. `moment(`${date} ${time}`)` 会将 "06/13/2023 07:00" 解析为本地时间，即 2023-06-13T07:00:00+05:00 (PKT)
// 2. `.tz(timezone)` 会将这个时间点从 PKT 转换到 Australian/Sydney
// 2023-06-13T07:00:00+05:00 (PKT) 等同于 UTC 2023-06-13T02:00:00Z
// UTC 2023-06-13T02:00:00Z 在 Australian/Sydney (+10) 中是 2023-06-13T12:00:00+10:00
const convertedTimeMoment = moment(`${date} ${time}`).tz(timezone).format();
console.log("moment().tz() 结果:", convertedTimeMoment);
// 预期输出（根据PKT本地时区）：2023-06-13T12:00:00+10:00
// 尝试设置默认时区后解析
moment.tz.setDefault(timezone);
const convertedTimeMomentDefault = moment(`${date} ${time}`).format();
console.log("moment.tz.setDefault() 后结果:", convertedTimeMomentDefault);
// 预期输出：2023-06-13T12:00:00+10:00 (行为类似)
// 尝试使用 moment.tz(string, timezone)
// 这种方式会将字符串直接解析为指定时区的时间，但前提是字符串中不包含时区信息
// 对于 "06/13/2023 07:00"，它会将其视为 Australian/Sydney 的 07:00 AM
const parsedTimeMomentTz = moment.tz(`${date} ${time}`, timezone).format();
console.log("moment.tz(string, timezone) 结果:", parsedTimeMomentTz);
// 预期输出：2023-06-13T07:00:00+10:00 (这才是我们想要的结果，但用户在问题中给出的输出是 17:00，这可能是由于 Moment.js 版本或环境差异，或者 `moment.tz` 在某些情况下默认行为不同，例如将输入视为 UTC 然后转换)
// **重要提示：** 用户在问题中给出的 `moment.tz(`${date} ${time}`, timezone).format()` 输出是 `2023-06-20T17:00:00+10:00`，这可能暗示了 Moment.js 的另一种解析行为，例如将无时区信息的字符串默认视为 UTC 再转换为目标时区。然而，通常情况下，`moment.tz(string, timezone)` 旨在直接在指定时区解析。为了避免这种不确定性，我们转向更明确的 Luxon 解决方案。从上述示例可以看出，moment().tz() 的行为是转换而非直接解析。虽然 moment.tz(string, timezone) 看起来更接近目标，但其在不同环境下的行为可能存在细微差异，且用户在问题中报告的输出也未能完全达到预期。为了获得更稳定和可预测的行为，我们推荐使用 luxon。
Luxon：实现精确时区解析的解决方案
Luxon 是一个现代、功能强大且设计精良的日期时间库，它提供了清晰的 API 来处理复杂的时区场景。它能够明确区分时间点（Instant）和本地时间（Local Time），这对于我们解决“直接在目标时区解析时间字符串”的问题至关重要。
核心概念：直接在目标时区创建时间对象
Luxon 的关键在于，它允许你在创建 DateTime 实例时就明确指定其所属的时区。这意味着你可以告诉 Luxon：“请将这个日期和时间字符串，直接视为某个特定时区的时间。”
这与先创建一个 DateTime 对象（可能在本地时区或 UTC），然后再使用 setZone() 方法将其转换为另一个时区是不同的：
- zone 选项（在 fromFormat 或 fromObject 中使用）：用于创建一个表示指定时区中特定日期时间组件的 DateTime 对象。
- setZone() 方法：用于转换一个已存在的 DateTime 对象，使其在另一个时区中表示同一个绝对时间点。
使用 DateTime.fromFormat() 进行解析
这是最直接且推荐的方法。DateTime.fromFormat() 允许你提供一个日期时间字符串、一个格式字符串，以及一个包含 zone 选项的配置对象，从而直接在目标时区创建 DateTime 实例。
// 首先安装 luxon: npm install luxon
const { DateTime } = require("luxon");
const time = "07:00";
const date = "06/13/2023";
const targetTimezone = "Australian/Sydney"; // 使用 IANA 格式的时区标识符
// 将日期和时间合并成一个字符串
const dateTimeString = `${date} ${time}`;
// 定义输入字符串的格式
const formatString = "MM/dd/yyyy HH:mm";
// 使用 fromFormat 并指定目标时区
// Luxon 会将 dateTimeString 按照 formatString 解析，并直接在 targetTimezone 中创建 DateTime 对象
const userDateTimeInTargetZone = DateTime.fromFormat(
dateTimeString,
formatString,
{ zone: targetTimezone }
);
console.log("\n--- Luxon 解决方案 ---");
console.log("在目标时区创建的时间对象 (ISO):", userDateTimeInTargetZone.toISO());
console.log("在目标时区的时间 (HH:mm):", userDateTimeInTargetZone.toFormat("HH:mm"));
console.log("在目标时区的完整格式 (yyyy-MM-dd HH:mm:ss ZZZZ):", userDateTimeInTargetZone.toFormat("yyyy-MM-dd HH:mm:ss ZZZZ"));
// 验证输出是否符合预期 (7 AM AEST 
