strtodate und Win NT 4.0
Martin Sigle
unter Windows NT 4.0 inkl. SP 6 führt folgender Delphi Befehl zu einer
Convert Exception:
strtodate('27.08.1999') unter Win 9x funktionierts problemlos. Woran könnte
dies liegen?
Danke - mfG
Martin
Cesario Lababidi
ich habe deine Routine unter NT4 ausprobiert es funktioniert einwandfrei.
Aber der Fehler ist mir wohl bekannt wenn das Datum in der Ländereinstellung
anders eingetragen ist ( 27-01-19000)
Oder verwendest du die amerikanische Schreibweise :-))) dann ist der Monat =
27 ( das kann nur schief gehen ).
Überprüf doch einfach Deine Ländereinstellung ( Datum ).
Ciao Cesario
Martin Sigle <MSi...@t-online.de> schrieb in im Newsbeitrag:
8kfnni$9gn$16$1...@news.t-online.com...
Michael Winter
> unter Windows NT 4.0 inkl. SP 6 führt folgender Delphi Befehl zu einer
> Convert Exception:
> strtodate('27.08.1999') unter Win 9x funktionierts problemlos. Woran könnte
> dies liegen?
Vielleicht an einem nicht-deutschen NT?
-Michael
Peter Haas
Martin Sigle schrieb in <8kfnni$9gn$16$1...@news.t-online.com>:
> unter Windows NT 4.0 inkl. SP 6 führt folgender Delphi Befehl zu einer
> Convert Exception:
> strtodate('27.08.1999') unter Win 9x funktionierts problemlos. Woran könnte
> dies liegen?
Auf meinem Win9x gibt es auch einen Fehler. Dies liegt daran, daß auf
meinem Rechner die Datumsangaben nach ISO 8601 erfolgen. Laß dir mal
ausgeben, was in ShortDateFormat steht, sicherlich nicht 'dd/mm/yy'.
Falls der eingetragene String wirklich wie im Beispiel eine Konstante
ist empfiehlt sich der schnellere direkte Weg über
EncodeDate(1999, 8, 27).
MfG Peter.
Joachim Wittmann
>Aber der Fehler ist mir wohl bekannt wenn das Datum in der Ländereinstellung
>anders eingetragen ist ( 27-01-19000)
>8kfnni$9gn$16$1...@news.t-online.com...
>> strtodate('27.08.1999') unter Win 9x funktionierts problemlos.
Problem erkannt, aber nicht gelöst. Wenn der nächste Task oder User die
Einstellung ändert, knallts wieder. War übrigens auch eine der Ursachen für die
Y2k-Probleme...
Deshalb:
Datum immer frei von Formatierungen speichern (z.B. String aus TDateTime mit
Str() bilden). Das kann immer wieder mit val in ein TDateTime (was eigentlich ja
nur eine Fließkommazahl ist) umgewandelt werden und dann mit FormatDateTime
formatiert dargestellt werden.
Gruß Joachim.
--
_____________________________________________________________
NewsGroups Suchen, lesen, schreiben mit http://netnews.web.de
Peter Haas
Joachim Wittmann schrieb in <396c4c44$1...@netnews.web.de>:
> >> Convert Exception:
> >> strtodate('27.08.1999') unter Win 9x funktionierts problemlos.
>
> Problem erkannt, aber nicht gelöst. Wenn der nächste Task oder User die
> Einstellung ändert, knallts wieder. War übrigens auch eine der Ursachen für die
> Y2k-Probleme...
Nein, die Ländereinstellungen waren garantiert nicht die Ursache für das
Y2k-Problem. Dies hatte einfach etwas mit der Speicherung der Jahreszahl
mit nur zwei Ziffern zu tun. Ob nun als String oder anderes ist dabei
sogar völlig egal. Änliche Probleme gibt es auch bei diversen anderen
Speicherformaten, das Unix-Datums-Format hat z.B. den ersten Knackpunkt
am 2038-01-19 03:14:07. Das 'aus' kommt dann am 2106-02-07 06:28:15.
Hintergrund: Das Unix-Datums-Format speichert in einer 32-Bit-Integer-
Zahl die Anzahl der Sekunden seit dem 1.1.1970.
Und auch TDateTime hat irgendwann seine Grenzen erreicht. Nur werden wir
das wohl nicht mehr erleben und unsere Enkel auch nicht.
> Deshalb:
> Datum immer frei von Formatierungen speichern (z.B. String aus TDateTime mit
> Str() bilden). Das kann immer wieder mit val in ein TDateTime (was eigentlich ja
> nur eine Fließkommazahl ist) umgewandelt werden und dann mit FormatDateTime
> formatiert dargestellt werden.
Wozu den diesen Aufwand. Warum das Datum in eine Zahl wandeln und dann
wieder zurück in einen String. Das macht nur Sinn, wenn die Daten als
Text abgelegt/übertragen werden müssen. Dann kann ich aber auch gleich
eine lesbare Form wählen, z.B. in dem ich das international gültige
Datum nach ISO 8601 in der Kurzform verwenden, das wäre bei oben
stehendem Beispiel 19990827. Daraus kann ich mit Copy, StrToInt und
EncodeDate schnell und sicher ein TDateTime erzeugen.
Und warum Str und Val und nicht StrToFloat und FloatToStr / FormatFloat?
MfG Peter.
Christian NineBerry Schwarz
Peter Haas schrieb am 14 Jul 2000:
> Wozu den diesen Aufwand. Warum das Datum in eine Zahl wandeln und
> dann wieder zurück in einen String.
Nun, in Delphi ist das Datum ja schon eine Zahl. Insofern muss
Joachim gar nichts umwandeln, sondern eben nur die Fließkommazahl,
die das Datum nun mal ist, abspeichern bzw. wieder lesen.
> Das macht nur Sinn, wenn die Daten als Text abgelegt/übertragen
> werden müssen. Dann kann ich aber auch gleich eine lesbare Form
> wählen, z.B. in dem ich das international gültige Datum nach ISO
> 8601 in der Kurzform verwenden,das wäre bei oben stehendem Beispiel
> 19990827.
Auch eine Möglichkeit...
> Und warum Str und Val und nicht StrToFloat und FloatToStr /
> FormatFloat?
Weil jenes auch wieder auf verschiedenen Systemen anders
funktioniert, einmal mit Punkt, einmal mit Komma als
Dezimalseparator.
Traubensaft gibt Traubenkraft
Christian "NineBerry" Schwarz
--
Probier etwas Neues diesen Sommer:
Handbücher lesen
Und Traubensaft bei 3° C
Peter Haas
Christian NineBerry Schwarz schrieb in <8F72D622...@NineBerry.de>:
> > Wozu den diesen Aufwand. Warum das Datum in eine Zahl wandeln und
> > dann wieder zurück in einen String.
>
> Nun, in Delphi ist das Datum ja schon eine Zahl. Insofern muss
> Joachim gar nichts umwandeln, sondern eben nur die Fließkommazahl,
> die das Datum nun mal ist, abspeichern bzw. wieder lesen.
Sag ich doch.
> > Und warum Str und Val und nicht StrToFloat und FloatToStr /
> > FormatFloat?
>
> Weil jenes auch wieder auf verschiedenen Systemen anders
> funktioniert, einmal mit Punkt, einmal mit Komma als
> Dezimalseparator.
Stimmt, Str und Val arbeiten generell mit . im Gegensatz zu StrToInt
benutzt StrToFloat eine eigene Routine. Die Frage nehme ich hiermit
zurück.
MfG Peter.