时区很麻烦
时区 很麻烦, 大概有这么几个问题
- 历史变更: 这个真的是随历史各个地域变化很大, 看看 wiki 上 中国时区 的历史吧.
- 夏令时: 基本靠 time 库支持了
- 数据库支持: 差异很大
- 客户端: 比如浏览器, 别说你的网站只考虑支持固定时区的用户
两个重要链接 iana.org/tz , worldtimezone , 数据的维护发布就靠他们了.
数据库差异
支持 | SQLite3 | MySQL | PostgreSQL | MongoDB |
存储时区 | 是 | 否 | 可选 | 否 |
时差相关运算/函数 | 否 | 是 | 是 | 否 |
可设定时区 | 否 | 是 | 是 | 否,只用UTC时间 |
多种日期格式 | 是 | 否 | 是 | 否 |
注: 本文 把"2012-12-12","2012 12 12","20121212" 当做同一种格式, MongoDB 通过函数完成的,不算多格式支持
格式交换
应用在和第三方进行数据通讯的时候, 可能会遇到多种不同的日期格式,这里面也涉及时区问题. 这需要你看所用语言库的支持了.
应用怎么办
如果你的应用不考虑时区支持, 那对于 MySQL和PostgreSQL来说,只要配置好时区就万事大吉.
否则,你可能遇到:
- 数据库有可能迁移
- 随时间推移,应用需要时区支持
- 返回到客户端日期要符合客户端的时区时间, 你的客户时区分布是如何呢?
综合问题您自己根据应用特性选择吧.