Error "ValueError: can't format dates this early" on one PC, works on other
Error "ValueError: can't format dates this early" on one PC, works on other
我有一个 Python 脚本，可以在我的开发 PC 上完美运行。两者都是 Windows 7，具有相同的 Python 版本 (2.7.9)。但是在目标机器上我得到一个
ValueError: can't format dates this early
The error 好像来自pywin32模块。
代码使用了pywin32调用的第三方库：
raw = win32com.client.Dispatch("MyLib.MyClass")
随后失败：
acq_time = raw.GetCreationDate()
现在我不知道为什么它在我的 PC 上工作而不是在目标机器上工作。两者的 "corporate install" 为 Windows 7，例如，相同的区域和日期时间设置。
这是什么问题？我该如何解决？
编辑：
查看评论。原因可能是使用了C++ 运行时间。我还在调查。我现在怀疑在安装 pywin32 时出现 运行 次很重要。为什么？因为我的开发 PC 上的 DependenyWalker 说 pywin 依赖于我的 Lotus Notes 安装中的 MSVCR90.DLL。这告诉我肯定没有 "hard" 链接。
2015 年 6 月 30 日更新：
我完全错了...现在我的电脑上也出现了这个问题。
一些进一步的信息。该脚本读取数据文件并插入读取的
元数据到数据库中。似乎只有较旧的文件受到影响
错误，而不是新错误（我现在认为这是错误的假设）。所以我的想法是在我的 Dev PC 上进行初始加载，然后希望这个问题不会再出现在新文件上。
如果 PC 是脚本 运行，它读取的文件位于
Windows 共享驱动器（映射网络驱动器）。我无权访问
驱动器，所以我只是将文件复制到我的电脑中。现在做初始
load 我请求访问所述网络驱动器和 BOOM。它也不
从我的开发工作。从共享驱动器读取时机器。
问题并不总是发生在同一个文件上。我现在认为它与特定文件无关。我也在 64 位 PC 上用 64 位 python 试过了。在那里花了更长的时间才发生错误。事实上，一个文件被成功读取，但在我的 PC 上却失败了。我现在认为这是某种内存问题？我相信它总是在日期行上失败，因为所有其他行只是 return null 或空字符串，这不会导致任何问题，并且完全有可能这样的值可以为 null。但是对于日期来说这是个问题，它不应该为 null 然后会抛出错误。
编辑更新：
在我的电脑上，它总是对同一个文件失败。单独加载该文件工作得很好。我现在认为这是某种 counter/number 溢出，在读取 n 个文件后，问题出现了。它与我根据脚本 运行 加载的文件数量有关，而不是文件本身。单独加载文件时失败的文件。
原来这个问题实际上是微不足道的，并且在某种程度上是由于我缺乏 python 的经验和误导性的错误消息。
COM 对象 raw = win32com.client.Dispatch("MyLib.MyClass") 用于循环打开专有文件。要解决这个问题，必须 "clean-up" 对象在下一次迭代之前。这是通过
del raw
要么
raw = None。
完全解决了这个问题。它与日期或日期格式完全无关。所以 Peter Brittain 可能是对的，达到了这个文件限制。
我有一个 Python 脚本，可以在我的开发 PC 上完美运行。两者都是 Windows 7，具有相同的 Python 版本 (2.7.9)。但是在目标机器上我得到一个
ValueError: can't format dates this early
The error 好像来自pywin32模块。
代码使用了pywin32调用的第三方库：
raw = win32com.client.Dispatch("MyLib.MyClass")
随后失败：
acq_time = raw.GetCreationDate()
现在我不知道为什么它在我的 PC 上工作而不是在目标机器上工作。两者的 "corporate install" 为 Windows 7，例如，相同的区域和日期时间设置。
这是什么问题？我该如何解决？
编辑：
查看评论。原因可能是使用了C++ 运行时间。我还在调查。我现在怀疑在安装 pywin32 时出现 运行 次很重要。为什么？因为我的开发 PC 上的 DependenyWalker 说 pywin 依赖于我的 Lotus Notes 安装中的 MSVCR90.DLL。这告诉我肯定没有 "hard" 链接。
2015 年 6 月 30 日更新：
我完全错了...现在我的电脑上也出现了这个问题。
一些进一步的信息。该脚本读取数据文件并插入读取的 元数据到数据库中。似乎只有较旧的文件受到影响 错误，而不是新错误（我现在认为这是错误的假设）。所以我的想法是在我的 Dev PC 上进行初始加载，然后希望这个问题不会再出现在新文件上。
如果 PC 是脚本 运行，它读取的文件位于 Windows 共享驱动器（映射网络驱动器）。我无权访问 驱动器，所以我只是将文件复制到我的电脑中。现在做初始 load 我请求访问所述网络驱动器和 BOOM。它也不 从我的开发工作。从共享驱动器读取时机器。
问题并不总是发生在同一个文件上。我现在认为它与特定文件无关。我也在 64 位 PC 上用 64 位 python 试过了。在那里花了更长的时间才发生错误。事实上，一个文件被成功读取，但在我的 PC 上却失败了。我现在认为这是某种内存问题？我相信它总是在日期行上失败，因为所有其他行只是 return null 或空字符串，这不会导致任何问题，并且完全有可能这样的值可以为 null。但是对于日期来说这是个问题，它不应该为 null 然后会抛出错误。
编辑更新：
在我的电脑上，它总是对同一个文件失败。单独加载该文件工作得很好。我现在认为这是某种 counter/number 溢出，在读取 n 个文件后，问题出现了。它与我根据脚本 运行 加载的文件数量有关，而不是文件本身。单独加载文件时失败的文件。
原来这个问题实际上是微不足道的，并且在某种程度上是由于我缺乏 python 的经验和误导性的错误消息。
COM 对象 raw = win32com.client.Dispatch("MyLib.MyClass") 用于循环打开专有文件。要解决这个问题，必须 "clean-up" 对象在下一次迭代之前。这是通过
del raw
要么
raw = None。
完全解决了这个问题。它与日期或日期格式完全无关。所以 Peter Brittain 可能是对的，达到了这个文件限制。