Windows 7: bei manchen Systemen falsches Datumsformat?

[ConstantGardener]

Also die Fehler treten nicht nur mit D6 auf. Auch unter D2006 und Win7 64Bit us mit deutschem Lang.Pack sind sie noch vorhanden. Das neu setzen im Programm geht wahrscheilich, ist aber eigentlich nicht Sinn der Sache. Es sind z.B. auch die Wochtagsbezeichnungen betroffen. Einige Nutzer melden das das expliziete umschalten der Ländereinstellung auf englich und dann zurück zur deutschen Einstellung das Problem beheben kann. Reproduzieren konnte ich den Fehler aber noch nicht, da er nur auf sehr wenigen Systemen auftritt.

cu cg

[sh17]

Ja stimmt, die Wochentagsbezeichnungen sind auch betroffen, die benutzen wir aber nicht, deswegen hatte ich die nicht angepasst.

Das mit dem setzen auf englisch und zurück nach deutsch kann ich ja mal testen.

[hitzi]

Das sind nicht zufällig Siemens Rechner (Esprimo) mit vorinstallierten Win7 Professional? Geh mal in die Systemsteuerung/Zeit, Sprache Region/Datum, Uhrzeit oder Zahlenformat ändern und in dem neuen Fenster unten auf "Weitere Einstellungen". Nu geht wieder ein neues Fenster auf, wo du unten mal bitte auf "Zurücksetzen" klickst. Danach war bei uns das Datumsproblem in Verbindung mit Informix weg. Muss aber für jeden User auf dem Rechner gemacht werden.

Das Problem bei den Siemensrechnern ist, dass die bei HKCU\Control Panel\International\Locale den Wert 409 eintragen, aber eigentlich der Wert 407 da rein gehört.

[himitsu]

Zitat von sh17:

Das mit dem setzen auf englisch und zurück nach deutsch kann ich ja mal testen.

Also, es kann praktisch sein, daß hier ein paar "fehlerhafte" oder falsch/unvollständig installierte/integrierte Languagepacks unterwegs sind, wo dann derartige Optionen nicht mit umgestellt wurden.

Beim um-/zurückstellen der Sprache würde dieses demnach dann allerdings mit angepaßt.

[sh17]

Zitat von hitzi:

Das sind nicht zufällig Siemens Rechner (Esprimo) mit vorinstallierten Win7 Professional?

Hab auch schon Notebooks gehabt, welche nicht von Siemens sind.

[himitsu]

Delphi-Quellcode:

CurrencyFormat := 3;
  NegCurrFormat := 8;
  ThousandSeparator := '.';
  DecimalSeparator := ',';
  CurrencyDecimals := 2;
  DateSeparator := '.';
  ShortDateFormat := 'dd.MM.yyyy';
  LongDateFormat := 'dddd, d. MMMM yyyy';
  TimeSeparator := ':';
  TimeAMString := '';
  TimePMString := '';
  ShortTimeFormat := 'hh:mm';
  LongTimeFormat := 'hh:mm:ss';

Wenn ich mich nicht täuche, dann aktualisiert Delphi diese Variablen, wenn am System sowas geändert wurde.

Demnach würde es danach dann wieder Probleme geben, wenn man für irgendeine Verarbeitung ein festes Format benötigt.

[v2afrank]

Es sei denn man setzt Application.UpdateFormatSettings := false;

[holliesoft]

Hallo an alle,

danke erstmal an alle, die geantwortet haben und mir bestätigen konnten, dass das kein Einzelproblem ist.

Interessant wäre noch zu wissen, ob auch Anwendungen betroffen sind, die mit aktuelleren Delphi-Versionen (2007-2010) kompiliert worden sind.

Sobald ich den nächsten Fall auf meinem Tisch habe, lasse ich mal ein kleines Testprogramm, das ich mit einem aktuellen Lazarus-Snapshot kompiliert habe, auf einem betroffenen System laufen. Wenn Lazarus auch die falschen Settings für das ShortDateFormat zieht, dann liegt der Fehler für mich zu 100% bei den betroffenen Windows 7-Systemen und nicht bei Delphi (Trotzdem: sich auf korrekte System-Einstellungen zu verlassen ist ohne Frage "pfui". Auch ein deutsches System kann bewusst ein anderes Datumsformat eingestellt haben).

[sh17]

Zitat von v2afrank:

Es sei denn man setzt Application.UpdateFormatSettings := false;

Interessant - kannte ich noch nicht

[himitsu]

Zitat von holliesoft:

Interessant wäre noch zu wissen, ob auch Anwendungen betroffen sind, die mit aktuelleren Delphi-Versionen (2007-2010) kompiliert worden sind.

Zitat von sh17:

Interessant - kannte ich noch nicht

Ich och nicht, aber da ich mich nicht auf bestimmte Systemeinstellungen einschränke, hab ich sowas auch nie gesucht.

Ich finde es eh etwas "schlimm", wenn man in seinem Programm den "Willen" des Nutzers ignoriert und vom System abweichende Einstellungen nutzt, bzw. nur bestimmte Einstellungen erlaubt, womit dann das Programm nicht auf allen Systemen läuft, wie man hier am Thema ja sehr gut erkennen kann.


ShortDateFormat := TranslateDateFormat(GetLocaleStr(DefaultLCID, LOCALE_SSHORTDATE, 'm/d/yy')); und

Delphi-Quellcode:

function TranslateDateFormat(const FormatStr: string): string;
var
  I: Integer;
  L: Integer;
  CalendarType: CALTYPE;
  RemoveEra: Boolean;
begin
  I := 1;
  Result := '';
  CalendarType := StrToIntDef(GetLocaleStr(GetThreadLocale,
    LOCALE_ICALENDARTYPE, '1'), 1);
  if not (CalendarType in [CAL_JAPAN, CAL_TAIWAN, CAL_KOREA]) then
  begin
    ...

Delphi-Quellcode:

function GetLocaleStr(Locale, LocaleType: Integer; const Default: string): string;
{$IFDEF MSWINDOWS}
var
  L: Integer;
  Buffer: array[0..255] of Char;
begin
  L := GetLocaleInfo(Locale, LocaleType, Buffer, Length(Buffer));
  if L > 0 then SetString(Result, Buffer, L - 1) else Result := Default;
end;
{$ENDIF}
{$IFDEF LINUX}
begin
  Result := Default;
end;
{$ENDIF}

GetLocaleStr = GetLocaleInfo
Delphi nutzt hier fast direkt die WinAPI.

Nun gibt es hier 2 Fälle entweder GetLocaleInfo liefert keinen String und es wird das Default genutzt oder GetLocaleInfo liefert wirklich einen anderen Formatstring.

In beiden Fällen sollte Lazarus ähnlich arbeiten und denmach auch ähnlich reagieren.