fix(ui): improve the labels for default timeones

[paulpopus]

Addresses #12700

Based on feedback, the current visual labels for the timezones we provide are not necessarily intuitive for people to use. Based on this article from NN Group, I've changed the labels so they follow a more recommended format to Cities - Region (Offset) instead of (Offset) - Cities so people can search and filter by region as well such as Europe when trying to narrow down their locations.

We're going to keep offsets based on the paper there but in the future we could enhance the picker here by:

• Making the offset dynamic based on current DST
• Have an indicator whether or not DST is active
• Show a preview time/date for any timezone
• Group timezones by Region
• Detect the user's timezone and highlight it

[ryami333]

This doesn't address my concern—it’s an aesthetic change that some might prefer, but it’s subjective.

I also think it’s a stretch to apply that research to this context. The study focuses on helping users identify their current timezone, prioritizing ease of use, not suitability for contexts like ours. For example, Slack’s timezone selector only affects how UTM dates are localized to the user’s preference. Payload’s case is the opposite: the UI must de-localize user-selected dates to UTM.

In fact, the article highlights a key distinction between timezones and timezone offsets—a distinction we should be careful not to blur.

---

Here’s an example of the problem:

(Note that Berlin's offset on June 1st is GMT+02:00, because DST applies during the summer)

If the user selects 2PM as above, what ISO string should be stored? Should it be …T13:00:00Z or …T12:00:00Z?

• If we store …T12:00:00Z, that accurately reflects 2PM in Berlin—but contradicts the GMT+01:00 label.
• If we store …T13:00:00Z, it aligns with the label but would display as 3PM when localized, which isn't what the user picked.

---

To summarise, I think it's very misguided to associate these timezone offsets with datetime-pickers, specifically. By all means, use them in other contexts that more closely resemble the conditions of that NN Group study, but not here.

[ThijsAtFreave]

If the user selects 2PM as above, what ISO string should be stored? Should it be …T13:00:00Z or …T12:00:00Z?
If we store …T12:00:00Z, that accurately reflects 2PM in Berlin—but contradicts the GMT+01:00 label.

Please tell me T12:00:00Z is stored. It'll be easy enough to tell people to basically ignore the "+01:00" label, it'll be impossible to get them to do their own timezone calculations to get the intended effect.

Besides that: completely agree with @ryami333 above: the offset should not be displayed here, as it'll be wrong a significant portion of the time.
If the offset should be presented, perhaps on hover of the timezone but dynamic based on the picked value?

[ryami333]

⚠️ Europe/London and Europe/Lisbon are not equivalent! This seems a bit ChatGPT hallucination-ish.

[ryami333]

Midway Island is not in Samoa, though it does use "Samoa Standard Time" which is not actually used in Apia, Samoa, ironically. I hope that this is illustrating just how important it is to just label a datetime-picker with just the IANA labels: Pacific/Midway and Pacific/Apia respectively.

[ryami333]

@paulpopus I'd quite like to revive this topic – I think I've illustrated the problems with this approach (and the incumbent approach) and I really do think that there's no sense in over-engineering this. I think this PR should either be closed or adapted to something closer to the following, which I've been adding to all of my Payload apps as a temporary workaround:

// payload.config.ts

export default buildConfig({
  // …
  admin: {
    // …
    timezones: {
      /**
       * ✝ Workaround for Payload issue, where dynamic timezones like
       * "Europe/Berlin" are labelled as if they have fixed offsets like UTC+01,
       * when in fact they depend on factors such as daylight-savings-time.
       *
       * https://github.com/payloadcms/payload/issues/12700
       */
      supportedTimezones: ({ defaultTimezones }) => {
        return defaultTimezones
          .map((item) => ({
            label: item.value, // overriding this label
            value: item.value,
          }))
          .sort((a, b) => a.label.localeCompare(b.label));
      },
    },
  },
  // …
});

export default payloadConfig;