The base fact (known to be 100% true) is that TIMESTAMP and SERVERTIMESTAMP in a FILTER will always be the same.
I also considered possible timeouts in PROCESS functions, we have ours set to 60 (seconds) because of some external AD processing done at times. Of course there are a lot of 'business time calculations' performed at submit of a ticket as well, which we all know are a "set fields from PROCESS", but even if everything timed out, we would need 60 of these to fail to get to an hour. There are differences of up to 16 hours in these timestamps (system created -create_date- versus our set-fields of TIMESTAMP) so that would be a bunch of timeouts! **GASP** what if the documentation is wrong? Set process timeout is not seconds but MINUTES? **GASP** naw that could not be true :) Also, please remember that we see differences that are "before and after" the create_date. That wonderful warping of "space and time"... Good suggestion about the PROCESS functions though,!! Thanks-n-advance; HDT Platform Incident / Problem Manager & Architect Robert Molenda IT OS PA Tel: +1 408 501 6310 Fax: +1 408 501 2410 Mobile: +1 408 472 8097 [EMAIL PROTECTED] Quality begins with your actions. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black Sent: Thursday, September 28, 2006 7:35 AM To: [email protected] Subject: Re: Server - Timestamp Issues generating random values Robert, I think your expectations are a bit off... First a few general statements. 1) All Date/Time fields in ARS are really "epoch GMT integer values". ( If you do not know what the means, try google, or http://en.wikipedia.org/wiki/Unix_time :) 2) All Date/Time field displayed values in the User Tool UI is localized by the client. So... When an active link "Returns" the SERVERTIMESTAMP then only "drift" you should see between TIMESTAMP and SERVERTIMESTAMP should be the same drift that exists between your client clock and the ARS server clock. If both are set off of the net (AKA Atomic clocks) then the values should be fairly close if not exactly the same. So just for giggle let me walk you through what I think your first test did not test... You defined the test as this: " Active Link: (on button click) > > Char 1 & Date/Time 1 = TIMESTAMP > Char 2 & Date/Time 2 = SERVERTIMESTAMP " When the Client sees TIMESTAMP it grabs the local client PC time (again in "epoch GMT") and uses the Client settings to localize and format the value for the 'Char 1' field. For the 'Date/Time 1' field it simply sets the "epoch GMT" value and lets the field widget do the localization and formatting for the display. When the Client sees SERVERTIMESTAMP it talks to the ARS server and grabs the SERVER time (again in "epoch GMT") and uses the Client settings to localize and format the value for the 'Char 2' field. For the 'Date/Time 2' field it simply sets the "epoch GMT" value and lets the field widget do the localization and formatting for the display. Do you see how the displayed values really should be the same? Now the filter processing time is a bit different so let me walk through a bit of the "black processing box" that I think (AKA: I am guessing) the ARS server goes through: There is a small amount of time that it takes for the client to send the "CreateEntry" API call from client to server. So any client TIMESTAMP in "epoch GMT" value is slightly altered already relative to what the current SERVERTIMESTAMP value is when the API call reaches the server. Sure we are splitting seconds here, but it could be that the network lag is such that this small gap of time spans a demark between one second and the next too. Then the ARS server fixes the value of SERVERTIMESTAMP/TIMESTAMP for the entire filter processing. (Because in truth it takes some time for the server to process each and every filter/action with possible multiple layers of pushs, messages to be queued, data base interactions ect...) So for the life of the filter processing I THINK (again, guessing) that those values are not really a now() type function, but just a reference to a static value set at the beginning of the processing. [ And before you get the idea that this is "BAD", I actually think it almost has to be done this way for performance and for consistency.] However, the System fields values may not be set to this predefined value. It is possible that just before the final commit to the DB that the ARS server does do a second now() function and would show the "lag" in time due to the network/filter processing in the differences between values supplied by the client, beginning of the Filter processing and the actual end of the filter processing time. I hope that helps explain my thinking on the topic. But all in all... I do not see a problem with what you have documented. Just as a point of reference... Some of our submit processing calls $PROCESS$ commands and can delay the submit process to take up to about 30 seconds without failing due to a timeout error. We will routinely see 'Create Date' values that differ from the "timestamp" that is supplied by the client in a different field by what we believe to be about the duration of the $PROCESS$ run time length for that record. (AKA: 10 or more seconds different.) So I am fairly sure that the value that is stuffed into 'Create Date' is set at the last possible instant in the ARS Server and is NOT the TIMESTAMP value that I believe it holds as a constant throughout the Filter processing. ( Yes all of this is very subtle details in the ARS server, but they can be important to understand all the same. To bad we do not have better docs to base our understanding on. But Trial and error, testing, and a few guesses are the best we have at this point. :) HTH. -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap.... Pick two. On 9/27/06, Robert Molenda <[EMAIL PROTECTED]> wrote: > ** > > > My understanding of 'Timestamps' was... (including a quick re-read of the > basic admin pdf which does not say tooooo much about this) > > > > Filters: TIMESTAMP will always equal SERVERTIMESTAMP because it is executing > on the server, and is not aware of the client in any fashion. > > > Active Links: TIMESTAMP = Localized Time at the client where-as > SERVERTIMESTAMP = the server timestamp (not localized) > > > So to ensure I'm not loosing cranium matter, I wrote a small test form with > > Button to trigger an AL > Char 1 - char 255 > Char 2 - char 255 > Date/Time 1 - timestamp > Date/Time 2 - timestamp > Active Link: (on button click) > > Char 1 & Date/Time 1 = TIMESTAMP > Char 2 & Date/Time 2 = SERVERTIMESTAMP > Filter (On Submit) > > Char 1 & Date/Time 1 = TIMESTAMP > Char 2 & Date/Time 2 = SERVERTIMESTAMP > > > > So, since my PC is in the same timezone (PST) with the server, I set it to > Hawaii. > > Active Link sets all timestamps = Hawaii Time! - Including the > SERVERTIMESTAMP!!!! > > ** > > ** I expected a 2 hour difference in the timestamps!!!! > > ** > > Submit sets all timestamps = Server Time > > * As expected > > > > So I adjusted the time by setting it 30 minutes ahead, but still in Hawaii. > > Active Link sets all timestamps = Hawaii Time! - Including the > SERVERTIMESTAMP! But as expected there is the 30 minute difference between > the servertime and pc time. > > ** As expected, but not localized servertimestamp > > Submit sets all timestamps = Server Time > > ** As expected > > > > So enough with playing with the PC Time-zone, so I set it to PST, and then > tweaked the Remedy Time-zone in the client. > > 1). I noticed that oddly enough HAWAII is missing from the selection! Guess > Remedy/BMC does not expect to sell any ARS to customers in HI! > > 2). Results were the same L > > > > So that was a "fun test", however it still does not explain the base issue > that the Create_Date Core field is different than TIMESTAMP! > > > > Thanks for the input!!! > > > Thanks-n-advance; > > HDT Platform Incident / Problem Manager & Architect > Robert Molenda > IT OS PA > Tel: +1 408 501 6310 > Fax: +1 408 501 2410 > Mobile: +1 408 472 8097 > [EMAIL PROTECTED] > > Quality begins with your actions. > > > > ________________________________ > > > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of Joe DeSouza > Sent: Wednesday, September 27, 2006 6:59 AM > > To: [email protected] > Subject: Re: Server - Timestamp Issues generating random values > > > > > > > Also have you tried $SERVERTIMESTAMP$ instead of $TIMESTAMP$ > > > > Joe D'Souza > > > Remedy Developer / Consultant, > > > BearingPoint, > > > Virginia. > > > > > > ----- Original Message ---- > From: Robert Molenda <[EMAIL PROTECTED]> > To: [email protected] > Sent: Tuesday, September 26, 2006 7:27:51 PM > Subject: Re: Server - Timestamp Issues generating random values > > > Good ideas, I thought about those as well, they happen randomly through > the year, as well as randomly during the day. > > The run-if on the filter has "no qualification" so it "always runs" on > Submit, regardless if the field is empty or not. > > We also have a act link on copy to new which nukes a bunch of fields we > do not want carried forward, and this is in the list as well. > > Thanks-n-advance; > HDT Platform Incident / Problem Manager & Architect > Robert Molenda > IT OS PA > Tel: +1 408 501 6310 > Fax: +1 408 501 2410 > Mobile: +1 408 472 8097 > [EMAIL PROTECTED] > Quality begins with your actions. > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of Grooms, Frederick W > Sent: Tuesday, September 26, 2006 3:07 PM > To: [email protected] > Subject: Re: Server - Timestamp Issues generating random values > > 2 things come to mind > > 1. Are these records right around a Daylight Savings Time / Standard > Time change? > 2. Could they be related to some Copy to New functionality? > > #1 would give you values in both directions depending on Spring/Fall. > > Fred > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of Robert Molenda > Sent: Tuesday, September 26, 2006 4:47 PM > To: [email protected] > Subject: Server - Timestamp Issues generating random values > > I am wondering if someone else has stumbled across this issue. > > On a form, we created a "Create Date Copy" field and on Submit (no > run-if) a Filter will simply do a "Set Fields = $TIMESTAMP$" to this > field. This was done as a test to see how long the filters took to run, > and was never removed :-( > > As you might expect, normally there is only a 0 or 1 second difference > between the core field and this copy. > > However since 2003 (that would be ARS 4.5) through today (and we're on > 6.3, with 5.1.2 in between) intermittently, this "Create Date Copy" > value will differ by HOURS. The majority of time in the past (Create > Date Copy < Create Date) but also a few in the future (Create Date Copy > > Create Date) > > They are always HOURS (plus or minus one second, but that is close > enough for me to say hour) and never anything else odd. (like 30 > minutes, etc) > > Over the years we only have 252 entries that have this condition out of > 966538 tickets, but it is very confusing. > > Thansk > > Thanks-n-advance; > > HDT Platform Incident / Problem Manager & Architect Robert Molenda IT OS > PA > Tel: +1 408 501 6310 > Fax: +1 408 501 2410 > Mobile: +1 408 472 8097 > [EMAIL PROTECTED] > > Quality begins with your actions. > > ****VISIT US AT: www.infineon.com <http://www.infineon.com/> ***** > > "This e-mail and any attachments are confidential and may be subject to > legal or some other professional privilege. They are intended solely for > the attention and use of the named addressee(s). If you are not the > named addressee(s) you must not use, disclose, retain or reproduce all > or any part of the information contained in this e-mail or any > attachments. Any unauthorised use or disclosure may be unlawful. If you > have received this e-mail by mistake, please inform the sender > immediately and delete it and all copies from your system and destroy > any hard copies of it." > > ________________________________________________________________________ > _______ > UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org > > ________________________________________________________________________ _______ > UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org > > > > __20060125_______________________This posting was > submitted with HTML in it___ > __20060125_______________________This posting was submitted > with HTML in it___ ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
