在现代web应用开发中，服务器通常配置为utc（协调世界时）以避免时区问题，但用户界面往往需要根据用户的本地时区显示数据。当需要获取某一特定本地日期（例如，“亚洲/雅加达”时区）的开始和结束时间戳时，直接使用date-fns库中的startofday和endofday函数可能会导致意外的结果。这是因为这些函数在处理date对象时，其内部操作可能不会完全按照我们期望的“本地时区”上下文来解释，尤其是在最终转换回unix时间戳时。
挑战：为何直接转换不奏效？
假设我们有一个UTC时间戳，代表某一时刻，我们希望找到它所在本地时区一天的开始和结束。以下是一个尝试，它将UTC时间转换为本地时区Date对象，然后应用startOfDay和endOfDay：
const { startOfDay, endOfDay, getTime, subDays } = require("date-fns");
const { utcToZonedTime } = require("date-fns-tz");
const timezone = "Asia/Jakarta"; // 目标本地时区
// 假设我们有一个参考的Unix时间戳，例如昨天
const selectedUnixTime = subDays(new Date(), 1).getTime();
// 将UTC时间戳转换为表示本地时区时间的Date对象
const localDate = utcToZonedTime(selectedUnixTime, timezone);
// 尝试获取本地日期的开始和结束
const localStartDateAttempt = getTime(startOfDay(localDate));
const localEndDateAttempt = getTime(endOfDay(localDate));
// 假设正确的本地开始和结束时间戳（UTC表示）
// 例如，对于2023-05-30在Asia/Jakarta时区，其开始是2023-05-30 00:00:00 (Jakarta time)
// 对应UTC时间是 2023-05-29 17:00:00 UTC (1685379600000)
// 结束是 2023-05-30 23:59:59.999 (Jakarta time)
// 对应UTC时间是 2023-05-30 16:59:59.999 UTC (1685465999999)
const correctLocalStartDate = 1685379600000;
const correctLocalEndDate = 1685465999999;
console.log(
{
isItCorrect: localStartDateAttempt === correctLocalStartDate,
correctDate: new Date(correctLocalStartDate),
systemDate: new Date(localStartDateAttempt),
},
"尝试获取的开始日期"
);
console.log(
{
isItCorrect: localEndDateAttempt === correctLocalEndDate,
correctDate: new Date(correctLocalEndDate),
systemDate: new Date(localEndDateAttempt),
},
"尝试获取的结束日期"
);运行上述代码，我们可能会得到如下结果（具体日期取决于运行时间，但isItCorrect会是false）：
{
isItCorrect: false,
correctDate: 2023-05-29T17:00:00.000Z, // 雅加达时间2023-05-30 00:00:00 对应的UTC
systemDate: 2023-05-30T07:00:00.000Z // 雅加达时间2023-05-30 14:0 
