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

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

[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 (?)