众所周知：parseTime 参数为 true 时，驱动会将 date/datetime/timestamp 类型根据 loc 时区解析成 time.Time 类型之后再返回。
timestamp 类型字段没什么疑议，本身底层是一个 unix 时间戳。
但是 date/datetime 类型本身只是一种时间表达方式。假设我有两条数据，虽然可能存储的都是“2025-09-19 14:44:00”的时间，但是业务层面，有可能一条的时区是 Asia/Shanghai, 另一条的时区是 Asia/Tokoyo ，我认为这个地方更适合交由业务层自行处理啊，如果用上 time.Time ，时区就会非常混乱，这里面会涉及到存储时的时区/数据库时区/服务器时区/DSN 中的 LOC 时区，非常折磨人啊。驱动也不提供单独解析 timestamp 类型的能力。
 |
1
Ketteiron 1 天前
别瞎搞这些有的没的。
服务器和数据库统一使用 UTC ，时间戳展示交给客户端。 datetime 没有时区，因此不建议用于有时区要求的场景。 如果想用 datetime 处理，设计接口时要额外传输时区信息，然后服务端转换成 UTC 时间，请求数据时转换成 Unix 让客户端自行处理。 当然这里存在一个问题，服务端完全丢失了该条数据的时区信息，如果业务有需要，再增加一个 timezone 字段。 |
 |
2
lysShub 14 小时 18 分钟前
time.Time 带有时区的
我司强制要求存 stamp, 非要存时区单独开个字段 |
 |
3
bbbblue 7 小时 25 分钟前
你想用的 timestamp 估计也会有问题。。。mysql 的 timestamp 是受到 session 的 timezone 影响的。。他虽然内部存时间戳 但是会根据 session 设置的 timezone 来处理它。。。
go 不知道 js 和 java 都是 数据库驱动如果没正确设置时区 timestamp 就炸了 java 侧是需要保证服务器时区和驱动时区能对上(可以把 session 改为服务器时区 或者 local+force) js 侧的 mysql2 是要填入 session 的时区 直接存时间戳(我是指数字)得了 这点不如 pg 有个 timestamptz 啥问题都没有 |
Select Language