Entwickler-Ecke
Windows API - Datumsformatfehler?
Tranx - Mo 28.03.11 07:58
Titel: Datumsformatfehler?
Hallo Leute,
habe gerade mal wieder einen merkwürdigen Effekt bei einem Rechner festgestellt. Das Betriebssystem ist Windows 7 64 bit. Bisher lief mein Programm auf allen anderen Betriebssystemen. Nun gab es den Fehler aus: '01.01.90' ist kein Datum. Ich habe getestet. (Wie gesagt 64bit Windows7) Das Betriebssystem verlangt den Teiler "/" als Trennstrich. Und das, obwohl in den Systemeinstellungen überall der Punkt steht. Selbst Shortdateformat zu setzen bewirkt nichts. Damit nun das Programm auf allen Betriebssystemen läuft, habe ich die StrToDate-Funktion "ergänzt" (s.u.). Nun funktioniert es wieder. Doch ich weiß nicht, warum überhaupt dieser Fehler auftrat. Bei dem 32bit Windows 7 trat der Fehler - wie gesagt - nicht auf.
Weiß jemand, wieso das so ist?
Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
| function StringToDate(s : string) : TDateTime;
begin
try
Result := StrToDate(s);
except
while Pos('.',s)>0 do
begin
s[Pos('.',s)] := '/';
end;
try
Result := StrToDate(s);
except
Result := -1;
end;
end;
Result := d;
end; |
Das Ergebnis -1 ist als Ergebnis für Nichtdatumstrings gedacht.
Nersgatt - Mo 28.03.11 09:13
Ja, darauf sind wir auch schon gestoßen - ist ein Problem von Windows.
Einmal in die Regionaleinstellungen in der Systemsteuerung gehen, einen Wert ändern, speichern, zurückändern, speichern, funktioniert. :roll:
jaenicke - Mo 28.03.11 11:12
Genauer gesagt gibt es das soweit ich das bisher bemerkt habe bei diversen OEM-Versionen, bei denen die Hersteller vermutlich ein englisches Windows als Vorlage genommen und dann Einstellungen auf ein deutsches übertragen haben.
Narses - Mo 28.03.11 11:12
Moin!
Tipp am Rande: wenn du von den Betriebssystemeinstellungen unabhängig sein willst, kannst du auch ein eigenes Set an Einstellungen verwenden:
| DOH hat folgendes geschrieben: |
Delphi-Quelltext 1:
2:
| function StrToDate(const S: string): TDateTime; overload;
function StrToDate(const S: string; const FormatSettings: TFormatSettings): TDateTime; overload; | |
Richtig spannend wäre, ob dann der "Fehler" auch auftritt. :idea: :nixweiss:
cu
Narses
jaevencooler - Mo 28.03.11 11:17
Tach auch,
das Problem hatten wir auch gerade bei einem großen Automobil Hersteller aus Stuttgart.
Dort wird auf Windows 7 64 Bit umgestellt, und diese Datum Format Problem ist dort bereits auc scho aufgetaucht,
aber eine Lösung seitens Mikrosoft noch nicht vorgestellt....
Ich werde das morgen auf einer Testmaschine mal ausprobieren, und dann berichten.
Beste Grüße
Michael
jaevencooler - Mi 30.03.11 15:19
Tach auch,
so jetzt nochmal ein kleines Update zu dem Thema:
Am zuverlässigsten funktioniert die Variante das man in den Ländereinstellungen ein anderes Land auswählt,
speichert und dann wieder auf die ursprüngliche Einstellung zurück stellt und speichert.
Einzelne Werte in den Ländereinstellungen ändern hat nicht immer zum Erfolg geführt.
(getestet an ca. 50 Rechnern / Laptops; Microsoft Win 7, 64 Bit, Enterprise)
Laut Microsoft ist das Problem bekannt, wann es behoben wird konnte man uns nicht mitteilen.
Beste Grüße
Michael
Tranx - Do 31.03.11 06:31
Danke für die Hinweise. Da allerdings auch andere Programme - welche ich nicht bearbeiten kann - Probleme mit der 64bit-Version haben, werde ich sowieso das Ganze auf 32bit umstellen müssen. Da hatte ich komischerweise keine Problem mit dem Datumsformat. An Windows 7 liegt es also nicht. Was allerdings der größere Adressraum mit Zahlen- und Datumsformaten zu tun haben soll, ist mir echt schleierhaft. Fragt sich da nur, was sonst alles noch nicht so läuft, wie es laufen soll.
Und zu dem größeren Adressraum. Schön. Aber hat sich Microsoft überhaupt Gedanken gemacht, wie sie den einigermaßen sinnvoll nutzbar machen wollen? Wenn ich an Word denke, mit Texten, die mehrere Seiten mit mehreren Bildern, eingebundenen Excel-Tabellen und Word-Grafiken (ganz grauenhaft, echt Risiko!) enthalten, denke, dann graut mir davor, was mit Dokumenten passiert, die nicht 30 MB sondern 3 GB groß sind. Dann kann man wohl die Steinzeit-PC-Methode nehmen: Daten eingeben, an Zentralrechner senden, dort verarbeiten lassen, und ma nächsten Tag hoffentlich das richtige Ergebnis erhalten. ;)
Andreas Schilling - Do 31.03.11 07:13
Das Probleme hatte ich auch mit dem Datumsfehler. Aber seit ich folgenden Quelltext in jedes Programm gleich zu Beginn eingebaut habe ich keine Fehlermeldungen mehr von Kunden bekommen. Groß- / Kleinschreibung spielt auch eine Rolle.
Delphi-Quelltext
1:
2:
3:
4:
5:
| DateSeparator := '.';
ShortDateFormat := 'dd.mm.yyyy'; TimeSeparator := ':';
ShortTimeFormat := 'HH:mm';
LongTimeFormat := 'HH:mm:ss'; |
Gruß Andreas
Nersgatt - Do 31.03.11 07:28
Damit legst Du Dich aber z.B. auf den Punkt beim Datum fest. Wenn Du nun einen Kunden hast, der sich den / eingestellt hat, wird der meckern. Spätestens wenn man sein Programm nicht nur innerhalb Deutschlands verkauft, gibts Probleme.
Andreas Schilling - Do 31.03.11 07:43
Ja ich lege mich damit fest. Einmal werden unsere Programme sowieso nur in Deutschland vertrieben und in den Programmen selber gibt es Maskedits, welche dieses Format erwarten. Ich hatte ohne diese Festlegung auch Probleme Datumswerte direkt über DBEditfelder (mit Datumsmaske) in Firebird-Datenbanken zu schreiben. Wer eine internationale Kundschaft hat, muß das Problem halt anders lösen.
Gruß Andreas
dickeWade - Do 31.03.11 17:42
 Nersgatt hat folgendes geschrieben  : |
Ja, darauf sind wir auch schon gestoßen - ist ein Problem von Windows.
Einmal in die Regionaleinstellungen in der Systemsteuerung gehen, einen Wert ändern, speichern, zurückändern, speichern, funktioniert. :roll: |
Hab ich gestern probiert. Solange das Programm läuft nimmt es die neuen Einstellungen auch an. Hab ich geprüft mit
Delphi-Quelltext
1:
| PostMessage(DateToStr(Date)); |
Aber nach Neustart des Programms ist wieder alles beim Alten und ich hab wieder das Format: "mm/dd/yy" statt "dd.mm.yy". Hab das kurzfristig erst mal geändert in dem ich DateToStr(Date) überprüfe und wenn da ein Schrägstich vorkommt, bastel ich den Datumsstring erstmal um bevor ich den an die Funktion StrToDate übergebe. Ist umständlich und ich werde mir mal bei Gelegenheit eine eigene Formatroutine zusammenfriemeln in der ich dann EncodeDate und DecodeDate benutze.
Gruss Tommi
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!