Virtual Happy Hour this month, Jun 28, we'll be getting a sneak preview at our soon to launch SaaS CMS!

Try our conversational search powered by Generative AI!

DateTime UTC Offset


I'm currently working on a site where we show StartPublish (among other datetime-properties) for the end user. When working locally where we have UTC+1 (Sthlm) everything works fine, but when deployed to Azure which uses UTC we notice some unwanted behavior.

If we set Published to 2015-02-26 00:00. It will be saved as 2015-02-25 23:00. Probably due to the fact that the editor is working on a browser with UTC+1, while the webserver is set to UTC. As long as the editor and the server uses the same timezone it works fine.

Our gobalization in web.config looks as such

Are we doing something wrong, and if so, can we do something to fix this? We're running C# MVC with EPiServer

Feb 26, 2015 12:31

Hi Sebastian!

I'm not sure that I understand the actual issue here. The user will see dates and time on their local time zone in the editorial interface while dates will be saved in the servers time zone. This should not matter anything since the effective time will be the same anyway. For instance, if a user in UTC + 1 sets the publishing date to 00:00 this will mean that the article is published at 00:00 UCT +1 which is the same as UTC 23:00.

Feb 26, 2015 14:41


I think the issue Sebastian is refering to has to do with displaying the UTC DateTime of StartPublish in a view. I have the same issue where I set StartPublish to say 2015-02-26 00:00 but when displaying @Model.CurrentPage.StartPublish the output is 2015-02-25 23:00. This is in an Azure Website as well.

Feb 26, 2015 16:16


Sebastian, in which timezone do you want to display the time? By default the time will be presented in the server's timezone. If you want to display it in another timezone you have to convert it yourself.

If you want to show it in your visitor's timezone, you're in for a treat... I think the only proper way is to have your users to login and make them to chose a timezone. You can also display the time in UTC and then correct the time with Javascript based on the user's current time. You can also do an IP look-up and guess the user's timezone.

Please have a look a the converter methods inside the TimeZoneInfo namespace.P

Feb 26, 2015 17:15


Is there anyway setting to let the editors see the server time in the pickers instead of local?


Mar 02, 2015 14:47

No, at least not that I'm aware of. The dates are normalized to the users time zone when converted from JSON to JavaScript objects if I remember correct. We actually tried this in the development of EPiServer 7, but it seemed very hard and bug prone so we thought that it was better to use the editors time any way. I would say that the servers time zone is becomming less and less interesting in a globalized world with cloud computer. For instance, you cannot handle load balanced servers over time zones with such a solution.

Mar 03, 2015 7:53

Thank you Johan and Linus.

We want to display it as the same timezone as the one entered by the editors, or preferably the same timezone as the user. It's not a big issue for us, but now I know how EPiServer handles timezones and why it seems to be the "correct" timezone in the datepicker, and a different when used as a property in code. It makes sense.

Mar 03, 2015 7:59

I know I'm late to the party here, but did any of you "solve" this issue? When displaying the value of a DateTime property, there is , AFAIK, no way to know what timezone the editor was in when saving it.

I can totally see how this is a valid use case for the StartPublish property, but for a datetime proeprty that is used for displaying a date, it becomes a bit of a brain exercise for the editor to keep in mind that they need to think UTC just because the solution is hosted in Azure.

Adding a property for the timezone, and converting it from UTC to that timezone is certainly a way to go about it, but it's hardly a user-friendly approach.

Nov 10, 2015 18:54


As Stephan as phrased here, I'm curious if anyone knows of a good approach to resolve this.

We have event pages and the editor chooses the DateTime property accordingly. This gets messy since they literally are stating the date time that they want displayed - is there a nice way to ensure it is stored and presented as the same timezone?

I'll post back if I figure out a way :)


Dec 09, 2016 4:02

Don't know if this is connected to the thread but here goes.

I display the following date and time in a dropdownlist: 09/12/2016 00:00:00

The user clicks on a button and the value is saved to an EPiServer property.

When viewed in edit mode, the value is displayed as 2016-09-12 02:00. That's an two extra hours.

Is this the desired behavior or is something wrong? We're running EPiServer 9 but I ran the date conversion script on the database anyway since it would be ok prior to version 10.

Dec 09, 2016 15:59


I’m a lite late on this one but where is some comments on how this issue where resolved so I want to share the changes we did.  

We have an DXC professional server setup (azure) and the issue accrued for us on both integration (with one hour) and production server (with two hours).

The site we are working on is only displayed in one language (sv) so I don’t know how this will resolve the issue for users from another time zone but since our users only is located in Sweden this worked for us.  

The solution is simple, we change the server configuration for WEBSITE_TIME_ZONE to Central Europe Standard Time on both integration and production and then the DateTime property displayed the right time for both editors and the end user.

So I guess we only change what Sebastian said in the start of this thread “As long as the editor and the server uses the same timezone it works fine.”

Feb 15, 2017 9:57

If I've understood everything correct it works like this:

Episerver CMS 10 saves dates as UTC, earlier versions saves dates as local server time.
The datetime (dojo) editor in edit mode automatically adapts to the datetime of the editor-user's browser/machine.
When getting the datetime value in e.g. a view you get the value in the server timezone.

When presenting the datetime to the end user you have to convert the value (from server time) to whatever timezone you want it to be presented as. That can be done by converting from server timezone to UTC and then to the selected timezone.

If you want the editor to be able to set the exact value that is shown to the user, then you basically have to use a string property instead (or adapt the dojo editor).

The solution suggested above (to change time zone on server) only works if your all editors machines are in the same timezone.

Yes, this gave med headake aswell...

Feb 17, 2017 16:43

Is there a better solution for this yet?  Is this fixed in EPiServer 11?

I am having this issue when presenting the dates of an event the editor has created. The end user needs to know the exact datetime that the editor chose for the event to start and end.  if the Editor chooses the event to start at 9am we cannot have epi converting it to 5pm because the server is in another time zone. This is a bit of a dxc failure!

Using a string property is a solution but seriously?

Jan 18, 2018 5:04

@john.walsh The default display template for DateTime will use ToString on the date time object and that will be the server time. You can create your own display template for DateTime that can convert the DateTime to the correct time zone for your visitors.

You can look at the display template in the alloy templates for a place to start:

Edited, Feb 07, 2018 14:15


This solution isn't acceptable for us. Many international clients are governed by laws which doesn't allow them to read the IP address of their clients navigating on their web site. Episerver should provide an option to add a DateTimeOffset in their content data. Loosing the timezone information in a date is something critical and Episerver shouldn't assume that saving the information in UTC fixes the problem. 

Please consider adding this type into the content data. 

Thank you! 

Feb 27, 2020 17:19

has anyone tried this?

Sep 27, 2021 11:33
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.