When working with two clients this past week, the issue of dates and time zone display came up. Dates are stored on the server in the server time zone (UTC, for example) but when the date is displayed through HPI, web browsers display the date according to the local time zone settings set in Windows. In some instances this automatic conversion to local time is helpful and in other instances it causes a lot of confusion.
Why Time Zones are an issue – Viewing
At first glance, displaying all dates in local time sounds like very user-friendly feature for all end users potentially located around the globe. This transformation of date/time display into local settings can be very helpful if the date display includes the time information as well. Unfortunately, if the date is displayed without time information and users are located in different time zones, this can cause confusion.
For example, if a document is stored on the server with an approval date of March 1 at 8:00 pm U.S. Central Time, but the date is viewed in Europe that date might be displayed as March 2 at 3:00am. If the time stamp is not displayed it would be confusing as to why some users are seeing the approval date set to March 1 and the user in Europe would see an approval date of March 2.
Why Time Zones can be an issue – Headers and Electronic Signatures
The other issue caused with displaying dates in the local time zone (even with at time stamp displayed) is that this time zone conversion is only applied to the display of property values the browser controls. In this case, the browser might control the display of  search results or the properties for a document, if the user decides to view them. However, this time zone conversion does not happen when the dates are added to the Document Overlay (Header) or on the electronic signature page, since the date stamping occurs on the server itself.
For example, if servers are set to US time and a document is approved at 8:00 pm US time the overlay and electronic signature will state that the approval date is March 1. The electronic signature page will show that the final approver approved the document on March 1 at 8:00pm. It will display the overlay and signature page with this data regardless of who is viewing the document (US or EU users). However, on the search results screen, the Approval date will be read by the user’s local browser and be changed to March 2nd for the end user in Europe.
HPI Updates
In both cases discussed above, our team determined it was best to turn off time zone localization. The latest release of HPI has just been updated to support this ability. An administrator has the ability to specify if the application should ignore the user’s local time zone settings. By choosing to ignore the local time zone settings, HPI can specify in which time zone the date/time fields should be displayed. Also, if users are allowed to update date or time fields via HPI, the date or time selected will be localized to the timezone specified in the HPI configuration. This would typically match up to your server settings.
Summary
Time zones are tricky and it would be great to display all dates/times in local values. Unfortunately due to the complexity of the applications there is not a clean way to update the display of all dates. So for now, if your company has users and/or servers in multiple time zones, TSG recommends turning off date/time localization.
Leave a Reply