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