Adjusting the timestamp

Transactions are monitored using the UTC (also known as GMT) time of a machine. UTC time is the time on a machine before being adjusted for timezone and daylight savings and displayed as the local time. Machines should have their time set with proper settings for the timezone and daylight savings. Issues exist with incorrect timezone or daylight savings settings where the time is set to the observed current local time but internally the UTC time is now inaccurate.

Best practice is to enable time synchronization with a time synchronization server for all machines involved with the transaction. Time skew occurs when a machine's clock keeps time slightly differently than another machine's clock, drifting away from the time synchronization server's time. Depending on how often time synchronization is done the drift can become fairly large. If this is the case, or you are unable to enable time synchronization, you can enable a feature that adjusts timestamp attributes by the average skew detected between the product agents and Topic Service.

To disable this feature for all agents

Configure the following in services.cfg:


To enable this feature for all agents in a release that supports this feature ( fixpack 1 or later)


To enable this feature for specific agents


and set the Adjust_Timestamp_Attributes_By_Skew agent preference using agentpref to on or off.

agentpref --set-agent Adjust_Timestamp_Attributes_By_Skew on
agentpref --set-agent Adjust_Timestamp_Attributes_By_Skew off

The following additional services.cfg keywords might be necessary to adjust the samples used to calculate the average skew.

skew_logic_samples_to_calculate_avg – this value defaults to 5. It defines the number of samples used to calculate the skew average. Acceptable values are 1-10. The smaller the number of samples the more reactive the service might be to time changes but accuracy/consistency across longer transactions is lost.

skew_logic_min_thresh_ms – this value defaults to 1000 milliseconds. The skew should not include any delays internal to the agent. This value defines the minimum the amount of time the agent must be sitting in a select waiting for socket activity before the skew adjustment is considered accurate. In very active agents a higher threshold might result in the skew never being calculated. In this case it could be reduced. It is not recommended this value be changed.

Was this page helpful? Yes No Submitting... Thank you