000034201 - A revocation request executes immediately in RSA Identity Governance and Lifecycle if the revocation date is defined beyond 03:14:07 UTC 19 January 2038

Document created by RSA Customer Support Employee on Oct 18, 2016Last modified by RSA Customer Support Employee on Apr 21, 2017
Version 2Show Document
  • View in full screen mode

Article Content

Article Number000034201
Applies ToRSA Product Set:  RSA Identity Governance and Lifecycle (RSA G&L)
RSA Version/Condition: All
IssueWhen a user sets the revocation date for an access request to occur after 03:14:07 UTC 19 January 2038, the revocation request is fulfilled immediately without waiting for the revocation date.  As an example,
  1. Create a change request that adds access to a user.
  2. Set the revocation date to occur after the year 2038 (a revocation date of 2 October 2040 (10/02/40) is used  in the example below).
  3. Note the automatically generated request to revoke the entitlement shows the fulfillment date as 10/02/2040, which is correct; but the fulfillment happens immediately, which is not correct.
User-added image
CauseThis problem occurs because the revocation date is internally set to 10/02/1902 due to what is know as the Year 2038 problem and the Unix Millennium Bug.  All date calculations in RSA G&L are affected.
The year 2038 problem is when certain computing systems (typically Unix or Unix-like 32-bit systems) will fail to encode times after 03:14:07 UTC on 19 January 2038 because of the way time values are currently stored on those systems.  Here is a definition of the Year 2038 problem from Wikipedia:
"The Year 2038 problem is an issue for computing and data storage situations in which time values are stored or calculated as a signed 32-bit integer, and this number is interpreted as the number of seconds since 00:00:00 UTC on 1 January 1970 ("the epoch").[1] Such implementations cannot encode times after 03:14:07 UTC on 19 January 2038, a problem similar to but not entirely analogous to the "Y2K problem" (also known as the "Millennium Bug"), in which 2-digit values representing the number of years since 1900 could not encode the year 2000 or later. Most 32-bit Unix-like systems store and manipulate time in this "Unix time" format, so the year 2038 problem is sometimes referred to as the "Unix Millennium Bug" by association."
ResolutionThis problem has been reported in engineering ticket ACM-61578 and is being worked on by engineering. When there is a resolution, this article will be updated.