Inconsistent timezones with date/time formatter?

[sohrab-]

I am not sure if this expected but I am seeing inconsistent behaviour across date/time formatters when it comes to timezones

For example, in a client component (not pre-rendered, etc.), I have this piece of code:

  console.log(`
${timestamps.createdAt}
${useFormatter().dateTime(timestamps.createdAt, { dateStyle: "short", timeStyle: "short" })}
${useFormatter().dateTime(timestamps.createdAt.getTime(), { dateStyle: "short", timeStyle: "short" })}
${new Intl.DateTimeFormat(undefined, { dateStyle: "short", timeStyle: "short" }).format(timestamps.createdAt)}
${new Intl.DateTimeFormat(undefined, { dateStyle: "short", timeStyle: "short" }).format(timestamps.createdAt.getTime())}
`);

When using Next.js dev server, they all check out fine:

Thu Mar 20 2025 16:29:23 GMT+1100 (Australian Eastern Daylight Time)
3/20/25, 4:29 PM
3/20/25, 4:29 PM
20/03/2025, 16:29
20/03/2025, 16:29

(ignore the slight differences, i didn't bother to pass in the locale to Intl.DateTimeFormat)

But when I deploy this to Vercel, the useFormatter() seems to return timestamps in UTC. Please note the the Date object is still carrying the timezone information and Intl.DateTimeFormat is behaving correctly.

Thu Mar 20 2025 16:29:23 GMT+1100 (Australian Eastern Daylight Time)
3/20/25, 5:29 AM
3/20/25, 5:29 AM
20/03/2025, 16:29
20/03/2025, 16:29

Versions:

"next": "14.2.3",
"next-intl": "^4.0.2",

[amannn]

Please note the the Date object is still carrying the timezone information

That might be the case, but have you checked which time zone the server uses? I.e. you're formatting a date (which might be referencing a particular time zone), but you're formatting it into the time zone of the target environment. The fact that a date string might include a time zone does not affect the formatting in any way—it's just a representation of how a particular moment in time is stored.

By default, the time zone of the server is used—you might want to pick an explicit time zone if the result does not match your expectation.

[sohrab-]

Is the server timezone relevant here? I am sending Zulu dates to frontend and it is getting formatted in user's browser.

If that was the case, shouldn't it affect Intl.DateTimeFormat as well, not just useFormatter().dateTime()? I may be missing something here.

[amannn]

The tricky part about JavaScript dates is that they don't contain a time zone. If you construct a date based on e.g. an ISO date string, it will only use this for initialization, but doesn't store the time zone in any way.

From the MDN docs on Date:

This timestamp is timezone-agnostic and uniquely defines an instant in history.

The difference between using Intl.DateTimeFormat directly and using format.dateTime(), is that the former always defaults to using the time zone of the current environment. If you have some Server- and some Client Components this would result in dates rendering differently depending on the environment, and maybe also hydration errors.

There's a lengthy blog post on this subject on the next-intl blog if you're interested in the details—but, the tldr; is: next-intl consistently uses the server time zone across your whole app, providing a guarantee for the rendered output.

So what I'd recommend is providing an explicit timeZone in your i18n/request.ts to make sure all rendered dates are formatted with taking this into account.