Summary

Time zone identification and processing in V5.3 differ from V5.2 and earlier versions . 

Suggested Approach

Time zone information is recorded on the Calendar form and the Operator ID form. Three-letter codes and GMT-based time zones have caused confusion and unexpected results in Versions 5.2 and earlier, and do not correctly implement recent changes to Daylight Savings Time.

Accordingly, in Version 5.3, time zones are specified geographically rather than by three-letter codes or GMT references.

Quick Links

• Time zone codes in Calendar instances
• Time zone codes in Operator ID instances
• Time zone codes in the model rule for Operator IDs

Time zone codes in Calendar instances

The Calendar record (Data-Admin-Calendar instance) has a Standard Time Zone field:

Beginning in Version 5.3, this time zone field must reference a valid time zone ID such as America/New_York.

You can time zone field may be left blank.  If no time zone is specified in the calendar record, then by default, the system uses a time zone which is appropriate for that calendar.  However, this is not a best practice.

This field uses a drop-down SmartPrompt:

Note, however, that not all entries in this drop-down field are valid for V5.3.  Values such as “GMT+5” are not valid; neither are the three-letter designations (“EST”).  (These values are provided by the ICU or the JDK, not by Pegasystems.)   See the following articles for details:

• Issue: Avoid three-character time-zone codes because they do not support Daylight Savings Time consistently
• International date,Ftime and currency processing depends on ICU4J library version

A calendar data instance named USDefault is included starting in V 5.3 (pictured above); it uses the America/New_York time zone. 

Time zone codes in Operator ID instances

Each Operator ID instance (Data-Admin-Operator-ID instance) has both a calendar and a time zone reference:

Process Commander does not require that the Time Zone field on the Operator ID match the Time zone specified in the calendar instance selected in the Calendar field.  However, it is a best practice to make sure the Time Zone field of the Operator ID instance matches the time zone information in the calendar instance. 

As with the calendar instances, not all entries in the time zone drop-down field (which is the ICU list, not provided by Pegasystems) are still valid.  Values such as “GMT+5” are not valid; neither are the three-letter designations (“EST”).  For more details, see:

• Issue: Avoid three-character time-zone codes because they do not support Daylight Savings Time consistently
• International date, Ftime and currency processing depends on ICU4J library version

You may leave this time zone field blank.  If no time zone is specified in the calendar instance, then by default, a time zone which is appropriate for that calendar will be used.  However, this is not a best practice.

Time zone codes in the model rule for Operator IDs

Beginning in V5.3, the model rules for Operator ID data instances now default the following values:

• Calendar:  USDefault
• Time Zone:  America/New_York

If these values are not correct for the your location, they should be updated before the model is used to create any new Operator ID records.

Other Changes

If you have an invalid combination of calendar and time zone in either your calendar instances or your Operator ID instances, you may find that some business calendar functions, such as skill-based routing or substitute routing, may no longer work correctly. 

When debugging these functions, check these fields and make sure they have compatible values; if they do not, change them to be compatible and re-test the functionality.