warnings.time im UTC-Format?

[bit-refresher]

node-red-contrib-dwd liefert ggf. mehrere warnings-Objekte. Aufeinanderfolgende Abfragen liefern tw. die gleichen Objekte mit gleichem Inhalt, jedoch in anderer Reihenfolge. Das erschwert die Detektierung identischer Warnungen erheblich. Mein Ziel ist, eine aus den Inhalten der Warnungen generierte XMPP-msg nur dann zu versenden, wenn sich gegenüber dem letzten Versand deren Inhalt verändert hat. Ich glaube, das mit meiner letzten Änderung recht gut bewerten zu können. Ein "Luxusproblem" verbleibt dennoch - das Format von warnings.time ermöglicht mit zumutbarem Aufwand nur eine endlich gute Sortierung.
(Ergänzend unten die Kommentierung meines change-nodes, welcher die XMPP-msg generiert. Die Bereitstellung der Zeitangaben im UTC-Format würde deren Bewertung drastisch vereinfachen. Bei Interesse stelle ich den node gerne bereit.)

Ich vermute (wegen der Lösung gem. https://www.home-assistant.io/integrations/dwd_weather_warnings/), dass die DWD-API die Daten zu warnings.time im UTC-Format bereitstellt. Falls dies zutrifft, wäre es sehr schön, wenn mit einem neuen release bspw. warnings.warning_start_utc und warnings.warning_end_utc zusätzlich bereitgestellt werden könnten. Mit dieser sicher minimalinvasiven Änderung wäre Abwärtskompatiblilität gewährleistet.

Vielen Dank im Übrigen für den node, welchen ich seit 2019 gerne nutze.

Gruß
bit-refresher

----- snip ----- snip ----- snip ----- snip ----- snip ----- snip ----- snip ----- snip ----- snip ----- snip -----

// Aus der Original-msg mit den DWD-Daten werden diejenigen Daten extrahiert, die als XMPP-
// Nachricht versendet werden sollen. Weil in der Eingangs-msg ggf. mehrere events über-
// mittelt werden, muss die Abfrage und Aufbereitung mittels einer Schleife erfolgen.
//
// update 03.01.2024:
// node-red-contrib-dwd 0.9.0 liefert Sequenzen von Warnungen, die nicht sortiert sind.
// Bei aufeinanderfolgenden Abfragen werden tw. die gleichen Warnungen, aber in unterschied-
// licher Reihenfolge geliefert. In diesen Fällen wirkt die Unterdrückung von dem Grunde nach
// identischen Nachrichtensequenzen nicht. Aus diesem Grund werden jetzt die Warnungen zuerst
// sortiert und erst dann zur Nachricht zusammengesetzt. Um eine geeignete Sortierung zu
// erreichen, werden einstelligen Stundenangaben vor der Sortierung Nullen vorangestellt.
//
// (Potentiell verbleibender Fehler in der Sortierung: bspw. dürfte eine Eingangssequenz
// "Mi. 3. Jan. 8:00" - "Di. 2. Jan. 18:00" - "Do. 4. Jan. 18:00" wie folgt aufgelöst werden:
// "Di. 2. Jan. 18:00" - "Do. 4. Jan. 18:00" - "Mi. 3. Jan. 08:00". Das sei wegen mutmaßlich
// geringer Vorkommenshäufigkeit b.a.W. mal hinzunehmen ... Lösungsansatz für langweilige
// Stunden: Sortierung auf Basis eines Teilstring mit abgeschnittenem führenden Wochentag -
// dazu müssten aber einstelligen Tagen ebenfalls Nullen vorangestellt werden - jedoch käme
// dennoch mit einer recht hohen Wahrscheinlichkeit in der Sortierung bspw. der 1. vor dem
// 31.)