Understanding Time Zones within Kentico
As an enterprise-class platform, Kentico must be able to handle implementations worldwide. Part of this support comes from Kentico’s ability to configure and manage time zones from within the platform, ensuring that all dates are correctly displayed. In this blog I will cover Kentico’s time zone support, available options for configuration, and some best practices when developing an application using this feature.
Overview
Time Zones in Kentico are extremely configurable, and allow developers to customize the way in which dates are displayed within their site. Through different levels of configuration, developers can set a base time zone for their server and site, as well as on the user and control level. This enables the site to be extremely dynamic and customized to a user’s specific settings, while still allowing dates to be stored in a uniform manner. All of the time zone logic is based in the way dates are displayed, and their conversion to the appropriate values.
You can read about time zones in Kentico’s documentation, found here..
Using Time Zones
Below, I will cover the different options when using time zones within a set. Choices made while configuring these options will determine how the application will handle time conversions, and the underlying data.
Enabling Time Zones
The first step is to enable the time zones functionality. In the Admin/Settings/System/Time Zones section, enable the time zones module.
Server Time Zone
After enabling time zones, the next step is to set the server time. This will serve as the main time zone for all data within the database. All dates will use this time zone so there is a consistent base time to convert to/from when displaying dates. This should be set during every Kentico installation.
Site Time Zone
Each site within an installation can be set to a different time zone. This may be especially helpful for a company with sites for different offices around the globe which therefore need to display dates/times in their respective time zone. For each site, set the appropriate zone.
User Time Zone
Another option is to allow users to set their individual time zones. This allows users to see posts/dates in a time zone familiar to them, without any additional storing or manipulation of the date values. Each user can have a specific time zone assigned to them in their profile.
Control Level Settings
One final configuration option is to set the time zone for a particular control. This is helpful when you have a calendar that needs to display dates in a specific time zone. Nearly every control has this configuration option, so you can use it wherever necessary.
Automatic Date Conversions
Once time zones are configured, there are several options for displaying date values in the correct format. Many areas of the site have built-in functionality to convert times to a user’s setting.
Take a look at the BlogPostDate value in the database for the sample post.
This reflects the server setting of UTC-5 (US Eastern Time). This value was entered when the blog post was originally created.
When viewing the document within the Pages module using the Administrator account, the date is different.
This happens because the Administrator uses time zone setting of UTC-6 (US Central Time), so the date is automatically converted. This automatic conversion occurs in several areas of the Administrator site.
Manual Date Conversions
When displaying dates on the site, developers will need to specify when/how to convert dates. This can be done easily using built-in transformations that leverage the TimeZoneHelper class.
In this example, there is a CMS repeater displaying blog post information. For the BlogPostDate value, I am using several transformation methods to convert the value to the desired time zone. I have added text to display the actual time zone for each type of date.
As you can see, the displayed value differs depending on the transformation method being applied.
Note that in the control, I have specified a time of UTC-7 (US Mountain Time). The GetDateTime method will use the control’s individual setting for converting the time.
You can find more about transformation methods here.
Best Practices
Now that I’ve covered how time zones work within Kentico, I want to provide a couple of best practices when developing an application.
Set the Server Time Zone Immediately After Installing
This will ensure that your site is set up correctly, and all of your dates start off on the right setting. This time is typically set to where the server physically resides.
When in Doubt, Set the Server and Site to the Same Values
To ensure you have proper conversion, I recommend setting the time zone for each site to the server time, when possible. This will help keep your dates in sync and prevent some confusion in the future. If you need to have a different setting for each site, do so as soon as the new site is created.
Leverage Transformation Methods if Users will Have Different Settings
Understanding how the transformation methods convert the data will allow you to build dynamic applications that will be catered to user’s preferences. This is especially important if you have a global audience of people who need to view dates in their own format.
Conclusion
Building dynamic sites that display information specific to users is extremely important for good site design. Leveraging Kentico’s time zone functionality can help you achieve this, and ensure that all of your dates are displayed correctly.
As always, be sure to leave a comment, and good luck!