Skip to Content.
Sympa Menu

freetds - Re: [freetds] ODBC date format?

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] ODBC date format?
  • Date: Mon, 12 Jun 2006 16:30:54 +0200

> >>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





Archive powered by MHonArc 2.6.24.

Top of Page