4

I am currently working on a project with a requirement that our software must operate until at least 2050. Recently we have run into problems dealing with the Y2.036K "bug" in the NTP protocol and also the Y2.038K bug. Basically, our software must continue to run past these dates with all data recorded using correct time stamps. Given that there is currently no solution to either of these bugs a workaround must be employed.

It is critical that our software keeps running after these two events and records dates correctly. It is not critical that the OS system time be correct. Given that we are using Java we should be able to handle dates relative to the prime epoch of 1900 after it rolls over. However, the java JVM will not even run if the system time is set before Unix epoch in 1970! It just crashes.

To add fuel to the fire, the NTP server is supplied by another vendor and we have no control over it. So using another protocol or modifying the server to handle any of this is not possible.

A creative solution is required. Needless to say, some deep voodoo must take place. We have considered the following:

  1. Modify the ntpd client software to somehow co-operate with the ntp server and offset the local time from a date greater than Unix epoch in 1970 rather than 1900. Thus allowing the JVM to run without crashing on initialization. All time stamps will then be handled relative to our chosen rollover date. (So basically, make sure we rollover to a date greater than the Unix epoch).

  2. Allow the ntp corrected time to rollover to 1900 epoch and find a fix so that the JVM will not crash.

Has anyone else tackled this issue? And also, are there any other issues that may occur which I have not foreseen, making one or both of these solutions not feasible at all?

Kara
  • 6,115
  • 16
  • 50
  • 57
S73417H
  • 2,661
  • 3
  • 23
  • 37
  • Why are the years 2360 and 2380 a problem for you if your software only needs to be operational until 2050? – Bombe Sep 09 '09 at 13:58
  • Ooopps! Y2.036K and Y2.038K. My bad. – S73417H Sep 09 '09 at 14:09
  • long time for sure -- have you found a solution? what it is? very interesting problem. – chx Jan 06 '11 at 00:47
  • Well, in our case we found that so many subsystems of our overall solution were so affected by this issue that it became infeasible to deal with them all. Given that the problem stems from a fundamental issue with operating systems not being able to correctly represent times passed Y2.038K we managed to argue the case to our customer that the issue will likely be more easily and concisely solved as we approach Y2.038K. By then we would expect the issue to be more comprehensively dealt with in the OS, hardware, third party software, etc. – S73417H Jan 07 '11 at 05:57

1 Answers1

3

Install your software on a 64 bit Linux with a 64 bit JVM. time_t and friends are 64 bit here, adjust the time past 2038 see if stuff still works. If you're good, toss away NTP, find a gps or other source which can be used as a precise clock and guarantees they don't have 32 bit problems, interface your software to read/sync time from that.

p.campbell
  • 98,673
  • 67
  • 256
  • 322
leeeroy
  • 11,216
  • 17
  • 52
  • 54