TZ is an OS environment variable that can be set at the operating system level (e.g. SET TZ=PST8PDST), on the WUT through the locale tab in "Options", or through a preference server. TZ stands for "Time Zone".
If it is set on your server, it most likely would have been done consciously prior to starting up the AR System server functions. It is more commonly set on clients. Thanks, -David J. Easter Sr. Product Manager, Service Management Business Unit BMC Software, Inc. The opinions, statements, and/or suggested courses of action expressed in this E-mail do not necessarily reflect those of BMC Software, Inc. My voluntary participation in this forum is not intended to convey a role as a spokesperson, liaison or public relations representative for BMC Software, Inc. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Whilden, Mark D. Sent: Tuesday, April 03, 2007 7:45 PM To: [email protected] Subject: Re: ARS Report Creator's time problem on queries David, Thanks for the feedback. Yes we are on 6.3. Can you help me with the TZ setting. Is this a client or server setting? Also is this an ar.conf setting (if on server)? If on client, is it the OS timezone? When I get into the Office tomorrow, I can check this out. Mark Whilden MITRE Corp -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Easter, David Sent: Tuesday, April 03, 2007 12:46 PM To: [email protected] Subject: Re: ARS Report Creator's time problem on queries Hi Mark, If you're on AR System 6.3, you might have hit bug #SW00262260: "Timezone names greater the 15 characters are truncated in JNI causing incorrect epoch timestamp value to be returned when time value is used in query." If you use the TZ setting, and the TZ itself is greater than 15 characters (and "America/New_York" is 16 characters), then the API call doesn't process properly and the TZ defaults to GMT. Possible solutions would be to either use a TZ that is 15 characters or less (e.g. "America/Bogota" works - and it is also GMT -5 hours), or to upgrade your Mid-Tier to AR System 7.0.01 where the API has been corrected. Might not be the problem, but the symptoms sound similar. I'd check if the problem also exists with other TZ's that are less than 15 characters to see if this is indeed the issue. Also, you'd need to confirm that you're on AR System 6.3, of course. Thanks, -David J. Easter Sr. Product Manager, Service Management Business Unit BMC Software, Inc. The opinions, statements, and/or suggested courses of action expressed in this E-mail do not necessarily reflect those of BMC Software, Inc. My voluntary participation in this forum is not intended to convey a role as a spokesperson, liaison or public relations representative for BMC Software, Inc. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Whilden, Mark D. Sent: Tuesday, April 03, 2007 8:42 AM To: [email protected] Subject: ARS Report Creator's time problem on queries Listers, After we applied the Daylight Saving time patches, we started to pay more attention to time zone issues. Note, I don't think the DST patch caused this, but caused us to look into time fields more closely. We found that for report run from Report Creator form, any queries against date fields weren't adjusted for difference between our zone (EST) and GMT. The Report Creator form is used for running Crystal Reports within ARS, or running ARS reports and Crystal Reports thru the MidTier. Whither we ran Crystal Reports or ARS reports from the web, or Crystal Reports from the client; we got the same results. If I ran the same query in User tool the query ran correctly. All the tools display the dates correctly in the reports or on the forms. To investigate this, I turned on SQL logging and repeated the same queries from the Report Creator and from User search. The Select statements vary within the where clause in the constant used against the date column. The difference is 14400 seconds or 4 hours. That is the difference between us and GMT. Our systems people are looking into time zone on the server, but I am doubtful this is the problem. However, I don't have a good culprit to pursue. Anyone seen this before or have a clue as to where to look to resolve this. Mark Whilden MITRE Corp [EMAIL PROTECTED] (571)252-4023 _______________________________________________________________________ _ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" _______________________________________________________________________ ________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
