前几楼聊浮点算钱、大整数失真，都是真金白银换的教训。我补一个时间处理里的坑，当年也栽过。
不少人第一反应：时间不就是加个偏移吗，存本地时间，换时区加8减8完事。真不是。夏令时一开，有些地区一年里凭空少一小时或多一小时，“加8”直接算飞。更要命的是时区政策本身会变，有的国家说取消夏令时就取消了，你硬编码个偏移量在代码里，过两年准翻车，而且翻得悄无声息。
我的做法很死板：库里永远存UTC时间戳，展示时再按用户时区转。本地时间千万别当字符串往库里塞，不然排序、计算、跨时区全得返工。
当年为这事儿半夜爬起来改历史数据，现在想起来还犯怵。时间这种东西，老老实实交给标准库，别自己拍脑袋算偏移。
我在悉尼这些年，对"凭空多一小时少一小时"倒是有切身体会。这边夏令时一来，和国内的时差就从两小时跳到三小时，约好的视频电话总得重算一遍。楼主那句"翻得悄无声息"真是一针见血——时间表面规规矩矩，底下的暗流从不肯停。
从前读"流光容易把人抛"，只当文人闲愁，如今倒觉得实在。人总想给流动的东西钉颗钉子，定死偏移量，可世界偏要往前走。半夜爬起来改旧数据那种怵，我没经历过，光想象那片静悄悄的错位，就后背发凉。
硬编码偏移真是最阴的 半夜爬起来救数据谁懂啊 我现在看时区俩字就ptsd
伦敦这边夏令时一开一关我每年都领教，真不是加8减8搞得定的。还是UTC打底最省心，sounds good
一个国家说取消夏令时就取消了 这操作也太儿戏 合着那一小时说没就没 我这种连时区都懒得管的人直接看呆 楼主惨是真惨 半夜爬起来改历史数据 那种以为睡踏实了结果被叫起来擦屁股的崩溃我太懂了 时间这玩意儿果然不能自己瞎琢磨 该认怂就认怂 哈哈
半夜爬起来改数据那种后怕我懂的，换我得做一周噩梦。UTC时间戳看着死板，可比自己拍脑袋算偏移靠谱一万倍。
加8哪够啊，曼谷这儿是加7，东南亚时区乱成一锅，半夜爬起来改数据太真实了
想当年刚来温哥华那阵，跟国内家里打电话就栽过这坑。国内没夏令时，这边一年拨两次钟，时差算着算着就对不上——冬天差十六小时，夏天变十五小时。我妈有回按她那边的上午给我打过来，我这边凌晨三点摸黑爬起来接，俩人对着电话都愣了。
有一说一
你讲硬编码偏移那段，我最怕的不是算错那一下的尴尬，是它悄无声息。话说回来浮点算钱好歹账单对不上能一眼瞅出来，时区这东西错一两个钟头，数据摆着都正常，没人会闲着去盯时间戳较劲，等真出事多半已经攒下厚厚一叠。
老老实实交给标准库吧。话说回来自己拍脑袋算偏移，跟拿算盘对账差不多，迟早的事。
说存UTC就万事大吉也不全对，tz数据库过期时历史时间戳照样算飞。Хорошо。
好家伙 半夜爬起来改历史数据 这谁顶得住 我看着都困
读到"现在想起来还犯怵"那句，心被轻轻揪了一下。嗯嗯，半夜被人从床上拽起来改历史数据，那种冷汗涔涔、手抖着敲命令的感觉，光听你说我就替你紧张。辛苦了，真的。这种拿睡眠和真金白银换来的教训，确实比看十遍文档都刻得深。
你说的"老老实实交给标准库，别自己拍脑袋算偏移"，我特别认。抱抱我虽然不是写程序的人，但生活里总犯同一种糊涂——总觉得能省一步就省一步，自己拍脑袋定了，结果后面全得返工重来。把流动又复杂的东西交给靠谱的工具和规则，真的省掉太多眼泪。
说起来我对时差也挺有体会的。追韩团得算首尔和北京的时间差，他们那边夏令时一调，稍不注意直播开场就错过，那种懊恼我到现在都记得。所以你那句"本地时间别当字符串塞库里"，我虽然半懂不懂，但道理我太懂了——时间这种流动的东西，硬套一个固定框，迟早翻车。
你这帖写得这么实在，后来的人看到肯定能少踩好几个坑。
夏令时这坑谁踩谁知道 我约国外朋友连麦白等过一小时，现在乖了，全让人家报本地几点我就不操心时差了
听说了吗，他这句"交给标准库"我得补个料。标准库底下那张tz database你们知道什么来头不？我听说这玩意儿最早是一个大佬靠一己之力攒了几十年，结果2011年差点被一家卖天文软件的公司告到消失——说tz数据侵权，当时整个社区都炸了，因为全世界系统转时区全指着它。所以"标准库"真不是铁板一块，它背后那张表得有人不停更新，你服务器不升tzdata，政策一变照样翻车，而且翻得比硬编码还安静。
服了还有个更阴的坑：他说存UTC我举双手赞成，但排未来的事要小心。比如"每周一早9点提醒用户"，你要是现在就把UTC算死，两年后那国时区一改，你存的UTC直接飘了。这种得存local rule别存具体offset。嘛嘿嘿
绝了
楼主说的半夜爬起来改数据，我怎么感觉背后还有故事，当时是哪国突然改的政策呀？
你这条里"库里永远存UTC"我大体认同，但有一个场景它反而会埋雷，值得单独拎出来说：未来时刻和周期性事件。
比如"每周三纽约时间下午3点开会"，如果你在创建那条记录时就算好UTC写进库，等美国夏令时一切换，你存的UTC对应的本地墙钟时间就漂移了——会议要么早开一小时要么晚开一小时，而且同样悄无声息。这类东西的正确姿势是存 IANA 时区名（America/New_York）加本地时间，真正要触发的时候再去临时算 UTC。换句话说，UTC 适合存"已经发生的绝对瞬间"（交易时间、日志、 birth 时间戳），不适合存"按日历约定的将来"。
再补一个你没展开的点：闰秒。严格讲 UTC 是含闰秒的，但 Unix 时间戳按 POSIX 定义根本不计闰秒，两者在某些秒是对不上的。授时、金融这类系统要是不小心，差一秒就够喝一壶。
还有"交给标准库"这句方向对，但前提是 tzdata 得跟着更新。我见过不少容器镜像把 tzdata 冻在构建那天的版本，本质上跟硬编码偏移没两样，过几年某国一改时区政策照样翻车。楼主当年半夜爬起来改历史数据那个怵劲儿，我看多半就是 tzdata 没跟上这类原因。