We have moved to GitHub Issues
Created by Mark van Schaik 11 Mar 2014, 00:11:25 Updated by Shannon Deminick 01 Nov 2017, 05:16:48
Problem: using cloud hosting such as Azure may mean the server is not located in correct timezone, current umbraco source uses server time for many settings.
Solution: replace all references of DateTime.Now and SQL (getdate()) associated with 'created', 'last edited', 'publish at' and 'unpublish at' (and any other relevant/affected fields) so they are based on a timezone configurable setting. eg. DateTime timeUtc = DateTime.UtcNow; TimeZoneInfo cstZone = TimeZoneInfo.FindSystemTimeZoneById("New Zealand Standard Time"); DateTime nzDateTime = TimeZoneInfo.ConvertTimeFromUtc(timeUtc, cstZone); where the timezone ('New Zealand Standard Time') could be set in the web.config.
changed status to bug (given that 'publish at' functionality no longer works as expected when using a non-local server) and major (given that azure hosting appears to be almost a default for many ppl now)
The same goes for 6.x versions.
This could be an extension method if a singleton were created for representing the system time.
Is there an update on the timeframe for this issue? Our client also is on Azure and scheduled publishing is created lots of issues. (umbraco 7.2.1)
Using a configurable timezone would solve the problem soewhat but some of our customers have editors in different timezones and would each like to set the publication time from their own perspective. Using UTC times and translating them to the browser timezone would be better
I share the same opinion of @Mark.van.Schaik - Umbraco on Azure Web Sites is becoming very popular! Not being able to use the "Publish/Unpublish at" funcionality is big bummer!
Is there any other solution for this? Event Handler for example. I tried to write an event handler to change dates before they saved into database but it didnt work. any help?
This also affects version 6.2.4, when running Umbraco on Azure.
Changed back to bug - publish/unpublish DO NOT work as expected if the editor is not within the same timezone as the server - an unrealistic assumption. As mentioned by sandor, a client-side solution would be the ideal, however a configurable timezone would go a long way to having this work correctly for editors located predominately within the same timezone.
Not to increase the scope of this fix, but it would be good (perhaps essential) to show the 'Umbraco time' in a conspicuous place in the backoffice. Currently editors have no way of knowing when a node will be auto-published and they'll assume that it's local time (to them). However, larger countries (e.g. Canada, USA) have multiple time zones and the likelihood of the server being in the same time zone is not very high - not to mention the challenges this poses for organizations with offices in different time zones.
Also, this clock in the back office will need to be configurable for 12/24 time format independently from the server/.NET settings as North American users tend to not understand 24-hour time. Ideally users would be able to set the preference in their user profile.
There is a supported way to change your Azure Web Apps (formerly known as Azure Web Sites) timezone configuration: http://blogs.msdn.com/b/tomholl/archive/2015/04/07/changing-the-server-time-zone-on-azure-web-apps.aspx
All you need to do is add an Application Setting (via the portal or the management APIs) called WEBSITE_TIME_ZONE and set that to the name of the time zone as defined in the Windows Registry under HKLM\Software\Microsoft\Windows Nt\CurrentVersion\Time Zones\ (for example, “AUS Eastern Standard Time”).
Unfortunately, this is not just an issue for sites on Azure. Our hosting environment has a machine with a single instance of IIS which contains a number of Umbraco sites, all for customers who span the U.S. in timezones ranging from Pacific to Eastern. This means that we can't do the "change the timezone of the server" trick.
In our case, we don't need per user timezones, although it would be fine if that was the implementation but we do need a configurable timezone per site.
The way that we did this with our SaaS app was to store all dates in the database in UTC, have a timezone specified on a per client basis and do the TO and FROM calculations where necessary for display purposes.
Currently, I am building a timezone property editor for our site settings doc type and building the timezone logic into a scheduling property editor that is aware of the site specific timezone. It would be nice for the date handling logic to be consistent -- so I may comment out my timezone logic and wait for it as a system-wide feature I can tie into.
I am using the following Github projects as a starting place and it seems to be working well.
Anyway, I'm glad timezone logic is on the radar for a future release.
Type: Feature (request)
Backwards Compatible: True
Fix Submitted: Inline code
Affected versions: 7.0.4, 6.2.1, 6.2.2, 6.2.3, 6.2.4, 6.2.5, 7.2.4
Due in version: