Strategy to Change the Appserver time zone
Hi All,
Our Current set up of the Production Environment is having the App Server time zone as PST.We are planning to change the app server time zone to GMT.Are there any recommendations from Pega ?.
What will be the impact areas.
Thanks
Dinesh
JP Morgan Chase
IN
I see atleast one area of impact is that of SLA's.These may behave differently because they use the value in the column pyminimumageforprocessing.
Pegasystems Inc.
GB
Hi Shankar,
PRPC actually stores Date Times in a standarized 'UTC' (~=GMT) times; here's an extract from (version 717) PRPC help page about this :
http[...]/prhelp/procomhelpmain.htm#concepts/concepts2/conceptsdatetime.htm
The internal representations
The internal representations are efficient for sorting and comparisons and Java operations, but may not be familiar to business users:
The internal representation of a Date value is eight digits in the format YYYYMMDD, for example 20061215 for December 15, 2006.
The internal representation of Time of Day value is six digits in the format HHMMSS, where the hours portion ranges from 00 to 23. For example, 153025 represents 25 seconds after 3:15 P.M.
For DateTime values, the internal representation has the format MM dd yyyy hh:mm:ss a GMT where GMT are literal characters, MM represents a month, dd is a day, yyyy is a year, hh is an hour value between 00 to 23, mm is a minute value between 00 and 59, ss is a second value between 00 and 59, and a is the a.m./p.m. marker. (The pattern character Z — for Zulu time — sometimes appears rather than the time zone characters GMT in some descriptions. The value always contains a space followed by the three letters GMT.)
And also note that PRPC OPERATOR records also allow you to specify which Timezone an Operator usually works 'out of': so broadly - PRPC doesn't care which Time Zone the Application Server is running in....
Hi Shankar,
PRPC actually stores Date Times in a standarized 'UTC' (~=GMT) times; here's an extract from (version 717) PRPC help page about this :
http[...]/prhelp/procomhelpmain.htm#concepts/concepts2/conceptsdatetime.htm
The internal representations
The internal representations are efficient for sorting and comparisons and Java operations, but may not be familiar to business users:
The internal representation of a Date value is eight digits in the format YYYYMMDD, for example 20061215 for December 15, 2006.
The internal representation of Time of Day value is six digits in the format HHMMSS, where the hours portion ranges from 00 to 23. For example, 153025 represents 25 seconds after 3:15 P.M.
For DateTime values, the internal representation has the format MM dd yyyy hh:mm:ss a GMT where GMT are literal characters, MM represents a month, dd is a day, yyyy is a year, hh is an hour value between 00 to 23, mm is a minute value between 00 and 59, ss is a second value between 00 and 59, and a is the a.m./p.m. marker. (The pattern character Z — for Zulu time — sometimes appears rather than the time zone characters GMT in some descriptions. The value always contains a space followed by the three letters GMT.)
And also note that PRPC OPERATOR records also allow you to specify which Timezone an Operator usually works 'out of': so broadly - PRPC doesn't care which Time Zone the Application Server is running in....
But I would still advise caution here I'm not sure that moving an (Production?) Application Server from one Time Zone to another is a particular common thing to do: and because of that I would say that there aren't many people have direct experience of what kinds of things could bite you here....
I would advise that an empircal approach should be taken here: taking a copy of the Production System and running through the procedure of changing the Time Zone of the App Server on a test system....
I don't know if anybody else could chip-in here - anybody got any direct experience of doing this ?
Cheers
John
One last note: in a certain limited sense - ALL PRPC systems DO have their Timezones changed - due to Daylight Savings kicking in....this can cause odd problems sometimes (Especially with Agent Scheduling) - but as far as I can remember these are usually 'in-flight' type problems (stuff scheduled to occur; and the sudden change of timezone (from BST->GMT for example) of the App Server confuses the Agent Scheduling - that sort of thing)...
JP Morgan Chase
US
what is the timezone of your database servers? and have you used any RDB- queries with SYSDATE,SYSTIMESTAMP etc in your app to store the current date time values
JP Morgan Chase
IN
Hi Pavan ,
Right now all the time zones are in sync the DB and App server are in PST time zone and we are planning to move it to GMT time zone.
Pegasystems Inc.
US
just want to point out that Pega requires all timezones (db, app server, os) to be the same and in sync (quote from installation guide, e.g., https://pdn.pega.com/documents/pega-719-platform-installation-guide-for-ibm-db2-for-linux-unix-and-windows-on-websphere-…
Configure time zone, character encoding and locales Configure your database server, application server, and the system on which you are running the installation to use the same: l Time zone l Character encoding (UNICODE or EBCDIC) l Regional settings/locale
Also read this article: https://pdn.pega.com/system-operations/how-to-synchronize-server-clocks-and-database-clocks-with-ntp-for-correct-service…
JP Morgan Chase
IN
Hi Kevin,
Right now all the time zones are in sync the DB and App server are in PST time zone and we are planning to move it to GMT time zone.As long as it takes the value from the BLOB there shouldnt be any problem and my only work is about the SLA execution ,if we have some internal queries where they take the value directly from a database column which i assume might cause an issue.
Thanks
Dinesh