Hi Fred, Thanks very much for your reply. I should have replied to you sooner when you first mentioned your success by setting your clock to non-UTC. I did try that and it didn't resolve the problem.
One additional piece of information that should be a clue to someone is that we see exactly the same behavior when the queries are run against a Mid-tier server running on Solaris. That Mid-tier is actually running on the same real hardware as the AR server. So that sort of eliminates the whole Linux-VM question altogether. We are testing using SoapUI. Still hoping to find someone in the EDT timezone who can confirm what I am seeing. Thanks again. Larry On Tue, Jun 12, 2012 at 2:48 PM, Grooms, Frederick W < [email protected]> wrote: > We had the same sort of problem with our webservice calls. The problem we > found was the physical clock and the clock in the Virtual Linux session > were set differently. We had to set our clock to not be UTC in the RedHat > server, and the problem went away. > > Here is a page that describes it better: > http://tldp.org/HOWTO/TimePrecision-HOWTO/set.html > > Fred > > -----Original Message----- > From: Action Request System discussion list(ARSList) [mailto: > [email protected]] On Behalf Of L G Robinson > Sent: Monday, June 11, 2012 8:25 AM > To: [email protected] > Subject: Re: Webservices and Queries > > ** > Hi Folks, > > I could use some help from the community to verify that the information I > am receiving from BMC support is correct. The issue has to do with queries > issued through a web service running against an ARS form. Specifically, the > query includes a clause like this: > > <urn:qualification>'datemodified' >= "05/30/2012 > 20:00:00"</urn:qualification> > > compared to a query like this: > > <urn:qualification>'datemodified' >= "05/30/2012 20:00:00 > EDT"</urn:qualification> > > The AR server, Mid-tier server and the client are all operating in the US > Eastern time zone with their date/times set to local time. My contention is > that these two queries should produce the same result. However, in my > system, they do not. The query containing the explicit specification of the > timezone (EDT) produces the correct result. The other does not. > > It should be noted that the query which does not include the timezone > information DID produce the correct result prior to the onset of DST in the > US. Unfortunately, I can not say what would have been returned before the > onset of DST if "EST" had been included in the query since we were not in > the habit of specifying time zone information until this problem was > discovered. > > I am looking for someone who has a similar environment and is willing to > run a test for me to see if you get the expected results on you system. > Ideally, I would like to see the results from a client/server/Mid-tier > combination in the Eastern time zone of the US operating under DST. The > other specifics of my system as listed below. > > The following is BMC support explanation of why the results I am seeing > are the expected behavior: > > The below is a confirmation from R&D about the statements I've provided > you with earlier: > "You have to specify a timezone, otherwise there's no way for arserver to > know what time you mean by 05/30/2012 10:00:00. MT and the Java API just > pass the query through as a string, they don't try to interperate what that > date/time value represents as far as timezone is concerned." > > Thanks for any assistance you can provide. > Larry > > Configuration: > > AR Server 7.6.03 Patch 002 201107191530 on Solaris 10 > Oracle 11.2.0.2.0 - 64bit on Solaris 10 > Mid-tier: > Server: 7.6.04 SP2 Hotfix 121511 > Tomcat: Apache Tomcat/6.0.32 > OS: Linux > JAVA: 1.7.0_02 > > > Larry Robinson > Remedy Developer/Administrator > NC State University > > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
