Re: Y2K and Radius: maExpireDate above 12-31-1999 (year 2000) produces login failures

Mike Stankavich ( (no email) )
Sat, 25 Jul 1998 15:48:45 -0700

Yes, 8 digit dates take care of it once and for all. I just wanted to point
out SQL Server's default behavior for 6 digit dates. If you're curious,
paste the following SQL into ISQL and execute it and you'll see exactly what
I'm talking about.

select convert(datetime, '12/31/49')
select convert(datetime, '1/1/50')

The first select returns Dec 31 2049 12:00AM
The second one returns Jan 1 1950 12:00AM

I'm very comfortable with 2.5's Y2K compliance. I did notice in 2.2 that if
I put in an saExpireDate >= 1/1/2000 authentication would think that the
account was expired, but no problem in 2.5.

-----Original Message-----
From: Dale E. Reed Jr. <daler@iea-software.com>
To: radiusnt@iea-software.com <radiusnt@iea-software.com>
Date: Saturday, July 25, 1998 3:22 PM
Subject: Re: Y2K and Radius: maExpireDate above 12-31-1999 (year 2000)
produces login failures

Mike Stankavich wrote:
>
> What about the SQL Server default behavior of converting 2-digit years
> between 00 and 49 to 2000-2049 and 50-99 to 1950-1999? That would explain
> why 2050 didn't work...

I assumed the date was actually checked in SQL Server on the 2050 thing.
Its very possible that putting 1/1/50 would not actually be 1/1/2050.
We are using only the new 8 digit date formats which are mmddyyyy for
inserting dates into SQL Server that resolves the date interpratation
problems.

--Dale E. Reed Jr.  (daler@iea-software.com)_________________________________________________________________       IEA Software, Inc.      |  RadiusNT, Emerald, and NT FAQsInternet Solutions for Today  |   http://www.iea-software.com