目录导航
-
撤销(Ctrl+Z)
-
重做(Ctrl+Y)
-
清空
-
H
标题(Ctrl+1~6)
- 一级标题
- 二级标题
- 三级标题
- 四级标题
- 五级标题
- 六级标题
-
粗体(Ctrl+B)
-
斜体(Ctrl+I)
-
删除线
-
插入引用(Ctrl+Q)
-
无序列表(Ctrl+U)
-
有序列表(Ctrl+O)
-
表格
-
插入分割线
-
插入链接(Ctrl+L)
-
插入图片
- 添加图片链接
-
插入代码块
-
保存(Ctrl+S)
-
开启预览
-
开启目录导航
-
关闭同步滚动
-
全屏(按ESC还原)
# 问题 * 在不同的环境下,程序运行得到的日期因为时区会不一致,可能会导致一些业务上出现错误。 # 原因 * 数据库的DateTime类型没有时区(time zone)信息,因此,存入的是本地时间,并且丢掉了时区信息。如果你把数据库服务器的时区改了,或者把应用服务器的时区改了,读出来的日期和时间就是错误的。如果以Timestamp类型存储,各数据库的实现也不相同,有的进行了内部时区自动转换,而且,存储的时间不超过2037年。 * 如果应用服务器的时区和数据库服务器的时区不一致,你无法确定数据库驱动程序会不会自动帮你转换。 # 解决 * 由于很难保证所有运行环境的时区保证一致,因此不建议使用程序时间进行数据库查询。 * 而时间戳是不会根据时区发生变化的,这里建议统一使用时间戳查询。 ``` where pay_time > FROM_UNIXTIME(#{payTime,jdbcType=BIGINT}) ```
问题
- 在不同的环境下,程序运行得到的日期因为时区会不一致,可能会导致一些业务上出现错误。
原因
- 数据库的DateTime类型没有时区(time zone)信息,因此,存入的是本地时间,并且丢掉了时区信息。如果你把数据库服务器的时区改了,或者把应用服务器的时区改了,读出来的日期和时间就是错误的。如果以Timestamp类型存储,各数据库的实现也不相同,有的进行了内部时区自动转换,而且,存储的时间不超过2037年。
- 如果应用服务器的时区和数据库服务器的时区不一致,你无法确定数据库驱动程序会不会自动帮你转换。
解决
- 由于很难保证所有运行环境的时区保证一致,因此不建议使用程序时间进行数据库查询。
- 而时间戳是不会根据时区发生变化的,这里建议统一使用时间戳查询。
where pay_time > FROM_UNIXTIME(#{payTime,jdbcType=BIGINT})
评论
请
登录后发表观点