Florin Iucha wrote: > On Thu, Dec 06, 2007 at 12:52:59AM -0600, Mike Miller wrote: > >> Are you saying that newer 32-bit Linux distros have a new version of 'date' >> that can deal with 2038? >> > > I was implying that, but I was wrong. Both Ubuntu 7.10 and Centos 5.1 > 32 bit have the same problem you described. Which is kind of silly - > there is no inherent limitation in the formatting part of the date > program that would force it to use 32 bits on 32 platforms. I > understand that hardware it what it is and you can only set 32 bits... > But I suspect (maybe wrongly, again) that the old beards that maintain > coreutils would just close a potential bug submission with 'works as > intended' 8^) > > Cheers, > florin > > > ------------------------------------------------------------------------ > > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/mailman/listinfo/tclug-list > From http://en.wikipedia.org/wiki/Year_2038_problem "There is no easy fix for this problem for existing CPU </wiki/Central_processing_unit>/OS </wiki/Operating_system> combinations. Changing the definition of |time_t| to use a 64-bit type would break binary compatibility for software, data storage, and generally anything dealing with the binary representation of time. Changing |time_t| to an unsigned 32-bit integer, effectively allowing timestamps to be accurate until the year 2106, would affect many programs that deal with time differences." I thought it would be an easy fix if two ints were stored, one for the past and the other for the future meaning the future one can be unsigned. What they're actually doing is waiting for users to adopt 64 bit hardware so the problem will fix itself.