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
