FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> From: Brian Bruns [mailto:camber AT ais.org]
> Sent: September 16, 2002 12:18 PM
> 
> > > From: Bill Thompson [mailto:thompbil AT exchange.uk.ml.com]
> > > Sent: September 16, 2002 8:34 AM
> > > 
> > > > 3) The date formats are different - the output format 
> > > > excludes the seconds
> > > > and milliseconds, which is not acceptable. 
> > > 
> > Instead of touching the global context, I think bcp_init() 
> should modify its
> > dbprocess:
> > 
> > 1. copy the global structure pointed to by g_dblib_ctx.
> 
> I think this is really a misuse of what TDSCONEXT is supposed to be. 
> There is only one (implicit) dblib context.  And it really 
> breaks down in ctlib.  

Perhaps my suggestion was a misuse of TDSCONEXT, OK. :) I don't understand
why, because I don't understand the technical meaning of "context" here,
apparently.  We need to find a way to isolate bcp from localization, though;
I'm open to how.  

AIUI Bill is dealing with date character representation in bcp.c.  He must
not rely on any user-specified preference for date formats when he's writing
to a bcp data file.  He must also not suppose, when reading a bcp data file
in character (-c) format, that dates are in some user-specified format.  

Microsoft nowadays insists on "ODBC" format (e.g., 1997-01-01 00:00:00.000)
in bcp files.  Previously they were more generous with what bcp would read,
but IIRC always wrote "mon dd yyyy hh:mi:ss:mmm[A|P]M", which is also
unambiguous.  I don't know how locale affects Sybase's bcp output.  I don't
know if it would ever read or write 'Maj 1 2002 00:00:00.000AM', if Swedish
were the language in force.  

Interpreting dates in localized formats is subject to misinterpretation:
"1/2/12" could be many dates to many cultures.  

Would you feel differently if I suggested bcp_init merely overwrote
DBPROCESS.tds_socket->tds_ctx->locale->date_fmt?  If not, how do you suggest
we isolate bcp operations from user preferences?  

I think poking date_fmt is preferable to passing explicit date format rules
into convert.c.  

> I would propose allowing each CLI to include date formats in the
> locales.conf file ('date format' being the default of course) and then
> some mechanism to pass this output 'styling' to tds_convert().  The
> convert() server function does something very similar so I 
> don't believe we are out on a limb if we choose this.

We have set each client library's default date conversion format to mimic
Sybase's and Microsoft's default choices, and we have allowed a generalized
override irrespective of API.  I really don't think anyone wants to set date
string formats per API.  

--jkl


The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above.  If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that for certain accounts we do not accept
orders and/or instructions by e-mail, and for those accounts we will not be
responsible for carrying out such orders and/or instructions. Kindly refrain
from sending orders or instructions by e-mail unless you have confirmed that
we accept such communications for your account. Please also note that to
satisfy regulatory requirements we review the outgoing and incoming e-mail
correspondence of staff members serving certain functions.