ServiceDesk sets a wrong timezone for user while the time is correct.

Article:TECH166190  |  Created: 2011-08-02  |  Updated: 2012-03-20  |  Article URL http://www.symantec.com/docs/TECH166190
NOTE: If you are experiencing this particular known issue, we recommend that you Subscribe to receive email notification each time this article is updated. Subscribers will be the first to learn about any releases, status changes, workarounds or decisions made.
Article Type
Technical Solution

Product(s)

Issue



When we detect and set the user timezone (which happens every time a user logs in) we set the user timezone to the first matching UTC value which is not necessarily the right timezone. See examples below.

This is causing considerable confusion, especially as customer-configurable options for setting timezone were removed in 7.1.

- User in UK always gets '(UTC) Casablanca' as timezone and never '(UTC) Dublin, Edinburgh, Lisbon, London' one would expect.

Due to a number of previous issues with ServiceDesk timezones and '(UTC) Casablanca', a better example:
- User in Sarajevo will not get the expected '(UTC+01:00) Sarajevo, Skopje, Warsaw, Zagreb' as a timezone but always '(UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna'


Environment



ServiceDesk 7.1
Workflow 7.1


Cause



In the Symantec Workflow engine that underlies ServiceDesk, the time zone region detection is approximate. The Workflow engine relies on the user using the correct offset, which approximates the region.


Solution



There is currently no way to determine the timezone region. The first offset match is chosen by default.

However, on the Account page you can deselect the Dynamically Select Time Zone option and select a specific time zone from the list.


Supplemental Materials

SourceETrack
Value2485508
Description

ServiceDesk user timezone is set to the first matching UTC value which is not necessarily the right timezone.


SourceETrack
Value2577533
Description

ServiceDesk user timezone is set to the first matching UTC value which is not necessarily the right timezone.



Article URL http://www.symantec.com/docs/TECH166190


Terms of use for this information are found in Legal Notices