On Mon, Nov 6, 2017 at 5:47 PM, Max Slimmer <maxslim...@gmail.com> wrote:
> If you don’t mind losing some precision you can do something like this: > ... [code to override dateconverter] ... That would address the first bug, at least for my own immediate application. It would take more digging to determine how generally applicable it would be for a patch to the package. > Or maybe you can use datetime2. Another possible solution, sidestepping the first bug altogether. Thanks for your helpful suggestions. I'll need to scratch my head further to see if I can solve the second problem (loss of precision when running under Python 3). If I can't, I may take a different route altogether, letting the application server decide what time it is instead of the database server. In this approach, I would just create a variable in Python to represent the current date/time with sub-second precision stripped (or rounded away) and store that value. That way, at the cost of some precision, I'll be able to guarantee that Python 2 and Python 3 code (any code, really) will get the same value from the database. In this particular instance, the consistency is worth more than the precision. -- 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
