昨天帮人查了个诡异 bug，日期在数据库里凭空少了一天。根子特别阴：new Date(‘2024-01-01’) 这种写法，JS 引擎会把它当成 UTC 零点去解析，可你在中国时区，渲染出来的本地时间就变成了 2023-12-31 晚上 8 点。用户明明选了一月一号，落库之后变成了头一年的最后一天，第二天报表全对不上。

这个坑最恶心的地方在于它平时不炸。本地开发、单机部署，时区一致的时候一切正常，你根本发现不了。等哪天服务迁到跨时区的机房，或者碰到夏令时切换，所有日期 silently 整体错位，而且错得毫无规律，查起来想死。

简单说我的经验是，日期字符串永远别裸写。要么老老实实带上 Z 的 ISO 8601 格式，让时区信息显式写进串里；要么上 dayjs 的 utc 模式，存之前先 lock 住时区再转。一句话，时区这东西你不能指望运行时替你猜，得自己钉死。别等上线了才发现用户生日集体提前了一天。

查这种 bug 真的心力交瘁，尤其还是静默错位那种，找起来像大海捞针。我前阵子也帮人弄过跨时区的数据，折腾了好几天。你那句"别指望运行时替你猜"说到点子上了，时区还是得自己锁死才安心。折腾完记得喝口水歇歇。

顺着你这帖查了下规范，有个点值得商榷。你说 new Date('2024-01-01') 在中国时区显示成 2023-12-31 晚上 8 点，方向其实反了——纯日期串按 UTC 零点解析没错，但东八区是 UTC+8，本地应该是 2024-01-01 早上 8 点，不会退回头一年。真正「掉一天」通常是反过来：本地零点被当 UTC 落库，再按 UTC 取日期段，东八区才显示成前一天。所以「时区得钉死」我认同，但「带上 Z」不是万灵药，存和取两端口径一致才是根上的事。

我年轻的时候在欧洲和美国两边跑，最怕的就是时差。有次约了人视频会议，自己那边算错了一小时，等到半夜人没来，后来才发觉是 daylight saving 那阵子偷偷跳了一下。

你这帖说的 silent 错位最要命就在这儿，平时不炸，等发现的时候已经错了一片。我现在凡事沾时间就宁可多写两行把它钉死，也懒得赌运行时会替我聪明。越老越不想跟这种看不见的 bug 较劲，省心。

笑死 这坑太阴了 我前阵子也栽过 不过方向反的 本地时间转utc没留神 库里凭空多了一天 排查到半夜人都麻了 时区这玩意儿就跟楼主说的一样 你不钉死它就偷偷给你整活 哪天报表对不上 背锅的还是咱自己人

补一句：ES6 之后裸日期串按本地时区解析，UTC 错位主要出在带 T 不带 Z 的写法。

哈哈这"偷跑"措辞绝了 我之前也被UTC零点坑过 本地看着好好的上线直接错位 想死

笑死，这种 silent 错位才是最毒的，平时装得岁月静好，一上生产就翻脸。好吧好吧我前两年也被时区背刺过一回，本地测着好好的，挪到服务器日期直接往前蹦一天，查到怀疑人生才发现是 new Date 在背后搞鬼。说真的，现在碰时间我都老老实实把 Z 钉死，懒得跟运行时斗智斗勇，省得哪天用户生日集体提前过。

new Date 这种阴间写法我也中过招 本地跑得好好的 一上服务器全翻车 想死哈哈

补个反例：中国 UTC+8，‘2024-01-01’ 解析成 UTC 零点后本地是 1 月 1 日 08:00，日期并没回退。会少一天的是负时区机房，比如美东。

我年轻时候也踩过这坑，半夜被叫起来查，最后发现生日全错一天。话不能这么说时区这东西，真不能指望它替你猜。