Year 2038 Date/Time Problem
As per Wikipedia (https://en.wikipedia.org/wiki/Year_2038_problem):
“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 (http://infocenter.sybase.com/help/topic/com.sybase.infocenter.dc32410.1520/pdf/refman.pdf).
Date/time |
|
smalldatetime |
January 1, 1900 to June 6, 2079 |
datetime |
January 1, 1753 to December 31, 9999 |
date |
January 1, 0001 to December 31, 9999 |
time |
12:00:00AM to 11:59:59:999PM |
bigdatetime |
January 1, 0001 to December 31, 9999 and 12:00.000000AM to 11:59:59.999999 PM |
bigtime |
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.
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: https://apps.support.sap.com/sap/support/knowledge/preview/en/2258792
Essentially, I got a dump in production with message class C7 message 133.
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)?
Thanks Guyon, will inform the PM for the product.
No problem! It certainly piqued my curiosity.