Besides other goodies in DotNetNuke 6, the Time Zone support has been enhanced to provide a much richer feature-set including support for Daylight Savings. Pre 6, Portal and User Time Zone settings were offset value in minutes, now they are referred through a first-class .Net object called as TimeZoneInfo.
UI Changes – User Profile and Portal Settings:
6 offers a much wider choice for Time Zone selection; same as what Clock on typical Windows workstation of server .
Pre 6 it was difficult for module developers to accurately detect if Time Zone supported Daylight Savings or not. Now with the availability of .Net TimeZoneInfo class, module developers can very easily find all the Daylight Savings related information, both for the portals and for the users. Some of the properties that can be useful are SupportsDaylightSavingTime and BaseUtcOffset.
As an example, in pre 6, an offset of -420 minutes meant just one value: Mountain Standard Time, disregarding the fact that there were two more Time Zone settings available with the same offset: Arizona and Chihuahua. 6 allows selection of any of the three options.
UI Changes – Time Zone Editor removed:
Since, there is no need for the old Time Zone Editor it has been removed.
API Changes
1) Old DotNetNuke.Entities.Users.UserProfile.TimeZone property is marked as Obsolete. Replaced by DotNetNuke.Entities.Users.UserProfile.PreferredTimeZone property. PreferredTimeZone is .Net TimeZoneInfo.
2) Old DotNetNuke.Entities.Portals.PortalSettings.TimeZoneOffset property is marked as Obsolete. Replaced by DotNetNuke.Entities.Portals.PortalSettings.TimeZone property. TimeZone is .Net TimeZoneInfo.
Note: As true with any obsolete APIs, they will continue to function, however, module developers should stop using them and move on to their replacements.
3) Two brand new APIs have been introduced to obtain current time. These API make a direct query into the database and return timestamp from database. These API will be very useful in a web-farm configuration with multiple web-heads or configurations where web-head and database are deployed on separate servers, perhaps separate time zones.
Obtaining timestamp directly from database removes any confusion about consistency or accuracy of timestamp. Since the API will be querying one single source all the time, the time returned will always be consistent and accurate.
a) DotNetNuke.Services.SystemDateTime.SystemDateTime.GetCurrentTimeUtc. Gets Current Date Time in Utc from database.
b) DotNetNuke.Services.SystemDateTime.SystemDateTime.GetCurrentTime. Gets Current Date Time from database.
Availability
The enhancements have been made in the core-framework and therefore will be available on all the editions of DotNetNuke 6 and beyond.
Upgrade Scenario
The new Time Zone settings (both Portals and Users) will be available on newer installations of 6 and also on the ones upgraded from a previous version.
The Portal’s time zone setting will be converted during upgrade itself.
The user’s time zone setting will be lazy upgraded, meaning they will be converted on first load of the profile (user login, viewing user’s profile, etc.).
The conversion is based on hard-coded mappings in the framework. The mapping is borrowed from TimeZones.xml file in App_GlobalResources folder from a standard pre 6 installation. For the curious mind, the mappings can be read in the source code here, just look for ConvertLegacyTimeZoneOffsetToTimeZoneInfo method.
What to watch out for
After upgrade, Portal Administrators should inspect Time Zone settings for each and every portals and make sure the auto-conversion from old offset to the new setting has been done per their expectations. If not, the setting can be very easily updated using Admin->Site Settings. Same can be done for Users as well.
Quick Video
Here is the link to a quick video on this:http://www.dotnetnuke.com/Resources/Video-Library/Viewer/VideoId/299/DotNetNuke-6-Daylight-Savings-Time-Changes.aspx