Date Field in Pacific Island timezones show incorrect date

[AndKenneth]

Describe the Bug

Hey team, I'm in Auckland NZ and I've run into this bug that is making the Date field very difficult to work with. I'm assuming this might also impact users who might be visiting NZ or other pacific island nations and use the dashboard.

Selecting the date while the users browser is in one of a handful of pacific timezones past UTC+12 or above will cause the following calendar day to be displayed across a few places in the admin UI.

Issue seems to come from the way payload handles date only fields in DatePicker.tsx.

const onChange: Extract<
    DatePickerProps,
    { selectsMultiple?: never; selectsRange?: never }
  >['onChange'] = (incomingDate) => {
    const newDate = incomingDate
    if (newDate instanceof Date && ['dayOnly', 'default', 'monthOnly'].includes(pickerAppearance)) {
      const tzOffset = incomingDate.getTimezoneOffset() / 60
      newDate.setHours(12 - tzOffset, 0)
    }
    if (typeof onChangeFromProps === 'function') {
      onChangeFromProps(newDate)
    }
  }

The goal of this code seems to be to set the time object to be midday UTC. While it does do this, when the timezone has an offset of at least +12 (basically everything from New Zealand eastward till the international date line), this will create a corresponding UTC time that will render as 1am or later on the following day when viewed in the dashboard from one of these countries.

Unfortunately there doesn't seem to be a way to pick a standard UTC time that works for both American Samoa and New Zealand at the same time. Changing the offset probably wouldn't be acceptable because there would be existing codebases that expect the specific time of UTC 1200.

Also unfortunately, the onChange override (seen in the code sample above as onChangeFromProps) no longer can be set in the payload config because you cannot pass a function to a client component from a server component.

Potentially there's a way to make sure the date is handled entirely in UTC and does not get localised to browser timezones when displayed on the dashboard. This is similar to what I'm doing in my frontend for this type of field (I just chop the time component of the UTC string). I think the full fix for this would have to come with a proper overhaul of the date/time system that can handle timezones natively.

Link to the code that reproduces this issue

https://github.com/AndKenneth/date-reproduction

Reproduction Steps

1. clone reproduction, install dependancies, run app
2. navigate to /admin and create account (will create a local sqlite db)
3. go to "events" collection
4. Go to chrome devtools, open sensors panel (menu dots next to close button -> more tools -> sensors
5. Change Timezone ID to Pacific/Auckland

6. Select any date, rendered date will be the following day.

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

area: core

Environment Info

Binaries:
  Node: 22.9.0
  npm: 10.9.0
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  payload: 3.8.0
  next: 15.1.0
  @payloadcms/db-postgres: 3.8.0
  @payloadcms/email-resend: 3.8.0
  @payloadcms/graphql: 3.8.0
  @payloadcms/live-preview: 3.8.0
  @payloadcms/live-preview-react: 3.8.0
  @payloadcms/next/utilities: 3.8.0
  @payloadcms/plugin-cloud-storage: 3.8.0
  @payloadcms/richtext-lexical: 3.8.0
  @payloadcms/storage-vercel-blob: 3.8.0
  @payloadcms/translations: 3.8.0
  @payloadcms/ui/shared: 3.8.0
  react: 19.0.0
  react-dom: 19.0.0
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.1.0: Thu Oct 10 21:05:14 PDT 2024; root:xnu-11215.41.3~2/RELEASE_ARM64_T8103
  Available memory (MB): 16384
  Available CPU cores: 8

[DanRibbens]

We will need to test if the new time zone flag fixes this issue or if something more is needed.
#10896