NEWS
[gelöst] Export Verlaufsdaten
-
@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.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 -
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@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
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.@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 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.@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
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.@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 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.
@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 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.
@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.
-
@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.@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
kein Support per PN! - Fragen im Forum stellen - es gibt fast nichts, was nicht auch für andere interessant ist.
Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash -
-
@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
@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 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.@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.
kein Support per PN! - Fragen im Forum stellen - es gibt fast nichts, was nicht auch für andere interessant ist.
Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash -
-
@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.
-
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
formatDateins Wunschformat bringen und fertig. -
@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.
@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.
-
@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.
@dgr
ich glaube du hast die Komplexität noch nicht verstanden.
Natürlich hättest du es lieber bequemerAber 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
"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.
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. -
@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.
@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 😉
-
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.@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
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.@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 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 😉
@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 !)
-
@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 !)
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,
1657382697kannst du in alle möglichen Zeitformate übersetzen. Computer können das richtig gut und schnell.Wie hättens denn gerne? Was ist 'richtig'?
599
Online32.7k
Benutzer82.4k
Themen1.3m
Beiträge