如何优化Node.js中时区转换的执行时间？解析性能瓶颈与替代方案

我正在开发一段代码，需要将大量UTC日期格式化为特定时区的ISO格式。
作为基准测试，我仅使用Date#toISOString()进行格式化，基准测试的平均执行时间为93毫秒。

测试过的时区处理方案 #

Luxon #

DateTime.now().setZone(ZONE).toISO()

date-fns-tz #

formatInTimeZone(new Date(), ZONE, "yyyy-MM-dd'T'HH:mm:ss.SSSXXX");

day.js #

dayjs.extend(utc);
dayjs.extend(timezone);

dayjs().tz(ZONE).format()

平均执行时间对比 #

从结果能明显看到，时区处理操作对性能影响极大。我想知道：这种情况是否存在固有原因？另外，有没有性能更优的替代方案？

一、时区处理性能差的固有原因 #

1. 时区规则的复杂性：Date#toISOString()直接输出UTC的ISO格式，无需处理任何时区转换规则。而时区处理库需要加载并解析IANA时区数据库（包含夏令时切换、时区偏移变更等复杂规则），每次转换都要查询这些规则并计算对应本地时间，这会带来大量额外开销。
2. 对象封装与功能冗余：这些库为了提供丰富的日期操作能力，会将原始Date对象封装成自定义类实例（比如Luxon的DateTime），封装过程中的对象创建、属性赋值等操作都会增加执行时间。即使只用到格式化功能，也会附带库的其他通用逻辑，造成性能损耗。
3. 字符串格式化的灵活性代价：时区库的格式化函数支持自定义格式字符串，需要解析格式模板、逐个替换日期组件，相比Date#toISOString()这种内置的、高度优化的固定格式输出，执行逻辑更复杂，速度自然更慢。

二、性能更优的替代方案 #

1. 预加载时区数据+缓存转换结果 #

如果业务中需要转换的时区固定，可以提前预加载对应的时区规则，并且对重复转换的日期进行缓存。比如Luxon允许预先配置时区，避免每次初始化都加载数据；对于频繁出现的日期，缓存其转换后的结果，减少重复计算。

2. 使用原生Intl.DateTimeFormat #

原生的Intl.DateTimeFormat是浏览器和Node.js内置的国际化API，性能优于第三方库——因为它是底层实现，没有额外的封装开销。示例代码：

function formatToTimezoneISO(date, timeZone) {
  const formatter = new Intl.DateTimeFormat('en-US', {
    timeZone,
    year: 'numeric',
    month: '2-digit',
    day: '2-digit',
    hour: '2-digit',
    minute: '2-digit',
    second: '2-digit',
    fractionalSecondDigits: 3,
    hour12: false
  });
  const parts = formatter.formatToParts(date);
  // 拼接成ISO格式字符串
  const year = parts.find(p => p.type === 'year').value;
  const month = parts.find(p => p.type === 'month').value;
  const day = parts.find(p => p.type === 'day').value;
  const hour = parts.find(p => p.type === 'hour').value;
  const minute = parts.find(p => p.type === 'minute').value;
  const second = parts.find(p => p.type === 'second').value;
  const millisecond = parts.find(p => p.type === 'fractionalSecond').value;
  // 获取时区偏移
  const offset = new Date(date).toLocaleString('en-US', { timeZone, timeZoneName: 'short' }).split(' ')[2];
  return `${year}-${month}-${day}T${hour}:${minute}:${second}.${millisecond}${offset}`;
}

虽然需要手动拼接ISO格式，但性能比第三方库好很多，接近原生Date#toISOString()的水平。

3. 手动计算时区偏移（仅适用于固定偏移时区） #

如果目标时区是固定偏移（比如GMT+8，无夏令时变更），可以直接手动计算偏移量，无需加载时区数据库。示例：

function formatFixedOffsetISO(date, offsetHours) {
  const timestamp = date.getTime();
  const offsetMs = offsetHours * 3600 * 1000;
  const localDate = new Date(timestamp + offsetMs);
  // 手动构建ISO格式，替换时区部分
  const utcIso = localDate.toISOString();
  const offsetSign = offsetHours >= 0 ? '+' : '-';
  const offsetStr = `${offsetSign}${Math.abs(offsetHours).toString().padStart(2, '0')}:00`;
  return utcIso.replace('Z', offsetStr);
}

这种方法性能几乎和Date#toISOString()一致，但只适用于无夏令时的固定偏移时区，局限性较大。

内容的提问来源于stack exchange，提问作者Rodrigo Sasaki