Skip to main content
This content has been archived and is no longer being updated. Links may not function; however, this content may be relevant to outdated versions of the product.

Issue: Avoid three-character time-zone codes because they do not support Daylight Saving Time consistently

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.


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:

Three-letter designation
Possible issues


Eastern Standard Time. Does not include Daylight Saving Time (in ICU version 3.x).


Eastern Daylight Time. Does not include standard time.


Central Standard Time in the US, or, China Standard Time.


Greenwich Mean Time. Could also use UTC.

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 WWW

IBM has also reported this as an issue:

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



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.


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 WWW

Other references:

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


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.


Background on the correspondence between UTC and GMT:

Did you find this content helpful?

Have a question? Get answers now.

Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.

Ready to crush complexity?

Experience the benefits of Pega Community when you log in.

We'd prefer it if you saw us at our best.

Pega Community has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice
Contact us