History
DST
Ever since the current project team took on the module in 2008, the inability to accurately display dates in the users timezone and to export iCal (.ics) files that are 100% correct, has been a major frustration. With version 6 that frustration will be put to rest.
Note: Version 6 is not released as yet. The current release version is v5.2.1, with v5.2.2 (a bug fix release) coming very soon. The team is working hard on v6, so we hope to bring to an extension library near you soon.
You may ask why we have been unable to provide accuracy. Ever since 2007 there has been an issue open on Gemini (DNN-4991 - Add Support for Daylight Saving Time (DST)) requesting DST support be added. DotNetNuke versions prior to 6.x have provided timezones, but these have lacked the level of granularity that is really required to map all the timezone/DST differences across the world. I think DNN provided 25 timezones whilst Windows provides 90+
This is of course through no fault of DNN, prior to ASP .Net V3 (I think) DST support was not provided by .Net, so DNN could not surface it. However with the move .Net 3.x and DNN 6.x DST is available. This document describes the changes included in DNN v6, which I think are all captured in this blog by Ash Prasad.
User Timezones
The inability to accurately correct for DST lead to Alan Vance (the original module creator) to agree with the community that the module will not display events in the users timezone, only in the module instance’s timezone. This can lead to confusion from users who are used to seeing a time that is relevant to them, but may in actual fact be something different to what is expected. To reduce this confusion, the module supported the ability to display timezone information alongside dates and times to make it clear as to what the presented time actually meant.
Of course for websites where the users all reside in the same timezone this isn’t an issue, except of course in exports such as .ics files where DST offsets for the user /module may not be accurately be corrected for.
The Future
The following lists the key principles I have used in updating the module
- With Events version 6, the module is updated to store event dates as a date/time in a particular timezone (previously it was a +/- minute offset from GMT). Note that a UTC date/time isn’t used here because countries do occasionally change their DST (or even UTC offset – note what Samoa did at the end of 2011), so UTC dates would then be incorrect.
- Other dates such as Created Date and Last Updated Date are all stored as a UTC+0 date.
- Dates can be configured to display in User(Userinfo.Profile.PreferredTimeZone) / Module (Settings.TimeZoneId) /Portal (PortalSettings.TimeZone) timezone and all events will be corrected to that timezone. User timezone will only work if the user is authenticated
- The exception to this rule (because there must be one) is that in Edit Events all dates are shown in the event timezone.
- Per event timezones (as opposed to module level timezones) can be enabled in module settings.
- Which leads to another display exception - If per event timezones is enabled, Detail view will show event timezone – note that it would therefore be wise to turn on display of timezone, or edit the event view template.
- When timezone information is displayed, it will show the display timezone (previously it showed the module timezone).
- Emails will be set in User/Module/Portal timezone as appropriate. Apart from Reminders which will use event timezone instead user timezone (because we don’t know the users timezone, only email address).
- iCals now output multiple timezones, so each event will be correctly linked to the relevant timezone to ensure DST corrections are included correctly (previously DST corrections were based on server timezone).
- New events will default to module timezone.
- Default initial timezone for module is portal timezone
Changes
In actual fact the changes to the data model are quite small. I’ve removed TimeZoneOffSet from the Events and EventsRecurMaster tables (and loads of sprocs) and converted this to a module setting TimeZoneId using the core DNN conversion logic.
New and updated events will have the relevant event EventTimeZoneId stored in a new attribute on EventsRecurMaster.
There are a lot of code changes to display the dates/times correctly, so anyone accessing any api’s may need to do code changes. In general all conversions to display timezone are done in the display logic rather than in the business logic. So a call to EventInfoHelper.GetEvents will now get a pure extract from the database with no time correction for sub-calendars in different timezones.
Questions and Thoughts
I’m open to any thoughts and comments on anything to do with this change.