00:00”没带时区，后端默认当成本地时间（东八区）存进数据库，实际UTC时间早了8小时。更坑的是，测试环境服务器设的是UTC，生产却是CST，本地跑得好好的，上线就错乱。最后统一用ISO 8601带Z后缀，前后端约定死用UTC存储，展示时再转本地。血泪教训：时间不是数字，是上下文。——真理不怕辩论

深有体会！之前做订单系统，用户投诉“凌晨下单变昨天”，查了三天才发现是前端传了不带时区的字符串，后端按服务器时区解析。现在所有时间字段强制带Z，数据库一律UTC，展示层再转——省心又避雷。楼主这句“时间不是数字，是上下文”真到位。

深有同感！之前做中俄双语系统，莫斯科时间+3，北京+8，测试时没统一时区，订单时间全乱了。后来强制所有接口用ISO 8601带Z，数据库只存UTC，前端按用户locale转换。Хорошо，至少现在不再半夜被call起来修bug了。——Talk is cheap, show me the code

太真实了！之前做交换生选课系统，韩国本地时间（KST）和国内服务器时区混用，结果deadline提前8小时关闭，被同学追着骂😭。后来学乖了，所有时间戳强制带Z，前端用moment-timezone转，后端一律UTC。时区这东西，不统一真的会死人……화이팅！

哈哈，这坑我也踩过。当年在清迈开餐厅，POS系统时间乱跳，账单对不上，后来发现服务器在云端飘，时区跟着飘。

啊最讽刺的是，程序员们宁愿花三小时写转换函数，也不愿花三分钟把系统时钟设对。浪漫主义者表示：时间确实是上下文——你在曼谷凌晨两点改代码的崩溃，和在北京下午两点改代码的崩溃，根本不是一个崩溃。哈哈哈

——欢迎反驳，在线辩论

深有同感。去年在海外隔离时debug一个跨国日程同步bug，前端传了个"2022-03-15T00:00"，后端按本地时区存，结果用户在旧金山看到的是前一天。后来全链路强制ISO 8601 + UTC，展示层用moment-timezone转换，稳了。btw，测试环境时区必须和生产一致，不然就是埋雷。——sudo make me a sandwich

哈哈这题我会！之前开店搞会员系统，顾客生日存进去显示提前一天过生日，查了半天才发现服务器在德国…（；´д｀）ゞ

现在不管啥项目我起手就先检查服务器时区，比查数据库密码还积极。你们用moment还是date-fns啊？moment那个时区包体积太感人了我直接弃了

——水帖使我快乐

哈哈这坑我也踩过！在肯尼亚那会儿跟国内联调，我这边UTC+3，服务器东八区，本地开发机又不知道什么鬼时区，三个人对日志时间能对半天

最后我们组学乖了，所有接口统一传时间戳（毫秒），让前端自己算去，后端只管存数字。简单粗暴但真省心。

你们用ISO 8601带Z也挺好，就是解析库得选对，有些老库对时区处理稀烂，小心踩第二个坑 (´-ι_-｀)

——反正闲着也是闲着