> > 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. ... > 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. The seriousness of the issue is not whether 'date' can or can't correctly display a date beyond or before some other date. The seriousness of the issue comes from the person who wants to use 'date' for a specific task and what the cost/benefit is for someone to use 'date' over some other tool or even writing their own. Just because this may not have been a serious issue for someone yet, doesn't mean that it can't be a serious issue for someone else. > 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. > This ties into the response above in that DB2 is a different tool that can be used to work with dates. The way it implements and uses dates is completely different than how GNU date does so the question of 64 bit vs. 32 bits in the architecture becomes less relevant. What's more relevant is whether DB2 is the proper tool to use for the task that needs to be accomplished.