fix: avoid timezone conversions when sending LocalDateTime to the database

[vlsi]

Previously, LocalDateTime was converted to OffsetDateTime using the default timezone, which made certain values unrepresentable. For instance, 2023-03-12T02:00 in America/New_York is hard to represent as it undergoes DST change.

It does not change resultSet.getObject(int | string), and resultSet.getString(int | string) and those methods would still have issues when accessing timestamps like 2023-03-12T02:00 when the client time zone is America/New_York

Fixes #1390
Fixes #2850
Closes #1391

[vlsi]

This change brings back inconsistency of getString() for timestamp values in binary vs text format.
The DB sends timestamp in text format as 2000-03-26 02:00:00, and when it sends the timestamp in binary we roundtrip with Timestamp, and result in 2000-03-26 03:00:00.

So getString should be fixed as well.

[vlsi]

This yields +00:00 OffsetDateTime since PostgreSQL does not store and return the offset.

It causes the failure like

    org.junit.ComparisonFailure: tstz -> getString, binary expected:<2005-01-01 1[5:00:00+03]> but was:<2005-01-01 1[2:00:00+00]>

Any thoughts on whether we should fix it?

[davecramer]

The only solution to this is to not allow sending timestamptz in binary. Or we apply the client timezone to the received value.

[vlsi]

I went with "apply client timezone to the received value" (see withOffsetSameInstant). It keeps compatibility regarding .getString() which might be a nice thing to have.

[vlsi]

This was the actual test for the feature. In other words, previously, the test used atZone formatting of the local date time which was invalid, and it augmented the input date. That made the test to pass without issues. Now we avoid atZone formatting, and we use the input value as is, and we test the output is the same.