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"
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
