CA DataMinder Tuesday Tip: Understanding Time Stamps.

Discussion created by devan05 Employee on Aug 21, 2012
Latest reply on Aug 22, 2012 by Chris_Hackett
Understanding Time stamp processing with CA (DLP) DataMinder published by Andrew Devine Snr. Support Engineer 21 August 2012.

Event data captured by CA (DLP) DataMinder contains a variety of time stamps, including an event’s time of capture, plus its expiry time, updated time and the time stamp of any associated audit actions. All of these time stamps are stored in the CMS database. There is also an event timestamp stored in the blob (Binary Large Object) files for a captured event.

Note: A BLOB (Binary Large Object) file contains the e-mail content and any attachments, or the Web page plus any uploaded files, stored in CA (DLP) DataMinder format.

Below is an example of the processing sequence where an event is captured or an audit action performed:.

1 Appropriate time stamps (in local time) are generated when an event is created or audited.
2 Windows API: These time stamps are converted from local time to UTC (Coordinated Universal Time) using Windows APIs that take DST into consideration.
3 Java API: The UTC time stamps are then passed to the local CA (DLP) DataMinder infrastructure.

This uses Java APIs to convert the time stamps back to local time and stored as event metadata in the local database. (By contrast, time stamps in blob files are stored in UTC.)

When an event is retrieved from the CMS database (for example, when a reviewer runs an event search in the iConsole, or when a content indexing job runs), the process is reversed;

1 Java API: On the CMS, the Java layer reads the time stamp (stored in local time) and converts that back to UTC using Java APIs.
2 The CMS then passes that UTC time stamp to the CA (DLP) DataMinder consoles.
3 Windows API: The Data Management console or the browser hosting the CA (DLP) DataMinder iConsole then converts the UTC time stamp to the local time using Windows APIs.

Daylight Savings Time (DST) changes has an impact on the handling of these stored time stamps. In most scenarios, the iConsole and Data Management console adjust displayed time stamps to reflect whether DST would be operative in the viewer’s TZ at the time of the time stamp. However, there is a known issue where the incorrect Timestamp is stored in the CMS for Events captured immediately before DST Ends.

Events captured in the hour before Daylight Saving Time (DST) ends are stored in the CMS database with an incorrect timestamp. Specifically,CA DataMinder fails to take account of clocks being adjusted backward at the end of DST, so events captured in the preceding hour are stored with a timestamp that is +1:00 hour later than it should be. In the worst case, the iConsole may report events as being captured in the wrong order. For example, the iConsole may show an email reply as being captured before the original email was sent. In practice customers are unlikely to be exposed to this anomaly because DST typically ends at 2am on a Sunday in most Western and Aisan countries.

For examples of where this issue could be encountered, please refer to the CA (DLP) DataMinder r14.1 Release Notes 3rd Edition available to download from here.