type Time struct {
	wall uint64
	ext  int64
	loc *Location  // 位置。用于调整时间的表示。
}

Golang 存储的不是 Unix 时间戳，但是会根据情况将其转换为时间戳。对于 loc 的修改不会对 Unix 时间戳产生影响，只会影响时间的展示形式。

MongoDB 使用的 bson.Date 使用 int64 存储从 1970 年 1 月 1 日以来的毫秒数。

MySQL 使用 DATETIME 类型存储不包含时区的年月日时分秒，查询时以 YYYY-MM-DD HH:MM:SS 的形式展示。也可以用四个字节的 TIMESTAMP 类型存储 Unix 时间戳。

时间戳的问题

以前在保存时间戳的时候，通常都使用四个字节，也就是 32 位的有符号整数存储。

把二进制的 01111111 11111111 11111111 11111111 转化为十进制后得到 2147483647，再转化为北京时间得到 2038-01-19 11:14:07。

这就表示 32 位整数最多只能存储到 2038 年的时间，因此被称为 “2038 年问题”。

比较新的一些项目会通过各种方式解决这个问题，通常是使用 64 位整数来存储时间戳。但使用方式各有不同。

例如 Golang 使用了两个 64 位整数来存储。其中无法符号整数 wall，第一位表示是否有单调时间。

• 如果为 1，则表示有单调时间。
  wall 的 2~34 位存储自 1885 年 1 月 1 日 0 时 0 分 0 秒以来的秒数，35~64 位存储纳秒数。
  有符号的 64 位整数 ext 存储从进程启动以来的纳秒数（单调时间）。
• 如果为 0，则表示没有单调时间。
  wall 的 2~64 不存储时间。
  有符号的 64 位整数 ext 存储从 0001 年 1 月 1 日 0 时 0 分 0 秒以来的秒数。

MongoDB 则是使用 int64 存储从 1970 年 1 月 1 日以来的 UTC 毫秒数。

MySQL 没有解决 TIMESTAMP 类型的问题，它始终是四个字节。因此如果要解决这个问题，最好使用 DATETIME。但是 DATETIME 也有问题，它没法存储时区。不过大多数应用都无需考虑时区问题，无需担心。

时间的展示

数据库都默认使用 UTC。如果不加以处理，存储到数据库的时间就会展示为与本地实际展示的时间不一致的形式。

例如 MongoDB 存储的是从 1970 年 1 月 1 日以来的 UTC 毫秒数，像 Navicat 这种工具，会用 UTC 的形式展示时间。这样其他时区的人看起来就会不习惯。

而 MySQL 就更难处理了，DATETIME 不带时区。

解决这个问题有三种思路：

1. 修改数据库配置，改成本地时区
   MongoDB 这样设置不会有影响，仍然存储的是毫秒数。只是在展示的时候会使用配置的时区格式化字符串。
   MySQL 这样设置后，会对 NOW() 这种函数的结果产生影响。不会对 SQL 语句中直接写 0000-00-00 00:00:00 的情况产生影响。
2. 查询的时候将其重新转换为本地时区
   有三种：
   • 为数据库连接会话设置时区。同上，只是在会话级别产生影响。
     MySQL 会有影响，如果不同地方的会话设置不同时区，又使用了 NOW()，得到的结果不一致。
   • 在代码上做一层包装，用于调整时区。
     MongoDB 没啥影响，毕竟存储的是毫秒数。只是展示的时候做个调整。
     MySQL 可以始终存储为 UTC 形式，然后要展示的时候，用代码把时间格式化为本地时区的形式。
   • 为数据库表创建 view，在 view 里面处理时区
     例如 MongoDB：

     db.createView("view_name","collection_name",[
         {
             $addFields: {
                 date: {
                     $dateToString: {
                         date: "$date",
                         format: "%Y-%m-%dT%H:%M:%S+08:00",
                         timezone: "+08:00"
                     }
                 }
             }
         }
     ]);
     

     addFields 会覆盖同名的字段。上面的语句会将原先的 date 字段的值以新的格式展示。
3. 存储的时候创建一个年月日时分秒和本地展示时间一致的 UTC 时间
   这会改变数据库存储的时间戳，使得时间戳与实际时间戳不一致。对 MongoDB 会产生影响。
   不过 MySQL 的 DATETIME 不是用时间戳，所以只要格式化到 SQL 语句的时间形式是本地时区的就行了。只是如果出现跨时区的用户、数据、开发人员，处理起来就比较麻烦。

具体实例

Golang MongoDB 库

MongoDB 的官方库在存储的时候，会使用 UTC 的时间戳。但在查询的时候，会判断是否设置了使用本地时间展示。如果没有设置按本地时间展示，则会将 Time 设置为 UTC 时区。

if !tc.UseLocalTimeZone {
    timeVal = timeVal.UTC()
}

builder := bsoncodec.NewRegistryBuilder()

// 注册默认的编码和解码器
bsoncodec.DefaultValueEncoders{}.RegisterDefaultEncoders(builder)
bsoncodec.DefaultValueDecoders{}.RegisterDefaultDecoders(builder)

// 注册时间解码器
tTime := reflect.TypeOf(time.Time{})
tCodec := bsoncodec.NewTimeCodec(bsonoptions.TimeCodec().SetUseLocalTimeZone(true))
registry := builder.RegisterTypeDecoder(tTime, tCodec).Build()

client, err := mongo.NewClient(options.Client().ApplyURI(uri), options.Client().SetRegistry(registry))