在数据库中存储当日起始时刻UTC时间是否为最佳实践？

好问题！咱们一步步分析你的当前流程，再聊聊这算不算最佳实践，以及怎么优化更稳妥。

先理清楚你当前的处理逻辑 #

你现在的步骤是：

1. 客户端传入带时区偏移的ISO日期：2018-04-17T12:47:12.123+01:00
2. 用moment("...").startOf('day').format()得到服务器本地时区的当日零点：2018-04-17T00:00:00+02:00
   • 这里Moment会自动把输入的日期转换为服务器所在的本地时区，再取当天起始时刻（你的服务器时区应该是+02:00，比如欧洲夏令时）
3. 再用moment.utc("...").toISOString()转成UTC时间：2018-04-16T22:00:00.000Z

结论：这不是最佳实践 #

你的做法能得到结果，但存在两个关键问题：

• 依赖服务器本地时区：如果服务器部署到不同时区的环境（比如从欧洲转到美洲），同一个客户端日期会得到完全不同的UTC结果，直接导致数据不一致，这在生产环境是很危险的。
• 中间步骤冗余且容易混淆：你其实不需要先转成服务器本地时区，再绕回UTC——完全可以基于客户端传来的时区信息直接处理。

更稳妥的优化方案 #

核心原则：基于客户端传来的时区，获取该时区的当日起始，再转成UTC，完全不依赖服务器本地时区。

用Moment实现的正确代码：

// 解析原始带时区偏移的日期，保留原时区信息（关键用parseZone，不是直接moment()）
const originalDate = moment.parseZone("2018-04-17T12:47:12.123+01:00");
// 获取原时区的当日起始时刻
const startOfDayInOriginalZone = originalDate.startOf('day');
// 直接转成UTC的ISO字符串
const utcResult = startOfDayInOriginalZone.toISOString();

// 最终结果：2018-04-16T23:00:00.000Z（对应原时区+01:00的当日零点）

这么做的好处：

1. 结果稳定一致：不管服务器在哪个时区，都严格按照客户端传来的时区计算“当日”，不会出现环境差异导致的错误。
2. 步骤更简洁：减少了不必要的时区转换，避免中间环节的混淆。

为什么你的原做法结果不同？ #

你第一步用moment("...")时，Moment会自动把输入的日期转换为服务器本地时区的时间。比如你的服务器是+02:00时区，那2018-04-17T12:47:12.123+01:00会被转成2018-04-17T13:47:12.123+02:00，再取当天零点就是2018-04-17T00:00:00+02:00，转UTC后自然是2018-04-16T22:00:00.000Z——但这其实不是客户端时区对应的“当日起始”。

额外建议：考虑替换Moment #

Moment已经进入维护模式（不再新增功能，只修复严重bug），如果是新项目或者可以升级，推荐用Day.js替代——它更轻量，API和Moment几乎兼容，处理时区也更灵活：

const dayjs = require('dayjs');
const utc = require('dayjs/plugin/utc');
const timezone = require('dayjs/plugin/timezone');

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

// 直接解析带偏移的日期，或者指定时区（比如Europe/London）
const originalDate = dayjs.tz("2018-04-17T12:47:12.123+01:00");
const startOfDay = originalDate.startOf('day');
const utcResult = startOfDay.utc().toISOString();

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