Skip to content
Permalink
Browse files
fix: infinite dates might be corrupted when transferred in binary for…
… certain JREs

The error was TimestampTest.testInfinity:122->runInfinityTests:154 expected:<[infinity]> but was:<[5881610-07-11]>

The bug reproduced when trying to build pgjdbc 42.1.0 using
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-468-11M4833)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-468, mixed mode)
  • Loading branch information
vlsi committed May 5, 2017
1 parent 4482761 commit 1e5bf563f41203417281117ed20b183cd295b4e0
@@ -2,3 +2,4 @@
* fix: calculation of lastReceiveLSN for logical replication [PR#801](https://github.com/pgjdbc/pgjdbc/pull/801)
* fix: make sure org.postgresql.Driver is loaded when accessing though DataSource interface [#768](https://github.com/pgjdbc/pgjdbc/issues/768)
* feat: support fetching a REF_CURSOR using getObject [PR#809](https://github.com/pgjdbc/pgjdbc/pull/809)
* note: there's no 42.1.0.jre8 due to infinity handling bug. Fixed in 42.1.1.jre6
@@ -830,14 +830,15 @@ public Date toDateBin(TimeZone tz, byte[] bytes) throws PSQLException {
long secs = toJavaSecs(days * 86400L);
long millis = secs * 1000L;

// Here be dragons: backend did not provide us the timezone, so we guess the actual point in
// time
millis = guessTimestamp(millis, tz);

if (millis <= PGStatement.DATE_NEGATIVE_SMALLER_INFINITY) {
millis = PGStatement.DATE_NEGATIVE_INFINITY;
} else if (millis >= PGStatement.DATE_POSITIVE_SMALLER_INFINITY) {
millis = PGStatement.DATE_POSITIVE_INFINITY;
} else {
// Here be dragons: backend did not provide us the timezone, so we guess the actual point in
// time

millis = guessTimestamp(millis, tz);
}
return new Date(millis);
}

0 comments on commit 1e5bf56

Please sign in to comment.