应用统一存储UTC时间时，为何需区分带/不带TIMEZONE的日期时间类型？

首先需要先纠正一个核心误解：无时区的DATETIME类型本身就和时区没有任何绑定关系，它存储的是纯粹的「年-月-日 时:分:秒」时间字面量，不会默认关联UTC做转换，两种类型的存储逻辑从底层就完全不同，哪怕应用层统一用UTC，区分两类类型依然有实际价值。

两种类型的存储差异对比 #

我们以BigQuery的实现为例说明两类类型的处理逻辑：

1. 插入不带时区的时间值 2021-12-02 14:45:00 时 #

• 对DATETIME类型：直接存储2021-12-02 14:45:00这个字面量，不会做任何时区转换，不管后续查询会话用什么时区，返回的永远是这个固定值。
• 对TIMESTAMP类型：会先读取当前会话的默认时区，将这个时间字面量转换为UTC时间后存储。如果当前会话时区是EST，该值会被转换为2021-12-02 19:45:00 UTC存储，查询时会根据会话时区自动转换为对应时区的时间展示。

2. 插入带时区的时间值 2021-12-02 14:45:00 EST 时 #

• 对DATETIME类型：会直接忽略后缀的时区信息，仅存储2021-12-02 14:45:00这个字面量，不会做任何转换。
• 对TIMESTAMP类型：会按照给定的时区将时间转换为UTC的2021-12-02 19:45:00存储。

为何哪怕全用UTC存储也需要区分两类类型 #

两类类型的本质是对应完全不同的业务场景：

• 很多业务场景下的时间根本不需要关联时区：比如用户生日、线下门店固定营业时间、活动的官方公示举办时间等，这类时间的核心是「用户/业务方看到的字面量本身就是正确值」，如果用TIMESTAMP存储反而可能因为时区转换出现逻辑错误：比如东8区用户提交生日1990-05-03，转UTC后会变成1990-05-02 16:00:00，后续如果查询会话时区设置错误，就会把生日误展示为5月2日。
• 类型区分可以避免业务逻辑歧义：TIMESTAMP类型强制所有写入必须做时区校验转换，从数据库层面避免了业务代码漏转时区直接写入本地时间的问题；DATETIME类型则明确告知开发者该字段是无地域属性的时间字面量，所有时区相关处理需要在业务层完成，不会出现数据库隐式转换导致的不易排查的错误。

内容的提问来源于stack exchange，提问作者David542