fix(nextjs): initialize new Date() with (0) to avoid breaking Next.js 16 Cache Components pre-render

[rikbrown]

Next.js Cache Components does not allow access to any "dynamic" data during pre-rendering, because this is intended to build a static shell that could be cached by a remote server. It throws an error to prevent mistakes - i.e. make the user make a conscious decision what they want to do with dynamic data (in your Next app, you would mark it as cached for some period of time, in which case it will be cached in the pre-render).

new Date() is one of those functions you need to mark as explicitly cached and tell Next.js how long to cache it for (because it's the current time, not a fixed date). new Date('<some fixed>') would not be flagged as it is not dynamic.

Unfortunately, Temporal.Instant.from(<some fixed ISO string>) is flagged as dynamic, because it is using new Date()... but then immediately setting it to a fixed value in isoToLegacyDate. This forces users to wrap it with caching, which is tedious and unnecessary when it is actually a fixed date:

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)

This fix inits it with new Date(0) instead, which stops Next.js complaining about this.

note: also raised this to Next.js: vercel/next.js#88696 because it's a bit unergonomic that this pattern is flagged, although I can see why it'd be hard to detect.

[fabon-f]

A change in timeMath.ts seems fine, but I think one in timeZoneConfig.ts breaks original intention. This pull request may introduce a new bug related to the time zone (though I don't verify it yet).

[rikbrown]

You're right, I was too broad in applying it here as it obviously is intended to get the current year. I am not completely sure the intention of this specific code, is it possible to do it in a way that does not require the current date? I traced it up (naively, didn't look in detail) and it looks like it's used in Instant.toString - it would be quite a bummer if we couldn't format a fixed Instant without needing to access the current date.