Unsere neue Auswertungssoftware läuft inzwischen recht ordentlich.
Ich hatte sie auf meinem Rechner installiert, um verschiedene Features auszuprobieren, während ich nebenher an der Test Spec schrieb.
Als ich die Daten nach Datum sortieren wollte, tat sich gar nichts. Alle anderen Sortiermöglichkeiten, die ich inzwischen geprüft hatte, schienen einwandfrei zu funktionieren. Bloß das Datum machte Probleme.
Vielleicht erinnert sich jemand von euch daran, dass ich mein Datumsformat auf „YMMD“ umgestellt hatte. Mir ist klar, dass dies für Sortierungen ungeeignet ist (weil dann bei einem Stringvergleich beispielsweise 2008 als später sortiert würde als 2017, und manche Werte sind noch nicht einmal eindeutig), aber dann hätte zumindest eine falsche Reihenfolge herauskommen müssen, statt überhaupt keine Änderung.
Also machte ich mit dem Entwickler aus, in den Sortieralgorithmus unter Debug-Bedingungen (also an seinem Rechner) hineinzusteppen. Dazu musste er zunächst sein Datumsformat umstellen. An den Anfang der Sortierroutine setzten wir einen .. na, was wohl? .. wer weiß es?
Wie ich es fast erwartet hatte, wollte das Programm den aus dem GUI gelesenen Datumstext in eine datetime-Variable umwandeln. Das schlug fehl, und warf eine Konvertierungsexception. Da diese irgendwo aufgefangen wurde, passierte gar nichts. Keine Fehlermeldung, sondern die Sortierung wurde einfach abgebrochen.
Auf die Äußerung meines Entwicklers, dass er ja schließlich nicht wissen könne, welches vertrackte Datumsformat der Anwender eingestellt hatte, erwiderte ich ihm, dass er das ohne weiteres aus den Usereinstellungen lesen könne, es allerdings wesentlich sinnvoller wäre, nicht erst das Datum in einen String zu verwandeln, um ihn auszugeben, und später diesen String wieder für den Vergleich zurückzukonvertieren, sondern von vornherein das Datum im Speicher zu halten, um die Datumsvariablen bei Bedarf direkt vergleichen zu können.
Das muss er jetzt nur noch umsetzen, aber ich rechne dabei mit keinen nennenswerten Problemen.
Mit etwas Glück ergibt das dann die Alphaversion.
breakpoint 
Es sind immer die Kleinigkeiten, die das Leben schwer machen.
Wenn User und PCs einheitlich sein würden, könnte man viele Abfangstrategien einfach weglassen. Aber die Welt ist eben keine Scheibe …. und kein Ponyhof.
LikeLike
Ja, so ist das wohl.
Und jeder User (auch der unerfahrenste DAU) hat das Recht, an seinem Rechner Profileinstellungen vorzunehmen, wie es ihm beliebt.
Als Entwickler muss man eben berücksichtigen, dass da auch ungewöhnliche Werte dabei sein können.
Für Standardkonfigurationen zu entwickeln, ist keine Kunst. Einen guten Entwickler erkennt man (auch) daran, dass seine Programme auch mit unüblichen Fällen zurechtkommen.
LikeGefällt 1 Person
Es ist immer hilfreich, seine Zielgruppe zu befragen 🙂 und die ersten Versionen von Produkten durch eine Person bedienen zu lassen, die keine Ahnung hat.
RTFM Fehler beschäftigen am Ende nur den Support.
LikeLike
Bei Privatanwendern stimme ich dir zu.
In unserer Branche ist es mit den Nutzern halt um einiges komplizierter.
Das fu ndierte Manual liest eh niemand.
LikeGefällt 1 Person
Wir sind hier mit unseren 4 Landessprachen dran gewohnt, die regionalen Einstellungen des Benutzers zu berücksichtigen. Bei Zusammenarbeit mit deutschen oder österreichischen Firmen gibt es immer wieder das Problem, dass an Sprachabhängigkeiten und regionale Besonderheiten überhaupt nicht gedacht wird.
LikeLike
Localization sollte eigentlich selbstverständlich sein.
Solange es sich um geläufige Eigenschaften wie Ordnernamen oder Dezimalseparator geht, funktioniert das auch im Allgemeinen.
Aber mit einem ausgefallenen Datumsformat rechnet halt kaum jemand. Ich hätte den Fehler auch nicht bemerkt, wenn ich es bei einem Standardformat belassen hätte.
Ich habe früher ein paar Anwendungen mit multi-language-Unterstützung geschrieben, dabei aber keinen Unterschied zwischen 0x0407 (de-de) und 0x0?07 (de-ch) gemacht.
Schreibst du deine Nutzeroberflächen nur einsprachig (deutsch xoder englisch), oder berücksichtigst du auch italienisch- oder französisch-sprachige Anwender (oder gar rätoromanische)?
LikeLike
Meist gibt es schon Probleme, weil wir Dezimalpunkt statt -komma verwenden.
Im Normalfall sind wir im deutsch- und französischen Sprachraum unterwegs. Englisch braucht hier kein Mensch / zumindest wurde das noch nicht gewünscht.
In der deutschsprachigen Schweiz sind die Wörter und die Rechtschreibregeln halt etwas anders. Ein scharfes s gibt’s hier z.B. nicht.
Ich selber habe immer englisch als OS-Sprache eingestellt und damit ein anderes Datumsformat als die testenden Kollegen.
LikeLike
Ich nutze auf manchen Rechnern Deutsch, auf anderen English als System Language.
So ziemlich das erste, was ich mache, wenn ich einen neuen Rechner oder Account in Betrieb nehme, ist, dass ich das Zahlenformat umstelle. Als Decimal separator will ich den Punkt, und nicht das nervige Komma.
Stört es Schweizer eigentlich, wenn sie ß lesen müssen (z.B. Menüeintrag „Schließen“ statt „Schliessen“)? Das fehlt auf der schweizer Tastatur ja nur, damit Platz ist für französische und italienische Sonderzeichen.
LikeLike
Nein – das „ß“ fehlt nicht auf der schweizerischen Tastatur wegen der französischen und italienischen Sonderzeichen. Den Buchstaben gibt es hier schlichtweg nicht.
Meist überlese ich das „ß“, finde es inzwischen ebenso seltsam wie „grillen“ statt „grillieren“ zu sagen.
Nur bei „Maße“ vermisse ich die Unterscheidung zu „Masse“ gelegentlich.
LikeLike
Meines Wissens wird das ß in der Schweiz deshalb nicht benutzt, weil auf Schreibmaschinen nicht genügend Platz für alle landesüblichen Sonderzeichen war.
Ist vielleicgt ein Henne-Ei-Problem.
„Maße“ durfte man vor der Rechtschreibreform als „Masze“ schreiben, habe ich aber noch nie gesehen.
LikeLike
Das glaube ich nicht und auch Wikipedia sagt was anderes:
„Die frühen Antiquadrucke kannten in der Schweiz wie auch in Deutschland kein ß. Im Bundesblatt der Schweizerischen Eidgenossenschaft fehlte nach der Umstellung von Fraktur auf Antiqua 1873 das ß zuerst, wurde aber bald darauf eingeführt, doch schon 1906 wieder aufgegeben. Der Beschluss der Zweiten Orthographischen Konferenz von 1901, ß auch für die Antiqua zwingend vorzuschreiben, fand in der Schweiz keine durchgängige Beachtung. In der Folge beschloss die Erziehungsdirektion (Kultusministerium) des Kantons Zürich in den Dreißigerjahren, das ß vom 1. Januar 1938 an in den kantonalen Volksschulen nicht mehr zu lehren; die anderen Kantone folgten. Als letzte schweizerische Tageszeitung entschied die Neue Zürcher Zeitung, die am 1. August 1946 von Fraktur auf Antiqua umgestellt hatte, ab dem 4. November 1974 auf das ß zu verzichten.[29] Mit der Reform von 2006 wurde es auch offiziell für den amtlichen Schriftverkehr abgeschafft. Schweizer Verlage, die für den gesamten deutschsprachigen Markt produzieren, verwenden das ß jedoch weiterhin.“
Wir haben an der Stelle die ¨-Taste (verwendet man hauptsächlich für grosse Umlaute, kleine gibt es auf der Tastatur). Nachdem die aber auch mit Caps-Lock produziert werden könnten, dürfte das kein Tastatur-Problem sein.
LikeLike
http://www.moserware.com/2008/02/does-your-code-pass-turkey-test.html
LikeLike
Es scheint, dass die türkischen Formateinstellungen den deutschen ähnlicher sind, als die amerikanischen.
Das US-amerikanische Middle-endian Datumsformat ist auch immer wieder Quelle für Konvertierungsfehler.
Da fällt mir gerade ein:
Ich wollte mal einen Scheck aus den USA einlösen. Der Bankmitarbeiter sagte mir, der Scheck sei abgelaufem, da älter als ein Vierteljahr. Ich hatte ihn aber erst vor einigen Tagen bekommen.
Dann schaute ich mir das Datum noch mal an. Er war am 2. Mai oder so ausgestellt worden. Der Banker hatte es als 5. Februar interpretiert.
LikeLike
Ausgefallenes Datumsformat? Das ist ein Standardformat nach DIN/ISO! Und ehrlich, wozu umwandeln, wenn es letztlich wieder als Datum fungiert? Die Datumsvariante an sich ist doch viel einfach zu vergleichen. da brauch ich vorher doch keinen Textstring.
Und bzgl. der Reihenfolge: im Normalfall kann man als Anwender wählen, ob es aufsteigend oder abfallend sortiert werden soll – und ich mag eh das aktuellste oben.
LikeLike
„YMMD“ ist schon ausgefallen. Das Basisformat von ISO 8607 wäre „YYYYMMDD“, typisch deutsche Einstellung „D.M.YYYY“.
Den String braucht man, damit der Nutzer lesen kann, welchen Wert das Datum hat. Mit irgendwelchen Einsen und Nullen in IEEE-double-Datentypen kann in der Hinsicht kaum jemand etwas anfangen.
Wenn man die Sortierung o.B.d.A. ASC hat, genügt es, die Reihenfolge umzukehren, um DESC zu bekommen. Die Umkehrung der Sortierreihenfolge ist selbstverständlich implementiert, und kostet den Anwender nur einen Klick.
LikeLike
Dann kann ich das Datum aber immer noch zum Schluß – also nach Sortierung etc. – in einen String wandeln, wenn das für den Nutzer notwendig ist.
Und Formate kann ich vorgeben, dann kann ich exotische ausschließen. Oder ich muß eben auslesen, welches Format der Nutzer eingestellt hat bzw. erwartet.
LikeLike
Ey, edi, da muss ich wohl weiter ausholen, als ich eigentlich wollte.
Da gibt es einen Schwung Datensätze, die jeweils aus mehreren Feldern bestehen.
Diese Datensätze werden tabellarisch dargestellt. Zur Anzeige ist es nötig, die Werte in ein menschenlesbares Format zu bringen, was nicht unbedingt identisch ist mit dem ursprünglichen maschinenlesbaren Format.
Durch Klick auf den Kopf einer Tabellenspalte soll nach dieser sortiert werden – also z.B. Strings alphabetisch, Zahlen der Größe nach, und Datumswerte chronologisch.
Insbesondere für Datumsangaben ist der Vergleich im Ursprungsformat sinnvoll, während die in Strings konvertierten Werte dazu nicht geeignet sind. Ich brauche sie aber trotzdem, damit der Nutzer sie lesen kann.
Das vom Nutzer eingestellte Format wird nur für die Ausgabe bzw. Darstellung des Datumswertes benutzt.
Intern rechnen wir mit 64-bit-Gleitkommazahlen für Datum und Uhrzeit, abgespeichert wird (sofern es sich nicht um eine binäre Datei handelt, also z.B. bei XML) als ISO 8601.
LikeLike
Und ist das nicht iso 8601?
LikeLike
https://de.wikipedia.org/wiki/Datumsformat#ISO_8601_und_EN_28601
LikeLike
Pingback: Ich weiß noch, was ich letzten Sommer getwittert habe //1835 | breakpoint