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"
