Time zone problem

Episode: Why time zones? The main reason is that there was a section in the creation of the contract to check the expiration of the contract. I made a joke about time zones and found that all creation times were 8 hours shorter, so today I spent the weekend talking about time zones.

1. Take a look at the mysql time zone of the current environment

Coordinated Universal Time (UTC) Because the abbreviations for CUT and TUC are different, the compromise is simply UTC.) UTC differs by 8 hours from Beijing time

The time taken in the code at the time was 8 hours off, so all contracts expired (embarrassing batch) and the problem was finally discovered

2.1. Solution (For mysql time zone problem)

  1. Set time zone + 8 hours (can be resolved by calling now() function)

2. Set the mysql time zone to CTS (not recommended, the time zone is chaos time zone, which is similar to JDBC in Java).

2.2 Solutions (For project operating environment)

Resolve this by adding serverTimezone (can’t resolve calling now() function) 2. Through Jackson Configuration

conclusion

This problem occurs because the time zone of the server is inconsistent with the time zone of the database, and the time zone of the database is not converted to the EAST 8 zone. As a result, the time zone where data is stored differs from the local time zone by 8 hours. You are advised to configure the same time zone for the server and database. Try not to use internal calls such as (now function), to solve this problem, first to locate the data time zone, or the server time zone problem, so as to take a different solution. (Of course, these are just some of the ways.)