[CONJ-202] java.sql.SQLException: The server time_zone 'EDT' cannot be parse by java connector. Created: 2015-10-06  Updated: 2015-10-06  Resolved: 2015-10-06

Status: Closed
Project: MariaDB Connector/J
Component/s: Other
Affects Version/s: 1.3.0
Fix Version/s: 1.2.3

Type: Bug Priority: Major
Reporter: Christian Bourque Assignee: Diego Dupin
Resolution: Not a Bug Votes: 0
Labels: None


 Description   

Opening a simple connection to MariaDB using current development driver (1.3.0-20150928.170949-11) leads to an exception (works fine with 1.2.3):

java.sql.SQLException: The server time_zone 'EDT' cannot be parse by java connector. The server time zone must be precised in the jdbc url string by the 'serverTimezone' parameter (or change server time zone)
at org.mariadb.jdbc.internal.mysql.MySQLProtocol.connect(MySQLProtocol.java:547)
at org.mariadb.jdbc.internal.mysql.MySQLProtocol.connectWithoutProxy(MySQLProtocol.java:770)
at org.mariadb.jdbc.internal.common.Utils.retrieveProxy(Utils.java:506)
at org.mariadb.jdbc.Driver.connect(Driver.java:102)
at java.sql.DriverManager.getConnection(DriverManager.java:571)
at java.sql.DriverManager.getConnection(DriverManager.java:215)
at com.expretio.mavenproject5.TestSuite.testMariaDB(TestSuite.java:120)

 Comments   
Comment by Christian Bourque [ 2015-10-06 ]

It works with 1.3.0-beta-2 as well!

Comment by Christian Bourque [ 2015-10-06 ]

Hmmm I just realized that my snapshot is really old (2015-09-28)! Is it normal that this is the latest one available here: https://oss.sonatype.org/content/repositories/snapshots?

Comment by Diego Dupin [ 2015-10-06 ]

We rely on Java time zone implementation to retrieve timezone from server Time zone value.
That may be not enough, but seems strange that TimeZone.getTimeZone("EDT") is unknown.
Will check that, that must be cause by something else.

(Snapshot is now up)

Comment by Diego Dupin [ 2015-10-06 ]

I confirm that only this snapshot has this error, current release version 1.2.3 and next version 1.3.0 doesn't have the problem.

For information, if using next option useLegacyDatetimeCode=false ( version > 1.3.0) you will have this problem too, because EDT is not a valid time zone (note sure of that, but the valid time zone corresponding to this one must be EST5EDT).

I close this issue. Feel free to answer, or recreate another one if not.

Comment by Christian Bourque [ 2015-10-06 ]

Hey Diego,

I can confirm that EDT is a valid timezone: https://en.wikipedia.org/wiki/Eastern_Time_Zone

And that Java 7 is able to parse its ID: TimeZone tz = TimeZone.getTimeZone("EDT");

Comment by Diego Dupin [ 2015-10-06 ]

If you list TimeZone.getAvailableIDs(), you will not find this ID.
The problem is that Java has a strange behaviour concerning TimeZone : it fall back on GMT when unknown.
You can check that with TimeZone.getTimeZone("EDT").getID().equals("GMT") (just tested with jre 8)

tzdata source distribution doesn't have this "EDT" Too, but have "US/Eastern" for backward compatibility.
Usage of tree letters TimeZone is deprecated, because of confusion with relocation for example - best to use full description like "America/New_York".

Comment by Christian Bourque [ 2015-10-06 ]

Well this is a problem because "EDT" is the actual value returned on our Linux/MariaDB server!

Even though the real timezone is mapped like that: /etc/localtime -> /usr/share/zoneinfo/America/Montreal

Comment by Diego Dupin [ 2015-10-06 ]

to be sure, check mariadb time_zone with this query : SHOW GLOBAL VARIABLES LIKE 'time_zone';
if the result is "SYSTEM", this is taken from system.

America/Montreal file is EST5EDT on debian 8.

It will not cause problem for MariaDB connector/J actually, you must just known that if a java application is on the same server, by default timestamps will be saved on GMT, not EDT time.

Comment by Christian Bourque [ 2015-10-06 ]

Indeed "SYSTEM" is returned!

Thanks

Generated at Thu Feb 08 03:13:56 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.