I am currently working on a project requiring our software to run until 2050. Recently, we have encountered problems related to the Y2.036K error in the NTP protocol, as well as the Y2.038K error. Basically, our software should continue to work over these dates with all data recorded using the correct timestamps. Given that there is currently no solution to any of these errors, a workaround is necessary.
It is very important that our software continues to work after these two events and the recording dates are correct. It is not necessary that the OS system time is correct. Given that we use Java, we should be able to handle dates relative to the first era of 1900 after being turned over. However, java JVM does not even start if the system time was set before the Unix era in 1970! He just falls.
To add fuel to the fire, the NTP server is supplied by another supplier, and we do not control it. Therefore, using a different protocol or modifying the server to process any of them is not possible.
A creative solution is required. Needless to say, there must be some kind of deep voodoo. We reviewed the following:
Modify the ntpd client software to somehow cooperate with the ntp server and shift the local time from a date greater than the Unix era in 1970 rather than 1900. Thus, allowing the JVM to run smoothly during initialization. All timestamps will be processed relative to the rollover date we have selected. (So basically, make sure we roll over to a date greater than the Unix era).
Allow ntp adjusted time to roll over to the 1900 era and find a fix so that the JVM does not work.
Has anyone else dealt with this issue? And are there also any other problems that may arise that I did not foresee making one or both of these solutions completely impossible?
source share