OmniDocRóżnica dat w Excelu wynosi cztery lata: najpierw spójrz na system dat w skoroszycie
iso_dates kontroluje metodę serializacji daty w pliku i nie zamienia automatycznie daty i godziny w pamięci na ciąg znaków. Numer seryjny daty wymaga epoki skoroszytu; tutaj porównujemy dwa systemy dat i sprawdzamy zapisane wartości XML i wartości odczytu.
Program Excel eksportuje daty przesunięte o cztery lata i w większości przypadków problem dotyczy systemu dat skoroszytu, a nie samych danych. Napisany dla programistów i osób odpowiedzialnych za eksport raportów, skrypty ETL lub międzyplatformową wymianę plików Excel. W przypadku wystąpienia sytuacji takich jak ogólne przesunięcie daty, liczby, których nie można wyświetlić jako dat, anomalie w danych około 1900 r. itp., można najpierw rozwiązać problem w kolejności opisanej w tym artykule.
Po przeczytaniu tego artykułu zrozumiesz różnicę między dwoma systemami dat 1900 i 1904, będziesz wiedział, jak odczytać workbook.epoch, aby potwierdzić system używany przez bieżący skoroszyt, oraz opanujesz metodę akceptacji sprawdzania XML i odczytywania wartości po zapisaniu. Kod i tabele w tym artykule zilustrowano syntetycznymi przykładami, odpowiednimi jako lista kontrolna przed pracą z prawdziwymi dokumentami.
Co powinienem zrobić, jeśli data w Excelu różni się o cztery lata? Wniosek w jednym zdaniu
Najpierw przeczytaj workbook.epoch skoroszytu i potwierdź system daty przed konwersją; Kwestie związane z datą graniczną i strefą czasową są rozpatrywane oddzielnie.
| twoja sytuacja | Zalecane praktyki | powód |
|---|---|---|
| Data wyeksportowania jest ogólnie przesunięta o około 1462 dni | Najpierw przeczytaj workbook.epoch, aby potwierdzić system dat skoroszytu | Różnica pomiędzy systemami 1900 i 1904 wynosi 1462 dni, a błędne założenia po stronie odczytu spowodują błędną interpretację wszystkich numerów seryjnych |
| Komórka jest liczbą, ale nie może być wyświetlana jako data | Sprawdź i uzupełnij maskę formatu daty number_format | Jeśli typ liczbowy jest prawidłowy, brakujące formaty spowodują nieprawidłowości w wyświetlaniu. |
| W danych pojawiają się daty sprzed marca 1900 lub 1900-02-29 | Oznacz jako nieważne lub przekaż do ręcznego przeglądu, zachowaj oryginalny numer seryjny | Data ta nie istnieje w kalendarzu gregoriańskim i nie należy jej wymuszać na przeliczaniu |
Należy zapisać datetime ze strefą czasową | Usuń tzinfo po ujednoliconej konwersji na UTC | Excel nie obsługuje przechowywania stref czasowych, wszystkie godziny są podane w czasie lokalnym bez świadomości |
| Pliki muszą być wymieniane między platformami | Jawnie zadeklaruj system dat | Domyślne ustawienia odbiornika są inne, co może powodować ciche przesunięcie |
Różnice pomiędzy systemami dat z lat 1900 i 1904
Data w pliku XLSX jest zasadniczo zmiennoprzecinkową liczbą seryjną, a jej znaczenie zależy całkowicie od systemu dat, z którym powiązany jest skoroszyt. Specyfikacja XLSX dopuszcza dwie podstawowe epoki:
- 1900 Date System: domyślnie używany przez system Windows, numer seryjny 1 oznacza 1900-01-01
- 1904 Date System: Używany domyślnie we wczesnych komputerach Mac, numer seryjny 0 oznacza 1904-01-01
Między nimi występuje stałe przesunięcie wynoszące 1462 dni, co jest głównym źródłem „czteroletniej różnicy dat". Ponadto system 1900 ma problem historyczny: błędnie traktuje rok 1900 jako rok przestępny, co powoduje, że nieistniejąca data 1900-02-29 zostaje zalegalizowana w Excelu.
Porównanie rdzenia
| Projekt | System dat 1900 | System dat 1904 |
|---|---|---|
| Punkt startowy numeru seryjnego | Numer seryjny 1 odpowiada 1900-01-01 | Numer seryjny 0 odpowiada 1904-01-01 |
| Powszechne źródła domyślne | Windows | Wczesny Mac |
| Przesunięcie z innego systemu | Różnica wyniosła 1 462 dni | Różnica wyniosła 1 462 dni |
| Numery specjalne | Błędnie licząc rok 1900 jako rok przestępny, istnieje 29 lutego 1900 | Ten artykuł nie porusza takich kwestii |
Dlaczego dane sprzed 1900 lat wymagają szczególnej ostrożności
Jeśli masz do czynienia z danymi historycznymi sprzed marca 1900 roku, modułdatetime w Pythonie nie może bezpośrednio reprezentować 29 lutego. Według oficjalnej dokumentacji OpenPyxl, aby wspierać zachowanie Excela, biblioteka symuluje ten wyjątek przy odczytach dat z stycznia i lutego w systemie 1900, ale sam 1900-02-29 nie może go przekonwertować na ważny obiekt Python datetime.
W przypadku większości nowoczesnych danych biznesowych kluczowe jest zidentyfikowanie, którego systemu używa aktualny zeszyt i wyraźne zadeklarowanie go podczas wymiany plików między platformami, aby uniknąć cichych przesunięcia spowodowanych różnymi domyślnymi ustawieniami odbiorcy.
Przykład syntezy: Metody wejścia i przetwarzania na granicy
Aby zobrazować problem, skonstruujmy scenariusz syntezy: system finansowy eksportuje raporty korzystając z systemu dat z 1904 roku, ale skrypty ETL domyślnie analizują system z 1900 roku.
Obsługa błędów lub wejścia granicznego:
- Jeśli wpiszesz numer seryjny 60, a zeszyt to system 1900, odpowiada on fikcyjnemu 1900-02-29 w Excelu. Natywny Python
datetimerzucaValueError. - W tym momencie nie wymuszaj konwersji; zamiast tego uchwyć anomalię i zapisz ją jako oryginalną wartość lub specjalny znacznik, ponieważ data ta nie istnieje w kalendarzu gregoriańskim.
- Jeśli obiekt
datetimezawierający informacje o strefie czasowej zostanie przesłany i zapisany, openpyxl nie przekonwertuje automatycznie strefy czasowej, lecz najpierw usuwa tzinfo; w przeciwnym razie mogą wystąpić błędy zapisu lub błędy. - Excel sam w sobie nie obsługuje przechowywania w strefach czasowych; cały czas jest niezauważalnym czasem lokalnym.
Kod wykrywania i konwersji systemu datowania
Poniższy przykład pokazuje, jak bezpiecznie radzić sobie z różnicami w systemie datowym w pamięci. Kod służy wyłącznie do logicznego pokazania i nie czyta ani nie zapisuje plików. Musi działać w twoim własnym zamkniętym środowisku zależności. Zalecany jest Openpyxl >= 3.1.0. Przykład nie obejmuje żądań sieciowych ani operacji nadpisywania plików; wszystkie asercje opierają się na danych syntetycznych.
from datetime import datetime
from io import BytesIO
from zipfile import ZipFile
from openpyxl import Workbook, load_workbook
from openpyxl.utils.datetime import from_excel, CALENDAR_MAC_1904, CALENDAR_WINDOWS_1900
assert from_excel(1, CALENDAR_MAC_1904) == datetime(1904, 1, 2)
assert from_excel(1, CALENDAR_WINDOWS_1900) == datetime(1900, 1, 1)
wb = Workbook()
wb.epoch = CALENDAR_MAC_1904
wb.iso_dates = True
value = datetime(2026, 9, 26, 12, 30)
wb.active["A1"] = value
assert wb.active["A1"].value == value
out = BytesIO()
wb.save(out)
with ZipFile(BytesIO(out.getvalue())) as z:
xml = z.read("xl/worksheets/sheet1.xml")
assert b't="d"' in xml and b"2026-09-26T12:30:00" in xml
restored = load_workbook(BytesIO(out.getvalue()))
assert restored.active["A1"].value == value
assert restored.epoch == CALENDAR_MAC_1904Kryteria akceptacji i granice ręcznej oceny
| Obserwuj to zjawisko | Warunki wejściowe lub brzegowe | Oczekiwane decyzje dotyczące wyników lub przetwarzania | Czy automatyzacja jest odpowiednia |
|---|---|---|---|
| Wszystkie daty są jednolicie przesunięte o 1462 dni | wb.epoch nie spełnia założenia analitycznego | Po odczytaniu wb.epoch przekonwertuj numer seryjny | Tak |
| 1900-02-29 pojawiło się w danych | System z 1900 roku z numerem seryjnym 60 | Oznacz jako nieważną datę, zachowując oryginalny numer seryjny 60 | Nie, znaczenie działalności musi być potwierdzone ręcznie |
| Czas jest częściowo stracony lub niedopasowany | Wpisz datetime z tzinfo | Po jednolistej konwersji na UTC, tzinfo jest ponownie usuwana i zapisywana | Niektóre wymagają ręcznego określenia docelowej strefy czasowej |
| Komórki wyświetlają liczby, ale są w formacie dat | Typ wartości jest poprawny, ale brakuje number_format | Sprawdź i uzupełnij maskę formatu daty | Tak |
| Historyczne daty (przed 1900-01-01) wykazują anomalie | Data wcześniejsza niż 1900-01-01 | Przejdź na przechowywanie tekstu lub dedykowane bazy danych historycznych | Nie, XLSX nie nadaje się do tego scenariusza |
Należy zauważyć, że demonstracja kodu jedynie potwierdza poprawność logiki konwersji i nie stanowi efektu end-to-end. Pliki rzeczywiste mogą łączyć różne formaty dat, formaty warunkowe lub daty generowane przez formuły, z których każda wymaga dodatkowych warstw parsowania. W przypadku dat sprzed marca 1900 roku, danych o współpracy między strefami czasowymi lub niestandardowych kalendarzy (takich jak lata księżycowe czy fiskalne) należy stosować ręczne procesy przeglądu, a automatyczne skrypty nie powinny być arbitralnie modyfikowane.
🎯 Która metoda ci odpowiada?
Jeśli musisz odczytać datę z pliku eksportu
Najpierw przeczytaj workbook.epoch, potwierdź system dat, a następnie zdecyduj, czy ponownie przekonwertować numer seryjny.
Jeśli twoje dane dotyczą dat sprzed marca 1900 roku
Oznacz dokument dotyczący 29.02.1900 jako nieważny, zachowaj oryginalny numer seryjny i przekaż go do instrukcji, aby potwierdzić znaczenie biznesowe.
Jeśli musisz zapisać czas z pasmami czasowymi w Excelu
Najpierw jednolicie konwersję na UTC, potem usunięcie tzinfo; Docelowa strefa czasowa musi być określona ręcznie.
Jeśli chcesz wymienić pliki z innymi systemami
Jawnie deklaruje system dat i weryfikuje wartość daty, którą ma odczytać po stronie odbiorcy.
❓ Najczęściej zadawane pytania (FAQ)
1. Dlaczego data eksportu jest ogólnie przesunięta o około cztery lata?
Częstym powodem jest to, że system dat w zeszycie ćwiczeń nie odpowiada założeniom po stronie czytania. Między systemami z 1900 i 1904 roku istnieje 1 462 dni.
2. iso_dates: Czy data będzie automatycznie przekształcona w ciąg znaków?
Nie. iso_dates kontroluje jedynie metodę serializacji dat w pliku i nie konwertuje automatycznie datetime w pamięci na ciąg znaków.
3. Dlaczego nie można przekonwertować 1900-02-29 na czas daty w Pythonie?
System z 1900 roku błędnie traktuje rok 1900 jako rok przestępny, przez co rok 1900-02-29 istnieje w Excelu, ale nie w kalendarzu gregoriańskim. datetime w Pythonie wyrzuca ValueError, który powinien zapisywać oryginalną wartość lub specjalny tag.
4. Jak zapisać datetime z przypisaną strefą czasową w Excelu?
Excel nie obsługuje przechowywania stref czasowych. Najpierw powinno być jednolicie przekonwertowane na UTC, a następnie zapisane po usunięciu tzinfo; OpenPyxl nie konwertuje automatycznie stref czasowych.
📝 Podsumowanie
Problemy z przesunięciem daty zwykle wynikają z systemu dat w zeszycie. Potwierdź workbook.epoch przed konwersją, co pozwoli uniknąć większości cichych błędów. Kwestie dotyczące granic, dat i stref czasowych powinny zostać przekazane do ręcznej weryfikacji.
Doświadczenie teraz: Prześlij dokument, aby zacząć tłumaczyć, zachowując oryginalne formatowanie
Bibliografia i kolejne kroki
- Oficjalny dokument daty i godziny OpenPyxl: https://openpyxl.readthedocs.io/en/stable/datetime.html
- Microsoft Explanation of the 1900/1904 system dat: https://docs.microsoft.com/en-us/office/troubleshoot/excel/1900-and-1904-date-system
- Wyjaśnienie Microsoftu błędu roku przestępnego 1900: https://docs.microsoft.com/en-us/office/troubleshoot/excel/wrongly-assumes-1900-is-leap-year
Następnie: Wybierz niespokojny przykład Excela, do którego masz dostęp, uruchom powyższy kod detekcji epoki i sprawdź, czy jego system dat odpowiada twojej logice przetwarzania. Jeśli zostaną wykryte nieścisłości, dostosuj parametry konwersji przed wygenerowaniem przetłumaczonego produktu.
Użyj tej listy kontrolnej do tłumaczenia dokumentów
Najpierw zdecyduj, która treść to tekst, a która formuła i kod biznesowy, a następnie przetłumacz tabelę. Inspekcja po tłumaczeniu nie tylko potwierdza, czy chiński został przekształcony w język docelowy, ale także zapewnia, że formuły, identyfikatory i relacje cytowania nie zostały zmienione.
OmniDoc (wpis produktu) oferuje wieloformatowe portale tłumaczeń dokumentów, a jego oficjalna strona internetowa wprowadza OCR, słowniki oraz funkcje dwujęzyczne referencyjne. Dla zespołów, które chcą zacząć bezpośrednio od plików, jest to ścieżka warta oceny na podstawie rzeczywistych próbek. Prosimy o użycie zanonimizowanego pliku, który uznałeś, aby przesłać i zweryfikować wyniki za pomocą listy kontrolnej opisanej w tym artykule. Niniejszy artykuł nie twierdzi, że OmniDoc korzysta z bibliotek open-source ani wewnętrznych algorytmów wymienionych w artykule, ani nie zastępuje testów wydajności produktów przykładami.
