Error “ValueError: no puedo formatear fechas tan pronto” en una PC, funciona en otra

Tengo un script de Python que funciona perfectamente bien en mi PC de desarrollo. Ambos son Windows 7 con la misma versión de Python (2.7.9). Sin embargo, en la máquina de destino me sale un

ValueError: no puedo formatear fechas tan temprano

El error parece venir del módulo pywin32.

El código utiliza una biblioteca de terceros invocada por pywin32:

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

y luego falla más adelante:

 acq_time = raw.GetCreationDate() 

Ahora estoy perdido por qué esto funciona en mi PC y no en la máquina de destino. Ambos tienen una “instalación corporativa” de Windows 7, por ejemplo, la misma configuración regional y de fecha y hora.

¿Cual es el problema? ¿Cómo podría resolverlo?

EDITAR:

Ver comentarios. La causa es probablemente qué tiempo de ejecución de C ++ se utiliza. Todavía estoy investigando. Ahora sospecho que importa qué tiempos de ejecución están presentes en el momento de la instalación de pywin32. ¿Por qué? Debido a que DependenyWalker en mi PC de desarrollo dice que pywin depende de MSVCR90.DLL en mi instalación de Lotus Notes. Esto me dice que seguro que no está “duro” vinculado.

Actualización 30.06.2015:

Estaba equivocado … El problema ahora también ocurre en mi PC.

Un poco más de información. El script lee los archivos de datos e inserta los metadatos de lectura en una base de datos. Solo los archivos más antiguos parecían estar afectados por el error, no los nuevos (ahora creo que esta es una suposición errónea). Así que la idea era realizar la carga inicial en mi PC Dev y luego esperar que el problema nunca vuelva a ocurrir con nuevos archivos.

En el caso de la PC donde se ejecutará el script, los archivos que lee se encuentran en una unidad compartida de Windows (unidad de red asignada). No tengo acceso a ese disco, así que simplemente copié los archivos en mi PC. Ahora, para hacer la carga inicial, solicité acceso a dicha unidad de red y a BOOM. Tampoco funciona de mi Dev. Máquina al leer desde la unidad compartida.

El problema no siempre ocurre con el mismo archivo. Ahora creo que no tiene nada que ver con un archivo específico. También lo probé en una PC de 64 bits con python de 64 bits. Allí tomó más tiempo hasta que ocurrió el error. De hecho, un archivo fue leído con éxito que falló en mi PC. ¿Ahora creo que es algún tipo de problema de memoria? Creo que siempre falla en la línea de fecha porque todas las demás líneas simplemente devuelven un valor nulo o una cadena vacía que no causa problemas y es totalmente posible que dicho valor pueda ser nulo. Pero para la fecha es un problema y no debe ser nulo y, a continuación, se produce el error.

EDITAR de actualización:

En mi PC siempre falla en el mismo archivo. Cargar ese archivo solo funciona perfectamente bien. Ahora creo que es una especie de desbordamiento de contador / número que, después de leer n archivos, ocurre el problema. Tiene que ver con la cantidad de archivos que cargo por ejecución del script y no con el archivo en sí. Los archivos que fallan funcionan al cargarlos individualmente.

Resulta que el problema era de hecho trivial y algo debido a mi falta de experiencia con Python y un mensaje de error engañoso.

El objeto COM raw = win32com.client.Dispatch("MyLib.MyClass") se usa para abrir archivos propietarios en un bucle. Para resolver el problema, uno debe “limpiar” el objeto antes de la próxima iteración. Esto se hace ya sea por

del raw o raw = None .

Eso resuelve completamente el problema. No tiene absolutamente nada que ver con fechas o formateo de fecha. Así que Peter Brittain probablemente tenía razón al llegar al límite de este archivo.