Rick, I agree with Rod, I would recommend changing your AL to use $SERVERTIMESTAMP$ instead of $DATE$ for setting of the value, it would eliminate all 'client' discussions regarding date/time.
-----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Rick Westbrock Sent: Tuesday, November 27, 2012 5:05 PM To: [email protected] Subject: Problem comparing date/time field to $DATE$ in a filter Hello all- I have got a real brain burner on my hands with a filter in a custom application that we are hosting. This filter has as part of its qualification the following clause: ('TR.DateField' != $DATE$) where DateField is a date/time field set to display date-only. This filter had been working fine for a long time when the Remedy server and all users were in the EST time zone. If the qualification passed it threw an error at the user advising that they needed to enter the current date into the DateField field. However once the application was hosted on our server in the PST time zone (three hours behind EST) suddenly the users were getting the error message when they shouldn't. The value in DateField is actually set via an Active Link (named SetFields) which pushes $TIMESTAMP$ and I validated via active link logging in my browser that it's setting only the date (no time) as follows where field 536870925 is the DateTime field in question and 536871091 is a different date/time field that is set to display both date and time: ActiveLink: SetFields - Tue Nov 27 2012 3:12:27 PM True actions: True action: {time}:F(536870925).S({time}expr:({char}keyword:$TIMESTAMP$)){time}:F(536871 091).S({time}expr:({char}keyword:$TIMESTAMP$)){time}:F(536871200).S({time}ex pr:({char}keyword:$TIMESTAMP$)){long}:F(536871219).S({long}expr:({long}goatt ype:EnumType 6 5 5)); action 0 Set-fields 536870925 = 11/27/2012 Set-fields 536871091 = 11/27/2012 6:12:27 PM Here's the rub: if I change the affected users to have PST as the Time Zone in their User Preference record they do not get the error, however if the time zone is null or EST they do get the error. I tried changing the qualification to use the value of DateField instead of the transaction value but that made no difference. I used all of the logs (including API and SQL) and nowhere does it show me how it is evaluating that qualification clause, it just shows pass or fail. If anyone has any ideas on how to make this work proprerly (besides setting the East coast users to PST in their preferences which is just a stopgap) I would be grateful. I know that $DATE$ is evaluated on the server since it's in a filter but it shouldn't matter which time zone a user is in because the date part of that field should be the same (except possibly between midnight and 3am EST if the filter is using the client value). Thanks, Rick ___________________________ Rick Westbrock QMX Support Services _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
