[Postgres] Accept LocalDateTime (and similar types without a timezone) as parameter for a column of type timestamptz

This is started as an issue for Quarkus.

The problem is that when passing a LocalDateTime (or some similar type without a timezone) as parameter of an insert query we get the following error:

io.vertx.core.impl.NoStackTraceThrowable: Parameter at position[0] with class = [java.time.LocalDateTime] and value = [2020-07-16T10:10:24.378] can not be coerced to the expected class = [java.time.OffsetDateTime] for encoding.

Timestamptz doesn’t really store the timezone and it’s just state that everything is converted to UTC. So I’m not sure why it would be a problem to save the LocalDateTime by assigning it an UTC timezone and convert it to an OffsetDateTime.

This is an issue for Hibernate Reactive because we don’t know the type of the column on the database and we just assume that a timestamp will work.

[DavideD]

I still don’t get what the problem is, though. As far as I understand it, there is no convertion to do and the type is always UTC.

If you want to store a LocalDateTime into timestamp with timezone convert it to your preferred timezone first and trust that the PostgreSQL will faithfully reproduce it, regardless of how it’s stored.

Hibernate doesn’t know the type of the column on the database, so we don’t know when to add the timezone.

If I understand correctly, what you are asking is to add a timezone to a value so that the driver can ignore it because … checking notes … the timezone is always stored as UTC.

I’m not asking to add it to a standard because different databases might behave in different ways, but I still don’t get it why it cannot work for Postgres.

[kdubb]

As an implementor of a fully compliant JDBC driver for PostgreSQL (http://github.com/impossibl/pgjdbc-ng)… please let me suggest allowing local times here is the wrong path.

JDBC did this in its first couple versions; assuming a lot with about timezones and how the driver should be expected to convert them. It’s impossible to get correct. One person’s “common sense” doesn’t work for everybody. This was a nightmare to implement and I really don’t want to see this mistake repeated.

The wisdom of this is seen with JDBC 4.2’s addition of java.time types. They explicitly disallow “local” date/times in explicit fields. E.g. you cannot insert a LocalDateTime into a timestamp with timezone. As far as I remember, even ZonedDateTime isn’t supported by the specification.

If you want to store a LocalDateTime into timestamp with timezone convert it to your preferred timezone first and trust that the PostgreSQL will faithfully reproduce it, regardless of how it’s stored.