Year 2045 problems
jdennis at redhat.com
Wed Aug 19 22:56:52 CEST 2009
On 08/19/2009 04:28 PM, Alan Buxey wrote:
>> 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?
More information about the Freeradius-Devel