Although if you are validating a business rule you do not want that functionality to reside only in the client. It is appropriate as a filter if it is enforcing a rule. Maybe you have an AL to catch it in the UIbecause it is friendlier and a filter to back it up in case the UI rule ever gets bypassed.
Jason On Wed, Nov 28, 2012 at 9:07 AM, Rick Westbrock <[email protected]> wrote: > ** > > 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: > [email protected]] *On Behalf Of *Rod Harris > *Sent:* Wednesday, November 28, 2012 8:48 AM > > *To:* [email protected] > *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 < > [email protected]> 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: > [email protected]] On Behalf Of Rick Westbrock**** > > Sent: Wednesday, November 28, 2012 9:16 AM > To: [email protected] > 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: > [email protected]] On Behalf Of Longwing, LJ CTR MDA/IC > Sent: Wednesday, November 28, 2012 5:36 AM > To: [email protected] > 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: > [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" > > > _______________________________________________________________________________ > 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"_ **** > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
