Fix Spring Boot MySQL Server Time Zone Unrecognized Error (2026)

The MySQL server refused to accept your connection because it couldn’t understand the time zone you specified.

This error, com.mysql.cj.exceptions.InvalidPropertiesException: The server time zone value '***' is not recognized, typically surfaces when your Spring Boot application tries to establish a connection to a MySQL database and the server’s configured time zone isn’t something the MySQL Connector/J driver knows about. The driver, which is responsible for translating your Java application’s requests into MySQL-speak, has a limited, built-in list of valid time zone identifiers. If your MySQL server is set to something obscure or custom, the connector just throws its hands up.

Here are the most common reasons this happens and how to fix them:

1. MySQL Server’s time_zone is Set to a Non-Standard Value

This is the most frequent culprit. Your MySQL server might have its time_zone system variable set to something that isn’t a recognized IANA (e.g., "America/New_York") or a simple UTC offset (e.g., "+00:00").

• Diagnosis: Connect to your MySQL server using the mysql client and run:

  SHOW VARIABLES LIKE 'time_zone';
  

  If the Value returned is something like SYSTEM, *** (as in the error), or a custom string, this is your problem.

• Fix: You need to set the time_zone to a recognized value. The best practice is to use an IANA time zone name.

  • Option A (Temporary, until restart):

    SET GLOBAL time_zone = 'UTC'; -- Or 'America/New_York', 'Europe/London', etc.
    

    This change is effective immediately for new connections but will be lost when the MySQL server restarts.
  • Option B (Permanent): Edit your MySQL configuration file (e.g., my.cnf or my.ini). Find the [mysqld] section and add or modify the time_zone directive:

    [mysqld]
    # ... other settings
    time_zone = 'UTC' # Or your preferred IANA time zone
    # ... other settings
    

    After saving the file, restart your MySQL server for the change to take effect.

• Why it works: By setting time_zone to a value the MySQL Connector/J driver expects, you’re allowing the communication handshake to complete successfully. The driver knows how to interpret standard time zone identifiers.

2. Spring Boot’s spring.datasource.url Overrides Server Setting Incorrectly

Your Spring Boot application’s application.properties or application.yml might be explicitly setting a time zone in the JDBC URL, and this value is not compatible with MySQL.

• Diagnosis: Inspect your application.properties (or application.yml) for the spring.datasource.url property. Look for a parameter like serverTimezone=....

  spring.datasource.url=jdbc:mysql://localhost:3306/mydb?serverTimezone=UTC
  

  If the value provided to serverTimezone is not a valid IANA time zone or a standard UTC offset, it can cause this error. Note that the MySQL Connector/J driver expects specific formats here.

• Fix: Ensure the serverTimezone parameter in your JDBC URL uses a valid IANA time zone name or a UTC offset.

  • Recommended:

    spring.datasource.url=jdbc:mysql://localhost:3306/mydb?serverTimezone=UTC
    

    or

    spring.datasource.url=jdbc:mysql://localhost:3306/mydb?serverTimezone=America/New_York
    

  • Alternatively, remove it: If your MySQL server’s time_zone is already correctly configured (as per fix #1), you might not need to specify serverTimezone in the URL at all. The driver will often default to UTC or the server’s setting.

    spring.datasource.url=jdbc:mysql://localhost:3306/mydb
    

• Why it works: The serverTimezone parameter in the JDBC URL is a direct instruction to the MySQL Connector/J driver about which time zone to use for its internal operations and for communicating with the server. Providing a valid, recognized value allows the driver to function correctly.

3. Mismatched Time Zone Information Between Java Runtime and MySQL Server

Less common, but possible, is a scenario where your Java Runtime Environment (JRE) has a different understanding of time zones than your MySQL server, and the connector gets confused by the discrepancy, especially if the MySQL time_zone is set to SYSTEM.

• Diagnosis:

  • Check your MySQL time_zone variable (as in fix #1). If it’s SYSTEM, this becomes more relevant.
  • In your Java application, you can check the JVM’s default time zone:

    System.out.println(java.util.TimeZone.getDefault().getID());
    

  If the JVM’s default time zone ID is something unexpected or different from what MySQL SYSTEM might infer, it can lead to issues.

• Fix: The most robust solution is to explicitly set the time zone for your Spring Boot application and ensure it matches a recognized MySQL time_zone setting.

  • In application.properties:

    spring.datasource.url=jdbc:mysql://localhost:3306/mydb?serverTimezone=UTC
    spring.jpa.properties.hibernate.jdbc.time_zone=UTC # If using Hibernate
    # Or for Tomcat/Jetty directly, though less common with Spring Boot's defaults
    # server.tomcat.zone-id=UTC
    

  • JVM Argument: You can also set the default time zone for the JVM when launching your Spring Boot application:

    java -Duser.timezone=UTC -jar your-app.jar
    

• Why it works: Explicitly defining the time zone for both the database connection (via serverTimezone) and potentially the application’s runtime (via user.timezone or framework-specific properties) ensures consistency. When MySQL’s time_zone is SYSTEM, it relies on the OS’s time zone, which might not align with your Java application’s default or configured time zone. Forcing a specific, known time zone eliminates this ambiguity.

4. Corrupted or Incomplete Time Zone Data in MySQL

The MySQL server relies on time zone definition files. If these are corrupted or missing essential entries, it can lead to unrecognized time zones.

• Diagnosis: This is harder to diagnose directly. If you’ve verified your my.cnf and the time_zone variable shows a standard name (like America/New_York) but you’re still getting the error, it’s possible the underlying data is bad. You can try running mysql_tzinfo_to_sql to re-import the time zone data.

• Fix: Re-import the time zone data into MySQL.

  1. Ensure you have the time zone information files on your system (often in /usr/share/zoneinfo).
  2. Execute the mysql_tzinfo_to_sql command, pointing it to your MySQL client:

     mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql
     

     You’ll be prompted for the MySQL root password.
  3. After importing, restart your MySQL server.
  4. Verify the time_zone variable again using SHOW VARIABLES LIKE 'time_zone';.

• Why it works: This process populates the mysql.time_zone_name and mysql.time_zone tables within the mysql system database. These tables contain the definitions that MySQL uses to interpret time zone names. Re-importing ensures the server has accurate, complete data to resolve the time zone specified.

5. Using an Outdated MySQL Connector/J Version

Older versions of the MySQL Connector/J might not support newer IANA time zone names or might have bugs related to time zone handling.

• Diagnosis: Check your project’s dependency management file (e.g., pom.xml for Maven or build.gradle for Gradle) to see the version of mysql-connector-java you are using. Compare it against the latest stable version available.

• Fix: Update the mysql-connector-java dependency to the latest stable version.

  • Maven (pom.xml):

    <dependency>
        <groupId>mysql</groupId>
        <artifactId>mysql-connector-java</artifactId>
        <version>8.0.33</version> <!-- Use the latest stable version -->
    </dependency>
    

  • Gradle (build.gradle):

    implementation 'mysql:mysql-connector-java:8.0.33' // Use the latest stable version
    

  After updating, rebuild your project.

• Why it works: Newer versions of the connector have improved time zone support, bug fixes, and compatibility with more recent MySQL server features and time zone definitions.

The next error you’ll likely encounter if you’ve fixed this and there are other configuration issues is related to character encoding, often appearing as Unsupported character encoding: UTF-8 or similar, if your useUnicode=true and characterEncoding=UTF-8 parameters are missing from the JDBC URL.