Do not serialize new Date(undefined) as "0NaN-NaN-NaNTNaN:NaN:NaN.NaN+NaN:NaN"

[ikonst]

Currently new Date(undefined) (an invalid date) is serialized as "0NaN-NaN-NaNTNaN:NaN:NaN.NaN+NaN:NaN" which is not parsed by Postgres in any meaningful way.

We can either fail early by throwing a JS error, or produce a Postgres value that more obviously indicates an invalid date (e.g. "Invalid date").

[abbas-ramish]

@charmander #3326

[itisrajeevsingh]

The behavior you're describing—where new Date(undefined) produces an invalid date is quirk. When you pass undefined, it tries to create a date from undefined, resulting in an Invalid Date object. However, when serialized (e.g., converted to a string), it can lead to unexpected results, like the strange "0NaN-NaN-NaNTNaN:NaN:NaN.NaN+NaN:NaN" output you observed.

To address this, the best practice would be to add validation logic that explicitly checks for invalid inputs to new Date() and throws an error early if the input is invalid. If you'd prefer the function to return a fallback value instead of throwing errors, you could use this approach:

function safeCreateDate(input) {
const date = new Date(input);
return isNaN(date.getTime()) ? null : date;
}

console.log(safeCreateDate(undefined));
console.log(safeCreateDate("2024-11-19"));

[charmander]

@brianc Does making this an error sound good? Target pg 9 with deprecation warning in pg 8, or…?

[brianc]

Yah i think that makes sense!

…

On Thu, Apr 16, 2026 at 2:53 PM Charmander ***@***.***> wrote: *charmander* left a comment (brianc/node-postgres#3318) <#3318 (comment)> @brianc <https://github.com/brianc> Does making this an error sound good? Target pg 9 with deprecation warning in pg 8, or…? — Reply to this email directly, view it on GitHub <#3318 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAMHIPAAOOZAUEYEIASGZL4WE23LAVCNFSM6AAAAACX4BLAMGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DENRSHE3TQNBVHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[charmander]

(After 9 bad AI-generated PRs on this, I figured I could use it as a demonstration of why the intermediary isn’t necessary. But I also did end up writing all of the code except for the deprecation message and the identifier names, because the AI-generated PRs on this are bad, and had to clean up the branch myself too. It was much slower and messier than doing it entirely by hand.)