Year 2045 problems

[John Dennis]

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 at redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/