Datumsformatfehler?

Tranx · Verfasst: Mo 28.03.11 07:58

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?

markieren

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.

_________________
Toleranz ist eine Grundvoraussetzung für das Leben.

Nersgatt · Verfasst: 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:

_________________
Gruß, Jens
Zuerst ignorieren sie dich, dann lachen sie über dich, dann bekämpfen sie dich und dann gewinnst du. (Mahatma Gandhi)

jaenicke · Verfasst: 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 · Verfasst: 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:

markieren

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:

cu
Narses

_________________
There are 10 types of people - those who understand binary and those who don´t.

jaevencooler · Verfasst: 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

_________________
Wissen ist Macht, nichts wissen macht auch nichts...

jaevencooler · Verfasst: 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

_________________
Wissen ist Macht, nichts wissen macht auch nichts...

Tranx · Verfasst: 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.

_________________
Toleranz ist eine Grundvoraussetzung für das Leben.

Andreas Schilling · Verfasst: 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.

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:

  DateSeparator := '.';
  ShortDateFormat := 'dd.mm.yyyy'; // <-- das hatte ich vorher groß geschrieben, kam auch Fehlermeldung
  TimeSeparator := ':';
  ShortTimeFormat := 'HH:mm';
  LongTimeFormat := 'HH:mm:ss';

Gruß Andreas

Nersgatt · Verfasst: 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.

_________________
Gruß, Jens
Zuerst ignorieren sie dich, dann lachen sie über dich, dann bekämpfen sie dich und dann gewinnst du. (Mahatma Gandhi)

Andreas Schilling · Verfasst: 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 · Verfasst: 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

markieren

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

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme