I find this conversation very interesting, but here is another perspective to think about. 2038 is 30 years away. Will you be using the same type of computer in 30 years? No, I'm guessing not. Think of what computers were 30 years ago. Will you be using software after 30 years? I don't think so, it won't run on your new operating systems, because so much will have changed. It's possible you will use the same software, but it will be a much later / fixed version. What about data stored in databases? I'm guessing date/time fields will be converted as needed. So, for future use, I do not see any problems. We could be computing on 65536 bit processors by then, who knows. So the remaining issue for today is that of future calculations, or in some cases, calculating backwards to the past. If this were a real serious issue, there would be effort being put in to it now. Where I work today, we use a product that will not store a null date. If you leave a date blank, it stores it as 1/1/3000. Obviously an arbitrary date, but it shows that our vendor is not having trouble storing this date in our current DB2 database. I don't know if our database is 64-bit or not, but I do know the product itself is only 32-bit. So, in a nutshell, the point of all this is that I am not seeing an issue that needs a lot of attention. But that is my 2 cents. - Joey On Dec 6, 2007 7:15 PM, Brian Hurt <bhurt at spnz.org> wrote: > > > On Thu, 6 Dec 2007, Mike Miller wrote: > > > Thanks to both Florin and Elvedin for looking this up. Very > interesting. > > I had no idea that this was how we would be dealing with the 2038 > problem > > on some of these machines - by replacing them with 64-bit machines. It > is > > really a software problem, but I guess it's much more easily resolved in > a > > 64-bit architecture so programmers are crossing their fingers and hoping > > all the 32-bit machines will be gone before 2038 gets here! I won't be > > surprised if air traffic controllers are using in 2038 machines that > they > > bought in 1997. > > In my opinion, we should have switched to 64-bit circa 1997. If you can't > mmap your whole hard disk, you don't have enough bits of adress space, and > you immediately start running into problems (for example, lseek breaking > on large files). The server chips had all switched by that point. > > But the computer industry, like governments, does the rational thing only > after all other possible alternatives are exhausted. > > Brian > > > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/mailman/listinfo/tclug-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mn-linux.org/pipermail/tclug-list/attachments/20071206/31ad33ce/attachment.htm