在这里记录一下我是怎么发现这个bug的吧，起因是我在 #3557 中给底层重新实现类型转换的时候发现的，
在我的本地环境 ubuntu 20.04 mysql8 go 1.22 gf 2.7.0
测试没什么问题，但是提交pr后，CI 一直过不去，我看了日志发现有个测试，期望日期是1880-10-24，但是经过orm转换后变成了1880-10-23，看下图

ci测试的连接

期初我以为是我的问题，我在我的本地环境又调试了一遍没发现什么问题，
于是我在 map=>struct 这一步加了日志，发现走到这步的时候，已经是1880-10-23了

ci测试的连接

这时候我已经发现可能是时区导致的问题了，于是我找到ci测试环境的mysql版本5.7.39，在我的本地装了一个同版本的

/*
		CREATE TABLE `timezone` (
		  `id` bigint(20) NOT NULL AUTO_INCREMENT,
		  `datetime` date DEFAULT NULL,
		  KEY `id` (`id`)
		) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin

	*/
table := vm3306.Model("timezone")
_, err = table.Data(TimeZone{
	DateTime: gtime.NewFromStr("1880-10-24"),
}).Insert()

record, err := table.One()

在查询的底层加一个打印的

输出的结果

可以和第一张图红圈上面的那个date做对比，上面图片的时区是UTC+0805，而这里的是+0800 CST 其实就是UTC+0800
其实这时候是没有什么问题的，因为mysql驱动对日期类型返回的是time.Time ，gf之前的做法对于time.Time类型直接返回的，并没有转为gtime.Time，date类型直接序列化为Y-m-d格式的，这时候由于是1880-10-24，测试没问题。

但是我在 #3557 中对于实现了sql.Scanner接口的类型，统一使用了sql.RawBytes接收，恰好gtime.Time实现了这个接口，
于是在我实现版本的中，解析过程就变成了 mysql驱动返回time.Time， 标准库把它转换sql.RawBytes，然后我接收到这个值，传给gtime.Time.Scan 方法，然后Scan方法最终调用gtime.StrToTime 来解析，
由于 ci测试环境下的mysql数据库返回的是UTC+08:05 和本地时区UTC+08:00(应该是go语言的有个单独的时区文件)经过比对发现时区不同 ，gtime.StrToTime会把时区转换为UTC+0时区，然后把对应的时钟分钟，根据+- 号来做加减，最后返回

这样就导致1880-10-24 00:00:00+08:05 解析后变成了1880-10-23 15:55:00Z，loc也是nil，等同于UTC+0

这样的实现其实是错误的，对比同样字符串的看下go标准库的解析

由于gtime.Time丢失了时区信息，导致日期格式化Y-m-d的时候变成了1880-10-23

@gqcn 我看到有好几个issue都是关于时区的问题，#1013 #1256 #1560 #1714 #2434 #3188 希望能够重视这个时区问题

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

@gqcn I saw several issues about time zone issues, #1013 #1256 #1560 #1714 #2434 #3188 I hope this time zone issue can be taken seriously.