On 08/19/2009 04:28 PM, Alan Buxey wrote:
Hi,
I'm assuming it's because the unix timestamp rolls over sometime in 2038 therefore impossible. 64 bit timestamps should fix this.
yep... AmigaOS 3.x and earlier die slightly earlier than this due to the wierdness of there counter too. 32bit dates get borked in 2038.
but 2045 dates now? thats a little preemptive even for my standards of tested! ;-)
FWIW, I did a quick test by extracting the gettime() function in valuepair.c into a little test program and passed it the offending date. The presumption of numerical overflow in a 32-bit time_t was indeed correct (mktime was failing when the year was 2038 or greater). Many OS's are now using 64-bit time_t and the rest will follow soon, I don't see this as a major concern at the moment. FWIW some guidelines suggest avoiding time_t in favor of a more robust solution, but like I said I think it's O.K because time_t will be widened. Correct time/date handling is non-trivial if you really want to do it right (I've done a lot of research in this area). -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/