I was just about to submit an Idea on BMC Communities to change the UI of the Date field. Just for fun I thought I would check in Mid Tier to make sure it behaves the same as WUT and what do you know it displays as a calendar. Since WUT is no longer shipped I guess the issue is as resolved as it is going to get.
[image: Inline image 1] I too stopped using Date fields because users always complained about them. I guess I can start using them again! Jason On Wed, Nov 28, 2012 at 8:47 AM, Rod Harris <[email protected]> wrote: > ** 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"_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
<<image.png>>
