Windows 7: bei manchen Systemen falsches Datumsformat?

[sh17]

OT

Zitat von himitsu:

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.

Na da bin ich nicht ganz der gleichen Meinung. Ich hätte schon gern die Kontrolle über meine Software, eben um solche Probleme mit neuen Windowssystemen zu umgehen. Mit jedem neuen Windows gab es wieder was neues, was geändert wurde und was Auswirkungen auf unser Produkt hatte. Da mach ich lieber alles selbst und weiß, es geht überall, weil ich sage, was zu tun ist und nicht irgend eine Ländereinstellung oder Sortierroutine (einfach mal bei Google "compare string works different" eingeben) die sich auf einmal anders verhält.

Bei tausend und mehr Kunden artet das in nicht endenden Support aus. Der wird mir nicht bezahlt. Jedem erzähl ich dann, stellen Sie mal auf englisch und dann auf deutsch zurück, dann gehts. 80% wissen erst mal nicht, was ich überhaupt von ihnen will. Das ist einfach Zeit, die ich nicht haben möchte, also lieber das Rad selbst bauen. Windows ist mir relativ Schnuppe - meinetwegen kann da wer weis was für ein System drunter liegen, hauptsache das Produkt funktioniert.

In diesem Sinne... (Sorry fürs Luft ablassen)

[himitsu]

Zitat von sh17:

Na da bin ich nicht ganz der gleichen Meinung. Ich hätte schon gern die Kontrolle über meine Software, eben um solche Probleme mit neuen Windowssystemen zu umgehen.

Hast du doch auch?

Erstmal kannst du für Dinge wo das Format wirklich feststehn muß immernoch den Format-Parameter nutzen.

Code:

function FormatDateTime(const Format: string; DateTime: TDateTime;
  const [b]FormatSettings: TFormatSettings[/b]): string;

Und ansonsten arbeitet man Programmintern einfach nicht mit solchen Werten,
sondern nutzt Formate, welche eben nicht systemabhängig sind.
If Now < StrToDate('01.01.2011') then If Now < 40544 then Jetzt wird das Datum nur noch zur Anzeige entsprechend Formatiert und schon kann der Benutzter das Datum so sehn, wie es ihm gefällt und wie es demnach im System eingestellt ist.

Tut mir Leid, aber ich sehe absolut keinen Grund, abgesehn von einer "lesbaren" Form der Datenspeicherung, um solche Werte formatiert zu verarbeiten.

Also wenn irgendwo eine bestimmte Einstellung des Systems unnötiger Weise "vorgeschrieben" ist, damit auch alles ordnungsgemäß läuft, dann ist das meiner Meinung nach ein Programmfehler und nicht ein Fehler des Systems, welches auch einfach mal anders eingestellt sein kann.

Derartige Einstellungen gehören zum UI (User Interface) und demnach auch nur in die Anzeige ... in der Internen Programmverarbeitung hat sowas nichts zu suchen.
Oder warum wird sonst schon seit Jahren geprädigt, das Verarbeitung und Anzeige getrennt sein sollten?

[sh17]

Das ich formatierte Daten nicht bei der internen Programmverarbeitung nutze versteht sich ja von selbst - gehört eigentlich zum Grundwissen.

Aber wenn mich der x-te anruft, warum denn auf seinem neuen Client plötzlich der Kalender englische Wochentage anzeigt und das Datum anders formatiert ist, oder der Dezimalseparator auf einmal ein Punkt ist, oder der Datenbankindex defekt ist, weil compareString nicht korrekt nach deutschen Gegebenheiten vergleicht, ...dann hab ich darauf keinen Bock. Dann häng ich Windows komplett ab und mach alles selbst. Nur darum gehts: S' muss gehn

[himitsu]

Wenn ich ein englisches Windows hab, warum sollte dann ein Programm nicht auch englische Formate nutzen?
Ein Amerikaner nutzt ja auch sonst den Punkt als Komma ... also könnte ihn ein Komma als Dezimaltrennzeichen genauso verwirren.

Aber OK, wenn der Rest der GUI deutsch ist, dann ist es richtig, wenn man dort kein englisch anzeigt.

Zitat von sh17:

oder der Datenbankindex defekt ist, weil compareString nicht korrekt nach deutschen Gegebenheiten vergleicht,

Dann ist die Berechnung des Index eben fehlerhaft.

[sh17]

Zitat von himitsu:

Dann ist die Berechnung des Index eben fehlerhaft.

Nein,das Verhalten von CompareString wurde ab Windows Vista verändert. Ich hatte genug Diskussionen dazu mit dem "Verantwortlichen" bei MS. Das Ergebnis bei MS - vorher war es falsch, jetzt ist es richtig. So kann sich auch rausreden.

Aber egal, mach mer Schluss mit dem OT, bevor der Mod noch den Thread schliesst.

[holliesoft]

Hallo nochmal,

falls es jemand interessiert:

Testprogramm mit Delphi2007 ==> US-Format
Testprogramm mit aktuellem Lazarus-Snapshot (mit FPC 2.4.1) ==> US-Format

Gruß,
Patrick

[cs.rumpelstilzchen]

Hallo Leutz!

Ich hab das gleiche Problem auf ASUS EeeTop2002-Systemen festgestellt. Scheint tatsächlich mit der Vorinstallation zu tun zu haben! Nach umstellen der Ländereinstellungen (auf z.B. Österreich) und sofortigem zurückstellen auf Deutschland, geht dann alles, wie es sein soll! Das gleiche passiert, wenn ich die Ländereinstellungen für Deutschland in der Systemsteuerung einfach "zurücksetze"!
Ist natürlich großer Mist! Vor allem für den Support...

Ich habe mir die Mühe gemacht, eigene Funktionen für Datums/Zeit und Währungsumwandlungen zu programmieren.

Ich deklariere mir eine globale Variable:

Delphi-Quellcode:

  // Formateinstellungen für Datum/Zeit-Funktionen
  // Damit Umwandlungen wie 'DateTimeToStr'
  // unabhängig von den Ländereinstellungen des
  // Systems funktionieren! z.B. bei Win7!!!!!
  // =============================================
  gFS : TFormatSettings;

Bei Programmstart initialisiere ich diese auf deutsches Format...

Delphi-Quellcode:

  // Deutsche Format-Settings holen!
  GetLocaleFormatSettings(1031, gFS);

...und benutze sie dann in meinen Funktionen:

Delphi-Quellcode:

function MyDateTimeToStr(const Datum : TDateTime) : String;
begin
  Result := DateTimeToStr(Datum, gFS);
end;

function MyTimeToStr(const Time : TTime) : String;
begin
  Result := TimeToStr(Time, gFS);
end;

function MyDateToStr(const Datum : TDateTime) : String;
begin
  Result := DateToStr(Datum, gFS);
end;

function MyStrToDateTime(const szDatum : String) : TDateTime;
begin
  Result := StrToDateTime(szDatum, gFS);
end;

function MyStrToDate(const szDatum : String) : TDateTime;
begin
  Result := StrToDate(szDatum, gFS);
end;

function MyStrToTime(const szTime : String) : TDateTime;
begin
  Result := StrToTime(szTime, gFS);
end;

function MyTryStrToDateTime(const szDatum: string; var Datum: TDateTime): Boolean;
begin
  Result := TryStrToDateTime(szDatum, Datum, gFS);
end;

function MyTryStrToDate(const szDatum: string; var Datum: TDateTime): Boolean;
begin
  Result := TryStrToDate(szDatum, Datum, gFS);
end;

function MyTryStrToTime(const szTime: string; var Datum: TDateTime): Boolean;
begin
  Result := TryStrToTime(szTime, Datum, gFS);
end;

Ich habe mir ein kleines Testprogramm gebastelt:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  FormatSettings: TFormatSettings;
  var MyLCID : Integer;
begin
  GetLocaleFormatSettings(SysLocale.DefaultLCID,FormatSettings);
  Label1.Caption := '(' + IntToStr(SysLocale.DefaultLCID) + ') -> ' +DateTimeToStr(now, FormatSettings);

  MyLCID := GetUserDefaultLCID;
  GetLocaleFormatSettings(MyLCID,FormatSettings);
  Label8.Caption := '(' + IntToStr(MyLCID) + ') -> ' +DateTimeToStr(now, FormatSettings);

  GetLocaleFormatSettings(1031,FormatSettings);
  Label2.Caption := '(' + IntToStr(1031) + ') -> ' + DateTimeToStr(now, FormatSettings);

  Label3.Caption := '() -> ' + DateTimeToStr(now);
end;

Interessant ist in diesem Zusammenhang folgendes:
Es machte auf den getesteten Windows 7 - Systemen (3 konnte ich testen) einen Unterschied, ob ich die SysLocale.DefaultLCID (->ergibt US-Format) oder die GetUserDefaultLCID (-> ergibt deutsches Format) benutze. Es ist nur die SysLocale.DefaultLCID betroffen! Anscheinend benutzt Delphi diese in den eigenen Funktionen! Die über GetUserDefaultLCID bezogene LCID ist immer korrekt!

Vermutlich ist die Lokalisierung der getesteten Windows 7-Systeme nur auf User-Ebene erfolgt...
Shit happens!

[mschaefer]

Moin moin,

Zum Beispiel bein Win64 auf Asus-Altec und das haut dann 'strtofloat' in Exceptions.
Solange das Programm deutsch spricht bekommt es also obigen Weg.

Grüße in die Runde

[RWarnecke]

Hallo zusammen,

ich habe das gleiche Problem. Meine Berechnung erfolgt noch komplett richtig in der jeweiligen Form, wie ich es in den Ländereinstellungen vorgegeben ist. Versuche ich aber nun mit FormatDateTime('dd.mm.yyyy', date) das Ergebnis als String auszugeben, dann gibt es eine Exception.
Da ich mit Datumswerten rechnen muss, hat jemand einen Vorschlag, wie man solche Sachen umgehen kann ?

[mschaefer]

Mir fällt da nur ein die Constanten entsprechend einer Spracheinstellung im Programm zu definieren.

Wenn das ein Windows Problem ist, weiss man kaum auf welchen Rechner man trifft. Zumal ich hier ein
gut geupdatetes Windows 7 habe und es auch keinen Hang zur Autokorrektur gibt. Eigentlich müßten auch
die Delphi 2010´er das Problem haben. Kann das mal einer Testen?

Grüße // Martin


PS: Ein kleiner Nebeneffekt:

Habe hier ein DBEdit mit Floatfeld als Datenbankbasis in FB.
Das Ding akzeptiert keine Kommas, dafür aber Punkte als Anteilstrenner.