[gelöst] Konvertierungsproblem mit Zahl in Zeit

[XxJooO]

Guten Morgen, kann mir jemand erklären, warum das folgende Blockly das unerwartete Ergebnis bringt?

In meiner Vorstellung sollte da 5.400.000/1.000/60, also 90 Minuten oder 01:30 Std. herauskommen. Ist das ein Bug? Oder ein Denkfehler von mir?
Wenn Bug, dann mache ich ein git issue auf.

[mehrwiedu]

@XxJooO

Vielleicht eine Rundungsdifferenz?
Ich habe Null Plan, wie der Baustein das rechnet und anschließend anzeigt, aber vielleicht ist die Anzeige (ss) = 1.5 auch gerundet auf 2 und (mm) dann mit tatsächlichen 30 angegeben, so dass anschließend 01.5:30 und dann eben gerundet 02:30 da steht?

Ist nur ein Schuss ins Blaue.
Was kommt denn raus, wenn Du 3.600.000ms also genau 1 Stunde, oder 7.200.000ms für 2 Stunden eingibst?

[thewhobox]

@XxJooO Guten Morgen,
So wie ich das hier verstehe erstellt er daraus ein Datumsobject.
Somit ist 5.400.000 => 1:30 Uhr.
Da wir Sommerzeit haben ist es 2:30 Uhr

Das ist nämlich der generierte JS-Code

formatDate(getDateObject(5400000), "hh:mm")

Entweder du fragst noch die Sommerzeit ab oder musst dir selbst eine Funktion dafür erstellen.
(Oder warten bis sie abgeschafft wird^^)

[Asgothian]

@thewhobox sagte in Konvertierungsproblem mit Zahl in Zeit:

(Oder warten bis sie abgeschafft wird^^)

Oder nutzt einen einfachen Trick:

Erstell Dir 2 Zeiten (einmal aus aus 0, einmal aus 5400000, und Bilde die Differenz. Da beide Uhrzeiten in Sommerzeit konvertiert werden bleibt die Differenz 1.5 stunden.

Geht nur dann ggf. schief wenn gerade umgestellt wird.

A.

[mehrwiedu]

@thewhobox sagte in Konvertierungsproblem mit Zahl in Zeit:

@XxJooO Guten Morgen,
So wie ich das hier verstehe erstellt er daraus ein Datumsobject.
Somit ist 5.400.000 => 1:30 Uhr.
Da wir Sommerzeit haben ist es 2:30 Uhr

Das ist nämlich der generierte JS-Code

formatDate(getDateObject(5400000), "hh:mm")

Entweder du fragst noch die Sommerzeit ab oder musst dir selbst eine Funktion dafür erstellen.
(Oder warten bis sie abgeschafft wird^^)

Welches Datum erstellt er denn daraus? Und warum genau geht die Funktion dann nicht auf die Systemzeit? Die ist aktuell UTC +2 für den geografischen Standort des Rechners.
Kann ja sonst nicht aus der Unixtime generiert sein, oder?
Ansonsten ist das doch eine ganz simple Umrechnung von Millisekunden in Stunden:Minuten
5.400.000 bleibt im Sommer wie im Winter, bezogen auf die Unixtime immer der 04.03.1970 13:00Uhr und nicht 13:30Uhr.
Wo holt die Funktion also 1:30Uhr her? PM oder AM ist jetzt erstmal egal. Geht um die halbe Stunde.
Aktuelle Zeit (09.04.2019 10:47Uhr) + 5.400.000ms sind auch nicht plötzlich 09.04.2019 13:17Uhr, sondern immer noch 12:17Uhr

Das kommt mir irgendwie sehr umständlich vor, da noch über das Datum zu gehen, anstatt die Millisekunden einfach umzurechnen.

Andersherum, wenn man davon ausgeht, dass es sich bei getDateObject um das Tagesdatum beginnend mit 0.00Uhr ist, dann kriege ich da auch keine Logik rein, denn dann holt sich die Funktion in Abhängigkeit von der Systemzeit nicht den 09.04.2019 0:00Uhr, sondern 09.04.2019 01:00Uhr. Dabei muss sie ja quasi beeinflusst werden. Ergibt aus meiner Sicht bei einer (geografisch) globalen Funktion überhaupt keinen Sinn. Auf der anderen Seite der Erde haben wir eine Datumsgrenze nach rechts und nach links verschoben. Gleiches Skript in Marokko bei gleicher Zeitzone wie Deutschland zeigt also korrekt 1:30Uhr an?

[thewhobox]

@mehrwiedu Edit: war blödsinn zuerst.

Edit2:
Nach ein bisschen rumprobieren hat sich folgendes ergeben:
getDateObject erstellt (wenn input kein string) ein neues Date

new Date(input)

Da der Input aber als Unix Stamp gehandelt wird und erhält somit auch direkt die Sommerzeit mit.

@XxJooO erstell dir einfach eine Javascriptfunktion mit:

formatDate(input, "hh:mm")

[mehrwiedu]

@thewhobox sagte in Konvertierungsproblem mit Zahl in Zeit:

@mehrwiedu Edit: war blödsinn zuerst.

Edit2:
Nach ein bisschen rumprobieren hat sich folgendes ergeben:
getDateObject erstellt (wenn input kein string) ein neues Date

new Date(input)

Da der Input aber als Unix Stamp gehandelt wird und erhält somit auch direkt die Sommerzeit mit.

@XxJooO erstell dir einfach eine Javascriptfunktion mit:

formatDate(input, "hh:mm")

Ich versuche zu folgen.
Hinter dem Blockly Objekt "Konvertiere Datum/Zeit (Zahl) nach SS:MM" steht ein newDate?
Wie ist das denn dann insgesamt zu verstehen? Ich erkenne die Logik dieses Bausteins nicht.
Und auch nicht, woher er dann die Sommerzeit nimmt? Dann muss doch quasi in Abhängigkeit der Systemzeit irgendwas berechnet werden?

5.400.000 ist in Unixtime der 04.03.1970 13:00Uhr. Das ist aber unerheblich, wenn ich das richtig verstanden habe.
Von welcher Zeit (Datum) wird denn jetzt bei der Funktion ausgegangen, wenn ich das in Relation zu 1:30Uhr setzen möchte und somit 01 Stunde 30 Minuten als (best) Ergebnis haben möchte muss es doch Tagesanfang Systemzeit sein.
Und das ist doch unabhängig von Winter oder Sommerzeit immer 0:00Uhr.
Irgendwo holt er sich aber doch fälschlicher Weise dann die aktuelle Zeitzone ab, ansonsten könnte doch niemals 2:30Uhr rauskommen.

/edit
Ahh nee. Jetzt glaube verstehe ich so langsam.
5.400.000 in Unixtime sind umgerechnet 62,5 Tage nach dem 01.01.1970 - 12:00AM

Nicht Millisekunden, sondern Sekunden.

5.400.000s / 60 = 90.000min
90.000min / 60 = 1.500h
1.500h / 24 = 62,5 Tage

01.01.1970 - 12:00AM + 62,5 Tage = 04.03.1970 - 12:00PM

Für die Funktion aber völlig unerheblich was 5.400.000 in Unixtime sind, weil es sie als Millisekunden interpretiert, ausgehend von Beginn der Unixtime.
Das Ergebnis aus dem obigen Block ist also keine Konvertierung, sondern einfach nur ein errechnetes Datum auf Basis der angegebenen Millisekunden plus einer Formatierung auf Stunde und Minute .

01.01.1970 - 12:00 AM + 5.400.000ms = 01.01.1970 - 01:30 AM

Die einzige Konvertierung, die stattfindet, ist die Konvertierung der Datumsanzeige. Es wird nun nur noch die Stunde und die Minute des Datums angezeigt. Also 01:30 Uhr.
Und da wir uns in der UTC +1 (Sommerzeit +2) befinden, sind 1,5 Stunden auf die Unixtime momentan 02:30Uhr.

So wird ein Schuh draus.

[thewhobox]

@mehrwiedu Also mal ganz am Anfang. Das Element sieht wie folgt aus:

Spoiler

getDateObject:  function (date) {
  if (isObject(date)) return date;
  if (typeof date !== 'string') return new Date(date);
  if (date.match(/^\d?\d$/)) {
    const _now = new Date();
    date = _now.getFullYear() + '-' + (_now.getMonth() + 1) + '-' + _now.getDate() + ' ' + date + ':00';
  } else {
    // 20:00, 2:00, 20:00:00, 2:00:00
    if (date.match(/^\d?\d:\d\d(:\d\d)?$/)) {
      const now = new Date();
      date = now.getFullYear() + '-' + (now.getMonth() + 1) + '-' + now.getDate() + ' ' + date;
    }
  }
  return new Date(date);
}

Du kannst auch mal versuchen

console.log(formatDate(new Date(0), "hh:mm"));

Da bekommst du 1:00 raus.

Unter w3schools steht folgende beschreibung für "new Date(number)"

01 January 1970 plus 100 000 000 000 milliseconds is approximately 03 March 1973:

Ich denke mal somit, dass er zu dem Unix Stamp 0 die 5400000 hinzu und macht es dann in die Richtige Zeitzone (eben +1 Stunde).

Um das zu verhindern kann man auch einfach von den 5400000 die 3600000 (1h) abziehen = 1800000

[mehrwiedu]

@thewhobox sagte in Konvertierungsproblem mit Zahl in Zeit:

@mehrwiedu Also mal ganz am Anfang. Das Element sieht wie folgt aus:

Habe oben in meinem Post ergänzt. Glaube, bin dahinter gestiegen.

Um das zu verhindern kann man auch einfach von den 5400000 die 3600000 (1h) abziehen = 1800000

Aber auch nur innerhalb der Sommerzeit. Ab Oktober zeigt das Skript sonst nur ne halbe Stunde Unterschied, solange wir die Sommerzeit haben.

Am Ende zeigt das Skript aber genau das, was es zeigen muss. Die korrekte Uhrzeit in Abhängigkeit von Winter- oder Sommerzeit. Es hat hier nur einen falschen Einsatz. Es konvertiert ja nicht, sondern formatiert nur.

[thewhobox]

@mehrwiedu

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^^

[Thisoft]

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?

[XxJooO]

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?

[mehrwiedu]

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

[thewhobox]

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

[mehrwiedu]

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

[mehrwiedu]

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

[thewhobox]

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

[mehrwiedu]

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

[XxJooO]

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

[mehrwiedu]

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