Timzone issues between server/client

[dBianchii]

Hi, I am having some trouble understanding the timezone configuration needed for server/client components. I see that there is a timezone configuration to be set on both provider and also request config.
https://next-intl-docs.vercel.app/docs/usage/configuration#time-zone

At first, I didn't set any timezone configuration and let the package handle the defaults. I then noticed problems in my testing. Locally, everything was working fine. But when I deployed to production (server is in a different timezone apparently), I started to have problems.

Take a look at this screenshot from my app:

The text (17 de setembro de 2024 às 23:00) is the text that was being generated from format.dateTime(). However, the date text is actually supposed to be 20:00 (the input on the bottom is the correct date). I think that my server is on UTC, while my computer is on UTC-3.

So, I am confused as to how to properly setup the timezones on server/client. I think that it is not adapting to each user's client timezones correctly

[amannn]

These are the important parts from the docs section you've linked to:

1. By default, the time zone of the server runtime will be used, but can be customized as necessary.

2. The time zone in Client Components is automatically inherited from the server side if you wrap the relevant components in a NextIntlClientProvider that is rendered by a Server Component.

How do you generate the 20 & 00 label in the UI? Are you using useFormatter for this? If not, this could explain the reason why your time zone from the server is not picked up.

Also note that dates and times don't automatically update for the client time zone. This is especially important since RSC's don't hydrate at all, otherwise this would cause an inconsistency.

If you'd like to have a request-specific time zone, you can read e.g. from headers() in i18n/request.ts in order to customize this setting per user.

Does this help?

[ScreamZ]

@amannn Thanks! I just encountered the same issue ahah.

In my case, I'm rendering a time-using

"use client";

  const t = useTranslations();
  const format = useFormatter();

 {session?.user.subscription?.cancelAt && (
        <AppCallout
          type="info"
          message={t.rich("Payment.willCancelAt", {
            date: session.user.subscription.cancelAt * 1000,
            count: session.user.subscriptionCredits,
            strong: (chunks) => <strong className="text-success">{chunks}</strong>,
          })}
        />
      )}

Everything is wrapped by NextIntlClientProvider "classic". I wasn't aware that things get inherited from server.

I'm developing locally in Europe/Paris (as I'm French), Vercel and other are in UTC.

I would like to display time based on User System setting.

When instantiating a new Date() system timezone is used in the browser. Which is my expected behavior.

I'm OK with having the server deal with UTC for internal purpose like CRONs. If I want to display user system TZ from client side, I just need to pass it as an argument to NextIntlClientProvider with something like const tz = Intl.DateTimeFormat().resolvedOptions().timeZone; ?

Otherwise I understand that I'm supposed to pass the timezone to the getRequestConfig but as it's server side...
Is there something better than using a header with the TZ on every request otherwise?

I would like to avoid storing the TZ for each user on registration and add it to the user profile (which is a common pattern)

Using this on a server component

 <NextIntlClientProvider
 timeZone={
            typeof window !== "undefined" ? timeZone : Intl.DateTimeFormat().resolvedOptions().timeZone
          }
>

Note

I tested this

"use client";
import { NextIntlClientProvider } from "next-intl";
import React from "react";

type NextIntlImprovedClientProviderProps = React.ComponentProps<typeof NextIntlClientProvider>;

export const NextIntlImprovedClientProvider: React.FC<NextIntlImprovedClientProviderProps> = ({
  children,
  ...rest
}) => {
  console.log(
    window === undefined,
    window === undefined ? rest.timeZone : Intl.DateTimeFormat().resolvedOptions().timeZone,
  );
  return (
    <NextIntlClientProvider
      {...rest}
      timeZone={
        typeof window !== "undefined" ? rest.timeZone : Intl.DateTimeFormat().resolvedOptions().timeZone
      }
    >
      {children}
    </NextIntlClientProvider>
  );
};

But this doesn't solve very well neither.

[amannn]

When instantiating a new Date() system timezone is used in the browser.

The peculiar thing about JavaScript dates is that they do not store a time zone (see e.g. What exactly is Date, and what it isn’t?). Only when formatting a date, a time zone is applied (which is by default the locale one of your server/browser—or in case of next-intl, the one that's distributed via i18n/request.ts and NextIntlClientProvider).

I want to display user system TZ from client side

This might get a bit hairy as you only have this information available in the browser.

If you consider your app server-first (or even -only, in case of RSC), then it's natural that you need some way of determining the time zone on the server side. If using the same time zone for every user is not an option, I'd really consider letting the user pick one (you could default to one that is computed based on the IP).

Calling Intl.DateTimeFormat().resolvedOptions().timeZone on the client side would yield the client time zone, but it's only available on the client side. If your Client Components also run on the server side, then you'll run into hydration errors. Additionally, in case you format any dates in Server Components, the displayed times will be inconsistent. Due to this, I'd really advise against this approach.

Hope this helps!

[ScreamZ]

Thank you very much for those kind explanations.

I might be using Client components for my use case using next/dynamic This way the context way I described above might be accurate.

Or I can set one on the register by default based on the IP. using SAAS.

If your Client Components also run on the server side, then you'll run into hydration errors.

Yes

I'll probably go full client side. And think about saving the user timezone somewhere. Looks like the most accurate way.

[dBianchii]

Thank you so much for the quick response, and also for the link to this great blog post. This is exactly the type of thing I've been trying to find on the internet, regarding JS Dates.

So to summarize:

• The default config (when you follow the getting started guide, without setting TZ anywhere) will always use the timezone of the server by default. Even if you use format.dateTime() from a client component, that time will be rendered in the TZ defined by the server. (This will not have any hydration issues)
• If you use different timezone settings between server/client, you will have hydration issues. (I believe this is the same case as doing new Date().toString() in a SSR'd ClientComponent)
• amannn recommends setting it via IP/user config.
  • Via IP: This is not ideal because IP addresses have no timezone data built into it. We would need to contact an external API/provider which is not good.
  • Via user config: sure, but then the user would need to set it manually, which is also not ideal in my opinion.

So, I'm still thinking of a way to do it. I'm thinking of just not using SSR in situations where I am calling the formatter. I'm not sure if that makes sense...

[amannn]

Yep, that sounds right to me! 👍 I mean, a lot of apps probably just use the server time zone, there's however a bit of work necessary when you want to make this customizable.

Regarding API provider: If you by chance use Vercel, they provide the x-vercel-ip-timezone header which could be used for this purpose. Still I'd be careful with this, and only use it as a default (as it could be wrong), and let your users decide by themselves.

[ScreamZ]

The link you sent on date is damn good, I really like Solberg content!

In the meantime, I ended up with this.

import dynamic from "next/dynamic";
import React from "react";
import { motion } from "framer-motion";

const NoSSRWrapper = (props: { children: React.ReactNode }) => (
  <motion.div
    initial={{ opacity: 0 }}
    animate={{ opacity: 1, transition: { ease: "easeIn", duration: 0.2 } }}
  >
    {props.children}
  </motion.div>
);

export default dynamic(() => Promise.resolve(NoSSRWrapper), {
  ssr: false,
});

<NoSSR>
  {session?.user.subscription?.cancelAt && (
    <AppCallout
      type="info"
      message={t.rich("Payment.willCancelAt", {
        date: session.user.subscription.cancelAt * 1000,
        count: session.user.subscriptionCredits,
        strong: (chunks) => <strong className="text-success">{chunks}</strong>,
      })}
    />
  )}
</NoSSR>

Wrapped with a custom

"use client";
import { NextIntlClientProvider } from "next-intl";
import React from "react";

type NextIntlImprovedClientProviderProps = React.ComponentProps<typeof NextIntlClientProvider>;

/**
 * Allow to use Browser Date formatting along with NoSSR components.
 */
export const NextIntlImprovedClientProvider: React.FC<NextIntlImprovedClientProviderProps> = ({
  children,
  ...rest
}) => {
  return (
    <NextIntlClientProvider
      {...rest}
      timeZone={
        typeof window === "undefined" ? rest.timeZone : Intl.DateTimeFormat().resolvedOptions().timeZone
      }
    >
      {children}
    </NextIntlClientProvider>
  );
};

This works. But requires a full client component as we said earlier.

Really happy to share and exchange about tech with you @amannn.
I wish I could spend more time writing issues, questions and pull request on next-intl. I have a looooot of things to ask (as you probably already seen in other threads ahah)

Have a nice night guys!