Browser Time Zone setting is unreliable

Resolving The Problem

Browser Time Zone setting is unreliable

The client has WP users in multiple time zones. The time zone for WP date and time display is set in either the site or user prefs, one option of which is "Browser Time Zone". This setting was an attempt to automatically set the user's time zone setting, but this is not always successful.

The automatic setting of the user's time zone is not always successful because there is no set standard for how browsers return the time zone 'code', and we do not control this. Because of the variation in the time zone 'code' returned by various browsers, AE employs some logic to try to set it correctly, but there are usually more choices than we have points of information to narrow the list. When AE cannot set the time zone definitively, it falls back to displaying the time zone of the AE server.

There is currently only one way to display a user's time zone correctly all of the time, and that is to set the user's time zone setting in the user prefs. When this is set, AE knows exactly what GMT offset to use, and can also apply DST updates as necessary. This should be WP 'best practice'.

Our documentation explicitly states that there can be variability when using 'Browser Time Zone'.


WP User Preferences Documentation:

Time Zone specifies how the time zone should be determined. Although the default is to check your browser's time zone setting, it is always more reliable to set a specific time zone value, in case a program can't determine your browser's setting. For example, if you are in the Pacific Time Zone and you switch to daylight savings time each year, you would choose (GMT-8) Pacific Standard Time. If you don't change to daylight savings time, then select (GMT-8) GMT-08:00.
Default
Browser Time Zone
AE Server Time Zone
a specific GMT value


AE Site Preferences Documentation:

Time Zone
The Time Zone preference determines which time zone should be used to display dates and times in Workplace. A drop-down menu lets you choose between:
Browser Time Zone (the time zone used by the browser on the client machine)
AE Server Time Zone (the time zone used by the application engine server that is running Workplace)
Specific GMT time zone, for example, (GMT-7) Mountain Standard Time
It is best if each client sets a specific GMT time zone. If the Application Engine is unable to determine the time zone being used by the client's browser, the following criteria are used:
If the client computer time zone uses Daylight Savings Time (DST), then the server time zone is used.
If the client computer time zone is not using DST, and the server time zone also does not use DST, and the offsets from Greenwich Mean Time (GMT) match, then the server time zone will be used.
If the client computer time zone is not using DST, and the server time zone does not match, then a generic time in the form GMT+/-HH:MM will be used.

For most of our clients who do not have users spread over multiple time zones, the default setting works well. Best practice when using Workplace over many time zones is to set the correct time zone in the user settings for each user. That is what the setting is for, the documentation states that individual user time zone settings should be used, and it works. The product is designed to give best functionality when using that setting.


Proposed Solutions (supplied by 3rd level):

About 'Browser Time Zone': We are constrained by what can be reliably returned to the AE server by JavaScript. If every browser used a standard time zone code, this would not be a problem. Unfortunately, different browsers return different time zone codes, and we have to support several different browsers. This is the reason this must be set manually.

There are two possible ways to increase the accuracy of using Browser Time Zone. Each comes with additional requirements and drawbacks.

1. Use a small Java applet in the browser that retrieves the local time zone and sends it back to the server.

Requirement: The browser must be configured to allow Java applets
Requirement: A JRE must be installed on the user's PC
Drawback: Possibly none if the requirements can be met, but the client may not be able to install a JRE on all user PC's. This also violates our no-footprint rule for Workplace.

2. Introduce a configuration file that maps offset minutes information to customer-specified time zones.

A key in the configuration file would be constructed using a concatenation of offset minutes, whether or not the time zone has DST (some do, some don't), and if the
time zone does have a DST, an indication of whether the time zone is Northern or Southern hemisphere. This is all information that can be reliably retrieved using
JavaScript. The config file would allow assignment of a single time zone for each of these keys.

Requirement: None for the end user
Drawback: This scheme would still fail on the small number of time zones (4) that have the same GMT offset, DST, and hemisphere values. The client would then need to pick which one is displayed.