Thanks for the explanation Rod, I had it in my head that both values were using the server's UTC value and didn't realize that it was translating the user's value from their time zone to UTC. I think that the customer needs to explain the business reason for this filter so that we can just design workflow from scratch to accomplish their objective. I didn't understand why the error message would tell the user to enter the current date instead of just setting the value automatically for them but then again I haven't been able to discuss the business rules with the customer yet.
LJ, this is being done in a filter and not an active link since they are comparing the transaction value of the date/time field to $DATE$; again I don't know why they are not just using the value of the field in an active link instead. It can definitely be challenging to inherit a custom application and understand why certain workflow was written the way it was. Thanks, Rick -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Longwing, LJ CTR MDA/IC Sent: Wednesday, November 28, 2012 5:36 AM To: arslist@ARSLIST.ORG Subject: Re: Problem comparing date/time field to $DATE$ in a filter 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:arslist@ARSLIST.ORG] On Behalf Of Rick Westbrock Sent: Tuesday, November 27, 2012 5:05 PM To: arslist@ARSLIST.ORG 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" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
