Re: [python-win32] datetime values in adodbapi

2017-11-07 Thread Bob Kline 
On Tue, Nov 7, 2017 at 10:11 AM, Vernon D. Cole  wrote:

> Obviously Bob has found a where a value an internal form blows up when fed
> directly back into an INSERT. I suspect that if his row.date value was run
> through a real datetime object that things would magically work differently.

I'm not sure what that means. The value I get back from adodbapi from my SELECT
query *is* a Python datetime object:

>>> row = cursor.fetchone()
>>> type(row[0])


What would be the difference between that and a "real datetime object"?

-- 
Bob Kline
http://www.rksystems.com
mailto:bkl...@rksystems.com
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] datetime values in adodbapi

2017-11-07 Thread Bob Kline 
On Tue, Nov 7, 2017 at 10:49 AM, Dennis Lee Bieber
 wrote:

> >> When running under Python 2.7.13, the first print statement shows that
> >> the datetime value has been correctly retrieved, preserving the
> >> precision:
> >>
> >> d=2017-11-04 07:52:18.11
> >>
> Given that string of 0s, the only thing I'd be able to conclude from
> the above is that the /formatting/ of the output specified a high
> precision, which may not be in the data itself.

The adodbapi package returns standard Python library datetime objects
for non-NULL values retrieved from SQL Server DATETIME columns, so
that's what row.d is. The fact that the printed representation of the
value has trailing zeros reflects the default formatting for datetime
objects.

-- 
Bob Kline
http://www.rksystems.com
mailto:bkl...@rksystems.com
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] datetime values in adodbapi

2017-11-07 Thread Vernon D. Cole 
The real question here is where the significance gets lost.  It's hard to
get a handle on what is really in the tables. Also, the time conversion
routines (both in and out of the database) are a mass of confusion.
Obviously Bob has found a where a value an internal form blows up when fed
directly back into an INSERT. I suspect that if his row.date value was run
through a real datetime object that things would magically work
differently. This code has been around since long before datetime was
invented, and tries to handle every possible format. Washing everything
through datetime internally is probably not the answer, either, since
datetime is _really_ slow -- at least it was last time I did performance
tests.

The code resorts to falling back to handling time values as ISO strings in
some cases -- depending on a guess of how the underlying database engine
will accept them. Remember that this module needs to work with *any*
database engine, not just the two sold by Microsoft. Data may be lost in
the conversion between COM dates, datetime dates, whatever the database
stores internally, and human readable dates.  I have never examined where
small amounts of precision might be lost. The unit tests are loose.  Tests
for time.time() are even worse -- if a test worked for me in US Mountain
Standard zone it was sure to fail for Mark in Australia. Ugh! But I
digress. This will take some really detailed debugging. My thanks go out to
whomever tackles it.
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32