Weihnachtsangebot 2025! 🎄

[diwoma]

Hi, ich logge Daten in die Influx-DB und in einen MS-SQL-Server. In den SQL-Server deswegen, weil ich mich mit der SQL-Syntax für Auswertungen besser auskenne als mit der Influx-Syntax.

Bei der Auswertung der Daten kommen mir vor allem beim Timestamp und beim _from in den Datenpunkten Fragen auf:

1. Timestamp: Ist das der UTC-Timestamp oder der lokale Timestamp? Ich nehme an, es ist der UTC-Timestamp, aber da die Timezone nicht mit angegeben ist, kann man es (zumindest nicht im MS-SQL-Server) einfach in die lokale Datetime umrechnen, zumal in Europa (noch) durch die Sommerzeit 2 Zeitzonen vorhanden sind. Man müsste bei allen Abfragen, wenn man die Zeit umrechnet eine Abfrage nach den Grenzen der Sommerzeit einfügen, was dann doch belastend für die Abfrage wäre.
2. im _from ist die Quelle eingetragen, die den Datenpunkt schreibt, ich habe 2 Quellen:

1	system.adapter.javascript.0
2	system.adapter.sql.0

Bei mir steht aber immer 1 (javascript) als Quelle, sollte nicht der 'adapter' eingetragen sein, zumal er die Datenpunkte schreibt? Bzw. wann würde der Adapter als Quelle eingetragen sein?

3. Wenn das mit mit dem Timestamp im MS-SQL-Server so kompliziert wird, macht es Maria-DB da einfacher. Ich habe mit MySql weniger Erfahrung, aber da gibt es eine eingebaute Funktion die einen Timestamp in ein Datetime umwandelt, berücksichtigt diese Funktion eine wechselnde Zeitzone aufgrund des Datums?

[fastfoot]

@diwoma schau mal hier. Kann es nicht testen aber sieht easy aus

[diwoma]

@fastfoot Ja, schaut einfach aus, hat nur ein Problem:
Das ist für lokale Zeit nur richtig, wenn der Timestamp auch ein lokaler Timestamp ist. Ist der Timestamp aber ein UTC-Timestamp dann sieht die Umwandlung wie folgt aus:

MEZ:   dateadd(s, v.ts/1000, '1970-01-01 01:00:00')
MESZ:  dateadd(s, v.ts/1000, '1970-01-01 02:00:00')

deshalb auch meine Frage, welcher Timestamp in die DB geschrieben ist.

Ist es UTC-Zeit dann wird es etwas komplizierter:
Da in den Datapoint's auch keine Zeitzonen-Beschreibung zum Datapoint dazugegeben wurde, muss man erst abfragen ob der Timestamp in die MEZ oder MESZ Zone fällt und dann entsprechend die Umwandlung durchführen:
Zuerst das Datum ermitteln, dann prüfen ob das Datum größer als MESZ-Startdatum und kleiner als MESZ-Enddatum für das jeweilige Jahr ist und dann 1 Stunde oder 2 Stunden addieren, wobei der Beginn und Ende der MESZ-Zone nicht fix ist sondern vom letzten Wochenende im März und Oktober abhängig ist.

[fastfoot]

@diwoma ja das ist utc. from_unixtime(ts/1000) in Maria-Db konvertiert das in die lokale Zeit. Du sagtest der sql Server unterstützt die Umwandlung nicht, was halt nur teilweise stimmt. Es fehlt halt die Umwandlung von UTC zu lokaler Zeit

[diwoma]

@fastfoot Wenn Du die reine Additon einer Anzahl an Sekunden zu einem 'beliebigen' Datum als Unterstützung meinst, dann hast Du Recht. In meinen Augen ist das nur eine Krücke. Und tatsächlich liegt das Problem wirklich an der fehlenden Erkennung zur Umrechnung in die lokale Zeit

[diwoma]

Ich habe eine Lösung in StackOverflow gefunden:

/* Aus MySQL ermittelt
select UNIX_TIMESTAMP('2022-06-06 15:00'); // => 1654520400
select UNIX_TIMESTAMP('2022-03-03 15:00'); // => 1646316000
*/

SELECT *, DATEADD(SECOND, UnixTimestamp, '1970-01-01') AT TIME ZONE 'UTC' AT TIME ZONE 'Central European Standard Time' AS LocalTime
FROM (VALUES (1646316000), (1654520400)) AS Tests(UnixTimestamp) 

UnixTimestamp	LocalTime
1646316000	03.03.2022 15:00:00.000 +01:00
1654520400	06.06.2022 15:00:00.000 +02:00

Und wie man aus der LocalTime sieht, wird die Sommerzeit auch korrekt erkannt. Ist zwar nicht so elegant wie in der MySql aber macht was ich wollte

[fastfoot]

@diwoma nun ja, was heisst elegant, ist doch voll flexibel, in mysql gibt es 'nur' die Umwandlung in die voreingestellte Systemzeit, soweit mir bekannt.

[diwoma]

@fastfoot Da gebe ich Dir recht.

Danke für die Begleitung und Hilfe.