#17 DateTime objects with milliseconds break
I was using v2.4 and ran into the milliseconds treated like seconds bug. I updated to 2.6.0.6 and am having problems getting any datetime with subseconds to work.
In apibase.py on line 191 there is a comment that "should return a string in the format 'YYYY-MM-dd HH:MM:SS:ms' (ms optional)". The datetime.datetime.isoformat(' ') string returned is actually in the format 'YYYY-MM-dd HH:MM:SS.000000'. Later code throws an exception because it expects a string with no decimal point subseconds.
The datetime object converts to ADO types fine. Why is the code converting it into a string and then trying to convert it to an ADO date? Shouldn't it just pass through the datetime object?
The original millisecond bug happened because the code used a variable called "ms" to refer to microseconds. The name seemingly implies milliseconds. The code still uses ms for the variable name in COMDate and ComDateFromTuple functions. Please change the variable name to something explicit like micros so these problems don't creep back in.
If this resulted in a "Application uses a value of the wrong type for the current operation" error then I've also fallen foul of this.
In my case I didn't need the precision so I did ".replace(microsecond=0)" on the datetime which has stopped it crashing.
The bug persists in 2.6.0.7, but only under Python 2.x. Using Python 3.x there appears to be a different bug, because sub-second precision is discarded when retrieving values from the database. Any plans for correcting these defects at some point in the (one hopes) not-too-distant future? Are patches accepted? If so, I'll look into whether it would be feasible to contribute to the fix(es).