Hibernate currently handles the SQL type TIMESTAMP WITHOUT TIME ZONE as some (varying between environments!) notion of local time, whereas all other environments that work with timestamps without any indication of timezone (save Kolab) handle it as anchored in UTC time.

Worse, Hibernate maps a java.util.Date (whose only currently-allowed constructor is the Long constructor taking milliseconds since the Unix epoch, UTC) to this by default.

Furthermore, mapping of the SQL type TIMESTAMP WITH TIME ZONE seems (according to a WWW and StackOverflow recherche) to have its own problems, so currently, applications using Hibernate can only reliably store timestamps as BIGINT (i.e. direct mapping from Long) in the database, which is not so nice on the SQL side, asides from being semantically wrong.

This proposal adds a UtcTimestampType which can be used with an @Type annotation to force bidirectional mapping of a java.util.Date as UTC time (unless an explicit timezone is given, i.e. changing just the cases where the “default timezone” was used prior), per occurrence in an entity. The addition of this as a new type which has to be manually enabled on a per-entity-field basis ensures no existing behaviour is changed in any way.

This is required in order to allow applications to reliably store and retrieve timestamps from a database. I have tested this with TIMESTAMP WITHOUT TIME ZONE to much success, and I believe it can also be used with TIMESTAMP WITH TIME ZONE.

The pull request will be sent RSN, I’m getting prereqs done first.