SoftMaker.de

Hallo,
bei mir läuft PM 2010 Rev.574 unter Windows XP SP3.

Habe Probleme bei Formatieren von Zellen/ganzer Spalten mit einem eigenen Datumsformat. Unter benutzerdefiertem Format habe ich für den korrespondierenden Monatstag neu hinterlegt " TT. " (natürlich ohne die Anführungszeichen). Die Eingabe geht dann schneller, weil man sich die führende Null und den Folgepunkt ersparen kann. das macht dann das Programm.

Für eine spezielle Anwendung benötige ich diese Zellformatierung für jeweils einen Tag des Monats, z.B. für den ' 2.Februar 2010 '. Eingabe in die Zelle: einfach die Ziffer < 2 > und < RETURN >. Nach Übernahme sollte in der entspechend formatierten Zelle erscheinen: 02. --- Tut es aber nicht! Es erscheint immer ein Tag weniger, in diesem Fall: 01. . So kommt beispielsweise bei Eingabe der 31 die 30. , bei 10 die 09. , bei 20 die 19. , bei 01 die 31. , und so weiter.

In MS-Excel klappt die Sache einwandfrei. Bei einer in Excel richtigen Tabelle erscheint ebenfalls bei Aufruf mit dem PM immer der Tag, zweistellig mit Folgepunkt (wie in Excel auch), aber stets minus 1, siehe oben.

Ebenso läuft es anders herum. Lege ich die Tabelle mit dem PM an, speichere sie im MS-Office kompatiblen Format und rufe sie dann mit MS-Excel auf, steht in den fraglichen Zellen der Tag zwar im richtigen Format, aber dann stets plus 1, was ja somit logisch ist.

Ich möchte fast auf einen Programmfehler im PM tippen oder --- mache ich da etwas falsch?

Gern höre ich mal, was andere feststellen und wie man das in den Griff bekommen wird.
Bis dahin!

So wie ich das sehe, verdaut PM einfach keine unvollständigen Daten. Wenn man bei dieser Formatierung z. B. tippt: "02.02.2010", dann erscheint tatsächlich die Anzeige "02.". Eine entsprechende Nur-Tag-Eingabe müsste wohl eher über Zahl "00." definiert werden.

Zum Thema Daten findet sich im Handbuch übrigens folgender Hinweis:


Die Eingabe einer blossen Kardinalzahl in einer als "Datum" markierten Zelle führt daher nicht zum gewünschten Ergebnis. Wie ich bereits an anderer Stelle erklärt habe, kann PM nicht von sich aus wissen, was mit der Eingabe einer blossen Kardinalzahl gemeint ist. Ausserdem bestimmen Formatierungen nur, wie etwas dargestellt wird, also das Aussehen, nicht aber was intern damit geschehen soll.
Im vorliegenden Fall kann PM also mit einer blossen "2" im Grunde nur zwei Dinge anstellen: Entweder interpretiert er "2" als "Tag 2 in der Reihe beginnend mit 0=1.1.1900", dann müsste er daraus aber eigentlich die Darstellung "03." machen. Oder aber er schaut unter Format nach und beschliesst dann, dass "TT." bedeuten soll, dass eine blosse Tages-Zahl eingegeben werden solle, und macht daraus dann "02.". Dieser zweite Weg ist aber eigentlich nach dem erwähnten Prinzip, dass Formatierungen nur die Darstellung, aber nicht die "Innereien" beeinflussen dürfen, nicht erlaubt - abgesehen davon, dass es bei Daten keine blossen Tage, Monate oder Jahre geben kann. Diese müssten streng genommen als Zahlen eingegeben werden.
Dass PM diese Schlaumeierei nicht akzeptiert, ist daher nur konsequent und IMHO richtig. Was mir nicht klar wird, ist der Grund, warum aus "2" aber "01." wird statt (richtig, wie oben ausgeführt) "03.", denn eigentlich steht die Zahl 2 im internen Datumsformat für den 3. Januar 1900. Die korrekte Definition dieser Reihe lautet: "Wieviele Tage sind seit dem 1. Januar 1900 vergangen?" Am 1. Janaur 1900 sind natürlich 0 Tage seither vergangen, am 2. Janaur aber bereits 1 Tag.
Ich habe also eher den Eindruck, dass Excel da wieder einmal etwas geschlaumeiert hat. Warum aus 2 nicht 3 wird, das sollten sich die SoftMaker aber mal anschauen.

Nachtrag und kleine Übungsaufgabe:

Man gebe die Formatierung Datum / "TT." ein und tippte danach probehalber ein paar mehrstellige Zahlen, z. B.:
1000 = 26.[09.1902]
5000 = 08.[09.1913]
50000 = 21.[11.2036]

Was PM da macht, mag nicht das gewünschte Ergebnis sein, aber es ist, soweit ich das sehe, das richtige.

Bei der Eingabe von z.B. der Zahl "2" unter der Formatierung "TT. " gehen PM wie auch Excel von dem Datum 02.01.1900 aus. Nimmt man nun in anderen Zelle - formatiert auf "Zahl, 0-Stellen" -Bezug auf eine dieser Zellen, sieht man, dass Excel exakt diese Zahl übernimmt und PM den Wert um 1 erhöht. Das erscheint mir ein Fehler zu sein und sollte sich einer vom SM-Team mal ansehen. Anbei ein Bildschirmausdruck.

Ja, das ist ein Fehler, allerdings einer in Excel. Die haben das Jahr 1900 zum Schaltjahr erklärt, was es nicht ist. Daher weicht der absolute Zahlenwert bei PlanMaker zwischen dem 1.1.1900 und dem 28.2.1900 um 1 ab. Danach verschwindet die Differenz, weil es den 29.2.1900 nicht gab.

_________________
Martin Kotulla
SoftMaker Software GmbH

Uups - bei Definitionen sollte man aufpassen. Gestern hatte ich geschrieben, dass in Tabellenkalkulationen die Anzahl Tage seit dem 1. 1. 1900 gezählt werde. Dann wäre (logisch gedacht) der 1. 1. 1900 Tag 0, der 2. Januar Tag 1, der 31. dann Tag 30, der 1. Februar 1900 Tag 31, der 28. Februar Tag 58 und der 1. März Tag 59 - oder richtiger: 1. Januar 1900 plus 59 Tage (und bei allen Daten entsprechend, eigentlich die Differenz an Tagen).
Aber: So isses nich!
Die "Logik" ist eine andere: Der 31. März ist Tag 61 - und da beginnen dann die Problem, denn 60 ist bei Excel der 29. 2. 1900 - ein Phantomtag -, und Tag 1 ist nicht etwa der 2. Januar, sondern der 1. 1. 1900. Bei PM ist aber Tag 60 nicht der (nicht existierende) 29. Februar, sondern der 28., entsprechend ist dann Tag 1 nicht der 1. 1., sondern der 31. 12. 1899.

Ich meinte mich zu erinnern, dass Grotefend schon vor 1900 publiziert habe. Aber das Taschenbuch der Zeitrechnung ist wohl nie auf Englisch übersetzt worden ...

Soviel nur mal zur Klärung, falls ich mit meinen gestrigen Ausführungen Verwirrung gestiftet haben sollte.

@Panosis
Jetzt bin ich aber ziemlich verwirrt! Soll das bedeuten, dass die (Computer)zeitrechnung am 01.03.1900 (mit 61) beginnt??? Oder waren die Amis (mit dem Schaltjahr) einfach zu blöd und der Rest der Welt muss jetzt mit einem falschen Datumswert leben? Ich dachte immer der 01.01.1900 ist der Tag 1 und dann werden einfach Tage dazugezählt (ich muss zugeben, dass ich noch nicht nachgeprüft habe, ob denn der Zahlenwert für den heutigen Tag von Excel richtig wiedergegeben wird).

Habe ich es richtig verstanden. dass PM am 31.12.1899 mit 1 beginnt?

_________________
Gruß
moba

Medion akoya E5218
Windows 7 und Ubuntu 11.10
Softmaker Office 2010 Rev.600
Datamaker 2009 Beta

Ja, du liebs Herrgöttle von Biberach - die Computer-Zeitrechnung beginnt höchst unterschiedlich.

Wir sprechen hier von PM und nebenbei von Excel. In Excel beginnt die "Zeitrechnung" am 1. 1. 1900 mit 1, soweit ich das festgestellt habe. Sodann hat dort das Jahr 1990 einen Schalttag, den es real nie gab.
PM versucht zu Excel nach Möglichkeit kompatibel zu sein, was immer dann zu Problemen führt, wenn Excel einen Fehler enthält. Das ist hier der Fall. Entweder stellt also PM eine eigene Zeitreihe auf, oder aber PM zählt vom 1. 3. 1900 an wie Excel, lässt aber den Phantom-Schalttag aus und zählt vom 1. 3. 1900 an rückwärts - dann kann aber der 1. 1. 1900 nicht Tag 1 sein. PM hält sich nun genau an dieses zweite Verfahren, das den Vorteil hat, dass die überwiegende Masse aller möglichen Datumsangaben mit Excel identisch ist - nicht aber die Tage vom 1. 1. 1900 bis 28. 2. 1900.

Nach der von mir gestern erwähnten, über Excel hinaus verbreiteten Definition müsste es eigentlich nochmals anders sein und sollte der 1. 1. 1900 eigentlich Tag 0 sein, aber das bleibe mal aussen vor.

Um die Sache nochmals komplizierter zu machen: Unter Mac OS beginnt die Excel-Zeitrechnung 1904.
Wieder andere Tabellenkalkulationen gehen nochmals andere Wege. Etwa Google Spreadsheet zählt den Kalender korrekt. Ich habe die interne Zählung dieser Anwendung nicht getestet, aber ich nehme mal an, dass dort 1. 1. 1900 = 1 ist - und anscheinend sind auch negative Zahlen, d. h. Daten vor 1900, möglich.

Alles nunmehr völlig unklar?

Ganz im Gegenteil! Auf gut Deutsch: es gibt keine Norm, jeder macht, was er gerade für richtig hält, wobei offensichtlich das google spreadsheet die intelligenteste Lösung hat (weil es sicherlich nicht versucht mit Excel kompatibel zu sein). Wobei meines Erachtens wirklich intelligent wäre, den 00.00.0000 (an Christi Geburt) als den Tag 0 zu nehmen und von da aus mit plus oder minus wegzugehen. Aber dann wärs ja nicht zu den Amis kompatibel.

Ich bin nur davon ausgegangen, dass die Berechnung des Datums genormt ist.

Danke für die Aufklärung.

_________________
Gruß
moba

Medion akoya E5218
Windows 7 und Ubuntu 11.10
Softmaker Office 2010 Rev.600
Datamaker 2009 Beta

Hallo Leute,

jetzt ist es mir fast peinlich, denn ich wollte mit meiner Nachfrage keinesfalls eine solche Lawine lostreten. Finde es aber ganz toll, dass so ein Echo gekommen ist. Hierfür danke ich Euch allen herzlich.

Nun nochmal zu den mathematischen Fakten:
Der Martin hat absolut Recht, 1900 war kein Schaltjahr. Das passiert alle vier Jahrhundertwechsel. Folglich 2000, 2100 und 2300 sind Schaltjahre. Dann 2400 ist mal wieder keins, hat mit der Astronomie zu tun und gleicht geringe Zeitdifferenzen aus.

Mathematisch gesehen beginnen die neuen Jahrhunderte erst mit dem Anbruch des ersten Tages des neuen Jahrhunderts, dann, wenn die Endnull xxx0 zur Endeins xxx1 wird. Genau ist es der Übergang aus der Null in das erste Jahr des neuen Jahrhunderts. Das haben die meisten Leute übersehen. So wurde auch das Neue Jahrhundert bereits ein Jahr zu früh gefeiert, als beim Eintritt in den 1. Januar 2000 bereits die Sektkorken knallten. Das nur nebenbei. Es herrscht hier keine Einigkeit und das stiftet Verwirrung.

SoftMaker sagt eine sehr weit reichende Kompatibilität zu MS-Excel zu. Diese ist aber in meinem Fall nicht realisiert worden. Gut, Microsoft hat hier offenbar den Fehler gemacht, aber SoftMaker kam erst später und hätte sich auch auf einen solchen Fehler einstellen können (oder müssen, wenn man kompatibel sein will). Jedenfalls stellt es sich so dar, dass ich nun alle bereits vorhandenen Tabellen weiterhin mit Microsoft lesen und bearbeiten muß, alle neuen zwar mit dem schönen PlanMaker machen kann, dann aber immer softwaremäßig zweigleisig fahren muss. SoftMaker wird sicher nicht behaupten können, dass diese Verfahrensweise komfortabel ist. Deshalb möchte ich eher eine Korrekturlösung seitens Softmaker begrüßen weil auch ältere Excel-Tabellen in jeder Menge existieren.

Aber ein großes DANKE für das lebhafte Echo und ... natürlich darf auch weiter diskutiert werden, denn das Thema scheint interessant zu sein.

Frohes Schaffen

Ähm. Wenn Sie in eine Tabelle eine 2 eingeben und dann als TT formatieren, haben Sie nicht den 2. Februar 2010 eingegeben, sondern den 2. Januar 1900.

Wenn Sie einfach nur eine laufende Zahl (die lediglich der Benutzer als Datum betrachtet) brauchen, dann sollten Sie als Formatierung ## oder 00 verwenden.

_________________
Martin Kotulla
SoftMaker Software GmbH

Nein, nein und nochmals nein! Kompatibilität zu Excel heißt in erster Linie kompatibel zu den Funktionen von Excel zu sein, nicht aber zu seinen Fehlern. Auf Fehler einstellen bedeutet zunächst einmal, den Fehler nicht wiederholen und es gleich richtig machen. Hier müsste sich MS bemühen, den Bug auszumerzen. Es ist für Sie bestimmt nicht schön, hier ggf. zweigleisig fahren zu müssen, aber dass können Sie nun mal nur B.Gates anlasten. Es kann nicht angehen, dass SMO-Anwender mit Fehlern beschenkt werden, damit MS sich nicht bewegen muss.
Aber davon mal abgesehen. Wenn sich die Inkompatibilität innerhalb der Word-Dokumente von Word 2010 zu Word 2003 auch auf die Excel-Dokumente ausweitet, dann werden die MSO-User sich an Mehrgleisigkeit sowieso gewöhnen müssen.

Ähm... falsch.
Alle glatten Hunderter sind KEINE Schaltjahre, ausser die glatt durch 400 teilbaren Jahre.
D.h. 1900, 2100, 2200, 2300 sind keine Schaltjahre, 2000 und 2400 sind es.



@Greifenklau: Die Umlaute in deinem letzten Beitrag sind kaputt. Hast du was an den Einstellungen deines Systems geändert oder von einem anderen System als sonst aus geschrieben?

Habe das auch schon bemerkt. ich weiß; nicht, woran das liegt. äöüß
Scheint wieder zu funktionierenn nachdem ich eine Textdatei im TM wieder geschlossen habe - was ich aber ganz und gar nicht nachvollziehen kann.