Adjust your ServiceNow instance Time Zone after Daylight Saving Time

jonnyseymour
ServiceNow Employee
ServiceNow Employee
‎03-29-2017 12:10 PM

Daylight Saving Time (DST) is the practice of advancing clocks during summer months by one hour so that evening daylight lasts an hour longer, while sacrificing normal sunrise times. Typically, regions that use Daylight Saving Time adjust clocks forward one hour close to the start of spring and adjust them backward in the autumn to standard time.

When the DST is enabled on some time zones (TZ), clients and applications will adjust the timezone offset twice a year. Note that only the "Display" value is changing. The time is stored in UTC and is not affected by the display change.

The key for a successful DTS change is to have both client and apps update the offset at the same time.

If a time zone in a ServiceNow instance is specified based on location (for example, America/Los Angeles), times will automatically be adjusted for Daylight Saving Time. If a time zone is specified based on the name of a time zone (for example, GMT), it will not adjust.

getready-for-daytimesaving.jpeg

Adjusting your ServiceNow instance time zone after Daylight Saving Time

I have a few recommendations for what to do after a DTS change to set your time zone. The app is the application used on your instance (e.g. Incident). The client is your browser, mobile app or operating system used to see the application.

Display values

It means

Corrective measures

If the time on the app is the same as on the client

Both client and app got updated

No action. Date and times continue to get stored correctly.

If the time on the app is 1 hour offset*

Only the client got updated

Validate app system TZ or user TZ. Check the time zone is based on location (e.g. America/Los_Angeles). In the meantime, use the app date and times to ensure they are stored correctly.

The time on the client is 1 hour offset*

Only the app got updated

Validate client TZ. Check that it is the same time zone as on the app. Most client time zones are inherited from the operating system (OS), so check the OS timezone. In the meantime, use the app date and times to ensure they are stored correctly.

The time on the app is the same as on the client, both with 1 hour offset* **

Both client and app failed to set DTS

Validate if the TZ is correct and based on location (not time zone names GMT, PDT, etc). Then validate both app and client TZ. Nevertheless, date and times are stored correctly.

* When compared to the official time.
** There are exceptional cases, where the time zone has officially changed but it has not yet been reflected in Java. On those cases, try to find a matching existing time zone to the official time even if it is not the right "location" until Java catches up the updated offset. If you live in such countries, you would know this practice already.

For example, your computer running Windows will update the time forward one hour, and your application will do the same. Otherwise, when you compare the application time with the one on your client clock, it may look one hour offset. To resolve the problem, ensure both time zone offsets have been set on the apps server and on the client.

ServiceNow will automatically update the offsets based on the latest java java.util.TimeZone definitions. If a time zone is specified based on the name of a time zone (for example, GMT), it will not adjust.

If any problem happens, use the application timings (e.g. the time display on your instance) to ensure the date and times will be stored correctly.

You can find more information on ServiceNow time zones here:

Preview file
33 KB
  • 11,328 Views
2 Comments