Multiple Time Zone!
Hi All, Multiple Time Zone! We have remedy server located in Australia. Currently our business is planning to use the same instance for New Zealand. Our requirements is to have different time setting so that system automatically calculates the times as per the zones. I tried the user preferences available in remedy. I created user profiles like locale as NZ AU. It worked and showed the times as NZ time zone n AUS time zone. But still not met our business requirements because those date calculations are used by other third party applications but still those date n times are still as Australian time. ARS 7.1 SQL 2005 Please help me out guys! Karthi -- *Thanks and Regards,* *Karthick S* ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Multiple Time Zone!
Actually, all times in the server are stored in GMT. The timestamp values are number of seconds since Jan 1, 1970 GMT. Regardless of the timezone you specify or enter the value in, the value that the AR System stores and returns is in GMT. It is the client responsibility to map it to the desired timezone. This is why setting the User Preference for timezone works just time. The clients translate to the correct target timezone – whether it is Australia or New Zeland (or Timbuktu). Now, you client programs are probably just using system environment settings and using the timezone of the OS environment in which they are running. They are using system utilities which automatically adjust the time for the environment timezone. If they were not doing this, then all times would have always being in GMT anyway. So, if you set the environment to say the US Pacific Timezone, you would likely find all your utilities would suddenly be doing all operations in PST – accurately in that timezone, automatically. Again, because the server has all values in GMT and you are using system routines that are automatically adjusting. To fix this, you need to look at the operations being done and determine whether they should be performed in GMT (and then configure that in your calls) or in some other timezone (and configure that in your calls). Stop just accepting the system environment default. NOTE: This includes calls by OS time calculate functions! I hope this helps, Doug Mueller From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Brian Goralczyk Sent: Monday, June 29, 2015 11:24 AM To: arslist@ARSLIST.ORG Subject: Re: Multiple Time Zone! ** Unless things have changed since I worked heavily on date and time functions in Remedy (including at the db level), they are all stored at the setting of the server. The client is then responsible for adjusting to the local timezome. The third party systems will be responsible for figuring out their timezone and adjusting the server time accordingly. HTH. Brian Goralczyk Phone 574-643-1144 Email bgoralc...@gmail.commailto:bgoralc...@gmail.com On Mon, Jun 29, 2015 at 7:38 AM, Karthick S karthick...@gmail.commailto:karthick...@gmail.com wrote: ** Hi All, Multiple Time Zone! We have remedy server located in Australia. Currently our business is planning to use the same instance for New Zealand. Our requirements is to have different time setting so that system automatically calculates the times as per the zones. I tried the user preferences available in remedy. I created user profiles like locale as NZ AU. It worked and showed the times as NZ time zone n AUS time zone. But still not met our business requirements because those date calculations are used by other third party applications but still those date n times are still as Australian time. ARS 7.1 SQL 2005 Please help me out guys! Karthi -- Thanks and Regards, Karthick S _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Multiple Time Zone!
I stand corrected. I know that I created stored procedures in oracle that calculated DST and timezone calculations, but that was back in the day of Remedy Web and User Tool. So things were a bit more funky for these calculations back then. Brian Goralczyk Phone 574-643-1144 Email bgoralc...@gmail.com On Mon, Jun 29, 2015 at 2:55 PM, Mueller, Doug doug_muel...@bmc.com wrote: ** Actually, all times in the server are stored in GMT. The timestamp values are number of seconds since Jan 1, 1970 GMT. Regardless of the timezone you specify or enter the value in, the value that the AR System stores and returns is in GMT. It is the client responsibility to map it to the desired timezone. This is why setting the User Preference for timezone works just time. The clients translate to the correct target timezone – whether it is Australia or New Zeland (or Timbuktu). Now, you client programs are probably just using system environment settings and using the timezone of the OS environment in which they are running. They are using system utilities which automatically adjust the time for the environment timezone. If they were not doing this, then all times would have always being in GMT anyway. So, if you set the environment to say the US Pacific Timezone, you would likely find all your utilities would suddenly be doing all operations in PST – accurately in that timezone, automatically. Again, because the server has all values in GMT and you are using system routines that are automatically adjusting. To fix this, you need to look at the operations being done and determine whether they should be performed in GMT (and then configure that in your calls) or in some other timezone (and configure that in your calls). Stop just accepting the system environment default. NOTE: This includes calls by OS time calculate functions! I hope this helps, Doug Mueller *From:* Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG] *On Behalf Of *Brian Goralczyk *Sent:* Monday, June 29, 2015 11:24 AM *To:* arslist@ARSLIST.ORG *Subject:* Re: Multiple Time Zone! ** Unless things have changed since I worked heavily on date and time functions in Remedy (including at the db level), they are all stored at the setting of the server. The client is then responsible for adjusting to the local timezome. The third party systems will be responsible for figuring out their timezone and adjusting the server time accordingly. HTH. Brian Goralczyk Phone 574-643-1144 Email bgoralc...@gmail.com On Mon, Jun 29, 2015 at 7:38 AM, Karthick S karthick...@gmail.com wrote: ** Hi All, Multiple Time Zone! We have remedy server located in Australia. Currently our business is planning to use the same instance for New Zealand. Our requirements is to have different time setting so that system automatically calculates the times as per the zones. I tried the user preferences available in remedy. I created user profiles like locale as NZ AU. It worked and showed the times as NZ time zone n AUS time zone. But still not met our business requirements because those date calculations are used by other third party applications but still those date n times are still as Australian time. ARS 7.1 SQL 2005 Please help me out guys! Karthi -- *Thanks and Regards,* *Karthick S* _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Multiple Time Zone!
Unless things have changed since I worked heavily on date and time functions in Remedy (including at the db level), they are all stored at the setting of the server. The client is then responsible for adjusting to the local timezome. The third party systems will be responsible for figuring out their timezone and adjusting the server time accordingly. HTH. Brian Goralczyk Phone 574-643-1144 Email bgoralc...@gmail.com On Mon, Jun 29, 2015 at 7:38 AM, Karthick S karthick...@gmail.com wrote: ** Hi All, Multiple Time Zone! We have remedy server located in Australia. Currently our business is planning to use the same instance for New Zealand. Our requirements is to have different time setting so that system automatically calculates the times as per the zones. I tried the user preferences available in remedy. I created user profiles like locale as NZ AU. It worked and showed the times as NZ time zone n AUS time zone. But still not met our business requirements because those date calculations are used by other third party applications but still those date n times are still as Australian time. ARS 7.1 SQL 2005 Please help me out guys! Karthi -- *Thanks and Regards,* *Karthick S* _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Multiple Time Zone!
Hello All, I'm Still Confused. I gone through the Configuration Guide Document and Found that we can use time zone concept in Business Time Segment form. Here are the below code used in our Remedy system that calculated the Early Start Due Date , this code works well for Australian Time. Early Start = $PROCESS$ @@: Application-Bus-Time-Add $Int_CurrentDate Time$ 0 2, Which Gives Current Time Stamp from Server. Due Date = $PROCESS$ @@: Application-Bus-Time-Add $Int_CurrentDate Time$ 240 2, Which Gives Current Time Stamp + 240 mins. So Due Date is 4 hrs In the Configuration Guide i found that by create Business Time Segments. *Application-Bus-Time2-Add startTime amount amountUnits* *TimeSegment1 TimeSegment2 TimeSegment3 TimeSegment4* I created One and Tried executing the command like $PROCESS$ @@: Application-Bus-Time2-Add $Int_CurrentDate Time$ $Response (min)$ 2 $TimeSegmentID$ It gives the result as 01/01/1970 11:00:00 AM [image: Inline image 1] Please correct me if I'm doing it wrong or is there some more corrections needs to be done in the above Business Time Segment form. On Tue, Jun 30, 2015 at 5:20 AM, Brian Goralczyk bgoralc...@gmail.com wrote: ** I stand corrected. I know that I created stored procedures in oracle that calculated DST and timezone calculations, but that was back in the day of Remedy Web and User Tool. So things were a bit more funky for these calculations back then. Brian Goralczyk Phone 574-643-1144 Email bgoralc...@gmail.com On Mon, Jun 29, 2015 at 2:55 PM, Mueller, Doug doug_muel...@bmc.com wrote: ** Actually, all times in the server are stored in GMT. The timestamp values are number of seconds since Jan 1, 1970 GMT. Regardless of the timezone you specify or enter the value in, the value that the AR System stores and returns is in GMT. It is the client responsibility to map it to the desired timezone. This is why setting the User Preference for timezone works just time. The clients translate to the correct target timezone – whether it is Australia or New Zeland (or Timbuktu). Now, you client programs are probably just using system environment settings and using the timezone of the OS environment in which they are running. They are using system utilities which automatically adjust the time for the environment timezone. If they were not doing this, then all times would have always being in GMT anyway. So, if you set the environment to say the US Pacific Timezone, you would likely find all your utilities would suddenly be doing all operations in PST – accurately in that timezone, automatically. Again, because the server has all values in GMT and you are using system routines that are automatically adjusting. To fix this, you need to look at the operations being done and determine whether they should be performed in GMT (and then configure that in your calls) or in some other timezone (and configure that in your calls). Stop just accepting the system environment default. NOTE: This includes calls by OS time calculate functions! I hope this helps, Doug Mueller *From:* Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG] *On Behalf Of *Brian Goralczyk *Sent:* Monday, June 29, 2015 11:24 AM *To:* arslist@ARSLIST.ORG *Subject:* Re: Multiple Time Zone! ** Unless things have changed since I worked heavily on date and time functions in Remedy (including at the db level), they are all stored at the setting of the server. The client is then responsible for adjusting to the local timezome. The third party systems will be responsible for figuring out their timezone and adjusting the server time accordingly. HTH. Brian Goralczyk Phone 574-643-1144 Email bgoralc...@gmail.com On Mon, Jun 29, 2015 at 7:38 AM, Karthick S karthick...@gmail.com wrote: ** Hi All, Multiple Time Zone! We have remedy server located in Australia. Currently our business is planning to use the same instance for New Zealand. Our requirements is to have different time setting so that system automatically calculates the times as per the zones. I tried the user preferences available in remedy. I created user profiles like locale as NZ AU. It worked and showed the times as NZ time zone n AUS time zone. But still not met our business requirements because those date calculations are used by other third party applications but still those date n times are still as Australian time. ARS 7.1 SQL 2005 Please help me out guys! Karthi -- *Thanks and Regards,* *Karthick S* _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ -- *Thanks and Regards,* *Karthick S
Re: Multiple Time Zone!
Hi Karthick, Could b issue with start date n end date being same as per below screenshot. Can you put end date something as in July 2015 or 2016 n again try to execute and check the result. Thnks. Regards munesh -Original Message- From: Karthick S karthick...@gmail.com Sent: 30-06-2015 08:25 AM To: arslist@ARSLIST.ORG arslist@ARSLIST.ORG Subject: Re: Multiple Time Zone! ** Hello All, I'm Still Confused. I gone through the Configuration Guide Document and Found that we can use time zone concept in Business Time Segment form. Here are the below code used in our Remedy system that calculated the Early Start Due Date , this code works well for Australian Time. Early Start = $PROCESS$ @@: Application-Bus-Time-Add $Int_CurrentDate Time$ 0 2, Which Gives Current Time Stamp from Server. Due Date = $PROCESS$ @@: Application-Bus-Time-Add $Int_CurrentDate Time$ 240 2, Which Gives Current Time Stamp + 240 mins. So Due Date is 4 hrs In the Configuration Guide i found that by create Business Time Segments. Application-Bus-Time2-Add startTime amount amountUnits TimeSegment1 TimeSegment2 TimeSegment3 TimeSegment4 I created One and Tried executing the command like $PROCESS$ @@: Application-Bus-Time2-Add $Int_CurrentDate Time$ $Response (min)$ 2 $TimeSegmentID$ It gives the result as 01/01/1970 11:00:00 AM Please correct me if I'm doing it wrong or is there some more corrections needs to be done in the above Business Time Segment form. On Tue, Jun 30, 2015 at 5:20 AM, Brian Goralczyk bgoralc...@gmail.com wrote: ** I stand corrected. I know that I created stored procedures in oracle that calculated DST and timezone calculations, but that was back in the day of Remedy Web and User Tool. So things were a bit more funky for these calculations back then. Brian Goralczyk Phone 574-643-1144 Email bgoralc...@gmail.com On Mon, Jun 29, 2015 at 2:55 PM, Mueller, Doug doug_muel...@bmc.com wrote: ** Actually, all times in the server are stored in GMT. The timestamp values are number of seconds since Jan 1, 1970 GMT. Regardless of the timezone you specify or enter the value in, the value that the AR System stores and returns is in GMT. It is the client responsibility to map it to the desired timezone. This is why setting the User Preference for timezone works just time. The clients translate to the correct target timezone – whether it is Australia or New Zeland (or Timbuktu). Now, you client programs are probably just using system environment settings and using the timezone of the OS environment in which they are running. They are using system utilities which automatically adjust the time for the environment timezone. If they were not doing this, then all times would have always being in GMT anyway. So, if you set the environment to say the US Pacific Timezone, you would likely find all your utilities would suddenly be doing all operations in PST – accurately in that timezone, automatically. Again, because the server has all values in GMT and you are using system routines that are automatically adjusting. To fix this, you need to look at the operations being done and determine whether they should be performed in GMT (and then configure that in your calls) or in some other timezone (and configure that in your calls). Stop just accepting the system environment default. NOTE: This includes calls by OS time calculate functions! I hope this helps, Doug Mueller From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Brian Goralczyk Sent: Monday, June 29, 2015 11:24 AM To: arslist@ARSLIST.ORG Subject: Re: Multiple Time Zone! ** Unless things have changed since I worked heavily on date and time functions in Remedy (including at the db level), they are all stored at the setting of the server. The client is then responsible for adjusting to the local timezome. The third party systems will be responsible for figuring out their timezone and adjusting the server time accordingly. HTH. Brian Goralczyk Phone 574-643-1144 Email bgoralc...@gmail.com On Mon, Jun 29, 2015 at 7:38 AM, Karthick S karthick...@gmail.com wrote: ** Hi All, Multiple Time Zone! We have remedy server located in Australia. Currently our business is planning to use the same instance for New Zealand. Our requirements is to have different time setting so that system automatically calculates the times as per the zones. I tried the user preferences available in remedy. I created user profiles like locale as NZ AU. It worked and showed the times as NZ time zone n AUS time zone. But still not met our business requirements because those date calculations are used by other third party applications but still those date n times are still as Australian time. ARS 7.1 SQL 2005 Please help me out guys! Karthi -- Thanks and Regards, Karthick S _ARSlist: Where the Answers Are and have been for 20
