setTimestamp use timestamptz db type

[arons]

setTimestamp use timestamptz db type
old pull request #2835
this pull request should fix also the issue #1325 ( test cases added into class org.postgresql.test.jdbc2.TimestamptzTest )

New Feature Submissions:

1. Does your submission pass tests?
2. Does ./gradlew styleCheck pass ?
3. Have you added your new test classes to an existing test suite in alphabetical order?

Changes to Existing Features:

• Does this break existing behaviour? If so please explain.
  it breaks currently behaviour only in case user set sqlTimestamptzAlways
• Have you added an explanation of what your changes do and why you'd like us to include them?
  explained already in pull request setTimestamp use timestamptz db type #2835
• Have you written new tests for your core changes, as applicable?
• Have you successfully run tests with your changes locally?

[davecramer]

Why do another PR ?

[arons]

I did some mistake on the original github fork and it closes the pull request. So I created a new one, sorry.

[davecramer]

s/time stamp/timestamp

[davecramer]

s/2004/2024

[liias]

Hmm ZonedDateTime.toLocalDateTime() would just forget the timezone of the zdt?
Also, why would it support ZonedDateTime, but not OffsetDateTime?

I might be wrong with my assumptions here of course.

[arons]

Your assumption is correct, so I changed it to use OffsetDateTime type so that time zone information is not lost but stored into the timestamptz.

Anyway, if you use OffsetDateTime to fetch data back form the db, the time zone info is lost as illustrated by the test case TimestamptzTest.test_ZonedDateTime_StoreAndSelect().
How is the correct way to get back the information of the timezone (without using string) ?

NOTE: in our application we always store dates in UTC time zone in the db to avoid any problem. If we need to store information about the time zone to use for some business logic that is stored into a separate fields independent to any stored timestamptz.

[vlsi]

Please avoid fail(e.getMessage()); pattern as it adds no extra value, and it hides the stacktrace. In cases like this just let the exception propagate, and do not catch it.

[vlsi]

@arons , can you please clarify which issue does this change solve?
Please see #2835 (comment)

I am afraid, it is hard to review the change without understanding the problem it solves.

[arons]

The problem it solves is to correctly pass the proper OID type for timestamps to the database, instead of just as text, which is the current behavior.

This is useful in many different cases as it allows SQL and PL/SQL to use the parameter properly without requiring an explicit cast.
Within the class TimestamptzTest, there are basic examples of statements that will fail if a timestamp parameter is passed as a string.
I can provide even more examples of problems if necessary.

[vlsi]

I can provide even more examples of problems if necessary

It would be great. I would suggest we solve problem a time rather than combine everything possible within a single discussion.

Within the class TimestamptzTest, there are basic examples of statements that will fail if a timestamp parameter is passed as a string.

There are cases like select ? and select pg_typeof(?), and I believe they are not quite niche, so we should not consider them as the primary driving factor.

[davecramer]

How is this different than #2715 ?

[arons]

There are cases like select ? and select pg_typeof(?), and I believe they are not quite niche, so we should not consider them as the primary driving factor.

testTypeOnDbSite_functionOverloading and testTypeOnDbSite_select are less trivial once already.

In the current implementation:
The first: it takes the worng function implementation in case of overloading.
The second: throw an exception if we try to add an interval to a timestamp passed parameter.

It should fix also the issue #1325 (also in the test case, no error any more in invoking the setObject method )

[arons]

How is this different than #2715 ?

If I understand the patch correctly, that is more about the returned meta data type and not about parameter set.

[davecramer]

How is this different than #2715 ?

If I understand the patch correctly, that is more about the returned meta data type and not about parameter set.

in which case these PR's should be combined.

[vlsi]

testTypeOnDbSite_functionOverloading

Currently it defines a function with timestmaptz, and a function with text parameters.

I would suggest adding timestamp (without tz), time, and timetz into the mix and suggest the way you would expect it to work.

Frankly speaking, I think setTimestmap( new Timestamp(..)) should fail rather than arbitrary select timestamptz overload among timestamp and timestamptz.

[arons]

testTypeOnDbSite_functionOverloading

Currently it defines a function with timestmaptz, and a function with text parameters.

I would suggest adding timestamp (without tz), time, and timetz into the mix and suggest the way you would expect it to work.

Frankly speaking, I think setTimestmap( new Timestamp(..)) should fail rather than arbitrary select timestamptz overload among timestamp and timestamptz.

I agree with that: https://wiki.postgresql.org/wiki/Don%27t_Do_This#Don.27t_use_timestamp_.28without_time_zone.29
So that is the reason I prefer to use timestamptz among timestamp, which for me should in general not be used.

So if you prefer to use timestamp over timestamptz I think we can close the discussion and close this pull request cause my motiviation is only about timestamptz.