我从SQL中的日期列中获得2019-09-01
,但使用Jooq前1天。我认为这是因为我的应用程序(操作系统级别和Java前端)使用US/Eastern
,而数据库使用UTC。请参见下面的SQL:
select kpisd1, convert_tz( kpisd1, 'US/Eastern', @@session.time_zone), convert_tz( kpisd1, @@session.time_zone, 'US/Eastern' ), @@session.time_zone from kpi where kpiprc = '00006330263815' and kpikpi = 'TURN' and kpists = 'HIST';
+---------------------+--------------------------------------------------------+---------------------------------------------------------+---------------------+
| kpisd1 | convert_tz( kpisd1, 'US/Eastern', @@session.time_zone) | convert_tz( kpisd1, @@session.time_zone, 'US/Eastern' ) | @@session.time_zone |
+---------------------+--------------------------------------------------------+---------------------------------------------------------+---------------------+
| 2019-09-01 00:00:00 | 2019-09-01 04:00:00 | 2019-08-31 20:00:00 | UTC |
+---------------------+--------------------------------------------------------+---------------------------------------------------------+---------------------+
1 row in set (0.00 sec)
我的C程序实际上是在更新数据库,实际上在将其添加到数据库之前并没有进行任何时区转换。它根据操作系统时区获取日期,然后使用该日期。因此,如果它加上2019年9月1日,我希望可以重新获得2019年9月1日。我尝试了select date( kpisd1 )
,但是那也没有用。我猜想,即使我打印出原始java.sql.Date时,它也与数据库不匹配,这意味着它可能是在JDBC中转换的。有什么想法吗?
[我唯一的其他选择是将数据库时区从UTC转换为“美国/东部”(以匹配我的应用程序服务器上的时区),但是我需要研究其后果,所以我试图不急于这样做艰巨的步骤(这是生产环境)。
根据@knutwannheden的建议,我进行了更改:
databaseUrl = "jdbc:mysql://" + host.trim() + ":3306/" + db.trim();
to
Calendar now = Calendar.getInstance();
databaseUrl = "jdbc:mysql://" + host.trim() + ":3306/" + db.trim() +
"?serverTimezone=" + now.getTimeZone().getID();
我根据上述文档选择了serverTimezone
:
serverTimezone
替代时区的检测/映射。从时区开始使用服务器未映射到Java时区
自版本:3.0.2是的,在我的情况下,这实际上是不正确的-MySql服务器设置为UTC,它确实映射到客户端,但由于我不希望映射,所以我尝试了此方法并成功了。我没有尝试其他时区参数,因为该参数可以立即工作,但是
noTimezoneConversionForDateType
或其他时区参数之一很有可能会起作用。
[如果有人对此解决方案有疑问,请提及他们。我希望我有点作弊,但我现在无法想到任何真正危险的副作用。