I often work in environments where it is lights management, as in I have not access to production servers. (I cannot critique this much as I also develop software that allows companies to do this). Therefore, I have extremely limited capacity to try and set server time or timezone, let alone influence the system admins.
The JDBC spec for 4.2; like Java 8 was finally cleaning up dates and times which have been an issue since Java 1.
From a practical perspective, what we care about is consistent representation of data when the data leaves Hibernate and maybe at the JDBC level. With PostgreSQL the value is always stored as UTC. The driver is responsible for translating UTC to local time. If you use Timestamp datatype in MySQL, the behavior is effectively the same as PostgreSQL with the difference that the database server handles the timezone translation based on the timezone established at connection. Oracle, I forget where the timezone is translated, but the result is handled in both cases where the timezone is included in the data type.
I do use my simple class above, but in reality it is not the correct solution, the correct solution requires more intensive changes in the dialect than what I did above. It solves my needs since I do not ever envision having a Timestamp without a timezone.
I believe the correct solution is to more correctly model the java data types, when the java data type includes a timezone implicitly (Instant) or explicitly (OffsetDateTime); Hibernate should respect it and map to TIMESTAMP_WITH_TIMEZONE if this is supported by the database. If the Java data type does not include timezone information (LocalDateTime) then mapping to TIMESTAMP without timezone would be correct. In PostgreSQL “timestamp with time zone” and “timestamp”. For MYSQL it would be “timestamp” and “datetime”. For Oracle, you can pick either ‘timestamp with time zone’ or ‘timezone with local time zone’ to handle the timezone and the normal ‘timestamp’ for the absence of timezone case.
And yes, this could be a breaking change. However, it is the correct solution, otherwise, you will get lots of band-aids such as mine above applied to Hibernate.