Nanosecond part of binary-received float8-timestamp needs to be rounded.

[horiguti]

If a float8-timestamp is received on a binaryTransfer connection, its
nanosecond part is just truncated in toParsedTimestampBinPlain. If the
result of the subtraction just before gets slightly smaller, the
result gets smaller by 1 microsecond. Nanosecond part is rounded off
on server side so it should be handled the same way.

This problem can be seen by the following steps, with pgjdbc versions from 9_2 where binaryTransfer was introduced.

Create a table on a PostgreSQL server built with --disable-integer-datetimes:
CREATE TABLE t AS (SELECT '2020-6-5 0:0:0.464'::timestamp as a);

Access by a program like the follows:
public static void main (String args[]) {

 String url = "jdbc:postgresql:postgres?binaryTransfer=true"; // URL

 try {
   Class.forName("org.postgresql.Driver");
   Connection con = DriverManager.getConnection(url);
   PreparedStatement pst = con.prepareStatement("SELECT a from t;");
   for (int i = 0 ; i < 6 ; i++) {
     ResultSet rs = pst.executeQuery();
     while (rs.next())
       System.out.format("%d: %s\n", i, rs.getTimestamp(1).toString());
     rs.close();
   }

You should see the following result. The last one is the issue here.

0: 2020-06-05 00:00:00.464
1: 2020-06-05 00:00:00.464
2: 2020-06-05 00:00:00.464
3: 2020-06-05 00:00:00.464
4: 2020-06-05 00:00:00.464
5: 2020-06-05 00:00:00.463999

reagrds.

[horiguti]

In second thought, just adding 0.5 seems to be better than using Math.round().

[davecramer]

I'm surprised anyone uses float8 timestamps. Is there a reason for this ?

[horiguti]

I'm surprised anyone uses float8 timestamps. Is there a reason for this ?

I'm surprised, too:p, and I'm not sure about the reason for the system(w/ PG9.6) being configured with float timestamps, nor the reason for upgrading JDBC driver from 9.0 to 42..

[davecramer]

So how do we test this ?

[horiguti]

The added test checks the behavior for the specific value, but that would be sufficient.
It fails with 9.6/float-datetimes without this fix, and succeeds with 9.6/float-datetimes with this fix. It skips the test when testing server is configured with integer-datetimes.

[davecramer]

@horiguti can you fix the style issues? Ideally I would like the name of the test to be more aligned with what it is actually testing.