[CONJ-822] Difficulties with time zone handling Created: 2020-08-20 Updated: 2020-08-20 |
|
| Status: | Open |
| Project: | MariaDB Connector/J |
| Component/s: | configuration |
| Affects Version/s: | 2.6.0 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Mauro Molinari | Assignee: | Diego Dupin |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Linux Mint 18.3 (based on Ubuntu 16.04) client |
||
| Description |
|
Was trying to better handle time zone differences between my client (time zone is GMT) and the MySQL server I connect to (whose time zone is CEST, which is GMT+2 right now due to DST). So, looking at: https://mariadb.com/kb/en/about-mariadb-connector-j/#infrequently-used-parameters The first problem I saw and that I discovered by debugging org.mariadb.jdbc.internal.protocol.AbstractConnectProtocol.loadCalendar(String, String) is that the mentioned property is ignored by default. I must also set another non-documented property which is: useLegacyDatetimeCode=false Secondly, once I added the latter option I got a parse error because "CEST" seems not to be a valid time zone id for Java. No problem, I can fix by setting serverTimezone=Europe/Rome instead. But it's much more strange the behaviour when you set useLegacyDatetimeCode=false but you don't set any serverTimezone. In this scenario, an when MySQL @time_Zone is set to SYSTEM, the driver is supposed to use the system time zone as set on the MySQL server. In fact, this code is executed in org.mariadb.jdbc.internal.protocol.AbstractConnectProtocol.loadCalendar(String, String):
In my case, srvTimeZone and srvSystemTimeZone are set by org.mariadb.jdbc.internal.protocol.AbstractConnectProtocol.postConnectionQueries() to be serverData.get("time_zone") and serverData.get("system_time_zone") respectively. On my MySQL instance, this query: To sum up, I see two problems:
Please note that the Ubuntu system where that MySQL instance is running has a /etc/timezone containing: Europe/Rome. Still, MySQL sets its @@system_time_zone variable to CEST (which is an alias for the same time zone, though). This is "by default", that is I didn't change anything in MySQL configuration to cause this. MySQL was installed through the distribution package manager (apt). |
| Comments |
| Comment by Mauro Molinari [ 2020-08-20 ] |
|
Strange enough, while Java supports "CET" (Central European Time, used in winter), it does not support "CEST" (Central Europen Summer Time), although when you create a new Date instance its toString() returns: Thu Aug 20 12:03:56 CEST 2020!! It seems like the parsing code in java.time maps CEST to Europe/Berlin though (https://stackoverflow.com/a/44658190/1465635): you may handle this in the same way, given that MySQL seems to use CEST... |