DB:
$ mysql --version
mysql Ver 14.14 Distrib 5.6.27, for osx10.10 (x86_64) using EditLine wrapper
Spring Boot: 2.1.1.RELEASE
The error:
2019-01-01 15:56:25.849 ERROR 39957 --- [ restartedMain] com.zaxxer.hikari.pool.HikariPool : HikariPool-1 - Exception during pool initialization.
> :bootRun
java.sql.SQLException: The server time zone value 'AEDT' is unrecognized or represents more than one time zone. You must configure either the server or JDBC driver (via the serverTimezone configuration property) to use a more specifc time zone value if you want to utilize time zone support.
Relevant parts of my properties file:
spring.datasource.url=jdbc:mysql://127.0.0.1:3306/avmaint-local?useSSL=false&serverTimezone=UTC
spring.datasource.username=#####
spring.datasource.password=########
spring.jpa.database-platform=org.hibernate.dialect.MySQL5InnoDBDialect
What I find odd about this is that the error indicates that the timezone being used it AEDT, and yet I specified UTC in the spring.datasource.url. Does Hikari read something else when it initializes?
It does look very much like Hikari ignores the server timezone setting in the database url in favour of using my own machine's timezone which happens to be 'AEDT' (Melbourne, Australia) - This is unwanted behaviour. I would like Hikari to ignore my own machine's timezone. Does anyone know how to make it do that?
Thanks for your answers, but I have found the solution.
As I suspected, Hikari ignores whatever you put in the datasource URL (so sorry guys, it doesn't matter what you chuck in there), essentially, it reads the timezone setting from MySQL itself, i.e., whatever the result you see when issuing the command:
SELECT @@GLOBAL.time_zone;
in MySQL. In my case, the result was "SYSTEM", which is whatever my local machine it set at. This was AEDT, which is not supported by the MySQL driver and hence my exception.
Running this same query in AWS yielded the value "UTC", which is supported (and, actually what I wanted).
Therefore, I had to set the timezone in my local MySQL server.
Firstly, I had to load the available timezones from my host (Mac OS X) into MySQL. I had to find out where the zoneinfo file was (/usr/share/zoneinfo in my case) then find out out where the `mysql_tzinfo_to_sql' utility was (bin directory of the MySQL installation) and use it to load my local machine's supported timezones. In Mac OS X, I ended up running the command:
/usr/local/mysql/bin/mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql
Then in MySQL I could run the command:
SET GLOBAL time_zone = UTC;
this is a valid timezone, and is synchronized with the cloud based instances.
I think this is a real trap for a lot of people using MySQL with Spring Boot. It will work while people are in supported timezones, but if your development machine should switch to an unsupported timezone, it will quite mysteriously break, I'm surprised that it isn't documented anywhere. The source code of the MySQL Connector/J makes it obvious, but you wouldn't know it otherwise.
Maybe its because MySQL is just so 5 years ago, and I'm an old fossil and, and, well, just get off my lawn!