> On Mon, 10 Jan 2000, Tom Goulet wrote: > > 2038, and it's more a Unix problem than a C problem. > > Unix states the date as the number of seconds since the > beginning of 1970. > > Simply, after some time in 2038, a 32 bit variable can not hold that > > many seconds. 64 bit machines will have the year 20 quadrillion problem > > or something. :-) > Actually, in '38 the problem is that if the 32 bit integer is signed, it > becomes negative, it's good for another 68 years if it's used unsigned. Dunno 'bout all that, but another problem was that in order to do a "quick and dirty" fix of the Y2K problem, a good number of people implemented windowing. Some used a window of 1930-2029 (which most Microsoft software uses to interpret 2 digit years), some used 1940-2039, etc. That gives those idiots another 29 years to fix the software the right way. I'd say "Oh, we won't still be using the same programs 29 years from now", but I'm sure that's what all those programmers said back in 1971 when they were writing their software with 2 digit years. Actually, MS software allows you to modify the window, so you could slide it to a different date. _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
