[bug] Tanstack Router: `parseAsTimestamp` parses defalt value as `1970-01-01T00:00:02.025Z` when reloaded or opened with searchParams

[mdhruvil]

Context

What's your version of nuqs?

"nuqs": "^2.7.2"

What framework are you using?

• ✅ Other (Tanstack Router)

Which version of your framework are you using?

"@tanstack/react-router": "^1.132.0",
"react": "^19.0.0",
"react-dom": "^19.0.0"

Description

BUG: When query states is changed to ?from=1760207400000&to=1760812199999 and I reload the page or open the same URL in different tab, it fails to parse the value and changes the url to ?from="1970-01-01T00%3A00%3A02.025Z"&to="1970-01-01T00%3A00%3A02.025Z"

EXPECTED: URL to be same and parse the timestamps correctly.

However this only happens when I add validateSearch in route definition

export const Route = createFileRoute("/")({
  component: App,
  // THE BUG ONLY HAPPENS WHEN USING validateSearch IF I REMOVE `validateSearch` IT WORKS AS EXPECTED
  validateSearch: createStandardSchemaV1(searchParams, {
    partialOutput: true,
  }),
});

Reproduction

Deployed Version: https://nuqs-repro.pages.dev/
GitHub Repo: https://github.com/mdhruvil/nuqs-repro

• Visit "/"
• Current Week is selected by default, see URL and values displayed on page
• Click on "Set to Previous Week"
• It changes url to select previous week (works as expected)
• Refresh the page or copy url and open in new tab
• It changes url to ?from="1970-01-01T00%3A00%3A02.025Z"&to="1970-01-01T00%3A00%3A02.025Z" instead of parsing the actual timestamp values

[franky47]

Yes, this is listed in the caveats section of the TanStack Router adapter docs:

https://nuqs.dev/docs/adapters#type-safe-routing-via-validatesearch

Due to differences in how TanStack Router and nuqs handle serialisation and deserialisation (global in TanStack Router and per-key in nuqs), only trivial state types are supported for type-safe linking. Those include all string-based parsers (string, enum, literals), number-based (integer, float, number literal), boolean, and JSON.

The urlKeys feature to provide shorthand key names is also not supported for similar reasons.

[mdhruvil]

Oh My bad! So Sorry, I didn't notice that. Should I close the issue then ?

[franky47]

Well at some point I'd like to be able to fully support nuqs in TSR/TSS's type-safe linking, we had leads with @TkDodo for tweaking how the StandardSchema validator works in order to revert TSR's automatic deserialisation and pass it through nuqs.

I don't have a ton of time this week with Next.js conf to organise, but I can have a look from next week.

See also PR #1128.