说起来，时间真是一个神奇的东西。以前人们通过观察太阳的位置来决定时间（比如：使用日晷），这就使得不同经纬度的地区时间是不一样的。后来人们进一步规定以子午线为中心，向东西两侧延伸，每 15 度划分一个时区，刚好是 24 个时区。然后因为一天有 24 小时，地球自转一圈是 360 度，360 度 / 24 小时 = 15 度/小时，所以每差一个时区，时间就差一个小时。

最开始的标准时间（子午线中心处的时间）是英国伦敦的皇家格林威治天文台的标准时间（因为它刚好在本初子午线经过的地方），这就是我们常说的 GMT （Greenwich Mean Time）。然后其他各个时区根据标准时间确定自己的时间，往东的时区时间晚（表示为 GMT+hh:mm）、往西的时区时间早（表示为 GMT-hh:mm）。比如，中国标准时间是东八区，我们的时间就总是比 GMT 时间晚 8 小时，他们在凌晨 1 点，我们已经是早晨 9 点了。

但是 GMT 其实是根据地球自转、公转计算的（太阳每天经过英国伦敦皇家格林威治天文台的时间为中午 12 点），不是非常准确，于是后面提出了根据原子钟计算的标准时间 UTC （Coordinated Universal Time）。

一般情况下， GMT 和 UTC 可以互换，但是实际上， GMT 是一个时区，而 UTC 是一个时间标准。

注：下面的代码示例可以在 node shell 里面运行，如果你运行的时候结果和下面的不一致，那可能咱们不在一个时区：）

1
2
3
4

new Date();           // 当前时间
new Date(value);      // 自 1970-01-01 00:00:00 UTC 经过的毫秒数
new Date(dateString); // 时间字符串
new Date(year, month[, day[, hour[, minutes[, seconds[, milliseconds]]]]]);

需要注意的是：构造出的日期用来显示时，会被转换为本地时间（调用 toString 方法）：

1
2

> new Date()
Mon Jan 11 2016 20:15:18 GMT+0800 (CST)

打印出我写这篇文章时的本地时间。后面的 GMT+0800 表示是“东八区”， CST 表示是“中国标准时间（China Standard Time）”。

有一个很“诡异”的地方是如果我们直接使用 Date ，而不是 new Date ，得到的将会是字符串，而不是 Date 类型的对象：

1
2
3
4

> typeof Date()
'string'
> typeof new Date()
'object'

这里我们主要来说下 T 、以及 Z 。

1
2
3
4
5

> new Date('1970-01-01 00:00:00')
Thu Jan 01 1970 00:00:00 GMT+0800 (CST)

> new Date('1970-01-01T00:00:00')
Thu Jan 01 1970 08:00:00 GMT+0800 (CST)

示例 1 的空格表示法被当做了本地时区，所以显示的时间和传入的时间一致。

示例 2 的 T 被当做 UTC 时间，所以显示的时间会加上本地时区（东八区）的 8 小时偏移。实际上， 1970-01-01T00:00:00 等价于 1970-01-01 00:00:00Z 。

1
2
3
4
5
6
7
8

> new Date('1970-01-01T00:00:00+08:00')
Thu Jan 01 1970 00:00:00 GMT+0800 (CST)

> new Date('1970-01-01 00:00:00')
Thu Jan 01 1970 00:00:00 GMT+0800 (CST)

> new Date('1970-01-01T00:00:00+00:00')
Thu Jan 01 1970 08:00:00 GMT+0800 (CST)

示例 1 是东八区时间，显示的时间和传入的时间一致（因为我本地时区是东八区）。

示例 2 和示例 1 结果一样，不指定时区就是本地时区。

示例 3 指定时区为 GMT 时区（偏移为 0），显示的时间会加上本地时区的偏移（8 小时）。

1
2

> new Date(1000 * 1)
Thu Jan 01 1970 08:00:01 GMT+0800 (CST)

传人 1 秒，等价于： 1970-01-01 00:00:01Z ，显示的时间加上了本地时区的偏移（8 小时）。

1
2

> new Date(1970, 0, 1, 0, 0, 0)
Thu Jan 01 1970 00:00:00 GMT+0800 (CST)

显示时间和传入时间一致，均是本地时间。注意：月份是从 0 开始的。

1
2
3
4
5
6
7
8
9
10
11

> Date.parse('1970-01-01 00:00:00')
-28800000

> new Date(Date.parse('1970-01-01 00:00:00'))
Thu Jan 01 1970 00:00:00 GMT+0800 (CST)

> Date.parse('1970-01-01T00:00:00')
0

> new Date(Date.parse('1970-01-01T00:00:00'))
Thu Jan 01 1970 08:00:00 GMT+0800 (CST)

示例 1，-28800000 换算后刚好是 8 小时表示的毫秒数， 28800000 / (1000 * 60 * 60) ，我们传入的是本地时区时间，等于 UTC 时间的 1969-12-31 16:00:00 ，和 UTC 时间 1970-01-01 00:00:00 相差刚好 -8 小时。

示例 2，将 parse 后的毫秒数传递给构造器，最后显示的时间加上了本地时区的偏移（8 小时），所以结果刚好是 1970-01-01 00:00:00 。

示例 3，传入的是 UTC 时区时间，所以结果为 0。

示例 4，将 parse 后的毫秒数传递给构造器，最后显示的时间加上了本地时区的偏移（8 小时），所以结果刚好是 1970-01-01 08:00:00 。

1
2
3
4
5
6
7
8

> Date.UTC(1970,0,1,0,0,0)
0

> Date.parse('1970-01-01T00:00:00')
0

> Date.parse('1970-01-01 00:00:00Z')
0

可以看出， Date.UTC 进行的是一种“绝对运算”，传入的时间就是 UTC 时间，不会转换为当地时间。

DATE 、 YEAR 、 TIME 比较简单，大概总结如下：

第一个区别是占用字节不同，导致能表示的时间范围也不一样。

第二个区别是 DATETIME 是“常量”，保存时就是保存时的值，检索时是一样的值，不会改变；而 TIMESTAMP 则是“变量”，保存时数据库服务器将其从 time_zone 时区转换为 UTC 时间后保存，检索时将其转换从 UTC 时间转换为 time_zone 时区时间后返回。

比如，我们有下面这样一张表：

1
2
3
4
5
6

CREATE TABLE `tests` (
    `id` INTEGER NOT NULL auto_increment ,
    `datetime` DATETIME,
    `timestamp` TIMESTAMP,
    PRIMARY KEY (`id`)
) ENGINE=InnoDB;

连接到数据库服务器后，可以执行 SHOW VARIABLES LIKE '%time_zone%' 查看当前时区设置。类似下面这样的结果：

说明我目前时区是 CST （China Standard Time），也就是东八区。

我们尝试插入下面的数据：

1

INSERT INTO `tests` (`id`, `datetime`, `timestamp`) VALUES (DEFAULT, '1970-01-01 00:00:00', '1970-01-01 00:00:00');

会发现有一个报错： Error Code: 1292. Incorrect datetime value: '1970-01-01 00:00:00' for column 'timestamp' 。给 timestamp 这一列提供的值不对，因为我们尝试插入 1970-01-01 00:00:00 时，数据库服务器会根据 time_zone 的设置将其转换为 UTC 时间，也就是 1969-12-31 16:00:00 ，而这个值明显超过了 TIMESTAMP 类型的范围。

我们换个大一点的值：

1

INSERT INTO `tests` (`id`, `datetime`, `timestamp`) VALUES (DEFAULT, '2000-01-01 00:00:00', '2000-01-01 00:00:00');

这次就成功插入了。

再次检索时结果也是正确的（数据库服务器将值从 UTC 时间转换为 time_zone 设置的时区时间）：

1

SELECT * FROM sample.tests;

如果我们先将 time_zone 设置为一个不同的值后再进行检索就会发现不同的结果：

1
2

SET time_zone = '+00:00';
SELECT * FROM sample.tests;

可以看到 datetime 列值没有受 time_zone 设置的影响，而 timestamp 列值却改变了。数据库服务器将其从 UTC 时区转换为 time_zone 时区的时间（首先 2000-01-01 00:00:00 在上面进行插入时根据 time_zone 被转换为了 1999-12-31 16:00:00 ，此次检索时 time_zone 被设置为 +00:00 ，转换回来刚好就是 1999-12-31 16:00:00 ）。

那这两种类型怎么选择呢？建议优先使用 DATETIME ，表示范围大、不容易受服务器的设置影响。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

SqlString.dateToString = function(date, timeZone, dialect) {
  if (moment.tz.zone(timeZone)) {
    date = moment(date).tz(timeZone);
  } else {
    date = moment(date).utcOffset(timeZone);
  }

  if (dialect === 'mysql' || dialect === 'mariadb') {
    return date.format('YYYY-MM-DD HH:mm:ss');
  } else {
    // ZZ here means current timezone, _not_ UTC
    return date.format('YYYY-MM-DD HH:mm:ss.SSS Z');
  }
};

代码逻辑如下：

举两个例子。

如果 timeZone 等于 +00:00 ，date 等于 new Date('2016-01-12 09:46:00') ，到 UTC 的偏移等于 (timeZone - 本地时区) + timeZone： (00:00 - 08:00) + 00:00 = -08:00 ，即 2016-01-12 09:46:00-08:00 ，于是 format 后的结果是 2016-01-12 01:46:00 。

如果 timeZone 等于 +08:00 ，date 等于 new Date('2016-01-12 09:46:00') ，到 UTC 的偏移等于 (timeZone - 本地时区) + timeZone： (08:00 - 08:00) + 08:00 = 08:00 ，即 2016-01-12 09:46:00+08:00 。于是 format 后的结果是 2016-01-12 09:46:00 。

如果 timeZone 等于 Asia/Shanghai ，结果也会是 2016-01-12 09:46:00 ，和 +08:00 等价。

sequelize 的 timezone 默认是 +00:00 ，所以，我们在 JavaScript 中的时间最后应用到数据库中都会被转换成 UTC 的时间（比实际的时间早 8 小时）。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

  switch (field.type) {
    case Types.TIMESTAMP:
    case Types.DATE:
    case Types.DATETIME:
    case Types.NEWDATE:
      var dateString = parser.parseLengthCodedString();
      if (dateStrings) {
        return dateString;
      }
      var dt;

      if (dateString === null) {
        return null;
      }

      var originalString = dateString;
      if (field.type === Types.DATE) {
        dateString += ' 00:00:00';
      }

      if (timeZone !== 'local') {
        dateString += ' ' + timeZone;
      }

      dt = new Date(dateString);
      if (isNaN(dt.getTime())) {
        return originalString;
      }

      return dt;
   // 更多代码...
}

处理过程大概是这样：

默认情况下，sequelize 在进行连接时传递给 node-mysql 的 timeZone 是 +00:00 ，所以，第 4 步的时间字符串会是类似这样的值 2016-01-12 01:46:00+00:00 ，而这个值传递给 Date 构造器，在显示时转换回本地时区时间，就变成了 2016-01-12 09:46:00 （比数据库中的时间晚 8 小时）。

如果是在旧表上定义模型，而这张旧表刚好有 TIMESTAMP 类型的列，对 TIMESTAMP 类型的列定义模型时还是可以使用 Sequelize.DATE ，对操作没有任何影响。但是 TIMESTAMP 是受 time_zone 设置影响的，这会引起一些困惑。下面我们来看一个例子。

sequelize 默认将 time_zone 设置为 +00:00 ，当我们执行下面代码时：

1
2
3
4

Test.create({
    'datetime': new Date('2016-01-10 20:07:00'),
    'timestamp': new Date('2016-01-10 20:07:00')
  });

会进行上面提到的 JavaScript 时间到 MySQL 时间字符串的转换，生成的 SQL 其实是（时间被转换为了 UTC 时间，比本地时间早了 8 小时）：

1

INSERT INTO `tests` (`id`,`datetime`,`timestamp`) VALUES (DEFAULT,'2016-01-10 12:07:00','2016-01-10 12:07:00');

当我们执行 Test.findAll() 来查询数据时，会进行上面提到的 MySQL 时间到 JavaScript 时间的转换，其实就是返回这样的结果（显示时时间从 UTC 时间转换回了本地时间）：

1
2

> new Date('2016-01-10 12:07:00+00:00')
Sun Jan 10 2016 20:07:00 GMT+0800 (CST)

和我们插入时的时间是一致的。

如果我们通过 MySQL 命令行来查询数据时，发现其实是这样的结果：

这很好理解，因为我们数据库服务器的 time_zone 默认是东八区， TIMESTAMP 是受时区影响的，查询时被数据库服务器从 UTC 时间转换回了 time_zone 时区时间； DATETIME 不受影响，还是 UTC 时间。

如果我们先执行 SET time_zone = '+00:00' ，再进行查询，那结果就都会是 UTC 时间了。所以，不要以为数据出错了哦。

总结下就是，sequelize 会将本地时间转换为 UTC 时间后入库，查询时再将 UTC 时间转换为本地时间。这能达到最好的兼容性，存储总是使用 UTC 时间，展示时应用端自己转换为本地时区时间后显示。当然这个的前提是数据类型选用 DATETIME 。

在默认配置下，情况如下：

查询 DATETIME 类型数据时，时间总是会晚 8 小时。比如，数据库中某条老数据的时间是 2012-01-01 01:00:00 （已经是本地时间了，因为没转换），查询时被 sequelize 转换为 new Date('2012-01-01 01:00:00+00:00') ，显示时转换为本地时间 2012-01-01 09:00:00 ，结果显然不对。

查询 TIMESTAMP 类型数据时，时间是正确的。这是因为 TIMESTAMP 受 time_zone 影响，sequelize 默认将其设置为 +00:00 ，查询时数据库服务器先将时间转换到 time_zone 设置的时区时间，由于没有时区偏移，刚好查出来的就是数据库中的值。比如： 2012-01-01 00:00:00 （注意这个值是 UTC 时间），sequelize 将其转换为 new Date('2012-01-01 00:00:00+00:00') ，显示时转换为本地时间 2012-01-01 08:00:00 ，刚好“侥幸”正确。

新插入的数据 sequelize 会进行上一部分说的双向转换来保证结果的正确。

维持默认配置显然导致查询 DATETIME 不准确，解决方法就是将 sequelize 的 timezone 配置为 +08:00 。这样一来，情况变成下面这样：

查询 DATETIME 类型数据时，时间 2012-01-01 01:00:00 被转换为 new Date('2012-01-01 01:00:00+08:00') ，显示时转换为本地时间 2012-01-01 01:00:00 ，结果正确。

查询 TIMESTAMP 类型数据时，由于 time_zone 被设置为了 +08:00 ，数据库服务器先将库中 UTC 时间 2011-01-01 00:00:00 转换到 time_zone 时区时间（加上 8 小时偏移）为 2011-01-01 08:00:00 ，sequelize 将其转换为 new Date('2011-01-01 08:00:00+08:00') ，显示时转换为本地时间 2011-01-01 08:00:00 ，结果正确。

插入、更新数据时，所有 JavaScript 时间会转换为东八区时间入库。

这样带来的问题是，所有入库时间都是东八区时间，如果有其他应用的时区不是东八区，那就需要自己基于东八区时间计算偏移并转换时间后显示了。