再谈golang的sql链接dsn

golang的time类型其中有一个field为loc *Location。这一点是golang和java不一样的地方
这是dsn的常见golang设置，这里说明下其中每个字段的含义

复制代码

root:root@tcp(127.0.0.1:3306)/user?charset=utf8mb4&parseTime=true&loc=Asia%2FShanghai&time_zone=%27%2B08%3A00%27

parseTime 是否将date，datetime,timestamp 等时间类型直接转换成golang 的model中的time.Time类型
time_zone，这个是设置当前session的时区。对timestamp类型的mysql数据，直接按照time_zone中设置的时区转换后给程序，这个转换是mysql做的，还不是驱动做的。其他类型的时间数据不会转换时区，返回的还是原来的字符串
loc=Asia%2FShanghai。这个是和java不一样的地方，java没有这个field。这个loc就是对应golang的time类型其中有一个field为loc *Location这个字段的。就是为了程序员自己在代码中进行时区转换使用的。例如：

3.1 本来数据库字段是datetime类型。数据库是utc时区。插入datetime类型时候，选择的是now().因此数据库写入的就是utc的时区时间。此时parseTime=true&loc=Asia%2FShanghai的话，就会导致dao层的model的time.Time 类型的loc表示是+8时区的。也就是表示这个时间是+8区的时间。

此时程序员进行程序转换：

复制代码

var cstSh, _ = time.LoadLocation("Asia/Shanghai") // 上海
r := users[0].CreateTime.In(cstSh).Format("2006-01-02 15:04:05")

将不会有任何变化，数据库的时间在程序中还是会认为是+8时区的时间

3.2 如果loc不写，此时读取出来的time.Time的loc为utc时区。此时还是进行时区转换时：

var cstSh, _ = time.LoadLocation("Asia/Shanghai") // 上海

r := users[0].CreateTime.In(cstSh).Format("2006-01-02 15:04:05")

就会将utc时间转换为+8时区时间

3.3 也就是本身datetime类型的数据，读出来的time.Time一定是数据库的时间。这一点没有疑问。但是这个附带的loc的值，是由dsn的loc决定的。如果程序员不主动进行时区转换，那么这个时间一定是数据库存储的时间，如果代码中不主动进行时区转换，而是直接使用time.Time的话，这个loc完全没有使用场景。因为本身就不关注field为loc *Location这个内容。

矛盾和出路

4.1 now()的使用决定了数据库的datetime类型的字段值一定是mysql的时区一致

4.2 如果增加了dsn的timezone字段，仅能自动修改掉timestamp类型的时间。但是该时间的loc还是由dsn的链接决定的。同时存在datetime和timestamp将导致两难，举例如下：

mysql是utc时间
dsn= parseTime=true&loc=Asia%2FShanghai&time_zone=%27%2B08%3A00%27
createtime = datetime。 modifytime = timestamp
读取的createtime对应的时间的loc=+8时区，但是值是utc时间的值。读取的modifytime的值是+8时区的值，但是loc=+8时区。也就是modifytime的时间是正确的了，但是createtime的时间和时区对不上
使用dsn= parseTime=true&loc=Asia%2FShanghai，不使用time_zone
这种情况下，读取的createtime对应的时间的loc=+8时区，但是值是utc时间的值。读取的modifytime的值是utc时间的值，对应的时间的loc=+8时区。依然是错误的
数据库now语句的使用，导致loc设置为和数据库的时区不一致的情况下，datetime类型值和时区一定存在矛盾。因为时区是loc决定的，值是数据库存储的值决定的。

8.因此loc的值必须和数据库的时区一致，而设置time_zone将没有什么意义，因为time_zone结合和时区不一样的loc的值，仅能将timestamp的值修改都正确。但是对使用now的其他字段的值，将无计可施。