Regression in 1.5.1, PG date to/from java.sql.Date conversions

[pmichalek]

After transition to winter time on night to 28th October 2018 calling TriggerResultSet.getDate(...) returns one day before.
DB: 28-10-2018 -> getDate(...) -> Java: 28-10-2018 (night was one hour longer)
DB: 29-10-2018 -> getDate(...) -> Java: 28-10-2018
DB: 30-10-2018 -> getDate(...) -> Java: 29-10-2018

Fedora 27 (time zone CET)
Java version 1.8.0.192 and 1.8.0.162
Postgresql 11.0 and 10.4 (timezone='Europe/Prague')

[jcflack]

On 10/30/18 4:08 PM, pmichalek wrote: After transition to winter time on night to 28th October 2018 calling TriggerResultSet.getDate(...) returns one day before. DB: 28-10-2018 -> getDate(...) -> Java: 28-10-2018 (night was one hour longer) DB: 29-10-2018 -> getDate(...) -> Java: 28-10-2018 DB: 30-10-2018 -> getDate(...) -> Java: 29-10-2018 Fedora 27 (time zone CET) Java version 1.8.0.192 and 1.8.0.162 Postgresql 11.0 and 10.4 (timezone='Europe/Prague')

Is the same problem seen with getObject(..., java.time.LocalDate.class)? Do you have an easy way to see if PL/Java 1.5.0 behaved differently (i.e., is this a behavior change)?

[pmichalek]

Is the same problem seen with getObject(..., java.time.LocalDate.class)?

getObject(..., java.time.LocalDate.class) seems to be OK!

Do you have an easy way to see if PL/Java 1.5.0 behaved differently (i.e., is this a behavior change)?

Unfortunately not.

[jcflack]

On 10/30/18 4:52 PM, pmichalek wrote: > Is the same problem seen with getObject(..., java.time.LocalDate.class)? getObject(..., java.time.LocalDate.class) seems to be OK! > Do you have an easy way to see if PL/Java 1.5.0 behaved differently (i.e., is this a behavior change)? Unfortunately not.

Unfortunately not easy to check, or not a behavior change?

[jcflack]

I can reproduce in PG 11 / PL/Java 1.5.1 by setting TimeZone to Europe/Prague (changing no other settings):

set TimeZone to 'Europe/Prague';
select *
  from
    (select date '2018-10-29') as p,
    roundtrip(p) as (tostring text, class text);
    date    |  tostring  |     class     
------------+------------+---------------
 2018-10-29 | 2018-10-28 | java.sql.Date

select *
  from
    (select date '2018-10-29') as p,
    roundtrip(p, 'java.time.LocalDate') as (tostring text, class text);
    date    |  tostring  |        class        
------------+------------+---------------------
 2018-10-29 | 2018-10-29 | java.time.LocalDate

Now to see if 1.5.0 did the same thing....

[pmichalek]

Postgresql 9.6.2 with branch trackpg/REL1_5_STABLE/pg96 seems to be OK!

[jcflack]

Rats. That would suggest 1.5.1 broke it then.

Could you try the bug/REL1_5_STABLE/issue199 branch?

[pmichalek]

Branch bug/REL1_5_STABLE/issue199 is OK

[jcflack]

There will be a 1.5.2 to fix this 1.5.1 regression.

However, analysis for this issue uncovered several other, longstanding issues in the legacy date, time, and timestamp conversions to and from the java.sql types, now detailed in #200. Because those are not regressions, they will be left alone in 1.5.2 and fixed in a later release.

Meanwhile, all of these issues underscore the advantages of migrating code to Java 8 or later and the java.time types wherever practical.

[jcflack]

Resolved with release of 1.5.2.