Błąd "ValueError: nie można sformatować dat tak wcześnie" na jednym komputerze, działa na innym

Question

Mam skrypt Python, który działa doskonale na moim komputerze PC. Oba są Windows   7 z tą samą wersją Pythona (2.7.9). Jednak na komputerze docelowym dostaję

ValueError: can't format dates this early

The error wydaje się pochodzić z modułu pywin32.

Kod wykorzystuje bibliotekę osób trzecich wywoływana przez pywin32:

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

a następnie nie później:

acq_time = raw.GetCreationDate() 

Teraz jestem zagubiony, dlaczego to działa na moim komputerze i nie na maszynie docelowej. Oba mają "firmową instalację" systemu Windows   7, na przykład te same ustawienia regionalne i daty i godziny.

Na czym polega problem? Jak mogę to rozwiązać?

EDYTOWANIE:

Zobacz komentarze. Prawdopodobnie przyczyną jest to, które środowisko wykonawcze C++ jest używane. Nadal badam. Teraz podejrzewam, że ważne jest, które runtime są obecne podczas instalacji pywin32. Czemu? Ponieważ DependenyWalker na moim komputerze programistycznym mówi, że pywin zależy od MSVCR90.DLL w mojej instalacji Lotus Notes. To mówi mi, że na pewno nie jest "twardo" połączony.

Aktualizacja 30.06.2015:

I wszystko było źle ... Kwestia teraz dzieje się również na moim komputerze.

Dalsze informacje. Skrypt odczytuje pliki danych i wstawia meta-dane do bazy danych. Wydaje się, że tylko starsze pliki zostały dotknięte przez błąd , a nie nowe (teraz uważam, że to założenie jest błędne). Więc pomysł polegał na początkowym obciążeniu mojego Dev PC i mam nadzieję, że problem nie powtórzy się z nowymi plikami.

W przypadku komputera PC skrypt był uruchamiany, pliki, które odczytuje, znajdują się na udostępnionym dysku Windows (zmapowany dysk sieciowy). Nie mam dostępu do tego dysku , więc właśnie skopiowałem pliki na mój komputer. Teraz za wykonanie początkowego obciążenia zażądałem dostępu do wspomnianego dysku sieciowego i BOOM. Nie działa też od mojego Dev. maszyna podczas odczytu z udostępnionego dysku.

Problem nie zawsze występuje z tym samym plikiem. Teraz myślę, że nie ma to nic wspólnego z konkretnym plikiem. Próbowałem również na 64-bitowym komputerze z 64-bitowym pythonem. Nie trwało to dłużej, aż wystąpił błąd. W rzeczywistości plik został pomyślnie odczytany, co nie powiodło się na moim komputerze. Teraz myślę, że to jakiś problem z pamięcią? Wierzę, że wtedy zawsze kończy się niepowodzeniem na linii daty, ponieważ wszystkie inne linie po prostu zwracają wartość null lub pusty łańcuch, który nie powoduje problemu i jest całkowicie możliwe, że taka wartość może być pusta. Ale dla daty jest to problem i nie powinno być puste, a następnie zgłaszany jest błąd.

EDIT aktualizacji:

Na moim komputerze nie zawsze w tym samym pliku. Ładowanie samego pliku działa doskonale. Teraz myślę, że jest to pewnego rodzaju przepełnienie licznika/liczby, które po przeczytaniu n plików powoduje problem.Ma to związek z ilością plików, które ładuję na jeden skrypt, a nie sam plik. Pliki, które przestają działać, podczas ładowania pojedynczo.

Answer 1

Okazało się, że problem był w istocie trywialny i nieco z powodu mojego braku doświadczenia z pythonem i błędnym komunikatem o błędzie.

Obiekt COM raw = win32com.client.Dispatch("MyLib.MyClass") służy do otwierania zastrzeżonych plików w pętli. Aby rozwiązać problem, należy "oczyścić" obiekt przed kolejną iteracją. Odbywa się to albo przez

del raw lub raw = None.

To całkowicie rozwiązuje problem. Nie ma to absolutnie nic wspólnego z datami lub datowaniem. Tak więc Peter Brittain miał prawdopodobnie rację, że ten limit plików został osiągnięty.