前两天被一个时间 bug 折磨了整整一个下午。一行看着人畜无害的代码 new Date(“2023-03-08”)，本地跑出来是当天零点，逻辑一切正常。结果上了生产，日期整体往前挪了 8 小时，定时任务算出来的"今天"变成了"昨天"，下游对账直接错乱。

后来才搞明白，ES5 之后 JS 对没带时区信息的日期字符串是按 UTC 零点解析的，而我们的日志和数据库默认走的是东八区本地时间。两边对不上，凭空差出 8 小时。更坑的是这问题在本地和测试环境根本复现不了，因为只有生产机的时区环境和解析器的假设对不上，属于"偶尔抽风"的类型，排查起来极其痛苦。

根治其实不难，就是别让解析器替你猜时区。要么全程用 Unix 时间戳，要么老老实实传带 Z 的 ISO8601，比如 2023-03-08T00:00:00Z。解析时显式声明时区，比事后对着错乱数据拍脑袋强太多。

这坑估计不少人都踩过，发出来给后来者提个醒。你们还遇到过什么时间相关的阴间 bug？

辛苦了，只在生产抽风的 bug 最磨人。我也踩过时区坑，日志时区对不上，对着错数据拍到半夜才回过神。

补个更阴的：同样没写时区，解析结果还看格式。new Date(“2023-03-08”) 按 UTC 算，new Date(“2023/03/08”) 却是本地时间，两种写法能差 8 小时。前后换种写法就自己埋雷，比统一 UTC 还难查。

顺带提一句，楼主说的"ES5 之后"那句不太准，ES5 那会儿这行为各浏览器自己定，真正把日期串钉成 UTC 的是 ES2015。结论不变，别让解析器替你猜就对了。

差这8小时，听着不算多，真落到对账和定时任务上就是一整天的偏差。最磨人的还是你说的那种，本地和测试环境都好好的，一上生产就抽风，你盯着代码盯半天它装没事，换台机器才露馅。

我年轻那会儿也总以为机器算出来的准，人算才容易错。后来碰得多了才懂，机器是最死心眼也最老实的，你不明说，它就按它自己那套假设来，半点不提醒你。它不恶意，就是懒得猜你的心思，你不说清楚，它就替你做主，一做主就错。

楼主说的显式声明时区，我顶赞成。宁可多写几个字把话挑明，也别事后对着错乱的数据拍脑袋。我这人怕麻烦，能提前讲清楚的事，绝不留到后头补漏洞。这事吧话说回来

说实话时间看着最准，其实最靠不住，差出来的那点工夫，全是后来人的命。

补充个更阴间的点：new Date(‘2023-03-08’) 按UTC零点，但 new Date(‘2023-03-08T00:00:00’) 反而按本地时区。同样ISO格式，带不带T和时分秒，解析假设完全相反。关键路径我一律传时间戳，不给药解析器发挥空间。

草 这8小时藏得也太阴间了 本地复现不了就生产炸 谁排查谁崩溃

做外贸的成天跟时差泡在一起，你这凭空少8小时我太有体会了。以前跟欧洲客户约会，算漏夏令时那一小时，人散会了我这边还在睡(；´Д`)

说回正题，最阴的不是差这8小时，是它"本地复现不了"。静默错比直接崩难查太多。跨时区的事还是老老实实对齐到一个基准再动，别让机器替你猜，btw这话你帖子里其实已经点到了。

以前不是这样的。早些年我用的那个老手机，闹钟按本地时间走，有一回跨了时区出差，它照旧按老家时间响，害我天没亮就爬起来干等了一个钟头。人对"默认"俩字马虎，机器可比人较真。有一说一

你帖里那句"别让解析器替你猜时区"，我觉得不单是说代码。好多麻烦的根子，就是两头各按各的默认走，谁也没把前提摆到明面上。生产那 8 小时，说穿了就这么点事。

这种坑急不得，越拍脑袋越乱，慢慢捋就出来了。

补充一个更阴间的细节：横杠和斜杠解析行为不一样。new Date("2023-03-08") 按 UTC 零点走，但 new Date("2023/03/08") 在大部分引擎里是按本地时区的。就换一个符号，8 小时直接没了。
其实
本地复现不了其实能复现，跑之前 export TZ=UTC 就能看到和生产一模一样的结果。建议 CI 里加一条多时区跑的测试，这比上线后对着错乱数据拍脑袋划算太多。

你们现在库里时间是存 timestamp 还是字符串？这个选型后面坑很多。

这bug太阴间了 本地复现不出来最坑 我隔着屏幕都替你脑仁疼

今天变昨天，bug干得出来。最阴的是本地复现不了，你对着代码觉得全世界都对，其实是时区在背后偷偷使坏。我当年也被这坑绊过，半夜救火才反应过来。