Date field timezone support: no way to reasonably set event times

[ssyberg]

Link to reproduction

No response

Describe the Bug

Scenario:

• You're in Hawaii (UTC -10)
• You are entering an event in your CMS that takes place in Moscow (UTC +3)
• The event takes place on 4/4/24 at 8am

I suggest there's effectively no reasonable way to represent this in payload. To display this on the frontend I believe you must set a timezone on this event (perhaps there's an argument that this could be business logic gleaned from an event location or that the frontend should always display the event time in the browsers local timezone but I'd say those are both pretty unreaonsable).

The admin experience here requires some extremely counter intuitive behavior to get this correct. As an admin I must understand that whatever date I enter here will be stored in UTC, despite what timezone I select in the timezone dropdown. In order to get this to show up correctly the admin has to convert their "browser" time to UTC and enter an incorrect event time, in this case they'd have to enter the event time as April 3rd at 10pm, but set the timezone drop down to display MSK. This gets even more confusing with multiple admins using this across timezones, as they will have different views of the record.

This of course is ignoring that the browser timezone could be inaccurate for any variety of reasons.

To Reproduce

n/a

Payload Version

n/a

Adapters and Plugins

No response

[paulpopus]

Moved this over to a discussion as it's a feature request! We can gather feed for this here

[ssyberg]

Ok I'm sorry to be a pain in your side, but I find it difficult to let this go since this behavior is clearly incorrect, no one would say this is "how a date field works"

• I set a date to April 3rd, 10pm
• It displays as April 4th, 8am

That is a bug.

[paulpopus]

I want to confirm the behaviour and your expectation here to make sure that there's no miscommunication between us, because if this is a bug then it obviously needs to be fixed.

You're setting the time as April 3rd, 10pm in the admin panel.
Then the API returns April 4th, 8am? Which is the UTC timestamp for the above when adjusted for your config. Is that right?

And this issue stems from having editors in different timezones who see different times when editing content?

If it's not what I described above then a reproduction would be helpful here to pinpoint the problem.
Not to sound condescending at all, we had a chat about this internally and I wanna clarify this thread.

[ssyberg]

Thanks for hearing me out!

I think if timezones are not supported, then they should not be affecting anything, I would simply remove the offset conversion in your onChange method and make it clear its all UTC (or like most other CMS' allow a config based setting for timezone). I don't actually think this is a result of multiple timezones for editors, I would suggest this is an actual bug for anyone editing that is not in UTC+0 because ultimately the the date/time that is entered is not the date/time that is stored.

[paulpopus]

I understand the need for timezone management in our date fields, at least to provide devs a bit more flexibility in how it's handled.

Until we can prioritise this for core I've added a date field with timezone support here if it can help you in the interim? Feel free to provide feedback in that repo if you need something extra for it

[ssyberg]

Whoa cool, I didn't even know about that repo!

[iamlinkus]

Oh man, this date field timezone issue has been driving me nuts for the past two weeks. Having the admins of a website scattered throughout the world, it's impossible to handle this issue easily. The dates are set for events that are also international and are in different timezones, so this issue is on a whole another level (figure out the editor timezone, adjust while saving to negate the timezone difference and then also get a hook that adjusts the time when another editor is viewing the field in another timezone.

This is 100% a bug, because outside of the people who actually live in UTC+0, this field becomes completely unpredictable.

And a simple solution to this would simply be setting the default timezone that the date is saved in the db with. That's it.