Zeitstempel berechnen

Hallo zusammen,

im angehängtem Vi versuche ich eine Zeit Differenz zwischen 2 Zeiten auszurechnen.

Im time1 subtrahiere ich zwei gleiche Zeiten als Ergebnis erwarte ich 00:00:00. Stimmt soweit.

Im time2 wandle ich eine Zeit nach UTC. Das Ergebnis was ich erwarte ist UTC +1 +1(Sommerzeit) Stimmt soweit.

Nun möchte ich die Differenz zwischen time 1 und time 2 berechnen und hier bekomme ich ein Problem. Ich würde erwarten das die Zeitdifferenz 2 Stunden beträgt.

Allerdings bekomme ich 3 Stunden Zeit Differenz. Mir ist nicht klar wo die eine Stunde zu viel herkommt bzw. wo mein Denkfehler liegt.

Lg Hubert

Anzeige

Hallo Hubert,

Zitat:Mir ist nicht klar wo die eine Stunde zu viel herkommt bzw. wo mein Denkfehler liegt.

Die eine Stunde ist die deutsche Zeitzone aka CET…

Tipp: bei Timestamps musst du IMMER daran denken, welche Darstellung/Formatierung du verwendest!
Und wenn du keine lokale Zeit (inklusive Zeitzonen-anpassung) anzeigen willst, dann solltest du nicht den Code "%<>T" verwenden, sondern "%^<>T" (wie in der Hilfe beschrieben)!
(Im IdeaExchange bei NI gibt es auch einen Vorschlag, bei Timestamps ebenfalls einen "Radix" anzuzeigen, damit man sofort zwischen UTC- und lokaler Anzeige unterscheiden kann…)

Noch ein Tipp: um eine relative Zeit (aka Zeitdifferenz) anzuzeigen, brauchst du keinen Timestamp-Indicator. Eine normale numerische Anzeige reicht völlig aus, wenn du dort dann das Format auf "%<>t" (kleines T!) umstellst:
   

Hallo Gerd,

vorab mal Danke für die Info.

Jetzt passt das auch mit der UTC und auch für andere Länder.

Noch folgenden Hinweis. Ich habe unter Win10 die Ländereinstellung zum Testen verändert.
Obwohl sich danach die Uhrzeit am PC richtig einstellt hat, rechnet LV noch mit der alten Zeit Einstellung.
Erst wenn ich LV beende und neu starte wird die Uhrzeit der Ländereinstellung übernommen.

Schönes Wochenende
Gruß Hubert

Hallo Hubert,

Zitat:Obwohl sich danach die Uhrzeit am PC richtig einstellt hat, rechnet LV noch mit der alten Zeit Einstellung.
Erst wenn ich LV beende und neu starte wird die Uhrzeit der Ländereinstellung übernommen.

Ja, richtig beobachtet.

Bestimmte OS-Einstellungen liest LabVIEW NUR beim Start, steht glaube ich auch irgendwo in der Anleitung.
Neben der Zeitzone betrifft das auch das Punkt/Komma in Zahlen…

Sorry, wenn ich hier nochmals diesen Thread aufmache.

Ich durchsuche eine DB und lasse mir ein Zeitfenster ausgeben. Funktioniert soweit.

Bei der Zeit Angabe muss ich ein Zeit Fenster vorgeben von – bis.

Die DB Abfrage verlangt, dass ich die Zeitangabe als String in einem genau definieren Format übergebe.

Dieses sieht so aus „2022-07-03T02:00:00.000Z“.
Hierzu verwende ich die LV Funktion Format Date/Time String mit dem folgenden time format string %Y-%m-%dT%H:%M:%S%3uZ.

Das Problem ist nun das die folgenden Zeitformatierung bekomme 2022-07-03T02:00:00,000Z.
LV macht das eigentlich richtig und setzt mir hier ein Komma „00,000Z“, weil die Länderspezifische Einstellung Deutschland ist.
Aber damit kann die DB nicht‘s anfangen und gibt einen Fehler aus.

Wenn ich nun den String über die Funktion „Search and Replace String“ das Komma durch einen Punkt ersetze bekomme ich das gewünschte Ergebnis.
Aber die Funktion Search and Replace String gefällt mir an dieser Stelle nicht. Ich würde das gern über den format string erledigen.

Kann mir jemand sagen was ich da ändern muss?

Gruß Hubert

Hallo Hubert,

Zitat:Die DB Abfrage verlangt, dass ich die Zeitangabe als String in einem genau definieren Format übergebe.
Dieses sieht so aus „2022-07-03T02:00:00.000Z“.
Hierzu verwende ich die LV Funktion Format Date/Time String mit dem folgenden time format string %Y-%m-%dT%H:%M:%S%3uZ.

Das Problem ist nun das die folgenden Zeitformatierung bekomme 2022-07-03T02:00:00,000Z.
LV macht das eigentlich richtig und setzt mir hier ein Komma „00,000Z“, weil die Länderspezifische Einstellung Deutschland ist.
Aber damit kann die DB nicht‘s anfangen und gibt einen Fehler aus.

Das ist ein Timestamp nach ISO8601. Sollte man überall verwenden IMHO…

Das Problem mit LabVIEW: LabVIEW kann zwar per %.;/%,; auf die Verwendung von Punkt/Komma als Dezimaltrennzeichen getrimmt werden - missachtet diese Formatcodes aber bei Timestamps. Du wirst also um ein Search&Replace nicht herumkommen…

Alternativen:
- Du stellst deinen Rechner auf die Verwendung englischer Zahlenformate um. Sollte man IMHO generell für Rechner machen, die mit wissenschaftlichen Daten oder Messgeräte zu tun haben…
- Du stellst in den LabVIEW-Optionen ein, dass LabVIEW NICHT die regionalen Einstellungen des Users verwenden soll. Dann wird generell der Punkt als Dezimaltrennzeichen verwendet…

Nachtrag:
Du weißt, was das "Z" am Ende des Timestamps bedeutet? Und du beachtest es beim Umwandeln von String <-> LV-Timestamp?

Anzeige

Hallo Gerd,

dann wird mir wohl nichts anderes übrig bleiben als Search&Replace zu verwenden.
Das Z am Ende ist die Abkürzung für Zulu und bedeutet UTC.

Gruß Hubert schöne Woche noch.

Moin Moin,

das klingt ganz so, als würde sich der Fehler aus einer doppelten Berücksichtigung der Sommerzeit oder aus einem Missverständnis bei der Zeitzonen-Konvertierung ergeben. Solche Probleme tauchen häufiger auf, wenn lokale Zeit, UTC und Sommerzeit (DST) ins Spiel kommen – gerade in automatisierten Berechnungen.

Ein hilfreiches Tool, das ich dir empfehlen kann, um solche Differenzen schnell und zuverlässig gegenzuprüfen, ist ein online Stundenrechner google danach einfach mal. Dort kannst du Start- und Enddatum mit Uhrzeit eingeben, und er zeigt dir sofort die exakte Differenz in Stunden und Minuten – ganz ohne Umrechnungsfehler.

Vielleicht hilft dir das auch, die Abweichung von einer Stunde besser einzugrenzen. Möglicherweise zieht deine Berechnung sowohl UTC+1 und zusätzlich die Sommerzeit drauf, obwohl letzteres schon im Offset berücksichtigt wurde?

Viele Grüße

(06.07.2022 09:05 )Hubert R. schrieb:  Hallo Gerd,

dann wird mir wohl nichts anderes übrig bleiben als Search&Replace zu verwenden.
Das Z am Ende ist die Abkürzung für Zulu und bedeutet UTC.

Gruß Hubert schöne Woche noch.

Also da gibt es schon noch Alternativen.

Format into String mit "%.;%<%Y-%m-%dT%H:%M:%S%3uZ>T" zum Beispiel. Und ja dann musst Du natürlich die aktuelle Zeit noch abfragen mit einem Get Date/Time in Seconds, aber das ist ja ziemlich trivial.

Ich verwende fast ausschliesslich die Format into String und Scan From String Funktion, da die mehr Möglichkeiten haben. Die Format Date/Time String Node ist noch aus der Zeit vor dass es Format into String gab und da wurde der Format String nicht angepasst wegen Backwardskompatibilität.

   

Also das Z wird zwar als Zulu buchstabiert, steht aber hier eigentlich für Zero, also keine Zeitzone, respektive UTC. Könnte man auch als Abkürzung für "Zone" interpretieren aber das geht doch nicht ganz auf. T wird benützt als Angabe dass nun die Zeitinformation folgt. Aber wenn man eine Zeitzone angibt wird das mit einem + oder - eingeleitet, ohne ein Z zu benützen.