Error "ValueError: can't format dates this early" on one PC, works on other
Question:
I have a Python script that works perfectly fine on my development PC. Both are Windows 7 with the same Python version (2.7.9). However on the target machine I get a
ValueError: can’t format dates this early
The error seems to come from pywin32 module.
The code uses a third-party library invoked by pywin32:
raw = win32com.client.Dispatch("MyLib.MyClass")
and then fails later on:
acq_time = raw.GetCreationDate()
Now I’m lost why this is working on my PC and not on the target machine. Both have a “corporate install” of Windows 7, for example, the same Regional and date-time settings.
What is the issue? How might I resolve it?
EDIT:
See comments. The cause is probably which C++ runtime is used. I’m still investigating. I now suspect that it matters which runtimes are present at install time of pywin32. Why? Because DependenyWalker on my development PC says that pywin depends on MSVCR90.DLL in my Lotus Notes installation. This tells me it sure isn’t “hard” linked.
Update 30.06.2015:
I was all wrong…The issue now also happens on my PC.
Some further info. The script reads data files and inserts the read
meta-data into a database. Only older files seemed to be affected by the
bug, not new ones (I now think this is assumption is wrong). So the idea was to to the initial load on my Dev PC and then hope the issue will never occur again with new files.
In case of the PC were the script will run, the files it reads are on a
Windows Shared drive (mapped network drive). I don’t have access to that
drive so I just copied the files into my PC. Now for doing the initial
load I requested access to said network drive and BOOM. It also does not
work from my Dev. machine when reading from the shared drive.
The issue does not always happen with the same file. I now think it has nothing to do with a specific file. I also tried it on a 64-bit PC with 64-bit python. There it took longer till the error occurred. In fact a file was successfully read which failed on my PC. I now think it is some kind of memory issue? I believe that it then always fails on the date line because all other lines just return null or an empty string which causes no problem and is entirely possible such a value can be null. But for the date it is a problem and it should not be null and then the error is thrown.
EDIT of Update:
On my PC it always fails on the same file. Loading that file alone works perfectly fine. I now think it’s some kind of counter/number overflow that after reading n files, the issue occurs. It has to do with the amount of files I load per run of the script and not the file itself. Files that fail work when loading them individually.
Answers:
Turns out the issue was in fact trivial and somewhat due to my lack of experience with python and misleading error message.
The COM object raw = win32com.client.Dispatch("MyLib.MyClass") is used to open proprietary files in a loop. To solve the issue one must “clean-up” the object before next iteration. This is done either by
del raw
or
raw = None.
That completely solves the issue. It has absolutely nothing to do with dates or date formating. So Peter Brittain was probably right that this file limit was reached.
I have a Python script that works perfectly fine on my development PC. Both are Windows 7 with the same Python version (2.7.9). However on the target machine I get a
ValueError: can’t format dates this early
The error seems to come from pywin32 module.
The code uses a third-party library invoked by pywin32:
raw = win32com.client.Dispatch("MyLib.MyClass")
and then fails later on:
acq_time = raw.GetCreationDate()
Now I’m lost why this is working on my PC and not on the target machine. Both have a “corporate install” of Windows 7, for example, the same Regional and date-time settings.
What is the issue? How might I resolve it?
EDIT:
See comments. The cause is probably which C++ runtime is used. I’m still investigating. I now suspect that it matters which runtimes are present at install time of pywin32. Why? Because DependenyWalker on my development PC says that pywin depends on MSVCR90.DLL in my Lotus Notes installation. This tells me it sure isn’t “hard” linked.
Update 30.06.2015:
I was all wrong…The issue now also happens on my PC.
Some further info. The script reads data files and inserts the read
meta-data into a database. Only older files seemed to be affected by the
bug, not new ones (I now think this is assumption is wrong). So the idea was to to the initial load on my Dev PC and then hope the issue will never occur again with new files.
In case of the PC were the script will run, the files it reads are on a
Windows Shared drive (mapped network drive). I don’t have access to that
drive so I just copied the files into my PC. Now for doing the initial
load I requested access to said network drive and BOOM. It also does not
work from my Dev. machine when reading from the shared drive.
The issue does not always happen with the same file. I now think it has nothing to do with a specific file. I also tried it on a 64-bit PC with 64-bit python. There it took longer till the error occurred. In fact a file was successfully read which failed on my PC. I now think it is some kind of memory issue? I believe that it then always fails on the date line because all other lines just return null or an empty string which causes no problem and is entirely possible such a value can be null. But for the date it is a problem and it should not be null and then the error is thrown.
EDIT of Update:
On my PC it always fails on the same file. Loading that file alone works perfectly fine. I now think it’s some kind of counter/number overflow that after reading n files, the issue occurs. It has to do with the amount of files I load per run of the script and not the file itself. Files that fail work when loading them individually.
Turns out the issue was in fact trivial and somewhat due to my lack of experience with python and misleading error message.
The COM object raw = win32com.client.Dispatch("MyLib.MyClass") is used to open proprietary files in a loop. To solve the issue one must “clean-up” the object before next iteration. This is done either by
del raw
or
raw = None.
That completely solves the issue. It has absolutely nothing to do with dates or date formating. So Peter Brittain was probably right that this file limit was reached.