FreeTDS Development Group

[Frediano Ziglio <freddy77 AT gmail.com>]

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