Skip to Content
Author's profile photo Arun Sitaraman

Year 2038 Date/Time Problem

As per 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.”

Financial Industry Applications (such as trade clearance risk analysis applications) could be encountering this limitation if they are using Signed 32 bit integers to represent Coordinated Universal Time (UTC). To avoid this problem, customers might choose to enhance their application by changing the date type to Unsigned 32-bit integer which will extend the application date encoding times to up to January 1, 1753 to December 31, 9999. In this scenario a common question in the context of SAP ASE as a database and SAP Replication Server in the application environment is whether they support datatypes to support this application change, especially in the case of older versions of these technologies, such as SAP ASE 15.0.3 and SAP Replication Server 15.2.

Let us use the SAP ASE Date/Time support table below for reference. The types smalldatetime, datetime, date and time have existed since ASE 12.5. The relevant ones namely datetime and date support up to year 9999. SAP ASE (version 15.0.3 and above) and SAP Replication Server (version 15.2 and above) support these (



January 1, 1900 to June 6, 2079


January 1, 1753 to December 31, 9999


January 1, 0001 to December 31, 9999


12:00:00AM to 11:59:59:999PM


January 1, 0001 to December 31, 9999 and 12:00.000000AM to 11:59:59.999999 PM


12:00:00.000000 AM to 11:59:59.999999 PM

So application date changes from Singed 32-bit integer to Unsigned 32-bit integer can be supported in a SAP ASE and SAP Replication Server environment, with appropriate data-type bindings as shown in the table above. However, as with any application changes, it is a good practice to stage those changes before production, to insure all is well.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Guyon Cumby
      Guyon Cumby

      I'm kinda bringing up an old discussion here, but hey, it's not like this discussion will be out of date for another 30 years.

      I recently came across this error:

      Essentially, I got a dump in production with message class C7 message 133.

      Scheduling termination: Invalid scheduling time

      According to my link above, this occurs when scheduling a call object after January 19, 2048. Why would this occur after 2048 as opposed to 2038? Is this message wrong, or has SAP done something to circumvent the 2038 problem for another 10 years (totally unlikely)?

      Author's profile photo Arun Sitaraman
      Arun Sitaraman
      Blog Post Author

      Thanks Guyon, will inform the PM for the product.

      Author's profile photo Guyon Cumby
      Guyon Cumby

      No problem! It certainly piqued my curiosity.