Wed Aug 19 11:34:04 2009 : Error: rlm_sql: Failed to create the pair: failed to parse time string "31 Jan 2045" Wed Aug 19 11:34:04 2009 : Error: rlm_sql (sql): Error getting data from database Wed Aug 19 11:34:04 2009 : Error: [sql] SQL query error; rejecting user The workaround is easy, stop setting Expiration, but I am curious as to where the fault is.
I'm assuming it's because the unix timestamp rolls over sometime in 2038 therefore impossible. 64 bit timestamps should fix this. On 19-Aug-09, at 12:58 PM, Joe Maimon wrote:
Wed Aug 19 11:34:04 2009 : Error: rlm_sql: Failed to create the pair: failed to parse time string "31 Jan 2045" Wed Aug 19 11:34:04 2009 : Error: rlm_sql (sql): Error getting data from database Wed Aug 19 11:34:04 2009 : Error: [sql] SQL query error; rejecting user
The workaround is easy, stop setting Expiration, but I am curious as to where the fault is.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
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! ;-) alan
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/
John Dennis wrote:
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).
It's made worse by the fact that RADIUS uses a 32-bit value for time. So fixing the server would be nice, but not enough. Alan DeKok.
participants (5)
-
Alan Buxey -
Alan DeKok -
Gabriel Blanchard -
Joe Maimon -
John Dennis