Frage

Excel interpretiert Dezimalzahl f. Achsenskalierung als Datum

Hallo,

ich habe ein seltsames Problem in Excel festgestellt: Das Programm scheint die Zahleneingabe in manchen Feldern als Datum zu interpretieren, wenn man vom Betriebssystem aus den Punkt als Dezimaltrennzeichen eingestellt hat. Sobald ich zum Skalieren einer Achse in einem Diagramm eine Dezimalzahl angeben will, wird diese also als Datum interpretiert, dann holt Excel sich den numerischen Wert dieses Datums und benutzt diesen dann als Skalierung. Wenn ich also eine Achse von 0.9 bis 1.1 skalieren will, wird der untere Wert richtig angenommen, da 0.9 kein gültiges Datum ist; die obere Grenze wird allerdings auf 40179 gesetzt. (1.1 = 40179, 2.1 = 40180 etc.)

Aus verschiedenen Gründen möchte ich die Einstellung des Dezimalpunktes im Betriebssystem behalten. Es wäre schon sehr ärgerlich, wenn sich dieses Problem nicht anders beheben ließe.

Beste Grüße


Am 13.08.2010 18:16, schrieb ccarmy:

Aus verschiedenen Gründen möchte ich die Einstellung des Dezimalpunktes im Betriebssystem behalten. Es wäre schon sehr ärgerlich, wenn sich dieses Problem nicht anders beheben ließe.

In meinen XL2002 finde ich unter Extras\Optionen\International die Möglichkeit die Trennzeichen einzustellen / vom Betriebssystem zu übernehmem.

Andreas.

Wurde Ihr Problem dadurch behoben?

Das war leider nicht hilfreich.



ccarmy meinte:

ich habe ein seltsames Problem in Excel festgestellt: Das Programm scheint die Zahleneingabe in manchen Feldern als Datum zu interpretieren, wenn man vom Betriebssystem aus den Punkt als Dezimaltrennzeichen eingestellt hat.

Nur so aus der Hüfte geschossen: Kann es sein, dass Du den Punkt jetzt als
Dezimal und Datumstrenner hast?

Christoph Sternberg */\

Wurde Ihr Problem dadurch behoben?

Das war leider nicht hilfreich.


Nur so aus der Hüfte geschossen: Kann es sein, dass Du den Punkt jetzt als
Dezimal und Datumstrenner hast?

Christoph Sternberg */\

Ja, für beides ist der Punkt eingestellt. Das sollte an sich aber kein Problem sein, weil es -- so vermute ich -- an Excel liegt, wie es die Eingabe in den Feldern interpretiert: Bei den beiden ist es offensichtlich so, dass der Zahlentyp, mit dem die Eingabe ausgelesen wird, nicht auf "Dezimalzahl" festgelegt ist, sondern eben erst durch Excel nochmal uminterpretiert wird -- so, als würde ich unter Verwendung des Komma als Dezimaltrennzeichen in einer Tabelle "2.5" eingeben, das wird dann ja auch als Datum interpretiert.

Die Felder "Hauptintervall" und "Hilfsintervall" zeigen dieses fehlerhafte Verhaltennicht . Ich tippe also darauf, dass dort (saubere Programmierung?) vorgegeben ist, dass die Angabe eine Gleitkommazahl sein muss. Anders kann ich mir diesen Konflikt nicht erklären.

Zusatz: Erwartungsgemäß lässt sich das Problem dadurch umgehen, dass das Trennzeichen im Datumsformat betriebssystemseitig umgestellt wird.

 

@Andreas Killer: Danke für die Antwort, ich weiß auch um die Option, aber leider bringt es mir nichts -- denn damit kann ich zwar wieder auf das Komma als Dezimaltrennzeichen zurückstellen, aber ich will ja gerade den Punkt behalten. Die Lösung besteht also nicht darin, das Dezimaltrennzeich zu ändern, sondern Excel auszureden, den Punkt auch als Trennzeichen für Datumsangaben zu interpretieren (s.o.). Das funktioniert zwar, ist aber auch nicht im Sinne des Erfinders.

Wurde Ihr Problem dadurch behoben?

Das war leider nicht hilfreich.


Am 14.08.2010 16:00, schrieb ccarmy:

@Andreas Killer: Danke für die Antwort, ich weiß auch um die Option, aber leider bringt es mir nichts -- denn damit kann ich zwar wieder auf das Komma als Dezimaltrennzeichen zurückstellen, aber ich will ja gerade den Punkt behalten. Die Lösung besteht also nicht darin, das Dezimaltrennzeich zu ändern, sondern Excel auszureden, den Punkt auch als Trennzeichen für Datumsangaben zu interpretieren (s.o.). Das funktioniert zwar, ist aber auch nicht im Sinne des Erfinders.

Naja, ja, nein. :-))

Im Sinne des Erfinders ist es dem User alle "Hindernisse", wie z.B. zuerst die Zelle auf Datum zu formtieren und erst dann das Datum einzugeben, abzunehmen. Man muss also quasi nicht einwandfrei arbeiten.

Genauso wird es auch bei übertragen der Daten in z.B. die Grafik gehandhabt, eine Zahl die in einer als Text formatierten Zelle steht wird trotzdem als Zahl interpretiert.

Wenn man noch weiter auf die Programmierung-Ebene (Makro/VBA) geht wird es deutlich was dort eigentlich passiert, man kann Texte und Zahlen und Datumsangaben bunt durcheinander zueinander zuweisen und es wird automatisch eine Typ-Konvertierung durchgeführt.

Dieses Verhalten wird, im allgemeinen, als Erleichterung empfunden und ganz ehrlich, ich glaube dadurch ist Office auch so weit verbreitet. Wenn ich an "alte" Zeiten an meine Anfänge zurückdenke, dann war man schon aufgeschmissen wenn man nicht wusste wie man einen REAL-Datentyp (eine Zahl mit Kommastellen) in einen INTEGER-Datentyp umwandeln konnte. Das geht heutzutage "von alleine".

In diesem Sinne hast Du leider Pech gehabt.

Aber mal 'ne blöde Frage: Wieso schreibst Du Deine Zahl nicht "vernünftig" mit 'nem Komma?

Eine Umwandlung von 0.9 in 0,9 ist mit Excel ziemlich einfach und auch gerade dann wenn man dies aus einer anderen Datenquelle einliest.

Andreas.

Wurde Ihr Problem dadurch behoben?

Das war leider nicht hilfreich.


Hallo Andreas,

ich habe das Gefühl, dass wir über vollkommen verschiedene Dinge reden. Nochmal: Es gehtnicht um die Daten, die aus einer Tabelle genommen und grafisch aufgetragen werden, sondern um die Achsenskalierung der Grafik selbst, beziehungsweise genauer um das Dialogfeld, über das die Skalierung eingestellt werden soll. Die Eingaben dort werden als falsche Datentypen interpretiert.

Um es nochmal grafisch zu verdeutlich: http://img713.imageshack.us/img713/4258/unbenanntkyf.png

Wurde Ihr Problem dadurch behoben?

Das war leider nicht hilfreich.


Am 14.08.2010 19:03, schrieb ccarmy:

ich habe das Gefühl, dass wir über vollkommen verschiedene Dinge reden.

Nönö, mir ist schon klar woher das Problem kommt, darfst Du mir ruhig glauben. .-)

Andreas.

Wurde Ihr Problem dadurch behoben?

Das war leider nicht hilfreich.


Nönö, mir ist schon klar woher das Problem kommt, darfst Du mir ruhig glauben. .-)

Andreas.

Glauben tue ich dir ja, außerdem kann es ja auch meinerseits passieren, dass wir aneinander vorbeireden. ;) Ich war auch gestern in Eile, deswegen kam eine vielleicht nicht ganz zielgerichtete Antwort.

Eine Eingabe mit Komma wird ja nicht als gültig akzeptiert, wenn als Dezimaltrenner der Punkt vorgegeben ist. Mit Komma als Dezimaltrenner wiederum taucht das auch wieder in meinem Diagramm an der Achse auf, was ich ja nicht will. (Wenn es nur um die "stumme" Verarbeitung der Daten im Hintergrund geht, wäre das nicht das Problem.)

Wurde Ihr Problem dadurch behoben?

Das war leider nicht hilfreich.


Ich kann das Problem bestätigen:

Tritt bei Ländereinstellung Deutsch (Schweiz) und Deutsch (Lichtenstein) reproduzierbar auf. Diese beiden Ländereinstellungen verwenden den Punkt sowohl als Dezimaltrennzeichen wie für das Datum.

Das Problem liegt wohl darin, dass eine Zahl mit einem Punkt auch schon als Datum interpretiert wird.

Die Workarounds mit ändern von Dezimaltrennzeichen in Komma sind nicht tauglich, da in offiziellen Dokumenten nicht zulässig.

 

Grüsse Luc

Wurde Ihr Problem dadurch behoben?

Das war leider nicht hilfreich.


Hallo Luc,

 

ein weiterer Workaround besteht (s.o.) darin, in den Einstellungen des Betriebssystems für das Datum ein anderes Trennzeichen einzugeben. Aber Vorsicht, wenn die Einstellung "Trennzeichen vom Betriebssystem übernehmen" eingeschaltet ist, lässt sich das Zeichen, auf das man hier ausweicht, in Excel dann ebenfalls nicht mehr benutzen. Wenn ich mein Datum also beispielsweise auf ein Format TT-MM-JJJJ umstelle, kann ich in Excel keine Formeln mit Subtraktionen mehr eingeben. Erst, wenn die Option "Trennzeichen vom Betriebssystem übernehmen" ebenfalls deaktiviert wird, läuft es rund.

 

Unterm Strich:

1.) Datumsformat im Betriebssystem ändern

2.) In Excel "Trennzeichen vom Betriebssystem übernehmen" ausschalten

3.) Sinnvollerweise das gewünschte Dezimaltrennzeichen dort einstellen (für uns wäre das der Punkt...)

Wurde Ihr Problem dadurch behoben?

Das war leider nicht hilfreich.


Hallo

Hatte dasselbe Problem auch. Es gibt eine Lösung, die nicht perfekt ist, aber es klappt wenigstens:
Die Datumsinterpretation erfolgt, solang man ZWEI Nachkommastellen schreibt. 
Deshalb versuchte ich es mal mit 1.5000 und siehe da --> alles läuft korrekt.

Gruss aus der Schweiz

Wurde Ihr Problem dadurch behoben?

Das war leider nicht hilfreich.


 
Informationen zur Frage

Aufrufe: 3.173 Zuletzt aktualisiert: 28 Juni, 2018 Gilt für: