is anybody doing anything about 2038 time_t bug? [

2020-07-10 09:03发布

问题:

This question already has answers here:
Closed 9 years ago.

Possible Duplicate:
What should we do to prepare for 2038?

I don't mean 'people' in the abstract. I mean are you doing anything and if so what?

I am an ancient programmer and recall when I wrote COBOL in the late 70's saying to others in my team "you know - this isn't going to work in 2000". To which the reply was "yeah but this system wont be in use by then, that's 25 years away".

2038 is 28 years away.

回答1:

I add a disclaimer to the release notes of my software that says: Best before 2038.



回答2:

Praying and getting ready for the next wave of expensive consulting gigs. Just in time for retirement!



回答3:

When I need to store seconds from the epoch, I use a 64-bit type. If I need to store a time stamp and storage isn't tight, I'll use an ISO-8601 formatted string.



回答4:

Many systems use a 64 bit time_t which won't wrap for a very long time (for ticks=seconds).

In my own code I just make sure to use a representation for time that has a very long period, or sometimes when doing embedded stuff I just design things so that wrapping around does not matter by restricting my time calculations to relatively small (compared to the length of measurable time) time deltas.



回答5:

The easiest way, I think, is to write software that can be easily maintainable. That is, low coupling between data models and algorithms operating over them. Most DBMSs and computer languages are already been designed to support this kind of abstraction.