错误“ ValueError：无法提前格式化日期”在一台电脑上，在另一台电脑上工作 [英] Error "ValueError: can't format dates this early" on one PC, works on other

问题描述

我有一个Python脚本，可以在我的开发PC上正常运行。两者都是Windows 7，具有相同的Python版本（2.7.9）。但是在目标计算机上，我得到了一个

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：不能这么早格式化日期

ValueError: can't format dates this early

The error seems to come from pywin32 module.

该代码使用了pywin32调用的第三方库：

The code uses a third-party library invoked by pywin32:

raw = win32com.client.Dispatch("MyLib.MyClass")

，然后稍后失败：

acq_time = raw.GetCreationDate()

现在我不知道为什么它可以在我的PC上而不是目标计算机上运行了。两者都具有Windows 7的企业安装，例如，相同的区域和日期时间设置。

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?

编辑：

查看评论。原因可能是使用了 C ++ 运行时。我仍在调查中。我现在怀疑在pywin32的安装时出现哪些运行时很重要。为什么？因为我的开发PC上的DependenyWalker说pywin依赖于Lotus Notes安装中的 MSVCR90.DLL 。这告诉我确定不是硬链接。

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.

更新30.06.2015：

我全错了...问题现在也出现在我的PC上。

I was all wrong...The issue now also happens on my PC.

一些其他信息。该脚本读取数据文件，并将读取的
元数据插入数据库中。只有较旧的文件似乎受
错误的影响，而不受新文件的影响（我现在认为这是错误的假设）。因此，我们的想法是在我的Dev 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.

如果是PC，脚本将运行时，它读取的文件位于
Windows共享驱动器（映射的网络驱动器）上。我无法使用该
硬盘，因此我只是将文件复制到了PC中。现在，为了进行初始
加载，我请求访问所述网络驱动器和BOOM。我的开发人员也无法使用
。

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.

同一文件并不总是会出现此问题。我现在认为与特定文件无关。我还在具有64位python的64位PC上进行了尝试。在那里花了更长的时间直到错误发生。实际上，文件已成功读取，但在我的PC上失败了。我现在认为这是某种内存问题？我相信它然后总是在日期行上失败，因为所有其他行仅返回null或空字符串，这不会造成问题，并且完全有可能使该值可以为null。但是对于该日期而言，这是一个问题，它不应为null，然后引发错误。

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.

更新编辑：

在我的PC上，同一文件始终失败。单独加载该文件效果很好。我现在认为是某种计数器/数字溢出，导致读取n个文件后出现此问题。它与每次脚本运行时加载的文件数量有关，而与文件本身无关。单独加载文件时失败的文件。

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.

推荐答案

事实证明，该问题实际上是微不足道的，部分原因是我缺乏经验与python和误导性错误消息。

Turns out the issue was in fact trivial and somewhat due to my lack of experience with python and misleading error message.

COM对象 raw = win32com.client.Dispatch（ MyLib.MyClass）用于打开专有对象文件循环。为了解决这个问题，必须在下一次迭代之前清理对象。可以通过

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
或
完成raw =无。

这完全解决了问题。它与日期或日期格式完全无关。因此，彼得·布里顿（Peter Brittain）达到此文件限制可能是正确的。

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.

这篇关于错误“ ValueError：无法提前格式化日期”在一台电脑上，在另一台电脑上工作的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！