Since Hibernate 5.2.3, you can also use the hibernate.jdbc.time_zone configuration property which is described in great detail in this article.

In your case, the property should be set like this:

<property
    name="hibernate.jdbc.time_zone"
    value="Europe/Berlin"
/>

Now, related to those MySQL settings you configured:

• zeroDateTimeBehavior=convertToNull
• useUnicode=true
• useJDBCCompliantTimezoneShift=true
• useLegacyDatetimeCode=false
• serverTimezone=Europe

According to MySQL JDBC Driver docs, if you set the useLegacyDatetimeCode to false will void the effect of useJDBCCompliantTimezoneShift

Setting this property to 'false' voids the effects of "useTimezone," "useJDBCCompliantTimezoneShift," "useGmtMillisForDatetimes," and "useFastDateParsing."

So the useJDBCCompliantTimezoneShift is not taken into consideration:

This is part of the legacy date-time code, thus the property has an effect only when "useLegacyDatetimeCode=true."

Just try with hibernate.jdbc.time_zone and see if it works better.

Also, related to this statement of yours:

The value is stored in consumer as java.sql.Date, producer timezone is considered (value is 315529200000 "milliseconds", see Online Converter).

Because the consumer is in GMT, the date's internal calendar is represented as 1979-12-31T23:00:00.000Z, which can be still described as correct because the time part is obligatory in the underlying calendar.

The java.sql.Date, just like java.util.Date, has no notion of timezone. It's just a point in time, or more cleraly, a number of millis since epoch. What you see when you call toString is just a formatting according to the local TimeZone. However, it has no effect on the way the date/time info is stored.