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 On Mon, Apr 30, 2012 at 4:19 PM, L G Robinson <[email protected]> wrote: > Hi Folks, > > Sorry to be late to this party... I have an open issue with ColumnIT > regarding DST and web services. From my observation, it appears that the > web service assumes EST instead of EDT if no timezone information is > present in the query (I'm in NC). Here is a more complete description of my > issue: > > > We have discovered a problem with our Mid-tier servers, possibly related > to the onset of Daylight Saving Time. > > We have implemented several web service calls, some of which accept > arbitrary queries. If a query includes a date/time component, the returned > results are not correct. For example: > > <urn:qualification>'datemodified' >= "03/30/2012 > 10:00:00"</urn:qualification> > > does not return any results, even though there are records which match the > specified criteria. However, if the query is changed to: > > <urn:qualification>'datemodified' >= "03/30/2012 10:00:00 > EDT"</urn:qualification> > > then the expected results are returned. > > This problem only presents with the web service calls. Similar queries > made to the same server using the Windows User tool and through the > Mid-tier web interface all return the expected results without having to > append the "EDT" to the date/time string. > > I have confirmed the system date/time on the Mid-tier server to be correct. > > AR Server 7.6.03 Patch 002 201107191530 > Mid Tier Version: 7.6.04 SP2 Hotfix 121511 > Apache Tomcat/6.0.32 > Java Version: 1.7.0_02-b13 > OS: RH Linux 2.6.32-220.7.1.el6.x86_64 > > Hope this is helpful. > Larry > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
