编程与软件工程codeblog.jonskeet.uk
存储 UTC 并非万能解药
Storing UTC is not a silver bullet
2019 — 2022，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇博客讨论为什么“一律存 UTC”并非万能：过去已经发生的明确瞬间适合用 UTC 记录，但未来事件若依赖某地的墙面时间，只存 UTC 无法应对时区规则或夏令时的变化。作者主张区分“精确瞬间”和“社会/本地时间”，后者需要保存时区信息（而不是仅保存偏移量）或本地时间。
为什么经久不衰：时区规则会变、人类时间带有社会政治属性，文中区分过去瞬间与未来本地时间的原则多年后仍是日期时间设计的实用提醒。
HN 评论精选
事件该绑定 UTC 还是本地时间取决于语义，iCalendar 是参考范例。
这和闹钟问题一样。用户创建事件时到底意味着什么？闹钟设了早上7点，然后飞到另一个时区，它该什么时候响？会议事件遇到当地时区规则变化或夏令时生效又该怎么办？主办方宣传材料写的是“1000 UTC开始”，还是“上午10点（当地时间）”？事件通常需要锁定到某个东西——锁 UTC 还是本地时区取决于应用。iCalendar 标准总体上处理得不错。
rlpb查看英文原文
This is the same as the alarm clock problem. When a user creates an event, what does that user _mean_? In the alarm clock example, what should happen if I've set my alarm clock 7am and then travel to a different time zone? In the conference event example, what should happen if the local time zone rules change, or daylight savings time comes into force? Did the event organiser print marketing materials that said "starts at 1000 UTC" or "starts at 10am" with a "in the local time zone" implication? Events generally need to be locked to _something_ - whether that is UTC or a local time zone depends on the application. The iCalendar standard (https://tools.ietf.org/html/rfc5545) generally gets this right.
过去记录瞬间用 UTC，未来别只存 UTC，要记录预期墙面时间及时区。
10个月前 Zach Holman 的文章下也有讨论。大致总结：系统日志这类明确瞬间用 UTC；足够久远的过去（当前时区规则确定正确）用 UTC；近期的过去（规则可能不准）可能还要存时区。所有过去时间都是在记录一个瞬间——一个与观察者和地点无关的精确时间点。未来时间很不同：有时引用未来瞬间可用 UTC，但多数时候你真正拥有的是“事件发生时我期望墙上时钟显示这个时间”，必须连同尽可能多的墙面时钟/时区信息一起记录。
sudhirj查看英文原文
There was another discussion here 10 months ago after Zach Holman's post: https://news.ycombinator.com/item?id=17181046 Sort of a summarization of most of the ideas here is: * for clear instants like a system log UTC makes sense * for times in the past (far enough in the past that you know your current TZ rules are correct) UTC makes sense. * for the immediate past (near enough where your rules might not be correct) you might want to store zone as well. For all cases of times in the past, remember that you're trying to record an instant. An exact unambiguous point in time that is the same irrespective of who is looking at it or where they are. For this UTC makes sense - people who see that instant converted to their local timezone are noting what their clocks would have shown at that instant, but everyone who will ever see it is always referencing the same instant. FUTURE times are very different. There are times at which you want to reference a future instant, at which point you can just use UTC, but most often what you really have is "this is what I expect to see on my wall clock when this thing happens". That is a very different beast, because nobody knows what the timezone rules or geopolitical situation will be when that thing does happen. You need to recognize the use cases where what you mean is " I expect to see XX:YY:ZZ on my wall clock when this happens" and just record that information as is, including as much information as you can about that wall clock - possibly which timezone it (currently) uses, where it is (in case the timezone itself changes) and then convert to an instant at the last possible moment, or keep updating your instant based on changing rules.
给出实用规则：过去用 UTC，涉及本地墙面时间必须带时区而非偏移，日期与时间戳分开。
我一直说程序员只需学两门课：日期时间编程和调试；第一门自然引出第二门。我的规则：1. 记录过去事件存 UTC。2. 需要记录过去或未来的本地时间时，存当时/届时本地时间加时区（不是偏移量）。3. 显示时间戳：能显示 UTC 就显示 UTC；否则按当前转换规则显示本地时间。4. 获取用户输入：能要 UTC 就要 UTC；否则要带时区（不是偏移量）。5. 日期不是时间戳，日期是一个区间：要么只存日期不带时区，要么若为某地日期区间，存起止时间戳及时区。
rswail查看英文原文
I've said for ages that programmers only need two subjects to learn. Date and time programming and debugging. The first one leads naturally to the second one. The rules I follow: 1. If you're recording an event in the past, store it in UTC. 2. If you need to record the local time for something either in the past or the future, store it as the local time as it was (for the past), or the local time as it will be (for the future), plus a timezone (not an offset). 3. If you're displaying a timestamp, a) if you can, display UTC, b) if needed, display in local time using current conversion rules 4. If you are getting user input, a) if you can, get it in UTC, b) if not, get it using a timezone (not an offset) 5. If you are storing a date, then that is not a timestamp. A date is a period, so either just store the date without a timezone, or, if it's a date period in a local area, store the start and end timestamps with their timezones.
历史数据按当前时区展示会扭曲日边界，说明还需保留事件发生时的时区上下文。
时间问题太多了。iPhone 健康 App 很烦：同一时区记录步数没问题，但换时区后数据按当前时区显示（我猜是存 UTC 再转当前时区）。技术上正确，但回看旅行那几周，看起来我每天从晚上9点走到上午11点（其实只是正常作息），日边界不是当时真实边界，日均步数也乱了。我希望能选择按当时所在时区显示，并在日粒度图上标出时区变化（差异小时跳过或重复）。
stephen_g查看英文原文
So many issues you can run into with time! One that really annoys me is the Health app on iPhone, where it records step count and other data, and does it well if you stay in the same timezone. But when you change timezone, the data is shown in the zone you’re in now (I assume it’s stored in UTC and then converted to the current timezone). Which is technically correct, but then looking back, it looks like I was doing a whole lot of walking from 9pm to 11am for a few weeks while I was on a trip (it was actually just a regular daily schedule), which then messes up the daily average step count, because the day boundaries aren’t what they actually were there. I’d really rather have an option to show it in the timezone that I was in at the time, and then on the daily resolution graphs mark where the time zone changed (with the hours in the difference either skipped or repeated depending on which way).
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选