Skip to Content.
Sympa Menu

freetds - Re: [freetds] dbdatecrack producing erroneous results

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Frediano Ziglio <freddy77 AT gmail.com>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] dbdatecrack producing erroneous results
  • Date: Sun, 22 Apr 2012 08:28:51 +0100

Il 22 aprile 2012 01:45, crunsus <crunsus AT gmail.com> ha scritto:
> 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
>

Quite strange... I extended odbc data test in order to test data in a
far future and using 3803 as year works correctly. Are you sure you
are using correct MSDBLIB definition ??
Could you post some code?

Frediano Ziglio




Archive powered by MHonArc 2.6.24.

Top of Page