[lkml]   [2005]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Y2K-like bug to hit Linux computers! - Info of the day
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
> More majordomo info at
> Please read the FAQ at
I think the most time value aren't timestamps (it's slower than a timestamp but works). So don't worry.

Matthias-Christian Ott
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-05-13 13:51    [W:0.056 / U:1.652 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site