Inaccurate association of fixed UTC offsets with dynamic IANA timezones

[ryami333]

Describe the Bug

Currently, the defaultTimezones entries are formatted like:

{ label: '(UTC+01:00) Berlin, Paris', value: 'Europe/Berlin' }

This representation is misleading because it implies that Europe/Berlin has a constant offset of UTC+01:00, when in fact the actual offset changes throughout the year due to daylight saving time. For example:

• In winter (CET), Europe/Berlin is UTC+01:00.
• In summer (CEST), Europe/Berlin is UTC+02:00.

By displaying (UTC+01:00) alongside Europe/Berlin, users may be led to believe that Berlin is always UTC+01:00, which is incorrect. This can cause confusion or even bugs when dealing with time calculations, scheduling, or cross-timezone coordination.

A more accurate approach might be:

• Omit the fixed UTC offset entirely, and simply list the timezone name as both its value and label, (e.g., { label: "Europe/Berlin", value: "Europe/Berlin" }).
• Or, dynamically calculate the current offset at runtime using the system clock or user-selected date (using e.g. Intl.DateTimeFormat), so that the displayed offset reflects the actual current offset for that timezone.

I think that the first option is safer and more correct, because the timezones are rendered alongside date fields where the date value can't be predicted to be within daylight-saving-time (or not).

Maintaining a hardcoded fixed offset with a dynamic timezone creates a false equivalence and can be a source of subtle time-related errors.

Link to the code that reproduces this issue

payload/packages/payload/src/fields/baseFields/timezone/defaultTimezones.ts

Line 35 in aef4f77

{ label: '(UTC+01:00) Berlin, Paris', value: 'Europe/Berlin' },

Reproduction Steps

No reproduction needed, the issue is conceptual, not logical. Simply note that there are incorrect offsets for European timezones at the moment, for example Europe/Berlin currently has an offset of UTC+2 due to daylight savings time, and that the static labels do not (and cannot) reflect this correctly for all timezones at all time.

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

area: ui

Environment Info

Irrelevant.

[paulpopus]

I think we might be able to make this dynamic - let me check in on a pattern for this

[ryami333]

I think it would be inadvisable to make these dynamic, because they're used in the context of datepickers (and datetimepickers), where the value is not known before those timezones (and their respective labels) are computed and rendered. The user might pick a date that's during DST, or not, and the label in that dropdown can only reflect one or the other, but not both.

The more that I think about this, the clearer it is to me that these two concepts (timezones, and timezone offsets) should simply not be conflated without risking bugs, confusion or both. If the dropdown simply lists timezones like Europe/Berlin etc, then there is no ambiguity, and I'm not sure why it would be beneficial to print the offset there.

[paulpopus]

I'm not sure why it would be beneficial to print the offset there

I've added more detail in the linked PR but based on NN Group's research we should keep the offset in the label, though I've made a PR to change the labels and in the future we could further improve the UX here.

[paulpopus]

Converted this into a discussion since it's not an immediate bug to fix. I've added this to my todo and will bring it up as part of the enhancements to implement in the 4.0 UI upgrade