dbdatecrack producing erroneous results

Hi,

I am trying to put together a C++ utility  class that uses FreeTDS to 
connect to SQL 2008 R2 from Linux and
it is so for working excellent with this small exception.

When reading datetime fields of 8 byte precision from SQL server and 
parsing them using dbdatecrack the date is passed incorrectly for values 
that are outside of what normally one would use (i.e years in the 
distant future like 2300 A.D)
I noticed that it works quite well for dates that are closer to our 
present time but it could be a day or so off for days that are in the 
distant future. I also noticed that when examining the results parsed by 
this function and cross checked with what SQL Manager would display, 
FreeTDS's results would be off by a day sometime, not all the times, 
depends on the praticular date.

Was wondering if anyone is aware of this variance, or I am the only one 
experiencing this.
Funny think is that when the same C++ code is compiled on win32 using 
borland's c++ compiler and dblib from Microsoft, it works perfectly so 
this is why I think Microsoft's implementation must be somehow different 
from the one used in FreeTDS. To me this is a make it or brake it kind 
of functionality that I got to have working perfectly  as I rely heavily 
on datetime manipulations in my code. Using MS's dblib is not an option 
as it has to run on Linux but for Win32 I could get around by using 
their libs, this is how I came to notice this.  While I am no C++ guru, 
I traced the problem to be in convert.c file in the tds_datecrack 
function.  I tried to fix it but I have to admit that I don't understand 
how that works, so instead I rolled out my own naive implementation 
which is very slow compared to that one but it has the property that it 
always works for me,so I use it just to get me going, unlike dbdatecrack 
which in my opinion is not fully functiona as it stands now.

     I would very much like to help get this fixed professionally so 
that it works in all cases and with good performance. My approach on 
doing the date cracking is very naive (lots of looping and counting of 
leap years etc, but it always matches MS's result to the milisecond even 
for year 4000 AD say, but admittedly it is slow and sub-optimal, still 
better for me now than fast and erroneous :).
     Just trying to get a feel of what everybody else thinks about it, 
this should be huge if true and I was wondering how come nobody else 
reported it, but maybe it's just me and somehow I compiled this 
wrongfully or who knows. But the rest of the FreeTDS  works great for me 
so how could that be? Anyways thanks a lot for this astounding piece of 
software and hopefully it can be solved in the future.

Best Regards,
Crunsus