Noticing that ITAM and SD are displaying different dates for the same field. Why is there a discrepancy between them when they share the same asset table ?
Release : 17.1 and higher
Component : CA SERVICE MANAGEMENT
The reason why the fields are displaying different values is due to how ITAM and SDM process the date field. The main concern is that ITAM displays a date field in GMT and omits the time element (HH:MM) whereas SDM accounts for the user's time zone and also provides a facility for the time element
Consider a date field that has been configured for display and access by both SDM and ITAM, in this case, the Warranty Start Date. In ITAM, where this field has been modified and saved, this is the field value presented:
In the above, the value, "07/18/2021" is present on ITAM. However, the same field in SDM presents as:
In the above, a date value of "07/17/2021 08:00 pm" is presented.
As stated earlier, the above date field was modified in ITAM and saved. As ITAM does not have a concept of hours and minutes in its date field, it will save the entry in the usp_owned_resource table, nr_wrty_st_dt field as "1626566400".
Running "1626566400" through a UNIX Epoch converter shows that this values translates to "Sunday, July 18, 2021 12:00:00 AM" GMT, or "Saturday, July 17, 2021 8:00:00 PM" for the local EST time zone in the above example. When SDM reads the same date field, it will also account for the local time zone, hence the date/time difference being seen across the two applications.
As ITAM does not have a concept of specific hours/minutes in its date fields, but SDM does, this is working as designed. ITAM treats the date field display as GMT/UTC internally despite not displaying the actual time, when viewing and saving the date field. When SDM reads the same date field, it will account for the time zone of the end user as SDM has a concept of hours/minutes in its date fields, resulting in the date/time discrepancy when the field is viewed from both applications.
In order to have date values remain consistent in this circumstance, some operational changes would be advised: