Warum kann keine andere Software das Datum zuverlässiger berechnen als Excel!?
5 Antworten
Datumsberechnungen sind eine hoch komplexe Angelegenheit.
Dir mag das vielleicht leicht vorkommen, aber bei Schaltjahren hört es nicht auf, es gibt z.B. noch Säkularjahre.
Dann gibt's noch die Zeitumstellung und es gibt Zeitzonen und ggf. behandeln manche Länder das alles anders? So tief bin ich da nicht drin.
Microsoft haben in ihrem .NET-Framework vor vielen Jahren eine ziemlich umfassende Berechnung dafür entwickelt, die - durch .NET bzw. die Entwickler, die es nutzen - auch sehr lange und umfassend getestet wurde. Da liegt die Vermutung dahe, dass sie das auch für Office nutzen.
Bei z.B. Java gibt's meines Wissens nach nichts derart ausgereiftes und ich kann es ihnen nicht einmal übel nehmen, weil mir klar ist, wie komplex das sein kann.
Die Entwickler vieler Projekte werden einen Teufel tun und das selber berechnen, da akzeptiert man lieber Rechenfehler, denn die hast Du ziemlich sicher trotzdem, wenn Du selber rechnest.
Aber auch, wenn man .NET nutzt, muss man es auch richtig nutzen. Es gibt z.B. viele Entwickler, die kennen den Unterschied zwischen DateTime und DateTimeOffset nicht.
Es ist also ein bisschen Unwissenheit der Entwickler und zum Großteil die enorme Komplexität dieser Thematik im allgemeinen.
Deine Grundannahme, dass "keine andere Software das Datum zuverlässig(er) berechnen" kann, ist aber falsch. Es gibt definitiv andere Software, die richtig damit rechnet, vielleicht sind es viele, vielleicht auch nicht, dazu kann ich nichts sagen. Aber jetzt weißt Du zumindest die Hintergründe, warum viele Programme (nicht alle) Probleme damit haben.
Ich habe das ganz anders in Erinnerung:
Microsoft Excel has, since its earliest versions, incorrectly considered 1900 to be a leap year, and therefore that February 29 comes between February 28 and March 1 of that year.
Mir ist nicht bekannt, dass Kalkulationsteile von OpenOffice-Programmen damit Probleme hätten
Du hast aber recht. Zuverlässiger als zuverlässig gibt es nicht (meine Meinung).
Zuverlässig reicht mir. 😉
es gibt sehr viele Programme die es schlechter machen. Da werden die Schaltjahre nicht berücksichtigt und sowas.
Der Sinn ist zu testen ob die Leute eine Frage exakt beantworten oder interpretieren.
Oder anders gesagt Leute mit der Realität verarschen.
es gibt sehr viele Programme die es schlechter machen.
Das war nicht Inhalt Deine Frage. Du erinnerst Dich wirklich nicht?
keine andere Software das Datum zuverlässiger berechnen als Excel!?
Du hast geschrieben:
Es gibt sehr viele Programme die es schlechter machen.
Da würde mich mal interessieren, von wie vielen Programmen du das wirklich beurteilen kannst.
Ich, der nun schon seit gut 30 Jahren mit solchen Programmen arbeitet und zeitgleich mit dem „Heimanwender-PC“ großgeworden ist, kenne viele Office- und Tabellenkalkulationsprogramme (und ich schreibe hier absichtlich nicht sehr viele, weil das wohl nicht zutreffen würde), aber wirklich beurteilen, ob diese ein Datum zuverlässig berechnen können, kann ich mit Sicherheit nur von wenigen sagen, weil ich nur wenige verschiedene jemals selbst benutzt habe oder von diesen habe Daten berechnen lassen.
Excel kann das jedenfalls nicht.
Dass es Programme gibt, die das noch schlechter können, ist denkbar.
Sekunden ab dem 01.01.1900 in ein richtiges Datum umrechnen. Mit allen daraus folgenden Konsequenzen.
Sekunden kann man nicht in ein Datum umrechnen. Ergebnis beim Umrechnen gäbe es
- Sekunden zu Minuten
- Minuten zu Stunden
- Stunden zu(m) Tag(en).
Das Ergebnis ist aber kein Datum sondern eine Anzahl der - letztendlich - Tage
Damit kannst Du allerdings von Datum + Tage = Datum ermitteln.
Sekunden an sich nicht.
Aber z.B. 2^31 Sekunden ab dem 01.01.1970 ergibt ein konkretes Datum, nämlich den 19.01.2038. Da steht uns noch was bevor ...
Ich habe das gestern auch von Excel berechnen lassen – und Excel konnte es korrekt berechnen.
Genauer als eine Trefferquote von 100% geht halt nicht.
Und die 100% sollten alle Tabellenkalkulationsprogramme haben wenn man sie richtig bedient.
War tatsächlich ein Bug in Lotus, der in Excel absichtlich übernommen wurde um Kompatibilität der Dokumente zu wahren. Die Erkennung des Schaltjahres war an der Stelle falsch implementiert. Der Tag wird tatsächlich inkorrekt falsch ausgegeben, was natürlich nur in seltenen Fällen überhaupt mal jemand merkt.
Gerundet sind wir wohl immer noch bei 100% Genauigkeit :D
Du sagst es doch selbst es WAR. ein Bug in einer Software und zwar einer Software von der ich seit Jahren nichts mehr gehört habe.
Ich könnte natürlich auf "100% aktueller Tabellenkalkulationsproramme" umändern aber da ich das eigentlich für selbstverständlich hielt das ich nicht von Software rede die z.B. aus dem letzten Jahrtausend ist habe ich das nicht gemacht.
Das hat jemand tatsächlich gemerkt, indem er die Gaußsche Osterformel implementiert hat, und nur Schrott als Angabe des Osterdatums herauskam.
Der von ihm kontaktierte Microsoft-Support meinte, dass wohl ein Fehler in der Formel vorliegt. Das empfinde ich als Abiturient eines Gauß-Gymnasiums als bodenlose Frechheit. Die Leute bei MS sollten erstmal rechnen lernen und dann sich informieren, was denn ein Schaltjahr ist.
Ich kann mir vorstellen, dass es dazu verschiedene Aussagen gibt, da Supporter und Entwickler sowas nicht unbedingt austauschen. Es gibt mehrere Quellen die die Kompatibilität zu Lotus aufführen, aber vielleicht haben die auch eine Funktion übernommen und es später versucht zu rechtfertigen.
Ob ein Jahr Schaltjahr ist oder nicht, kannst Du leicht selber programmieren. Beispielsweise in C:
int leapYear(int y)
/*----------------------------------------------------------------------
* Returns whether y is a leap year or not. Reference: english Wikipedia.
*----------------------------------------------------------------------
*/{
int i,result;
i = y/4;
if(i*4 != y)
result = 0;
else
{
i = y/100;
if (i*100 != y)
result = 1;
else
{
i = y/400;
if (i*400 != y)
result = 0;
else
result = 1;
}
}
return(result);
} /* leapYear()*/
Das kann man auch übersichtlicher programmieren, aber es ist zumindest richtig.
Ich war damals mit den Nerven am Ende. Grund: Ich hatte mich vorher über die deutsche Wikipedia schwarz geärgert. Schwülstige, schöngeistige historische Ergüsse für esoterische Bildung, aber nichts mit Hand und Fuß was man mal eben schnell nachprogrammieren kann. Huiii, was sind wir heute mal wieder enzyklopädisch! Als ich endlich in die englische Wikipedia flüchtete wollte ich nur noch den Sch... hinter mich bringen, deshalb stellte ich mich doof und programmierte es so.
Ja, ist ja alles gut 😉.
Um in C zu testen, ob eine Zahl durch 100 teilbar ist, kann man auch
if((y % 100) == 0) ...
schreiben. Deine Version ist die "klassische" Variante. Die funktioniert immer.
Oh, danke. Dann geht das doch noch kürzer: if(!(y % 100)) ...
Das ist richtig.
Aber da ich nach MISRA-Standard programmieren muss, darf ich das nicht. 😀
Aber zumindest goto ist in bestimmten Fällen wieder erlaubt.
genau. Ich habe nicht geschrieben dass es kein Programm so gut kann wie Excel :)