Hi Rick,
All date times whether or not they are set to display as a date only or not
are stored and evaluated as the number of seconds since midnight 1/1/1970
UTC.
Active links use the datetime of the client when evaluating the $DATE$
keyword and set it to midnight local time of the current day. (In your case
this could be say 9pm the previous day for the server's time). Filters run
on the server and use midnight on the server's date. Hence in your case
moving the server's timezone away form the client's has caused your
comparison to fail.
So what may be happening in your case is that the user has entered
midnight. In the servers time this is the previous day to the client's time
so the compare fails. For the comparison maybe what you could do is to
always add a number of hours to the date entered by the user after entry
but before the comparison. This way they should both be in the same date.
There is a $SERVERTIMESTAMP$ keyword you could use to figure out the
optimal amount to add to get the time to be midnight server time.
Hope this makes sense. Timezones can be a bit tricky.
Here in Perth, Western Australia we have a bit of experience dealing with
servers that are 2 or 3 hours ahead of us. In fact in many versions of
Remedy the supplied timezone for us is incorrect by an hour and we need to
use Singapore time.
Rod
On 28 November 2012 08:05, Rick Westbrock <rwestbr...@qmxs.com> wrote:
> 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"
