`temporal-polyfill` `Temporal.Instant.from` flagged with "used `new Date()` before accessing either uncached data"

[rikbrown]

Link to the code that reproduces this issue

https://github.com/rikbrown/nextjs-temporal-polyfill-cache-components-issue

To Reproduce

1. Start the provided application in next dev
2. Visit http://localhost:3000/from-iso
3. Observe cache components error

Current vs. Expected behavior

Basically, Temporal.Instant.from(<iso>) polyfilled via temporal-polyfill is throwing the uncached data error. This isn't expected: this is used to create an instant from a fixed point of time which should be safe in cached environments.

This does not reproduce:

1. creating via new Date(<iso>).toTemporalInstant() -- this is the workaround for now in production
2. creating via Temporal.Instant.from(<epoch ms>)

I think Temporal.Instant.from(<iso>) is internally creating a new Date() somewhere, which is causing it to be flagged by Next.js. I suspect it is doing it to assign fields to the date, not to actually use anything about the current date, but haven't been able to go deep in their code yet (will update ticket soon). See comment below for the culprit code.

With Temporal starting to be released in browsers, it's likely many more people will reach for a polyfill so they can use it, and this is the most popular (or one of two most popuar) polyfills. Is there a way to allowlist this path so it is not considered uncached data access?

---

Current:

Error: Route "/from-iso" used `new Date()` before accessing either uncached data (e.g. `fetch()`) or Request data (e.g. `cookies()`, `headers()`, `connection()`, and `searchParams`). Accessing the current time in a Server Component requires reading one of these data sources first. Alternatively, consider moving this expression into a Client Component or Cache Component. See more info here: https://nextjs.org/docs/messages/next-prerender-current-time
    at Home (page.tsx:4:35)
    at Home (<anonymous>:1:13)

Expected:
no error

Provide environment information

pnpm next info

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 25.3.0: Sun Jan  4 19:18:29 PST 2026; root:xnu-12377.80.267~81/RELEASE_ARM64_T6041
  Available memory (MB): 131072
  Available CPU cores: 16
Binaries:
  Node: 22.18.0
  npm: 10.9.3
  Yarn: 1.22.22
  pnpm: 10.18.3
Relevant Packages:
  next: 16.1.1-canary.32 // Latest available version is detected (16.1.1-canary.32).
  eslint-config-next: N/A
  react: 19.2.3
  react-dom: 19.2.3
  typescript: 5.9.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

cacheComponents

Which stage(s) are affected? (Select all that apply)

next dev (local), next build (local), next start (local)

Additional context

Attached github has the repro and the two non-repros discussed above.

I will go deep in temporal-polyfill and see if it's patchable there (or just understand why it's occurring too).

[rikbrown]

Ok I traced the culprit to this call used within Temporal.Instant.from:
https://github.com/fullcalendar/temporal-polyfill/blob/bc1baf3875392ecd8522d40e7eecb55fa582808c/packages/temporal-polyfill/src/internal/timeMath.ts#L331

As I expected, it's creating a new Date() just to set the fields to a fixed setting, which shouldn't be a violation? (But I can see why it'd be hard to know).

I can patch this to new Date(0) and will raise a PR with that with the other repo - but might be worth allowlisting if that's something you do?

(by the way, tracing this was incredibly annoying - I had to manually patch this package in node_modules to emit console.trace() to help me see the stack trace. If Next.js knows a "new Date()" is occurring somewhere why not show the full trace inside the module so I can find it myself?)

[rikbrown]

I created fullcalendar/temporal-polyfill#82, but the repo does not seem to be well-maintained currently so not sure if there will be traction. I will patch this locally in the meantime.

[rikbrown]

For anyone reading this + experiencing this issue, I've made a fork @rikdotcodes/temporal-polyfill which applies the above patch. Hopefully the maintainer picks this up and I can close the fork.

[apostolos]

The exact same issue exists in the date-fns/tz package. Because the internal Date is not initialized with a static value, the same error occurs in Next.js.

The PR also hasn’t been picked up yet: date-fns/tz#69

I suspect that similar issues exist in many other packages as well, and they’ll likely catch a lot of people off guard until awareness improves.