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)...

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.

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