返回
-
标题
Expected Behavior for Date/Time in Identity Manager -
说明
Administrators utilizing Identity Manager may report issues with date/time due to how Identity Manager stores and works with date/time values.
Most often these problems will be in customizations that directly query the SQL Database for the value, receiving the UTC value without time zone based localization. -
原因
The primary reason for issues is that by default and for all default columns the date/time value is entered in local time, and then converted to Coordinated Universal Time (UTC) before being stored in the database.
An Employee Leaving Date entered by an Admin based in New York entered as 05/05/2023 12:00PM Eastern Daylight Time (EDT) will be saved in the database as 05/05/2023 08:00:00. The date/time value should consistently translate from the UTC value to the local time zone of the system from which the Identity Manager application is run. This includes SQL Queries run within the Object Browser application.
Another common reason customers contact support is the differences in how date/time may be stored in target systems, synchronized users may appear to have different dates or time when viewed in Identity Manager's applications.
Two commonly reported issues include Active Directory last date and SCIM/LDAP target systems where only a Date value is stored rather than Date/Time.
Active Directory will present the end date/time for a user as 12/01/2023 24:00 without time zone information, it does this so that the end user date is always midnight regardless of the domain controllers location. With Active Directory the first domain controller that reaches midnight local time disables the account.
Identity Manager on synchronizing with Active Directory will see that as 13/01/2023 00:00 local time for the job server performing the synchronization. So if the job server is in New York the value will be treated as 13/01/2023 00:00:00 (-5 UTC) and then stored in the SQL database as 13/01/2023 05:00:00.
For target systems where only a Date type value is stored rather than the Date/Time type customers may report issues with the time being imported as without the time information, Identity Manager will utilize the time zone of the job server for conversion and storage into the database.
A date only value of 12/01/2023 will be treated as 12/01/2023 00:00 by a job server in New York, and as 12/01/2023 00:00 by a job server in Tokyo. The job server in New York will write 12/01/2023 05:00:00 (UTC) while the same import performed by the job server in Tokyo will write 11/01/2023 15:00:00 (UTC).
When Starling Connect is used as an intermediary between cloud hosted services and Identity Manager, the local time zone as configured in Starling Connect will be utilized rather than the job server’s time zone.
-
解决办法
For default columns and tables there is no resolution, this is intended behavior and cannot be modified.
For Date values being converted to Date/Time values, customers should ensure that the job server or Starling Connect used for the synchronization project have the correct time zone for the appending of 00:00:00 time.
Custom columns may be created which are not bound by the default behavior if a customer wants to store a date/time value and not convert to UTC automatically. See Identity Manager 9.1 - Configuration Guide (oneidentity.com) for details on the schema extension necessary to add a custom column.