数据库存储时间的时区问题

先说一下mysql中DATETIME和TIMESTAMP的区别

TIMESTAMP是标准的unix timestamp，它存储的是1970-1-1到现在经过的秒数，4字节存储。mysql用这个类型还蛮方便的，一个是有很多内置的函数和trigger来处理它，比如CURRENT_TIMESTAMP宏，最关键的是在取数据的时候mysql会自动帮你处理DST和时区的问题。

DATETIME的范围更大，好像可以从0000-00-00 00:00:00到9999-12-31 23:59:59，8字节存储，当然mysql内部肯定也是用整数而不是字符串的（说了是8字节了），所以效率不是大问题。但DATETIME不带时区，比如我在程序里生成了一个2015-05-07 15:26:00的时间（实际上是+8时区的，但这个对象可能是timezone naive）的，存到mysql里，再从不同时区的地方拿出来，这个时间可能就混了。

但TIMESTAMP也有两个很大的问题：

1. 4字节长度限制，它只能到2038年
2. 很多时候我们希望根据用户所在地的时区显示时间而不是光显示一个服务器时间

所以比较好的做法是，数据库中使用DATETIME，然后存时间的时候一律用程序生成UTC时间（而不是local时区的时间）存进去，取出来的时候不管想显示服务器时间还是显示用户的时间都可以处理。

顺便提一句，根据用户所在地时区显示时间有两种做法：

1. 当用户第一次访问网站的时候，用js获取时区发送到服务器上存到session里
2. 用js处理时间的显示（我觉得这种比较方便一点，毕竟不用改服务端代码）

Java获取当前UTC时间戳（毫秒）

public static String getUTCTimeStr() throws Exception {
        Calendar cal = Calendar.getInstance();
        return String.valueOf(cal.getTimeInMillis() / 1000);// 返回的就是UTC时间
    }

使用这种做法的唯一缺点是sqlite3没有internal的DATETIME类型，所以在ORM框架如sqlalchemy中，它会直接存字符串进去。（sqlite3的文档也说，你要么存成int要么real要么字符串）。尽管这可能带来一些不方便和性能的下降，但我认为还是符合“keep it simple and stupid”的原则。

至于用INT存时间，是另一种可行的方法，参见http://www.liaoxuefeng.com/article/0014132675721847f569c3514034f099477...
我个人不是很喜欢这么做，因为这样你必须把模型中表示时间的成员声明为int类型。这样是比较不符合逻辑的（那些Date呀Datetime之类的类就没有用了呀，最多就有个Dateutil就好了），而且会使得程序不易读（卧槽这个publishedDate为什么是int，它到底表示的是时间吗？）。总之见仁见智。