关于 MariaDB 和 JavaScript 中 CST 时区的区别

这篇文章不是调错记录，所以会花时间说前因后果。

在写一个项目的时候，用到了 MariaDB 配合网页前端，其中的数据包含时间与日期信息。于是很自然地选择了 DATETIME 数据类型，然后写了个脚本导入数据。

数据导入了两天三夜，期间服务器满载。现在想来应该至少做一些分表操作的，但是时间紧，况且也只是一个演示程序，所以这种所谓「长久考虑」的内容就暂时抛下了。

现在开始写页面，但是突然遇到了好玩的事情—— MySQL 里的 DATETIME 是没有单独存储时区信息的，所有时间计算全部基于系统变量 @time_zone 和 @system_time_zone. 这两个变量的值我也从来没有动过，导入数据的时候也忘记设置了。现在再设置再重新导入数据显然是不现实的。

不过幸好对这两个变量进行更改并不会影响已经插入的数据，而且当时这个数据也是直接通过字符串插入的。现在只需要计算出数据库和计算机之间的时间差，然后统一使用 UTC 时区应该就可以了——或者最理想的情况是数据库的默认时区刚好就是中国标准时间，这样就不需要做任何处理了。

于是 SHOW VARIABLES LIKE 'time_zone';, 得到的结果是 SYSTEM. 查了手册知道这表示使用 system_time_zone 的值作为时区；那么再做查询，得到结果是 CST.

这一下就让人感到不安了——CST 这三个字母能代表的时区至少有两个，一个是中国标准时，另一个是在美国的中部时间。

那就没辙了，先看一下对于时间戳的解析形式——SELECT UNIX_TIMESTAMP('2019-05-14 00:00:00');, 得到的值是 1557763200. 换算出来正好是 GMT+8, 证明 MySQL 认为的 CST 是中国时间，当然或许是因为 locale 中的设置让 MySQL 将 CST 解析成中国时间也有可能。

而 JS 就不吃这一套了，如果直接用 new Date('2019-05-14 00:00:00 CST').getTime() / 1000; 得到的值是 1557813600, 换算出来是 GMT-6. 那么还是老老实实指定 GMT+8 比较好。