The three-letter designations for time zones (such as "EST" and "GMT") are unreliable.

When used in an Operator ID instance, the system time calculations and displays can be off by an hour, due to Daylight Saving Time.

This issue affects only the conversion and display of times, not internal calculations.

Explanation

The Time Zone field, on the Availability tab in the Operator ID instance (Data-Admin-Operator-ID), allows developers to specify the time zone that this Operator is in. This data is stored in the clipboard on the OperatorID page, as the value for the .pxDefaultTimeZone property.

The SmartPrompt on this field shows the time zones listed in alphabetical order by time zone. The list begins with the geographic areas exactly opposite “GMT” (Greenwich Mean Time, considered the “zero point” for time measurements) on the globe, which are 12 hours away:

All of those areas are listed together, and then for the next time slice (GMT + 11), all areas in alphabetical order, and then all areas for GMT+10, etc.

If left blank, the Time Zone setting defaults to the system’s time zone.

This setting is used by HTML Property rules, which in turn are used by reporting rules (summary view and list view rules).

When data is stored in the PegaRULES database, DateTime values are automatically converted to a GMT time zone. If a record is created at noon on November 1 in New York, the database timestamp would show the record was saved at 7 a.m. GMT that day.

Using the old three-letter designations in the Time Zone field can cause problems, as they are ambiguous; they also may not include Daylight Saving Time. Example three-letter designations:

To interpret these designations, Process Commander relies on either the JDK or the ICU functionality (provided by the ICU4J.jar file). Unfortunately, this functionality has changed from version to version:

• Process Commander Version 4.2 (ICU version 2.8) uses the JDK (either Sun or IBM) to interpret the designation (“EST”). In this version, “EST” is interpreted the same as “America/ New_York” and includes Daylight Saving Time (provided that the correct DST and backward compatibility patches have been applied to the JDK).

• Process Commander Versions 5.1 and 5.2 (ICU version 3.x) use the Olson timezone data to interpret the designations. In this version, “EST” now means “Eastern Standard Time” only, and does not include Daylight Saving Time.

Thus, dates and times which worked fine in Version 4.2 now behave differently in Version 5.x, because the underlying third-party interpretation of “EST” changed.

As of March 2007, there is no formal industry standard for this data. The Olson timezone data is the generally accepted standard for timezone data. See http://www.twinsun.com/tz/tz-link.htm.

IBM has also reported this as an issue:

Use of three-character TimeZone identifiers incompatible with some SDK or JRE Service Refreshes

Excerpts:

Abstract

Information for customers running Java™ applications on an IBM®-supplied SDK or JRE or who have downloaded an IBM SDK or JRE. Problems are associated with code that uses some 3-character time zone symbols in Java after applying recent Java Service Refreshes (SRs), or patching with the IBM Time Zone Update Utility for Java.

Statement of Problem

An incompatibility may be exposed when applying any of the following Java Service Refreshes:

IBM SDK or Runtime Environment, Java 2 Technology Edition, Version 1.4.2 SR5 or above

IBM SDK or Runtime Environment, Java 2 Technology Edition, Version 5.0 SR1 or above.

The incompatibility is also present in all instances of Java 1.4.2 and 5.0 that have been patched by the IBM Time Zone Update Utility for Java prior to V1.4.7c. In applications where a time zone identifier of "EST" or "MST" has been coded as a parameter of the TimeZone Java class in the application program, or in the user.timezone system property, the time returned by the API call will be incorrect by one hour if the location referred to falls outside Arizona during the annual Daylight Saving Time (DST) period.

For the entire article, see the IBM knowledge base.

Solution

Instead of using “EST” or “CST” in the Operator ID field, use the long names for these: “America/New_York”, or “America/Chicago”.

For a full list of the long names, see http://www.timezoneconverter.com/cgi-bin/tzref.tzc

Other references:

• http://wwp.greenwichmeantime.com/info/timezone.htm
• http://www.timeanddate.com/library/abbreviations/timezones/
• http://www.w3.org/TR/2005/NOTE-timezone-20051013/
• http://www.twinsun.com/tz/tz-link.htm

UTC versus GMT

There is a difference between UTC (Coordinated Universal Time) and GMT (Greenwich Mean Time) which has relevance in certain scientific communities. However, for Process Commander use, specially insofar as the Java TimeZone implementation is concerned, UTC and GMT may be considered equivalent. The difference between UTC and GMT is less than 0.9 seconds (maintained via the use of "leap seconds") and therefore indistinguishable for practical purposes. Times reported and used by Process Commander are only as accurate as the time source, which is provided through Java and the underlying operating system.

Neither UTC nor GMT is subject to Daylight Saving Time (based on both the olson 2007b timezone data and the JDK implementation). For a timezone such as Europe/London, GMT is the abbreviation for standard time, BST is the abbreviation for summer time. In particular "GMT" is NOT equivalent to Europe/London during conversions in Java.

The relevant rules in the Olson 2007b data are:

# Zone   NAME              GMTOFF   RULES    FORMAT   [UNTIL]
Zone     Europe/London   -0:01:15 - LMT      1847 Dec  1 0:00s
                            0:00    GB-Eire  %s       1968 Oct 27
                            1:00    -        BST      1971 Oct 31 2:00u
                            0:00    GB-Eire  %s       1996
                            0:00    EU       GMT/BST
Link     Europe/London   Europe/Jersey
Link     Europe/London   Europe/Guernsey
Link     Europe/London   Europe/Isle_of_Man

And

Zone     Etc/GMT                  0        -        GMT
Zone     Etc/UTC                  0        -        UTC
Zone     Etc/UCT                  0        -        UCT
Link     Etc/GMT                                    GMT

The conventions for formatting date fields, as normalized in the CLDR data, use GMT as the base time zone when no local abbreviation is available or sufficient.

References

• Common Locale Data Repository: http://www.unicode.org/cldr/ and see timezone fallback rules #Time_Zone_Fallback
• Sites such as NOAA admit to a practical equivalence of UTC and GMT http://www.aoml.noaa.gov/hrd/tcfaq/A13.html even though this is one of the fields where the difference is potentially relevant.

Background on the correspondence between UTC and GMT:

• http://www.physics.sfasu.edu/astro/jupiter/offset.html
• http://www.its.bldrdoc.gov/fs-1037/dir-009/_1277.htm