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

[Thomas Braun]

@dgr sagte in Export Verlaufsdaten:

"Den Datenexport könntest du auch an einen New Yorker weitergeben,..." - ich denke mal, sowas kommt sehr selten vor.

In der Netzwerktechnik kommt das milliardenfach in der Sekunde vor.
Pakete aus der 'Zukunft' würden da z. B. auch verworfen. Deswegen muss ein Zeitpunkt genau festgelegt sein, ohne Einflüsse von Zeitzonen. Deswegen halt intern die Z-Zeit, da spielt es keine Rolle in welcher Zeitzone du gerade bist.

Es war wohl für den Programmierer einfacher, auf die Grunddaten beim Export zuzugreifen

Natürlich, der müsste ja sonst jeden Datensatz in die Zeitzone des Systems konvertieren und wieder zurück. Das funktioniert so nicht. Bzw. wäre unnötig aufwändig, wenn es schon einen Standard für Zeitstempel gibt.

[DGR]

@thomas-braun
es ergibt für mich keinen Sinn, wenn z.B. ein New Yorker sich die Temperaturangaben aus Berlin um dort 8 Uhr Berliner Zeit auf die New Yorker Zeit 2 Uhr anzeigen läßt.
Die Daten wurden ja schon in die Zeitzone des Systems konvertiert, sonst könnten sie ja nicht im ioBroker korrekt angezeigt werden. Warum also nicht diese Daten exportieren ?

[DJMarc75]

@dgr Grunddiskussion oder kommt man dem Rätsel/Problem näher ? Glaub nicht dass man hier interkontinental jetzt eine Diskussion anfangen sollte....

[Thomas Braun]

@dgr

Über die 'Zeitproblematik' haben sich schon ganz andere Leute den Kopf zerbrochen. Man ist dann zu dem Ergebnis gekommen, dass man Zeitstempel immer in Relation zur Null-Zeit angibt, weil das einfach am einfachsten, klarsten und problemlosesten funktioniert und dann nur die Darstellung basierend auf den lokalen Zeitzonen verändert wird.
Das ist jedenfalls sinnvoller als Zeitpunkte immer noch mit der lokalen Zeitzone zu versehen. In deinem Beispiel müsste dann statt Z da CEST stehen, zur Winterzeit dann CET und der iobroker user in Portugal hätte dann wieder ein anderes Kürzel dabei, weil der ja in einer anderen Zeitzone lebt. Macht keinen Sinn.

Im Excel gibt es mit Sicherheit eine Funktion, die die Zeitkonvertierung vornehmen kann.

Das ganze ist also kein Bug, sondern 'du machst was falsch' bzw. machst was notwendiges nicht.

Eine ähnliche Diskussion zu 'time stamps' gab es übrigens ganz aktuell hier:

https://forum.iobroker.net/topic/56186/shelly-adapter-6-0-0-uptime?_=1657373231029

[DGR]

@thomas-braun
Die Grunddaten können doch so bleiben. Sie wurden doch für die Darstellung schon in die lokale Zeitzone umgewandelt. Also ist es offenbar möglich und diese umgewandelten Daten könnten exportiert werden.

[Thomas Braun]

@dgr

Zeitstempel werden grundsätzlich in Z-Zeit angegeben. Gründe dafür hatte ich ja schon genannt.
Verarbeite die Daten halt zum gewünschten Format weiter, deswegen heißt das ja auch EDV.

Kannst ja froh sein, dass überhaupt ein menschenlesbares Format rüberkommt. Man hätte es auch noch komplett anders ausgeben können. So macht es dmesg z. B. :

[148554.091265] CIFS: Attempting to mount \\192.168.178.1\fritz.nas
[179577.387458] CIFS: Attempting to mount \\192.168.178.1\fritz.nas

Übersetzt:

[Fri Jul  8 19:05:17 2022] CIFS: Attempting to mount \\192.168.178.1\fritz.nas
[Sat Jul  9 03:42:20 2022] CIFS: Attempting to mount \\192.168.178.1\fritz.nas

[DGR]

@thomas-braun
Zeitstempel können von mir aus auch weiter in Z-Zeit angegeben werden. Das habe ich schon gesagt (Grunddaten). Aber wenn die Angaben schon mal "lesbar" umgewandelt wurden, warum dann nicht so exportieren ?

Verstehe schon, dass wir hier offenbar nicht weiterkommen.
Danke. Muss man wohl mit dem Vorhandenen auskommen.

[Thomas Braun]

@dgr sagte in Export Verlaufsdaten:

Muss man wohl mit dem Vorhandenen auskommen.

Ja, du musst die vorhandenen Daten weiterverarbeiten und in das von dir bevorzugte Format bringen.
Die Amis schreiben ja auch z. B. Tagesdatum und Monat 'verkehrt' herum. Wie soll da also ein auf lokalen Vorlieben basierender Export aussehen? Das muss immer eine standardisierte Ausgabe sein.

[DGR]

@thomas-braun
noch einmal: die Daten wurden für die Anzeige schon aufbereitet (Bild). Das wird wahrscheinlich für jede Zeitzone und jedes Grundformat gemacht. Wahrscheinlich statt in °C auch in °F.
Es geht doch nur darum, diese einmal aufbereiteten Daten auch so zu exportieren. Das wäre wirklich anwenderfreundlich. Statt dessen programmtechnisch einfach machen und die Grunddaten exportieren (oder wenigstens wahlweise). Soll sich der User doch damit rumschlagen und was draus machen.

[Thomas Braun]

@dgr sagte in Export Verlaufsdaten:

noch einmal: die Daten wurden für die Anzeige schon aufbereitet

Das weiß ich... Das wird vom Admin basierend auf den Rohdaten und der hinterlegten Zeitzone jeweils umgerechnet. Das ist deutlich effizienter als jeden Datensatz beim Export schon zu konvertieren.

Soll sich der User doch damit rumschlagen und was draus machen.

Genau das ist ja der Ansatz. Es werden Daten roh angeliefert und jeder hat die Möglichkeit die flugs auf das gewünschte Format umzurechnen. Kann dann auch der Maya-Mondkalender oder das dyskordische Zeitformat sein.

In einer Visualisierung willst du auch nicht vorgegeben bekommen, das die Schriftfarbe gelb ist und kursiv gesetzt. Die Formatierung der Daten musst/darfst du selber machen.

[DGR]

@thomas-braun said in Export Verlaufsdaten:

Das wird vom Admin basierend auf den Rohdaten und der hinterlegten Zeitzone jeweils umgerechnet. Das ist deutlich effizienter als jeden Datensatz beim Export schon zu konvertieren.

Muss ich erstmal so hinnehme, obwohl ich die Logik dahinter nicht verstehe. Wenn man die Rohdaten in Bezug zur jeweils hinterlegten Zeitzone und den anderen Daten (°C/°F) umrechnen kann, wo ist dann das Problem, das auch beim Export zu machen ?

Das müsste man vermutlich eher den Programmierer fragen. Kann ja sein, dass es da unüberwindbare Hürden gibt.

"... jeder hat die Möglichkeit die flugs auf das gewünschte Format umzurechnen." - das kann jeder auch machen, wenn er die Daten wie angezeigt exportiert bekommt.

[Thomas Braun]

@dgr sagte in Export Verlaufsdaten:

wo ist dann das Problem, das auch beim Export zu machen ?

Es ist technisch keins, aber warum sollte man den Aufwand in seinem Programm oder Adapter haben, wenn die grundlegende Funktion in jedem System schon viel besser vorhanden ist? Und sei es nur durch gesetzte $LOCALES auf einem Multiuser-System wie es Unix eins ist. Es widerspricht auch den 'Best practises'.

das kann jeder auch machen, wenn er die Daten wie angezeigt exportiert bekommt.

Dann muss er es aber zweimal umrechnen. Von der falschen Zeitzone auf Z und dann wieder auf seine richtige. Macht man halt nicht, zu viel Aufwand und zu Fehler anfällig.

[Homoran]

@dgr sagte in Export Verlaufsdaten:

Sie wurden doch für die Darstellung schon in die lokale Zeitzone umgewandelt.

nein, nicht u

@dgr sagte in Export Verlaufsdaten:

die Daten wurden für die Anzeige schon aufbereitet (Bild).

eben nicht!
sie liegen nach wie vir in Zulu-Zeit vor.
Nur der Admin zeigt sie anders an.

das ist genauso wie eine Werteliste, in der die Daten 1,2,3,... gespeichert sind (und bleiben), im Admin aber gesclossen, gekippt, offen,.... angezeigt wird.

Ist müssig zu diskutieren, wenn man von unterschiedlichen Voraussetzungen ausgeht.

Mach bitte ein Issue auf, ob es möglich sei die Daten beim Export umzurechnen

BTW EXCEL sollte die Zuluzeit als solche erkennen

[Thomas Braun]

@homoran sagte in Export Verlaufsdaten:

Mach bitte ein Issue auf, ob es möglich sei die Daten beim Export umzurechnen

Dann will ich aber auch den jüdischen, den muslimischen, den Maya-Mondkalender, die dyskordische Zeit und meinen persönlichen Biorhythmus für den Export auswählen können!
Die hunderttausend verschiedenen Möglichkeiten ein Zeitformat darzustellen sind natürlich auch berücksichtigt, ist ja klar.

[Homoran]

@thomas-braun sagte in Export Verlaufsdaten:

@homoran sagte in Export Verlaufsdaten:

Mach bitte ein Issue auf, ob es möglich sei die Daten beim Export umzurechnen

Dann will ich aber auch den jüdischen, den muslimischen, den Maya-Mondkalender, die dyskordische Zeit und meinen persönlichen Biorhythmus für den Export auswählen können!

dann sollte das gewünschte Format auch in dem aktiven Frontend, auf dem der Export durchgeführt wird, im System e7ngestellt und abfragbar sein.

[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.