FreeTDS Development Group

["ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>]

> >>Revision 1.316 of src/odbc/odbc.c added milliseconds to the 
> ODBC date 
> >>format.  This broke things for my users after an upgrade from 
> >>0.62.3 to 
> >>0.64RC2.
> >>
> >>I have reverted this change locally, and I think it should be 
> >>reverted 
> >>in the master copy as well.
> >>
> >>Freddy, this change was yours.  Do you remember the 
> >>rationale?  Do you 
> >>agree that it should be reset back to the standard date format?
> >>
> > 
> > 
> > Well... I don't even rememeber what I ate yesterday :)
> > The change is
> > 
> http://freetds.cvs.sourceforge.net/freetds/freetds/src/odbc/od
> bc.c?r1=1.
> > 315&r2=1.316&sortby=date that is on ChangeLog
> > 
> > Thu Apr 15 21:25:15 CET 2004    Frediano Ziglio 
> <freddy77 AT angelfire.com>
> >         * src/odbc/odbc.c: fix date format
> >         * src/tds/convert.c: fix date approximation
> > 
> > perhaps is related to DBD::ODBD fixes (seeing near 
> changes)?? I don't
> > know... there must be a reason but I don't really remember. 
> I think is
> > better to find your problem and try to fix it. Which is the correct
> > bahavior?? Using ODBC 3 you can set precision that for date is the
> > number of digits, this is not yet implemented. Which is the 
> default? I
> > think the date format is used only converting date to char that is
> > binding date to a char and doing a simple select that 
> return date... Am
> > I wrong?
> 
> Yes, we do a lot of that sort of thing in our environment.  I know we 
> could work around it by having the users find all their date output 
> selects and explicitly convert them to the desired format.  But 
> meanwhile we would potentially have lots of breakage, so it's simpler 
> for now just to revert globally to the old format.
> 

I think so... I discovered that is depends on IRD/SQL_DESC_PRECISION...
that is 3 for DATETIME and 0 for SMALLDATETIME. This means that when you
read a DATETIME format have 3 decimal digits for second precision
(xxxx-xx-xx xx:xx:xx.xxx) while it have no digits for SMALLDATETIME
(xxxx-xx-xx xx:xx:xx). So format depends on data type... currently
format depends on... nothing. So both formats are wrong... one if wrong
for DATETIME (former) and the other for SMALLDATETIME (current). And I
have to say that precision setting in FreeTDS is not correct :( Not that
hard to fix :)

> I don't know which is the default format in a "normal" ODBC 
> environment, 
> because my only ODBC environment is FreeTDS/unixODBC/DBD::ODBC.
> 
> If we can have hooks to set the precision and I can get the 
> old behavior 
> somehow, I'd be happy with leaving the default precision with 
> milliseconds in place.  I tried looking through the ODBC 
> documentation, 
> but I think adding this configuration option is over my head.
> 

I don't think there is any configuration for this and
IRD/SQL_DESC_PRECISION is not writable... so the only way is to add a
FreeTDS extension...

> On a sort-of related note, I just checked in some format changes for 
> default and en_US locales in locales.conf.  With this change 
> the format 
> produced by FreeTDS using the DB-Library API is identical to Sybase's 
> output.  I think this is the correct behavior, but if there's 
> a reason 
> for a different default behavior then please let me know.
> 

I don't think there is any problem...

freddy77