As you are working with Filters the time zone will not be an issue (as you are processing the keyword on the server in both cases)
I only noticed it when I had a form with a lot of Filters that took a while to process Fred -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Westbrock Sent: Thursday, June 13, 2013 11:17 AM To: arslist@ARSLIST.ORG Subject: Re: Create Date later than $TIMESTAMP$ from filters ** Interesting! I will have to give that a try. The problem doesn't happen to all first-call resolution tickets but I don't know what percentage of them have this problem so it might take a while to replicate in the test environment. I am not sure if that would cause problems if the user is in a different time zone than the server; the only reason I mention that is we had resolved a totally unrelated issue by switching keywords like that due to the time zone difference. -Rick ___________________________ Rick Westbrock QMX Support Services -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W Sent: Wednesday, June 12, 2013 20:28 PM To: arslist@ARSLIST.ORG Subject: Re: Create Date later than $TIMESTAMP$ from filters ** One thing I have seen is $TIMESTAMP$ is only set at the beginning of the filter cycle. If you want the real time inside a filter you need to use $SERVERTIMESTAMP$ Fred From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Westbrock Sent: Wednesday, June 12, 2013 3:57 PM To: arslist@ARSLIST.ORG Subject: Create Date later than $TIMESTAMP$ from filters ** In light of the other thread about Create Date vice Modified Date I ran into something along similar lines today an wondered if anyone else has seen something similar. We have a set of filters that put $TIMESTAMP$ into date/time fields, one per status value (i.e. if there are five different status values there will be five date/time fields). The qualifications on the filters are such that if the status changes to that value (i.e. if ticket changes to status value 2 then the Status 2 Date/Time field is used) and sets $TIMESTAMP$ into the corresponding date/time field. The strange behavior that I am seeing is that these status date/time values are all exactly one second older than the value in the core Create Date field. My assumption is that $TIMESTAMP$ is evaluated during the filter processing but the Create Date field is not populated by the server until probably the very instant before the record is actually committed to the database; if filter processing takes too long then the clock might tick over into the next second. Has anyone else run into this dilemma? It is only a problem for me because in reporting any tickets that have say the Work In Progress date/time less than the Create Date field then it is out of compliance and we have to massage the data for multiple tickets after the fact. In a recent check I found that there were 796 records where the status date/time fields were less than the Create Date but only four of them were more than one second older (obviously due to unrelated issues). The obvious quick & dirty fix for this (which may not be optimal) is to modify the filters to set the status date/time fields to $TIMESTAMP$ + 1 so that they either match the Create Date or might possibly be one second later but I wanted to investigate the root cause before touching any existing code. -Rick ARS 7.6.04 SP2/Windows/MS-SQL ___________________________ Rick Westbrock QMX Support Services _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
