Skip to Content.
Sympa Menu

freetds - [freetds] dbdatecrack producing erroneous results

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: crunsus <crunsus AT gmail.com>
  • To: freetds AT lists.ibiblio.org
  • Subject: [freetds] dbdatecrack producing erroneous results
  • Date: Sat, 21 Apr 2012 20:45:49 -0400

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





Archive powered by MHonArc 2.6.24.

Top of Page