2038 Bug

muscat

Power Member
Não sei se já ouviram falar, mas aqui fica na mesma, atenção ao pessoal do c++ que usa o CTIME, e particularmente aos embedded systems, pois estes ficarão por alguns anos ....

In the first month of the year 2038 C.E. many computers will encounter a date-related bug in their operating systems and/or in the applications they run. This can result in incorrect and grossly inaccurate dates being reported by the operating system and/or applications. The effect of this bug is hard to predict, because many applications are not prepared for the resulting "skip" in reported time - anywhere from 1901 to a "broken record" repeat of the reported time at the second the bug occurs. Also, leap seconds may make some small adjustment to the actual time the bug expresses itself. I expect this bug to cause serious problems on many platforms, especially Unix and Unix-like platforms, because these systems will "run out of time". Starting at GMT 03:14:07, Tuesday, January 19, 2038, I fully expect to see lots of systems around the world breaking magnificently: satellites falling out of orbit, massive power outages (like the 2003 North American blackout), hospital life support system failures, phone system interruptions (including 911 emergency services), banking system crashes, etc. One second after this critical second, many of these systems will have wildly inaccurate date settings, producing all kinds of unpredictable consequences. In short, many of the dire predictions for the year 2000 are much more likely to actually occur in the year 2038! Consider the year 2000 just a dry run. In case you think we can sit on this issue for another 30 years before addressing it, consider that reports of temporal echoes of the 2038 problem are already starting to appear in future date calculations for mortgages and vital statistics!

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901

Fonte: http://www.deepsky.com/~merovech/2038.html


Early UNIX programmers had quite a sense of humor. In their documentation for the tunefs utility, a command-line program that fine-tuned the file system on the machine's hard disk, a note at the end reads "You can tune a file system, but you can't tune a fish." A later generation of UNIX authors, fearful that stuffy, humorless corporate drones would remove this cherished pun, added a programmer's comment inside the documentation's source code that read, "Take this out and a UNIX demon will dog your steps until the time_t's wrap around!" On January 19, 2038, that is precisely what's going to happen.
For the uninitiated, time_t is a data type used by C and C++ programs to represent dates and times internally. (You Windows programmers out there might also recognize it as the basis for the CTime and CTimeSpan classes in MFC.) time_t is actually just an integer, a whole number, that counts the number of seconds since January 1, 1970 at 12:00 AM Greenwich Mean Time. A time_t value of 0 would be 12:00:00 AM (exactly midnight) 1-Jan-1970, a time_t value of 1 would be 12:00:01 AM (one second after midnight) 1-Jan-1970, etc.. Since one year lasts for a little over 31 000 000 seconds, the time_t representation of January 1, 1971 is about 31 000 000, the time_t representation for January 1, 1972 is about 62 000 000, et cetera.
If you're confused, here are some example times and their exact time_t representations:
Date & timetime_t representation 1-Jan-1970, 12:00:00 AM GMT 0 1-Jan-1970, 12:00:01 AM GMT 1 1-Jan-1970, 12:01:00 AM GMT 60 1-Jan-1970, 01:00:00 AM GMT 3 600 2-Jan-1970, 12:00:00 AM GMT 86 400 3-Jan-1970, 12:00:00 AM GMT 172 800 1-Feb-1970, 12:00:00 AM GMT 2 678 400 1-Mar-1970, 12:00:00 AM GMT 5 097 600 1-Jan-1971, 12:00:00 AM GMT 31 536 000 1-Jan-1972, 12:00:00 AM GMT 63 072 000 1-Jan-2003, 12:00:00 AM GMT 1 041 379 200 1-Jan-2038, 12:00:00 AM GMT 2 145 916 800 19-Jan-2038, 03:14:07 AM GMT 2 147 483 647
By the year 2038, the time_t representation for the current time will be over 2 140 000 000. And that's the problem. A modern 32-bit computer stores a "signed integer" data type, such as time_t, in 32 bits. The first of these bits is used for the positive/negative sign of the integer, while the remaining 31 bits are used to store the number itself. The highest number these 31 data bits can store works out to exactly 2 147 483 647. A time_t value of this exact number, 2 147 483 647, represents January 19, 2038, at 7 seconds past 3:14 AM Greenwich Mean Time. So, at 3:14:07 AM GMT on that fateful day, every time_t used in a 32-bit C or C++ program will reach its upper limit.
One second later, on 19-January-2038 at 3:14:08 AM GMT, disaster strikes.

Fonte: http://pw2.netcom.com/~rogermw/Y2038.html

:kfold:
 
Back
Topo