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.