Inconsistent content schedule challenge for Umbraco Cloud. Why is it an hour off?

[karlmacklin]

To handle time-sensitive publishing scheduling, I am interacting with Umbraco looking at the content schedule.

I get the schedule for an item as such:

var schedule = _contentService.GetContentScheduleByContentId(item.Id);

I noticed however that the resulting schedule.FullSchedule.First().Date is correct when running locally, and incorrect when running in Umbraco Cloud.

At first I thought this was a timezone issue within dotnet/Umbraco itself, but I see the error directly in the backoffice frontend.

For example, let’s say I schedule something for 21:00 on my local dev machine, running either on UTC or my own timezone (UTC+1), then the release.Date from the schedule has a value of {2025-12-02 21:00:00}.

This is paired with my browser, in the backoffice, doing a request to /umbraco/backoffice/umbracoapi/content/PostSave where the posted JSON has variants[0].releaseDate value of "2025-12-02 21:00:00"

However, in the Umbraco Cloud installation, the release.Date from the schedule has a value of {2025-12-02 20:00:00} . Even if I set it to 21:00. The picker still says 21:00.

Likewise, the request to /umbraco/backoffice/umbracoapi/content/PostSave where the posted JSON has variants[0].releaseDate now has a value of "2025-12-02 20:00:00"

It has removed one hour!

Where did it go? I wonder if there’s some timezone shenanigans within the backoffice? I haven’t found any setting that would relate to that however?

I can’t just go and bruteforce “change” these values, since the actual publishing still happens in the correct times (give/take couple of minutes, hence my need to look at this).

Any tips on what to try?

[sebastiaan (Sebastiaan Janssen ⚓)]

Just FYI: the cloud servers are all set to UTC so that is probably why.

Unfortunately this will stay a problem in v13, in v17 we’ve finally normalized date/times to prevent these types of problems.

[karlmacklin]

But if I run this locally I can force my local development environment to be UTC. And even then, the dates are consistent.

Also, dotnet runtime’s timezone is one thing I suppose, but the fact that the backoffice ajax call to PostSave has already adjusted the time is significant. Wouldn’t that mean that the backoffice frontend code has its own timezone set somehow somewhere?

[sebastiaan (Sebastiaan Janssen ⚓)]

The current logic is that there’s a comparison between your browser’s time and the server’s time. Based on that we show you the time you’re expecting (you want to publish at 21:00) and in the database we store the time that would be on the server (20:00). The publish will happen at 20:00UTC, which is 21:00 your time.

I’m not sure where you’re running into a problem to be honest, but it seems more like you deployed a node with a publishing schedule from local to the server maybe?

[karlmacklin]

Sorry for the confusion, I’ve been thrown off by the difference in behavior from cloud vs local, and that I can’t figure out how/where the frontend acts on a certain timezone.

I think I have a working solution now, bar one issue that a datetime field read only property shown in a node property tab shows UTC time , so 1 hour off. But functionally it is correct if you omit any timezone adjustments whatsoever.