Consider timezone of users

[aerni]

As briefly mentioned in #551 (comment), it would be awesome if date fields throughout the CP were to consider the current user's timezone.

[RafaelKr]

This would be pretty cool to have. Best practice is:

• Always use UTC times for everything internally. Especially when storing dates (in yaml files/database/etc).
• Convert the times for presentation to the current users timezone.
• Convert times given by the user from their timezone to UTC.

Currently we can only control what happens with the dates on the frontend, but not in the CP.

As we don't have a way to get the users browser timezone from the request the only way is to use JavaScript to determine the timezone.
So I think it would be nice to have a global preference which default CP view timezone should be used and make it overwritable per user. When the user signs-in a check with JavaScript could be added to compare the users timezone to the global preference. If it differs a popup could ask the user to change their user preference to their browser timezone.

More context on why UTC should be used everywhere:

• https://kylekatarnls.medium.com/always-use-utc-dates-and-times-8a8200ca3164
• https://stackoverflow.com/a/58619021/4303873

Related

The Symfony Framework handles this in a nice way for their Form Builder component. Their date fields have the configuration options model_timezone and view_timezone both defaulting to the system default timezone. When loading or saving dates with those fields the timezone is always converted between those two values.

The EasyAdminBundle available for Symfony, which is somehow comparable to the Statamic CP, provides a global way to configure which timezone format should be used across their Dashboard. All dates are presented in the timezone configured globally. Dashboard Date inputs (internally using Symfony Form Fields) also use that global configuration and it could be overwritten on field level.

[jasonvarga]

The difficult part is figuring out how to get people to migrate dates properly when upgrading.

Also, since we put human readable dates in entry filenames (like 2024-03-28.post.md) it would be awkward for users to see those dates in UTC.

I agree that we should be storing UTC everywhere and doing exactly what you described.

[duncanmcclean]

We've made a bunch of timezone-related improvements in statamic/cms#11409, which'll be released as part of Statamic 6.

You can find more information about exactly what's changing in the PR description.