String -> Zeitstempel

Hi,

helft mir auf die Sprünge...

warum klappt das linke Beispiel nicht?

   

Ich bekomme die Zeit im Format des linken Strings (JahrMonatTag-Stunde:Minute:Sekunde ... alles zweistellig). Muss ich mir die doch selbst auseinanderpflücken.

Versagt hier der Formatcode oder hab ich was übersehen?


Gruß SeBa

BOahh geil vieleicht kann ich dir ja wirklich helfen

ALso im linken Bild fehlen die Punkte hinter y m und d


des Rätselslösung??


mfg und schönens we

fizzer

was heisst linkes BIld meinte den linken String

' schrieb:BOahh geil vieleicht kann ich dir ja wirklich helfen
ALso im linken Bild fehlen die Punkte hinter y m und d
des Rätselslösung??

Neee.... das die Punkte fehlen ist Absicht. Denn genauso steht der String in einer Datei.

Wenn ich Punkte dazwischen mache klappts... aber warum nicht ohne die Punkte?

Gruß SeBa

Woher soll der Konverter (Format lesen) wissen, was für %y verwendet werden soll? Soll "10" verwendet werden oder "1001" oder gar "100129"?

Wenn da steht "%y." dann ist klar: Alles vom Anfang bis . ist %y - also: "10". Eine eindeutige Zuordnung kann also nur dann gemacht werden, wenn zwischen den einzelnen %-Parametern Trennungszeichen vorhanden sind.

Die Richtung "Format schreiben" ist da wesentlich unempfindlicher: da liegen die entsprechenden Parameterwerte ja explizit getrennt vor.

' schrieb:Woher soll der Konverter (Format lesen) wissen, was für %y verwendet werden soll? ... Er soll sich an seine eigene Hilfe halten Soll "10" verwendet werden oder "1001" oder gar "100129"?

Wenn da steht "%y." dann ist klar: Alles vom Anfang bis . ist %y - also: "10". Eine eindeutige Zuordnung kann also nur dann gemacht werden, wenn zwischen den einzelnen %-Parametern Trennungszeichen vorhanden sind.

In der Hilfe zu den Formatcodes steht doch folgendes:

<%d> Tag des Monats (01–31)
<%H> Stunde (24-Stunden-Anzeige) (00–23)
<%m> Monat (01–12)
<%M> Minute (00–59)
<%S> Sekunde (00–59)
<%y> Jahreszahl ohne Jahrhundertangabe (00–99)

Im Gegensatz zu "<%Y> Jahreszahl mit Jahrhundertangabe (zum Beispiel 1997)" sind das alles zweistellige Angaben.
Keiner der Formatcodes braucht mehr als zwei Zeichen.

Ich verstehe das dann so, dass %y bedeutet von Anfang bis zwei Zeichen weiter ... also "10"

%y%m%d sollte also auch mit der Angabe 100129 zurechtkommen, da die Zeichenkonvention von [00-99][01-12][01-31] ja eingehalten wird.


Gruß SeBa

' schrieb:In der Hilfe ...

... steht viel, wenn der Tag lang ist.

Oder sagen wir lieber: Ist halt ein Bug drin.

Anzeige

' schrieb:Oder sagen wir lieber: Ist halt ein Bug drin.

Und das kurz vor dem Wochenende...


Gruß SeBa

' schrieb:Oder sagen wir lieber: Ist halt ein Bug drin.

Kaum ein Mensch käme auf die Idee, in so einem Hieroglyphenstring wie 100129.09:58:13 ein Datum zu vermuten. Und weil LabVIEW diesen String auch nicht mag, nennt ihr das einen Bug? Wenn hier überhaupt etwas zu bemängeln ist, dann höchstens das Fehlen eines entsprechenden Hinweises im LV-Hilfetext. daß mit dem Formatstring nicht jeder Blödsinn machbar ist der rein syntaktisch eingentlich gehen müßte.
Das ist nicht nur kein Bug, sondern eine kluge Entscheidung. Denn die Tage und Monate müßten ansonsten grundsätzlich zweistellig sein, d.h. Angaben wie 1.1.10 gingen nicht - und auf diese Freiheit will doch niemand verzichten.

' schrieb:Kaum ein Mensch käme auf die Idee, in so einem Hieroglyphenstring wie 100129.09:58:13 ein Datum zu vermuten.

Zumindest der String "100129" alleine ist sehr wohl üblich.

Zitat:Und weil LabVIEW diesen String auch nicht mag, nennt ihr das einen Bug?

Wenn in der Beschreibung steht %y kann zweistellig dezimal sein, dann hat das so zu sein. Zumal ich mir ohne weiteres eine programmatische Umsetzung genau so vorstellen kann. Wenn also die Beschreibung sinnvoll klinkt, ist die Nichtumsetzung ein Bug.

Zitat:Wenn hier überhaupt etwas zu bemängeln ist, dann höchstens das Fehlen eines entsprechenden Hinweises im LV-Hilfetext. ...

Diese Betrachtungsweise ist natürlich erlaubt. Würde es so sein, würde ich ja sagen, dass es ein miserabel integriertes Feature ist.

Zitat:Das ist nicht nur kein Bug, sondern eine kluge Entscheidung. Denn die Tage und Monate müßten ansonsten grundsätzlich zweistellig sein, d.h. Angaben wie 1.1.10 gingen nicht - und auf diese Freiheit will doch niemand verzichten.

Probiers aus.
Und du wirst sehen was alles geht: %y%m%d:00440322, %y.%m.%d:20440322, %y/%m/%d:44/03/22, %y/%m/%d:44/0322 (!), %d%m%y:1.2.33 - u.v.m.

Möglicherweise fehlt in der Beschreibung ein Hinweis, dass das Y-Format in Zusammenhang mit den Betriebssystemeinstellungen zu sehen sind. Für Monat und Tag gibt es da keine Probleme, wohl aber mit dem Jahr. Da kann nämlich voreingestellt werden, ob die Jahreszahl zwei- oder vierstellig ist. Und hier beißt sich bestimmt die Implementation von %y in LV.


Was mir gerade einfällt, Lucki: Hatten wir uns nicht schonmal diskuttiert bezüglich dieses Themas? Ich glaube da war mal was ...

Hier ein Link mit einem ähnlichen Problem. Auch hier wird vermutet, dass der Fehler eher aus dem Zusammenspiel zwischen Betriebssystem und LV folgt.

' schrieb:Möglicherweise fehlt in der Beschreibung ein Hinweis, dass das Y-Format in Zusammenhang mit den Betriebssystemeinstellungen zu sehen sind. Für Monat und Tag gibt es da keine Probleme, wohl aber mit dem Jahr. Da kann nämlich voreingestellt werden, ob die Jahreszahl zwei- oder vierstellig ist. Und hier beißt sich bestimmt die Implementation von %y in LV.

LV unterscheidet aber zwischen %y (zweistellig) und %Y (vierstellig)... hab ich ja oben schon eingeworfen.

Gruß SeBa