Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Thomas Braun]

@homoran @DGR

Und weil das Ganze ins Uferlose wächst macht man das so nicht, sondern formatiert die Grunddaten entsprechend auf dem Zielsystem in das erforderliche Endformat.

[haus-automatisierung]

Wer da was eigenes möchte, kann doch auch einfach selbst einen CSV-Export bauen - z.B. mit dem JavaScript-Adapter und sendTo / getHistory. Dann mit formatDate ins Wunschformat bringen und fertig.

https://github.com/ioBroker/ioBroker.history/blob/master/docs/de/README.md#zugriff-auf-history-werte-mit-javascript

[DGR]

@thomas-braun
"warum sollte man den Aufwand in seinem Programm oder Adapter haben, wenn die grundlegende Funktion in jedem System schon viel besser vorhanden ist?"

• weil es benutzerfreundlich ist.

"Dann muss er es aber zweimal umrechnen."

• man braucht es m.E. nur einmal umrechnen, von der einen Zeitzone in die gewünschte, falls sowas überhaupt sinnvoll ist bei Temperaturangaben.
  Was nützt einem New Yorker, wenn er nach seiner Zeit eine Temperaturangabe aus Berlin bekommt ? In Berlin war es um 14 Uhr 28°C. Er rechnet die Zeit um und weiß dann, dass es nach seiner Zeit 8 Uhr in Berlin 28°C (oder etwas in °F) war. Das würde bedeuten, dass es aus seiner Sicht in Berlin schon früh sehr heiß war.

[Homoran]

@dgr
ich glaube du hast die Komplexität noch nicht verstanden.
Natürlich hättest du es lieber bequemer

Aber erstens ist der Export in Zuluzeit absolut üblich (nicht nur) in der EDV, zweitens ist das ein Fass ohne Boden, wie bereits eben beschrieben

und der Aufwand für alle Eventualitäten, den du für deinen einenmSonderwunsch nicht bereit bist auf dich zu nehmen, s8ll der Entwickler für alle Möglichkeiten umsetzen, obwohl bisher nur einer von 65000 Usern für eine Variante dafür Bedarf angemeldet hat.

[Thomas Braun]

@dgr

Dein Horizont hört auch am Ortschild auf, oder?

man braucht es m.E. nur einmal umrechnen, von der einen Zeitzone in die gewünschte.

Bei 24 Zeitzonen sind das also wie viele mögliche Konstellationen? Und da ist dann nichtmal sowas wie unterschiedlicher Beginn von Sommer/Winterzeit (oder gar keine Zeitumstellung) berücksichtigt.
Das ganze ist höchst komplex.

[haus-automatisierung]

@dgr Du siehst das falsch. Es gibt einen bestimmten Zeitpunkt, zu welchem es 28 Grad in Berlin waren. Dieser wird aufgezeichnet und so gespeichert, dass es keinen Spielraum für Interpretationen gibt. Ganz einfach. Das machen alle Systeme so.

Stell dir vor Du hast eine Datenbasis, auf welche alle auf der Welt zugreifen. Wie das Forum hier. Hier steht deine Lokalzeit, weil das für Dich so aufbereitet wird. Wenn das Forum jemand aus Sydney besucht und jetzt einen Beitrag schreibt, möchtest Du also einen Datum angezeigt bekommen, was für Dich in der Zukunft liegt? Nicht sehr logisch 😉

[DGR]

@thomas-braun
habe ich mich da vielleicht missverständlich ausgedrückt, oder doch noch nicht richtig verstanden (?)
Ich meinte, wenn ein User die Exportdaten hat, dann kann er diese falls notwendig in die gewünschte Zeitzone konvertieren und muss m.E. nicht erst in die die Z-Zeiten umrechnen und dann in die gewünschte Zeitzone.

[Thomas Braun]

@dgr sagte in Export Verlaufsdaten:

dann kann er diese falls notwendig in die gewünschte Zeitzone konvertieren und muss m.E. nicht erst in die die Z-Zeiten umrechnen und dann in die gewünschte Zeitzone.

Dafür müsstest du dann aber von JEDER Zeitzone die Differenzen zu ALLEN anderen Zeitzonen wissen. Das ist ja noch mehr Aufwand als sich nur auf die unveränderliche Z-Zeit zu beziehen.

[DGR]

@haus-automatisierung
"Es gibt einen bestimmten Zeitpunkt, zu welchem es 28 Grad in Berlin waren. Dieser wird aufgezeichnet und so gespeichert, dass es keinen Spielraum für Interpretationen gibt."

Das Argument hat mich endlich überzeugt (wirklich !)

[Thomas Braun]

@dgr

Anhand der 'Unixzeit' kann man das auch verstehen:

09.07.2022 18:04:57 (Berlin)
9. Juli 22 18 Uhr 4 Minuten 57 Sekunden (MESZ)
07/09/22 6:4:57 PM (CEST)
09.07.2022 um 10:04:57 Uhr (UTC -6)
10.07.2022 00:49:57 Uhr. (UTC+8:45)
Levenherrmann, alt su spät? Ich muss fott! (Kölle am Rhing)

alles (halbwegs) gültige Formate für diese gleiche Sekunde / Time Stamp:

1657382697

Die simple Information, 1657382697 kannst du in alle möglichen Zeitformate übersetzen. Computer können das richtig gut und schnell.

Wie hättens denn gerne? Was ist 'richtig'?

[Homoran]

@dgr sagte in Export Verlaufsdaten:

Das Argument hat mich endlich überzeugt (wirklich !)

und warum die bisherigen inhaltsgleichen Aussagen nicht?

oder den Sinn / die Bedeutung der Zuluzeit

@dgr sagte in Export Verlaufsdaten:

doch noch nicht richtig verstanden (?)

[DGR]

@homoran
manchmal fällt der Groschen (zu) langsam. Hatte mich bisher nicht mit den unterschiedlichen Zeitformaten beschäftigt.

[Homoran]

@dgr sagte in Export Verlaufsdaten:

@homoran
manchmal fällt der Groschen (zu) langsam. Hatte mich bisher nicht mit den unterschiedlichen Zeitformaten beschäftigt.

Ich bin aber neugierig, mich würde es wirklich interssieren, wo dein gedanklicher "Hänger" war.

Wenn ich mir das hier ansehe

@dgr sagte in Export Verlaufsdaten:

und muss m.E. nicht erst in die die Z-Zeiten umrechnen und dann in die gewünschte Zeitzone.

dann glaube ich nach wie vor, dass du die Zulu-Zeit als weitere Zeitzone siehst.
Das ist sie nicht. Das ist die allgemein gültige Zeitbasis.
Da wird nichts hin umgerechnet, das liegt so vor.

[Thomas Braun]

@homoran sagte in Export Verlaufsdaten:

Da wird nichts hin umgerechnet, das liegt so vor.

Genau genommen ist natürlich unsere Mitteleuropäische (Sommer)-Zeit auch nur von dort abgeleitet. Halt im Sommer +2, im Winter +1 Stunde.

[Homoran]

@thomas-braun sagte in Export Verlaufsdaten:

@homoran sagte in Export Verlaufsdaten:

Da wird nichts hin umgerechnet, das liegt so vor.

Genau genommen ist natürlich unsere Mitteleuropäische (Sommer)-Zeit auch nur von dort abgeleitet. Halt im Sommer +2, im Winter +1 Stunde.

ja!
Aber die Zulu Zeit wird nicht aus der ME(S)Z berechnet

[Thomas Braun]

@homoran

Nee, das ist wie beim Liedchen uss d'r Kayjass Nummer Null :-D :clown_face: