Re: Y2K-like bug to hit Linux computers! - Info of the day

[Matthias-Christian Ott <matthias.christian@tiscali.de>]

Srinivas G. wrote:
> Tuesday, January 19 2038. Time: 03:14:07 GMT. If Linux programmers get
> nightmares, it's about this date and time. Immediately after that second
> is crossed, current computer systems running on Linux will grind to a
> halt or go into a loop. This will trip up a lot of databases. No, this
> is not another hoax raised by some anti-Linux lobby. It is Linux's own
> Y2K nightmare, says Businessworld. 
> 
> If you ask what this 2038 bug is, you will have to put up some technical
> argot. The bug has its origins in the way the C language, which has been
> used to write Linux, calculates time. C uses the 'time_t' data type to
> represent dates and times. ('time_t' is an integer that counts the
> number of seconds since 12.00 a.m. GMT,  January 1 1970.) 
> 
> This data is stored in 32 bits, or units of memory. The first of these
> bits is for the positive or negative sign, and the remaining 31 are used
> to store the number. The highest number that these 31 bits can store
> works out to 2147483647. 
> 
> Calculated from the start of January 1 1970, this number would represent
> the 2038 time and date given at the top. Problems would arise when the
> system times of computers running on Linux reach this number. They can't
> go any forward and their value actually would change to -- 2147483647,
> which translated to December 13 1901! That will lead many programs to
> return errors or crash altogether. 
> 
> It's more damaging than the Y2K bug. That's because Y2K mostly involved
> higher-level applications such as credit card payment and inventory
> management. The 2038 bug, on the other hand, affects the basic
> time-keeping function. 
> 
> "I would guess the biggest issue would be in the embedded field, where
> software isn't changed all that often, if at all. Process controllers,
> routers, mobile phones, game consoles, telecom switches and the like
> would be the biggest victims," says Raju Mathur, GNU and Linux
> consultant and president of the Linux Delhi Users Group. 
> 
> He, however, adds that the rate at which we are changing technology,
> most systems are unlikely to use 32-bit processing by the time we get to
> 2038. 
> 
> But what about the present? Many applications running on Linux could
> soon be making calculations for dates 30 years away -- say, for mortgage
> and insurance calculations -- and could start giving out error messages
> well before D-day. The problem could be widespread because more and more
> corporates today are migrating to Linux because of the better security
> it offers. 
> 
> "The problem is not on the radar of most people, except the techies,"
> says Charles Assissi, editor, Chip magazine. 
> 
> How can the problem be sorted? Modern Linux programs could use 64-bit or
> longer time_t data storage to overcome the problem. As for the existing
> systems, the way the C language stores time_t data could be changed and
> then all the programs could be recompiled. All this is easier said than
> done. 
> 
> "There must be millions, if not billions of lines of C code floating
> around that use the time_t value. Locating them, changing them, managing
> programs for which source isn't available, updating embedded systems,
> redeploying, is, in my opinion, an impossible task," says Mathur. Will
> that be another lucrative opportunity for India's army of coders?
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
I think the most time value aren't timestamps (it's slower than a timestamp but works). So don't worry.

Matthias-Christian Ott