.NET Core中TimeZoneInfo与momentjs结合使用的最佳实践是什么

原生moment.js无法直接识别.NET Core返回的TimeZoneInfo.Id完成时区转换，搭配moment-timezone扩展、提前处理好时区ID兼容性问题之后，完全可以实现你要的前端灵活格式化需求，不需要把所有格式化逻辑挪到后端。

• 先解决时区ID不兼容的核心坑：.NET Core在Windows环境下生成的TimeZoneInfo.Id默认是Windows时区标识（例如China Standard Time），但moment-timezone只支持标准IANA时区标识（例如Asia/Shanghai）。你可以二选一处理：
  • 后端生成时区列表时，统一将Windows时区ID映射为对应的IANA ID再返回给前端，.NET 6+内置了时区转换方法，不需要自己维护映射表；
  • 直接把服务部署到Linux/容器环境，.NET Core在非Windows系统下默认返回的就是IANA格式的时区ID，无需额外转换。
• 前端格式化逻辑：拿到用户选择的原始日期时间值、对应IANA格式时区ID后，不要直接用普通Date对象构造moment实例，调用moment.tz()方法绑定时区上下文，之后就可以自由调用.format()方法按任意格式输出时间。示例代码如下：

// 接口返回的用户选择时间、用户所属时区ID（IANA格式）
const selectedDateTime = "2024-06-15 14:30";
const userTimezone = "Asia/Shanghai";

// 构造带指定时区上下文的实例
const tzTime = moment.tz(selectedDateTime, "YYYY-MM-DD HH:mm", userTimezone);

// 格式串可独立抽成配置，UI调整无需部署后端
console.log(tzTime.format("YYYY年MM月DD日 HH:mm")); // 输出：2024年06月15日 14:30
console.log(tzTime.format("MM/DD/YYYY h:mm A")); // 输出：06/15/2024 2:30 PM

• 存储层注意事项：不管前端怎么展示，数据库里统一存UTC格式的时间或者UTC时间戳，不要直接存用户选的本地时间，避免跨时区访问、夏令时切换时出现时间计算错误。

你提到的前端格式化灵活度优势确实成立：把格式串抽成前端独立配置项后，UI调整日期展示样式只需要修改配置，不需要走后端发布流程，迭代效率更高，只要把时区ID的兼容性问题处理好，这套方案的稳定性完全可以满足生产要求。
如果后续考虑替换moment.js，可以直接迁移到dayjs加timezone插件，两者API几乎完全兼容，包体积不到moment的1/10，迁移成本极低。

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