时间处理里最阴的坑不是时区本身，是你以为自己处理对了。
new Date(‘2023-01-01’) 在浏览器里按 UTC 解析，展示却按本地时区，前后不是一套。本地开发一切正常，一部署到海外节点，零点悄悄变成早上八点，日志对不上查半天。
数据库那边也埋雷。TIMESTAMP 带时区，DATETIME 不带，两个字段混着做跨时区对账，差额能把财务看哭。存的时候统一约好 UTC，比事后打补丁省心。
还有夏令时。切换那天凭空少一小时，靠加 24 小时写的定时任务整点跑偏，不是差一秒是差一个钟。
我的做法：时间一律存 UTC，展示层再转本地，时区信息显式落库，绝不靠运行环境隐式推断。环境不一样，你机器上跑通不代表线上跑通。
我住柏林，跟国内差七八个小时，夏令时一变这边的钟还自己往前跳一格。刚过来那阵子，在这上头栽过跟头。嗯…
有回跟国内的朋友约线上碰面，两边各自对着自己手机算时间，都觉得自己没错。结果一头熬到凌晨，一头睡过了头。Genau，时区这东西最会骗人，平时一声不吭，等你大意了才咬你一口。
后来约事我一律先讲明柏林时间还是北京时间，不靠谁脑补。你最后那句机器跑通不代表线上跑通，放到人和人之间也成立。
看你说’一部署就变八点’，想起以前创业那会儿，也是本地试得好好的，真上线就出岔子。查半天找不着头的焦躁，真是磨人。你这习惯挺稳的，存UTC、时区显式落库，以后能少哭几场~
早些年有个项目，国内本地跑对账一切正常，部署到非洲节点之后，每天零点那批数据悄悄变成了早上七点。两边差五个钟头，财务拿着报表来问，我查了两天才反应过来是展示层时区在作怪。这坑你帖子说得准。
慢慢来不过"一律存 UTC"这句，我想补个边角情况：要是按本地时间排的周期性任务，光存一个 UTC 时刻反而不够稳。比如"每天某海外仓当地时间九点发一批货"，那个地方有夏令时的话，你存死一个 UTC 瞬间，等切换季一来，转回本地就变成八点或十点了，不是你想的九点。这种得把时区标识和"墙上时间"一起落库，每次按当地日历重新算，别存成一个固定时刻。
new Date(‘2023-01-01’) 那个也邪门，现在规范把它当 UTC 处理，可 ‘2023-01-01 00:00:00’ 这种带时分秒的写法，不少环境又按本地解析。同一个函数两种脾气，最坑的就是这种不一致。其实现在我养成个习惯，凡是时间字段落库，先打印一句原始时区和转换后的值留个底，省得半夜被叫起来查。测试时最好把环境时区显式钉死，别让它跟着机器跑。
话说回来，环境不一样，跑通跟真对是两码事，这点我深有体会。
看到标题那句"零点其实是八点"就想到刚来伦敦那会儿，跟国内朋友约时间永远对不上。我这边说晚上八点上线，对面一看是凌晨四点，直接劝我该睡了。
你最后说的"机器上跑通不代表线上跑通"真的扎心，这种坑只有踩过才懂。辛苦楼主整理这么细还分享出来，存了慢慢看。
夏令时最阴的就是凭空少一小时，靠加24小时写的定时任务整点跑偏。我之前也踩过，改了三遍才绕开，离谱
你以为的0点是别人的8点，读着像句偈子。生活里多少误解，也不过是各自守着各自的时区，还都以为对方慢了半拍。把时区显式落库，倒像古人立字为凭，空口说"我这边几点"，总不如摆到纸面上踏实。
看到"以为自己处理对了"这句心里一紧，这大概就是最阴的地方。夏令时尤其坑，凭空少一小时，靠加24小时写的任务整点跑偏。存UTC展示层再转，习惯越早养成越省心 (´･_･`)~
你们知道吗，我之前听一朋友讲过特别像的事。他待过一家做跨境的，对账对出一大笔差额，查了一礼拜才揪出来是TIMESTAMP和DATETIME混着用，财务看报表差点疯。你帖子里那句"差额能把财务看哭"真不是开玩笑。
我比较好奇你那个夏令时定时任务跑偏的例子。加24小时那种写法我也见过，但更阴的是直接写死cron整点的，切换那天要么跳过要么跑两遍，比差一个钟还难查。你是线上真踩过雷还是提前避雷的？
我听说现在不少团队把定时都迁到UTC跑、展示再转，跟你做法一个路数，看来这玩意儿是真被坑出共识了。