Softwareentwickler MATLAB/Simulink (w/m) Erarbeitung von Lösungen im Bereich der Schnittstelle zum Simulink-Modell und der Benutzeroberfläche von TargetLinkdSPACE GmbH - Paderborn
Verfasst am: 28.01.2011, 14:07
Titel: Probleme aufgrund unterschiedlicher Datumsformate?
Gesucht: Welche Probleme aufgrund unterschiedlicher Datumsformate sind bekannt?
Liebe gomatlab Community,
jeder der schon einmal einen Termin an einem siebten Juni verpasst hat, weil er glaubte er findet am sechsten Juli statt weiß, dass weltweit die unterschiedlichsten Datumsformate üblich sind:
Auch wenn es MATLAB nur in Englisch (und in gewissem Umfang in Japanisch) gibt, arbeitet MathWorks seit vielen Jahren an verschiedenen I18N Initiativen ( http://de.wikipedia.org/wiki/Internationalisierung_(Softwareentwicklung) ).
Eine spezielle Herausforderung im MATLAB Umfeld ist, dass sehr viele Dinge möglich sind an die die Entwickler nicht im Traum gedacht haben.
Ich möchte der gomatlab Community die Möglichkeit geben MathWorks mögliche oder faktische Probleme zu berichten die aufgrund unterschiedlicher Datumsformate entstehen können oder schon entstanden sind. Dies kann sowohl hier im Forum geschehen, als auch per E-Mail an mich. Für dieses Forum schlage ich 2 Möglichkeiten vor:
1. Problembeschreibung zu der schon ein Workaround existiert, oder eine Lösung nicht (mehr) akut ist: Antwort aus diesen Post
2. Problem zu dem eine Lösung benötigt wird: Separater Post mit dem Stichwort „I18N“ in der Titelzeile
Verfasst am: 28.01.2011, 17:54
Titel: Re: Probleme aufgrund unterschiedlicher Datumsformate?
Hallo Andreas,
Der DIR-Befehl erzeugt in modernen Matlab-Versionen das Datum in lokalisierter Form, z.B. "02-Okt-2010 15:16:30", während es z.B. in Matlab 6.5 unebhängig von der lokalen Sprach-Einstellung "02-Oct-2010 15:16:30" zurückgab.
Ich habe in der FEX ein Tool zum Auslesen und Setzen der File-Create, -Write und -Access-Zeit veröffentlicht. Zwar sind Input und Output dieser Funktionen DATEVEC Vektoren, also nicht von der Sprache abhängig, aber in der Test-Funktion habe ich doch die Strings von DATESTR und vom DIR-Befehl verglichen. Im Juni funktionierte das ("Jun" und "Jun"), im Oktober aber nicht mehr ("Oct" und "Okt").
Zudem trat das Problem auf, dass Windows und Matlab die Sommerzeit unterschiedlich behandeln: Während unter Windows die Zeit eines alten Files beim Sommerzeit/Winterzeit-Wechsel mitgeändert wird, liefert Matlab's DIR viel logischer die gleiche Filezeit unabhängig von der aktuellen Zeit. Deshalb habe ich in GetFileTime 3 Methoden eingebaut: "Local" (gleiche Zeit wie Matlab), "Windows (ratet mal) und "UTC" (UTC Zeit ohne lokale Anpassung).
Ein Nachteil der umfangreichen Zeitfunktionen (DATENUM, DATEVEC, DATESTR) ist die erschreckend langsame Laufzeit. Ich habe die speziellen Konvertierungen, die ich selbst benötige, in deutlich abgespeckter Form als Funktion geschrieben und komme z.B. bei DateString(0) -> DateNumber Konvertierung auf 0.9% Rechenzeit (FEC: DateStr2Num, C-Mex) und DateString(0) -> DateVector auf 1.1% Rechenzeit (FEX: DateConvert, M-Funktion). Für DateNumber->DateString(0) sind es immerhin 20% Rechnenzeit im Vergleich zu Matlab's DATESTR, aber als C-Mex liesse sich da noch mehr rausholen.
Aber natürlich haben diese abgespeckten Funktionen viel weniger Features als die super-schlauen Matlab Funktionen: DATESTR kann z.B. locker mit [2011, 1, 28, 16, 49, -87654] und "28.Januar2011" umgehen und eben natürlich auch lokalisierte Datums-Strings erzeugen. Wenn diese Intelligenz dann Standard-Aufgaben aber 100mal langsamer macht als nötig, ist das ein Overkill.
Deshalb wäre es nützlich zwei Sätze von Datums-Funktionen zu haben: Einen Satz schneller Funktionen, bei denen die Daten wohlgeformt sein müssen, und einen Satz intelligenter Funktionen, die auch "28. Januar 2001" und "2011-Jan-28" gleich gut verstehen können.
Gruß, Jan
Options and Permissions
Du kannst keine Beiträge in dieses Forum schreiben. Du kannst auf Beiträge in diesem Forum antworten. Du kannst deine Beiträge in diesem Forum nicht bearbeiten. Du kannst deine Beiträge in diesem Forum nicht löschen. Du kannst an Umfragen in diesem Forum nicht mitmachen. Du kannst Dateien in diesem Forum posten Du kannst Dateien in diesem Forum herunterladen
MATLAB, Simulink, Stateflow, Handle Graphics, Real-Time Workshop, SimBiology, SimHydraulics, SimEvents, and xPC TargetBox are registered trademarks and The MathWorks, the L-shaped membrane logo, and Embedded MATLAB are trademarks of The MathWorks, Inc.
RSS