Mismatch in Date precision causes odd behavior

The PostgreSQL TIMESTAMP type has a maximum precision of 1 microsecond, but the JavaScript Date type only has a maximum precision of 1 millisecond. This causes information to be silently discarded, leading to bizarre behavior:

client.query("SELECT '2017-01-01 00:00:00.00001'::timestamp as d", (err, res) => {
let date = res.rows[0].d;

client.query("SELECT '2017-01-01 00:00:00.00001'::timestamp = $1 as eq,\
'2017-01-01 00:00:00.00001'::timestamp > $1 as gt", [date], (err, res) => {
console.log(res.rows[0].eq); //false
console.log(res.rows[0].gt); //true
});
});

I’m not sure this a bug that could be fixed without using a non-standard Date object, but even if it isn’t fixed it should be at least noted in the documentation.

[williamstein]

For what it’s worth, I probably wasted about 60 hours last week, and cause a lot of pain to users, because there wasn’t a sentence about this in the main README.md page. I did systematically read through the fine README before starting to use the driver, and if there was a warning about timestamps silently rounding by “textually deleting the last 3 digits” instead of rounding, it would have helped. (And other than this, I really like this driver!)

I think the behavior of the driver is perhaps more surprising than your examples above suggest. What happens with the driver is completely different than what happens using postgresql’s ::timestamp(3) explicit cast, which rounds to the nearest timestamp, rather than just textually removing the last 3 digits.

[vitaly-t]

JavaScript doesn’t support microseconds, so wouldn’t this be self-implying for a JavaScript library?

No point documenting the obvious, imo.

And there is nothing bizarre in your example, because:

let date = res.rows[0].d;
//=> 2017-01-01T00:00:00.000Z

which makes the rest logically apparent:

2017-01-01 00:00:00.00001 = 2017-01-01T00:00:00.000Z => false
2017-01-01 00:00:00.00001 > 2017-01-01T00:00:00.000Z => true