Datum wird fehlerhaft kopiert, von .xls zu .xlsx

[Kai]

Eine .xls Datei wird von einem anderen Programm erzeugt, listet in den beiden ersten Spalten ein Datum auf (dd.mm.jjjj).
Geöffnet mit Planmaker, werden diese Angaben als Datum gelistet, und korrekt angezeigt.

Werden diese Daten jedoch mit "Werte einfügen" in eine .xlsx Datei kopiert, ist das Jahr um -4 Jahre versetzt.
Werden die Daten der Original-Datei als "Standard" formatiert, zeigen sich Zahlen, die dem "falschen" Datum entsprechen.

In MS Excel kommt das so nicht vor. Damit gehe ich davon aus, dass PM hier etwas anders implementiert hat, was mir fehlerhaft erscheint.

[greifenklau]

Müsste ein Bug in PM sein; das gleiche mit Numbers durchgespielt ergibt den gleichen Fehler.
Das sollte sich das Team von SoftMaker mal ansehen.

[Herr S.]

Tach!

Das ist kein Bug sondern hängt damit zusammen, wie Windows und macOS mit Datumsangaben umgehen.
Windows verwendet das Datumsystem von 1900. Startpunkt ist hier der 01. Januar 1900.
macOS verwendet das Datumsystem von 1904. Startpunkt ist hier der 01. Januar 1904.
Das ergibt also eine Differenz von vier Jahren und einem Tag (wg. Schaltjahr).

Die Softmaker-Anwendungen sind Windowsprogramme, welche auf macOS konvertiert wurden und intern mit dem 1900er Datum arbeiten. Werden also Daten aus einer macOS-Tabellenkalkulation, wie z.B. Numbers, nach Planmaker importiert, so verschieben sich die Datumsangaben um vier Jahre und einen Tag. Werden Daten aus Planmaker in eine macOS Tabellenkalkulation, wie z.B. Numbers, importiert, werden die Datumsangaben in Numbers ebenfalls um vier Jahre und einen Tag verschoben, nur eben in die andere Richtung.
Microsoft Office für macOS verwendet ebenfalls standardmäßig das 1904er Datumsformat des Mac, so dass Datumsangaben, die in Excel für Mac erstellt wurden, beim Import in Planmaker ebenfalls wieder um vier Jahre und einen Tag verschoben sind.
Die letzte Microsoft Office Version die ich auf meinem Mac verwendet habe, war MSO 2011. Wenn mich meine Erinnerung nicht trügt, gab es dort einen Schalter mit dem man festlegen konnte, ob das 1900er oder das 1904er Format verwendet werden soll. So etwas bräuchte Planmaker auch, um mit dem Datumsformat des Mac kompatibel zu sein. Wenn das Datumsformat von Planmaker für Mac einseitig auf das 1904er Format geändert werden würde, wäre es bezüglich der Datumsformate nicht mehr kompatibel zu Planmaker für Windows und Linux.

[martin-k]

Datei, Eigenschaften, Kompatibilität, Datumssystem -> 01.01.1904

[Herr S.]

Das ging schnell! Schwupps ist der Umschalter programmiert!

[Herr S.]

Datei, Eigenschaften, Kompatibilität, Datumssystem -> 01.01.1904

Ich habe gerade einmal ein wenig mit der Einstellung herumgespielt und einige Datumsangaben von Planmaker nach Numbers kopiert und dabei folgendes festgestellt:

• Erstelle ich ein neues Planmakerdokument (01.01.1904 ist voreingestellt), gebe dort ein Datum ein (Zellformat Datum), kopiere anschließend das Datum und setze es in Numbers ein, wird das Datum in Numbers korrekt übernommen.

• Öffne ich ein bestehendes, älteres Planmakerdokument (xlsx-Format, 01.01.1904 ist voreingestellt), kopiere ein dort vorhandenes Datum (Zellformat Datum) und setze diese in eine Numberstabelle ein, wird das Datum um vier Jahre verschoben angezeigt. Schalte ich in dem Planmakerdokument die Datumseinstellung zwischen 1900 und 1904 hin und her, werden die Datumsanzeigen in Planmaker entsprechend geändert. Für Numbers ist es allerdings unerheblich, ob ich in dem alten Planmakerdokument das 1900 oder 1904 Format ausgewählt habe. Die Anzeige ist immer um vier Jahre verschoben.

[Kai]

Danke für die schnellen Antworten.
Die Zieldatei (erstellt auf Mac mit MS Excel) hat als Datumssystem den 31.12.1899 eingestellt. Die Quelldatei, mit den "frischen" Daten die ich übernehmen möchte, hat als Datumssystem den 01.01.1904 eingestellt.
Jetzt ist mir zumindest verständlich, warum ein simples Kopieren von Datumswerten zu überraschenden Ergebnissen führen _kann_.

Jetzt würde ich als Benutzer doch erwarten, dass ein Copy&Paste Vorgang diese Unterschiede erkennt und entsprechend korrigiert. So kenne ich es von MS-Excel für Mac. Und erwarte es auch von Planmaker ...
Natürlich kann ich mir für diesen speziellen Zweck einen Workaround basteln. Aber dafür gibt es doch "mitdenkende" Programme, oder?

[Kai]

Nach längerer Pause möchte ich den Umgang mit verschiedenen Startpunkten für Datums-Angaben noch einmal angehen.
Ausgangpunkt ist, dass ich Konto-Bewegungen aus meinem Finanzprogramm im Mac, ausgegeben in .xls, in eine Übersicht (.xlsx) über verschiedene Konten und Jahre zusammenführen möchte. Für diese Zusammenstellung wurde über viele Jahre MS-Ecel benutzt. Damit konnte ich problemlos Teile der Kontobewegungen markieren, kopieren, und mit "Wert einfügen" in die Sammeldatei kopieren.
Ich habe keinen Einfluss auf das unterstellte Startjahr, mit dem das Finanzprogramm Auszüge erstellt (01.01.1904). Und es ist nicht praktikabel, die Zusammenstellung (Start 30.12.1899) auf ein anderes Startjahr umzustellen, damit die eingefügten Werte passen (10 Dateien, jeweils >20 Blätter).

Ich habe kein Verständnis dafür, dass PM beim Copy & Paste das Ursprungs- bzw Ziel-Zahlenformat nicht komplett betrachtet wird. Schließlich gehört die "Startbasis" eines Datums inhärent mit zur korrekten Interpretation des Inhalts. Anzunehmen, dass ich als Nutzer diese kenne, standardmäßig prüfe, herausfinde, wie PM damit umgeht - das kann es irgendwie nicht sein. Nicht zuletzt findet sich auch im aktuellsten Handbuch nur der Hinweis:
"Hier können programminterne Einstellungen zur Kompatibilität mit älteren PlanMaker-Dokumenten und Excel-Dokumenten vorgenommen werden. Diese werden beim Öffnen des Dokuments automatisch gesetzt und sollten normalerweise nicht verändert werden." Da wird die dahinterliegende Komplexität nicht annähernd erkennbar.

[greifenklau]

Wie soll PM erkennen können, dass eine Datumszahl in Windows oder in einem Unix-System erstellt worden ist?
Dein Wunsch würde bedeuten, dass PM in jeder Datei die Datumsformatierung 1.1.1900 oder 1.1.1904 speichert und beim Öffnen die Umstellung in PM vornimmt, wenn man die jeweilige Einstellung nicht dauerhaft haben will. Dumm nur, wenn man 2 Dateien geöffnet hat - eine mit Datumseinstellung a) und die zweite mit b).

[Kai]

Zum Einen kann das PM erkennen, mit dem Menu-Punkt Datei-Eigenschaften-Optionen-Kompatibilität wird das Bezugsjahr angezeigt. Die Information gibt es also.
Ebenso gelingt es MS-Excel diesen Kopiervorgang korrekt durchzuführen, mit verschiedenen Bezugsjahren.
Und ja, auch LibreOffice stolpert an der Stelle. (Also auch kein Kandidat für einen geschickten Umweg.)

[Goonies]

Das sehe ich genau so.
Warum kann M$ das und warum PM nicht?

Ich bin über dieses Problem schon so oft gestolpert...
Und selbst das Kopieren von Datumsangaben (bspw.) von Webseiten etc. klappt nur mit dem jeweiligen Versatz von 4 Jahren+1 Tag, wenn die jeweiligen Tabelleneinstellungen eben so sind, wie sie sind.
Dabei gehe ich doch davon aus dass eine extern (Webseite) kopierte Datumsangabe erstmal nur als Plaintext in der Zwischenablage liegt, völlig unbeleckt von System-Datums-Einstellungen...

Das muss doch von so einem Programm, wie PM richtig interpretierbar sein?!

M$ schafft das doch, wie gesagt, auch...

[FFF]

Was Windows beim Kopieren in die Zwischenablage legt, entscheidet erstmal Windows selber.
Was die "Quelle" an Formaten schickt, die Quelle.
Welche Version dann benutzt wird, entscheidet das "Ziel", ebenso, "wie" es den Inhalt interpretiert.
Das da "nur" Plaintext abgelegt ist, ist unwahrscheinlich .

Das MS "das hinbekommt" ist nicht so verwunderlich, sie kontrollieren mindestens zwei der drei Beteiligten - und sie "hacken" dabei an den Regeln vorbei seit Tag 1. Man darf es der Konkurrenz ja nicht zu leicht machen...