U4-265 - Time zone adjustment in Umbraco backend for Date/Time picker

Created by Jeavon Leopold 16 Aug 2012, 09:21:32 Updated by Sebastiaan Janssen 14 Oct 2016, 09:48:51

This is mostly to do with scheduled publishing. A user shouldn't need to know what the server's time is in order to do scheduled publishing correctly, they should be able to select the time it is in their timezone and be certain that it will be published in their time zone for the time they've selected.

Update: for clarity, this is how it works for editors: https://our.umbraco.org/forum/extending-umbraco-and-using-the-api/80651-time-zone-adjustment-changes-in-u75-plus

To do this without breaking compatibility here's how this works:

  • For the date/time picker property editor, we create a new pre-value to enable server time offsetting, by default this is false = so it's the same as it always has been
  • For the scheduled publishing date/time pickers these will be forced to offset the time based on the model mappers that are used to create these properties
  • We will add the server's timezone offset to the Umbraco ServerVariables
  • The JS in the date/time picker will check if it's configured to offset the time, when this is true it will convert the model's value (server date/time) to the local date/time to make visible to the user
  • When the user updates the date, the model's value will be updated to the server's timezone for persisting
  • A server time is shown below the date/time picker when offset is enabled


Sebastiaan Janssen 19 Nov 2012, 10:19:08

Just to update, I misread this at first: the problem really is that when you do scheduled publishing, the use needs to factor in timezone difference first. For Concorde this would indeed mean that it would be a bigger problem as the server time is not guaranteed to be the local time.

Sebastiaan Janssen 07 Oct 2015, 13:53:41

We'll detect the user's timezone and offset that with date/time pickers so that when editors choose a time to publish items on, it will be on that time, without having to manually calculate the time difference between you and the server.

Warren Buckley 24 May 2016, 14:55:12

@Shandem can you let me know if this will effect anything in the Forms codebase please. As the date range picker in the entries viewer of forms uses the Umbraco backoffice user's locale to display the calendar & dates in the correct locale.

Shannon Deminick 25 May 2016, 07:59:59

PR: https://github.com/umbraco/Umbraco-CMS/pull/1284

Testing notes:

  • This is sort of an odd one to test since to do it correctly you need to have your client in a different timezone than your server - so we can fake it: ** You'll need to change the BackOfficeController to hard code a server time offset temporarily instead of using the default one

  • build the solution, build the grunt, make sure JS tests are executed and pass

  • On a content item: ** ensure no JS errors ** add a date for scheduled publish and unpublish ** make sure the server date shows up below the selected date/times and make sure it's correct based on your hard coded server time offset

  • Create a date and a date/time property for this content item ** Make sure these function the way you expect without any timezone offsetting (i.e. they way they work < 7.5) ** Be sure to save a date and date/time value for this content item

  • Go to the date/time data type ** Make sure that the offset pre-value is false by default ** Make sure the wording is ok for the description ** enable the offset and save it, be sure that this is persisted (i.e reload it)

  • Go back to the content item with the date/time picker property ** Make sure it functions correct with the offset - the value displayed should actually now be the offset value, not the one that you originally saved ** The 'date' (not date/time) should not have changed, since this doesn't have an offset option

  • Be sure to not commit your hard coded offset in the BackOfficeController!!

Sebastiaan Janssen 25 May 2016, 08:24:02

You'll need to change the BackOfficeController to hard code a server time offset temporarily

Or just throw the site up on Azure in a different region than yours. ;)

Shannon Deminick 25 May 2016, 08:59:33

Sure, whatever you think is quicker - just make sure that the Azure timezone isn't the same as your local one. If you change the BackOfficeController, this is the change:

before: app.Add("serverTimeOffset", Convert.ToInt32(DateTimeOffset.Now.Offset.TotalMinutes));

after: app.Add("serverTimeOffset", 600);

== that will equal Sydney time, this value is in minutes and Sydney is +10

Sebastiaan Janssen 30 May 2016, 13:56:11

Left some comments and questions on the PR!

Shannon Deminick 31 May 2016, 12:05:23

@sebastiaan I have pushed up changes to the PR and to the uaas site

Shannon Deminick 09 Jun 2016, 12:37:54

@sebastiaan can this be merged in yet?

Sebastiaan Janssen 09 Jun 2016, 12:48:51

@Shandem Just need to update that "Server time" label, it should be hidden if you haven't selected anything (else it's just an empty thing that adds no info) and it should say something like.. the time you selected above is the following time on the server. I'm not sure how to make that a concise message.. Maybe just link to documentation explaining it in more detail.

Shannon Deminick 09 Jun 2016, 12:55:01

yup it's hidden if you are in the same timezone as the server and/or haven't selected anything. Will update the the message

Stephen Adams 16 Jun 2016, 04:14:45

@Shandem any plans to backport this to previous 7.x versions?

Shannon Deminick 20 Jun 2016, 08:04:16

It will be in the next release: 7.5.0, there are no plans for any more 7.4.x

Sebastiaan Janssen 22 Jun 2016, 15:20:52

@Shandem Added one more commit for showing / hiding the "Server time" message, which is now expanded, localized and points to documentation. If you can have another look then I think it's all good now!

Priority: Normal

Type: Feature (request)

State: Fixed


Difficulty: Normal

Category: Localization

Backwards Compatible: True

Fix Submitted:

Affected versions:

Due in version: 7.5.0

Sprint: Sprint 36

Story Points: