[gelöst] Konvertierungsproblem mit Zahl in Zeit
-
Aber auch nur innerhalb der Sommerzeit. Ab Oktober zeigt das Skript sonst nur ne halbe Stunde Unterschied, solange wir die Sommerzeit haben.
Das denke ich nicht. Da wir nur die +1 Zeitzone (im vergleich Winter zur Zentralen Unix Time) abziehen und nicht die Sommerzeit.
Um das zu testen müsste ich aber entweder die Uhrzeit bei mir umstellen wenn ich daheim bin oder bis Oktober warten^^ -
Also - ich hab ja mit Blockly so gar nix am Hut... Aber mal von der JS-Funktion ausgegangen würde ich sagen, was passiert denn wenn du statt der Zahl 5400000 einen String im Sinne von "01:30" angibst?
-
Ein fröhliches Hallo zusammen,
als TE möchte ich jetzt folgendes ergänzen:
-
ich bin sehr erstaunt über die herausgebrachten Gründe, warum da 02:30 Std. und nicht 01.30 Std. bei herauskommen.
-
ich kann kein Javascript und möchte mich auch eher nicht damit beschäftigen - sondern ich möchte gerne, dass das gewünschte Ergebnis, nämlich 01:30 Std. dabei herauskommt - was faktisch ja auch so richtig ist.
-
nach den letzten Theorien mit der Umrechnung der Unix-Zeit müsste ich jetzt ja in Blockly eine Funktion schreiben, die mir herausrechnet ob Sommer-, Winter- oder zukünftig immer Sommerzeit oder Winterzeit ist. All das muss sich aber doch umgehen lassen, denn von der Funktion erwarte ich doch das Ergebnis 01:30 Stunden...
Sieht das Jemand anders?
-
-
@thewhobox sagte in Konvertierungsproblem mit Zahl in Zeit:
Das denke ich nicht. Da wir nur die +1 Zeitzone (im vergleich Winter zur Zentralen Unix Time) abziehen und nicht die Sommerzeit.
Denke schon, denn 5.400.000ms sind nun mal 1,5h. Wenn ich die verkürze auf 1.800.000 = 0,5h zeigt mir das Ergebnis heute zur Sommerzeit 01:30 an und zur Winterzeit 00:30, weil es ja die Uhrzeit, bzw. die entsprechende Millisekundenanzahl nach dem 01.01.1970 00:00 Uhr, gekürzt auf die Stunden und Minuten anzeigt.
Aktuell habe ich 0,5h Unterschied zwischen Unixtime Anfang (weil Sommerzeit + 1 zusätzliche Stunde) und 01:30Uhr. Zur Winterzeit sind es dann wieder 1,5h bis 01:30h.
Kann man hier sehr schön sehen.
Wenn wir wieder auf UTC +1 sind, verschiebt sich die Realzeit auch wieder um 1 Stunde nach hinten.
-
@Thisoft Ein String wird anscheinend anders gehandhabt.
Da wird erst das heutige Date Object erzeugt (mit richtiger Zeitzone) und danach Uhrzeit/Tag/Jahr (falls vorhanden) gesetzt.@XxJooO Theoretisch kannst du auch einfach die Stunde in Blocklyy vorher abziehen.
@mehrwiedu Er scheint da die Sommerzeit gar nicht zu beachten:
Du vergisst aber, dass Javascript nicht einfach alles in der Zentralen Unixtime angibt.
Ich korrigiere damit ja den Zeitzonen "Fehler", da ich eig gar keine Zeitzone möchte. -
@XxJooO sagte in Konvertierungsproblem mit Zahl in Zeit:
denn von der Funktion erwarte ich doch das Ergebnis 01:30 Stunden...Sieht das Jemand anders?
Anfangs nicht, jetzt ja.
Das was Dir die Funktion liefert ist nicht eine reine Konvertierung von Zahl in Stunden: Minuten, Sprich 5.400.000ms = 1 Stunde 30 Minuten, sondern sie liefert Dir eine Uhrzeit. Dabei ist es egal, ob sie die vergangenen Stunden und Minuten ab Unixtime 0 + 5.400.000ms anzeigt, oder die tatsächliche Uhrzeit in Realzeit. Beides ist aktuell zur Sommerzeit bei UTC +2 in Deutschland entweder direkt 2:30Uhr oder eben 1,5h nach der ersten Stunde, also auch wieder 02Stunden:30Minuten.Die Funktion ist demnach für Dein Vorhaben einfach nicht zu gebrauchen.
-
@thewhobox sagte in Konvertierungsproblem mit Zahl in Zeit:
@mehrwiedu Er scheint da die Sommerzeit gar nicht zu beachten:
Du vergisst aber, dass Javascript nicht einfach alles in der Zentralen Unixtime angibt.
Ich korrigiere damit ja den Zeitzonen "Fehler", da ich eig gar keine Zeitzone möchte.Das unterstreicht doch aber genau was ich sage, oder bin ich da wieder der Javascript Logik aufgesessen?
getDateObjekt(5400000) liefert exakt die Uhrzeit, die es benötigt. 02:30Uhr. Basis 01:00Uhr Unixtime bei UTC +1 (Sommerzeit).
newDate(5400000) ebenso. Ansonsten ließe sich doch die aktuelle Realzeit gar nicht bestimmen.getDateObject("1:30") hingegen ist ja nicht relativ, sondern absolut angegeben und muss direkt auf die Realzeit zugreifen, bzw. in Abhängigkeit von 0 demnach UTC +2 berücksichtigen.
Das erscheint mir komischerweise vollkommen logisch.
Das was man auch bei meinen Screenshots sehr schön erkennen kann ist, dass Unixtime 0 hier nicht auf 0:00Uhr abzielt, sondern auf 01:00Uhr und somit bei UTC +1 bleiben kann und an dieser Stelle bereits die Sommerzeit ignoriert.Wenn ich im Oktober diese Abfrage auf 0 mache, steht da auch wieder 0:00Uhr und dann hätte man doch mit Abzug der 3.600.000ms im Skript die Sommerzeit zweimal ignoriert.
Das was ich mit newDate(5400000) erhalte ist die korrekte Uhrzeit eineinhalb Stunden später als Unixtime in einer durch Sommerzeit geprägten Zeitzone. Gleiche Funktion gibt mir zur Normalzeit auch wieder die korrekte Uhrzeit eineinhalb Stunden nach Unixtime. Sonst wie gesagt, kann ich doch keine Realzeitabfragen damit tätigen.
-
@mehrwiedu na gut überredet^^ Jetzt sehe ich es auch.
Jetzt sind wir aber weit vom Thema abgekommen.
Zu sagen ist: Nein es ist kein Bug. Tut alles was es soll.@XxJooO
Gegenfrag: Wofür brauchst du das?
Vll gibt es ja ander Methoden für das was du machen möchtest. -
@thewhobox sagte in Konvertierungsproblem mit Zahl in Zeit:
@mehrwiedu na gut überredet^^
Du, ich hab keinen Plan (immer noch nicht) von Javascript. Ich vertraue Dir da wesentlich mehr, was die Funktionen angeht.
Da bist Du der Profi.
Ich hab das anfangs nur nicht gerafft, was der Block da eigentlich machen soll.
Am Ende stünde für mich die Aussage, dass wirklich ein Konvertierungsblock fehlt, der schlicht und einfach eine Zahl in ms in Stunden und Minuten umrechnet.
Wobei man das eben auch mit mathematischen Blöcken selbst erledigen kann, wenn man nicht auf eine Uhrzeit aus ist, oder damit rechnen will.
-
@mehrwiedu sagte in Konvertierungsproblem mit Zahl in Zeit:
Am Ende stünde für mich die Aussage, dass wirklich ein Konvertierungsblock fehlt, der schlicht und einfach eine Zahl in ms in Stunden und Minuten umrechnet.
Gut zusammengefasst, denn das ist genau das, was ich erreichen wollte. Ich berechne die Sonnenuntergangszeit ab Mitternacht in Minuten und ziehe davon die aktuelle Zeit in Minuten ab. Die Funktion sollte einfach das Resultat in Minuten in SS:mm umrechnen um das in einer vis anzuzeigen.
Wir haben jetzt gelernt, dass die gebotene Funktion das nicht leistet und haben von den Experten herleiten lassen, warum nicht das gewünschte Ergebnis rauskommt.
Aber mal ehrlich, hätten nicht die von Euch, die erklärt haben warum das Ergebnis 02:30 Std. ist, nicht primär auch ein anderes Ergebnis erwartet?Wie auch immer werde ich die Frage als gelöst markieren und das Ergebnis "zu Fuß" umrechnen. Bei dem ganzen hin und her mit der Sommerzeit und dem, was vielleicht in 2 Jahren kommt müsste ja mit den Linux-Updates die Zeitabfrage unter Linux selbst angepasst werden. So müsste die "zu Fuß" Lösung, die @Asgothian angeboten hat, nämlich die Differenz von Konvertierung von "0" und der berechneten Minuten in Zukunft immer das gewünschte Ergebnis bringen.
Ist schon ein geiles System, viele Ecken und Kanten, aber sehr lehrreich. Nicht zuletzt durch Alle, die mit machen.
-
@XxJooO sagte in [gelöst] Konvertierungsproblem mit Zahl in Zeit:
Aber mal ehrlich, hätten nicht die von Euch, die erklärt haben warum das Ergebnis 02:30 Std. ist, nicht primär auch ein anderes Ergebnis erwartet?
Ich hatte tatsächlich von dem Block erwartet, dass er 1 Stunde und 30 Minuten als Ergebnis zeigt.
Nun ist es aber so, dass er ein Datum inkl. Uhrzeit anzeigt, was in Abhängigkeit der Optionen nur zurechtgestutzt wird.
Nimm mal anstelle Deines Beispiels "SS:mm" abwechselnd "Stunden", "Minuten" und "Sekunden". Da kommt dann 2, anschließend 30 und dann 0 raus.
Und das ist unabhängig der Sommerzeitproblematik ein ganz anderes Ergebnis als erwartet werden darf.
Der Block ist quasi eine übersetzte rechts - links Funktion aus Excel.Das sind in der Erwartung eines Ergebnisses natürlich echt zwei unterschiedliche Dinge und lassen auch oft verzweifeln.
Wer weiß, vielleicht ist das aber nur für jemanden unlogisch, der nicht programmieren kann.
Da hakt es bei mir auch noch mit der Javascript- und folglich auch mit der Blockly Logik.Ich habe bis heute die Schwierigkeit zu verstehen, warum ein Timeout rein von seiner Platzierung zuerst gestoppt wird, bevor er beginnt.
Aber wie Du schon sagst, das ist hier das Interessante an jeder einzelnen Frage die gestellt wird, man lernt immer und überall etwas dazu und es macht im Gegensatz zu anderen Bereichen auch noch richtig Spaß, weil ein produktives Ergebnis dahinter steckt. -
Eine super Diskusionsrunde! Habe mal wieder was gelernt. Danke an alle Teilnehmer.
