I think a lot of it comes down to the fact that the original designer is using TR.DateField, if they could just use DateField and do the comparison on the client-side via an active link I think the time zone problem goes away entirely without having to use a workaround. Since the date displayed/selected in the form and the evaluated value of $DATE$ on the client will both be in the client's time zone I think that would take care of it nicely.
-Rick From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Rod Harris Sent: Wednesday, November 28, 2012 8:48 AM To: arslist@ARSLIST.ORG Subject: Re: Problem comparing date/time field to $DATE$ in a filter ** Yes LJ, a date field doesn't worry about timezones so would solve Rick's problem for sure. The main issue I had with it is that the control is not as user friendly as a date only datetime control. The need to be able to specify BC is not normally useful and having to type in or use a drop down rather than a calendar control is also not ideal. For me I added about 12 hours to everyone's "date only" input before doing the DATE translation just so that everyone in Australia and surrounding areas was on the same day. I guess it works for us but if you need to support people across a more than 12 hour spread of timezones you would want something more robust. Rod On 29 November 2012 00:36, Longwing, LJ CTR MDA/IC <lj.longwing....@mda.mil> wrote: Another thing you may be able to do...if the only reason for this field is to compare this stuff, and should always be today's date, you may try replacing it with an actual date field instead of a date/time....they don't suffer from the same timezone problems that sometimes plague date/time set to display date only. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Westbrock Sent: Wednesday, November 28, 2012 9:16 AM To: arslist@ARSLIST.ORG Subject: Re: Problem comparing date/time field to $DATE$ in a filter 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" ____________________________________________________________________________ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" _attend WWRUG12 www.wwrug.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"
