UTC dates in v6

[andjsch]

Statamic 6 is storing dates in UTC time. Which is fine, but once you aren't in UTC, things get really complicated. Let me explain.

What the docs say

The upgrade guide suggests to leave your application timezone in UTC - then nothing should change…

As for the docs, so far so good. If I have a date field e.g. 2026-02-10, it should store still store as 2026-02-10, with the timezone set to UTC. That's what I would expect.

What really happens

For me living in UTC+1, the above absolutely didn't happen. If you have a date field in the CP, you will set it as your local timezone! That means, although everything is set to UTC, a normal date field (without time) will convert to 2026-02-09-2300. This leads to some fun stuff like this:

That's absolutely confusing and hard to work with.

The solution to this - not really mentioned in the docs (upgrade guide):

You should set your timezone either in app.php or statamic/system.php (display_timezone, which will fall back to your timezone set in app.php). This will still convert everything to UTC in the background, but it will convert it back to what has been set in your config.

For 99 % of sites, it's necessary to set a timezone and not leave it as UTC.

The solution I'd like to discuss/have

I think it's quite obvious that the current date behavior isn't really user-friendly and also quite a pain for developers, as we now explicitly have to check our timezone settings for the app. And while storing everything in UTC might be useful to some, it's rather cumbersome for the rest.

A probable and easy solution that could fit all use cases would be to give CP users a timezone preference. If not set, any date-input should be assumed to be the app timezone. Currently, it's always the users local timezone that is provided through the browser, which is the actual problem. This solution should make the statement of the docs completely true and the breaking change way less troublesome.

The questions I have are

• How do teams/editors that are located in different timezones handle this? If you set a certain publish date in the future, do you account for the timezone difference? I doubt it.
• What if an editor is traveling and is in a different timezone? The set date would never match what he'd actually assume to have typed in, unless accounted by themself (same as above)…

What's the feedback from others that have upgraded to v6 and do have dates somewhere?

[jasonvarga]

When you use a date field in the CP, the date you pick is the date in your operating system's timezone.

That was the whole reason anything changed. If you have editors spread across the world, they would previously need to know which timezone the application is configured in. Now, when you pick a date, its your date.

For me living in UTC+1, the above absolutely didn't happen. If you have a date field in the CP, you will set it as your local timezone! That means, although everything is set to UTC, a normal date field (without time) will convert to 2026-02-09-2300.

That sounds accurate. If your app is configured as UTC, and you are in UTC+1, when you select a date, its your midnight which is 11pm the previous day in UTC.

Then when you do {{ date_field }} in your template, it will display it in whatever timezone you have configured for statamic.system.display_timezone, falling back to app.timezone. So in your UTC+1 example, the date would appear as 11pm the previous day there too.

How do teams/editors that are located in different timezones handle this?

If your team is spread through timezones and you expect to-the-minute entry dates, then your date fields should include times

What if an editor is traveling and is in a different timezone?

Their computer timezone would change, and then the dates they pick would be from the new current timezone.

[andjsch]

Yeah, it does make sense, especially when the time is enabled. Yet, it's a bit confusing with dates only. I guess I'll have to wrap my head around these changes a bit more.

The upgrade guide could still benefit from a little notice that a timezone should be set. I think that started my confusion in the first place. Should I create a PR for that?

[jasonvarga]

Sure!

[helloDanuk]

I'm still a little confused about this too. As I understand it, with these settings it works as follows:

‘timezone’ => ‘UTC’,
‘display_timezone’ => ‘Europe/Zurich’,

Goal: Create an event in Zurich on the 11th at 21:00

Implementation with date field only:

• Saves as 10th 23:00
• In a separate time field, I choose 21:00 (wall clock time). This is just plain text and never does time shifting.

Implementation with date field and time enabled:

• Saves as 11th 20:00

As long as I work in Zurich timezone, I see the correct time in the CP and in my template I can use the tz-modifier to display 21:00.

But if I travel to Los Angeles and would like to create the same event in Zurich on the 11th at 21:00, things are a bit different?

Implementation with date field only:

• Saves as 11th 08:00
• In a separate time field, I choose 21:00 (wall clock time). Because this is just plain text, it behaves the same, no matter in which timezone I am working.

Implementation with date field and time enabled:

• To receive the right time for the event in Zurich I need to choose 11th 12:00, which saves as 11th 20:00
• In CP collection listings I also see 11th 12:00

Is this conclusion correct?

In CP, when I travel to a different timezone, I have to calculate the time in my head. I need to know what time it is in Los Angeles (12:00) when it is 21:00 in Zurich. Back in Zurich, this displays as 21:00 in CP again.

…or I don't change my timezone on my computer when working abroad.

Second question, and this is what really gives me a headache:
With a date field only (without time), the date switches one day for the same event in CP listings, but only for the event created in Zurich.

Screenshot 1 has Zurich time:

Screenshot 2 has Los Angeles time:

Is it because it's saved as 10th 23:00, which is in Zurich +1 => 11th 00:00, but in Los Angeles -8 => 10th 15:00?
It is not obvious that this date invisibly includes midnight I guess. This makes it very difficult to know which date is actually meant.

This only happens in listings. If I open the entries I see the 11th in the date field for both timezones and entries. That seems correct to me, but at the same time it is confusing when a different date is displayed in the list and another in the entry.

What best practice do you recommend?

• When I only need the date? => Confusion about midnight in CP, when changing working timezone
• When I need date and time? => Save the time in the date field or use a wall clock seperate time field?

Thank you very much for your hard work, and please excuse my limited knowledge on this subject.