36

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.

beginner_
  • 7,230
  • 18
  • 70
  • 127
  • 2
    Same version of `pywin32` on both machines? Same version of the library? – Deacon May 29 '15 at 12:11
  • The linked comment from Mark Hammond says `_tcsftime tries to be "helpful" by dieing with a too early date in some CRT implementations (eg, vs2008 64bit - and probably others)`. What CRT are you using? – Peter Wood May 29 '15 at 12:12
  • 1
    What about Windows regional settings, especially the date format? – Ihor Pomaranskyy May 29 '15 at 12:15
  • @DougR The PC causing the error had a never version (the newest, 2.19). However I uninstalled it and installed same version as on my dev PC, namely 2.18. Error still persists (Did that before asking the question). – beginner_ Jun 01 '15 at 11:15
  • @PeterWood How can I determine which CRT is used? Doesn't that depend on how the library was built, eg. which version it targets and hence the same pywin32 version should use the same CRT? – beginner_ Jun 04 '15 at 11:21
  • @beginner_ Maybe use [depends](http://www.dependencywalker.com/) to find the DLLs being used. For example my installation uses `MSVCR90.DLL` located in `C:\windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_50934f2ebcb7eb57` – Peter Wood Jun 04 '15 at 12:09
  • @PeterWood And how is it determined which one is used? How could I change that if possible at all? – beginner_ Jun 09 '15 at 08:45
  • I don't know, maybe search, or ask a new question with details. – Peter Wood Jun 09 '15 at 09:30
  • It would be helpful if you could give an example of a command that can be issued from the Python command prompt that causes that ValueError on your target machine but not on the other. – Alan Jun 23 '15 at 20:31
  • @Alan The command is `acq_time = raw.GetCreationDate()` but of course you need the commercial 3rd party library that said call requires. So no, it's not possible for you to reproduce the error. – beginner_ Jun 24 '15 at 05:16
  • I think more info is needed to solve this. Can you at least say what the 3rd party COM object is? Someone might have it available, or docs might suggest a way to reproduce the problem without commercial software and therefore give a definite solution. Without that, ths problem can only be definitively narrowed down by you and would be of limited use to future users. – J Richard Snape Jun 28 '15 at 08:11
  • Are you able to recreate the problem in the same folder as a working file? – Martin Evans Jun 30 '15 at 07:31
  • 1
    Just a guess, but given your latest edits, are you hitting the Windows C runtime [file limit](https://msdn.microsoft.com/en-us/library/kdfaxaay%28vs.71%29.aspx) and so dying as something else in your COM object needs access to a new file? – Peter Brittain Jun 30 '15 at 16:52
  • @PeterBrittain Yes, that could be the case. I might have found a solution. Will add an answer once I'm sure. Running the script takes couple of hours. – beginner_ Jul 01 '15 at 04:19

1 Answers1

1

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.

beginner_
  • 7,230
  • 18
  • 70
  • 127