max. verarbeitbare Anzahl Millisekunden
-
@paul53
Hi Paul,
hast du mir hierfür auch noch einen Tipp.
Ich möchte einen Datenpunkt nur 1 x am Tag nach influxdb schreiben, z.B. abends um 19 Uhr.
Brauche ich dafür ein Script? Sagt zumindest ChatGPT
-
@cbrocker sagte: Brauche ich dafür ein Script?
Sicherlich, denn ich glaube nicht, dass man influxdb entsprechend konfigurieren kann.
Ich würde dafür täglich um 19:00 Uhr einen eigenen Datenpunkt unter "0_userdata.0" setzen, der historisiert wird. -
@paul53 ah, Groschen gefallen. Natürlich logisch. Ich war jetzt auf einem anderen, umständlicheren Weg. Aber mit deinem Tipp ist das natürlich viel einfacher.
Vielen Dank für deine wertvollen Tipps -
hier die spezifikation von javascript zum thema zeit
https://262.ecma-international.org/5.1/#sec-15.9.1.1das date objekt kann also jeweils 100 Millionen Tage vor und nach dem 1.1.1970 rechnen.
Das müsste für die meisten Anwendungsfälle ausreichend sein.15.9.1.1Time Values and Time Range
A Date object contains a Number indicating a particular instant in time to within a millisecond. Such a Number is called a time value. A time value may also be NaN, indicating that the Date object does not represent a specific instant of time.Time is measured in ECMAScript in milliseconds since 01 January, 1970 UTC. In time values leap seconds are ignored. It is assumed that there are exactly 86,400,000 milliseconds per day. ECMAScript Number values can represent all integers from –9,007,199,254,740,992 to 9,007,199,254,740,992; this range suffices to measure times to millisecond precision for any instant that is within approximately 285,616 years, either forward or backward, from 01 January, 1970 UTC.
The actual range of times supported by ECMAScript Date objects is slightly smaller: exactly –100,000,000 days to 100,000,000 days measured relative to midnight at the beginning of 01 January, 1970 UTC. This gives a range of 8,640,000,000,000,000 milliseconds to either side of 01 January, 1970 UTC.
The exact moment of midnight at the beginning of 01 January, 1970 UTC is represented by the value +0.
-
@oliverio Hey, danke für die Info.
Ja, dieser Time Range sollte auf jeden Fall reichenGrüße
-
@cbrocker
Wenn im Adapter keine Sonderbehandlung für lange Zeiträume implementiert ist, dann kann es bei Intervallen / Timeouts größer 2147483647 ms (ca. 24,8 Tage) zu einem Fehlverhalten kommen:When delay is larger than 2147483647 or less than 1, the delay will be set to 1. Non-integer delays are truncated to an integer.
Die oben diskutierten 64 Bit betreffen nur Timestamps. Die node Funktionen setTimeout / setIntervall arbeiten NICHT mit 64 Bit.
Welche Limits für den javascript Adapter gelten weiß ich nicht.
Quelle: https://nodejs.org/dist/latest-v18.x/docs/api/timers.html
-
@mcm57 sagte: When delay is larger than 2147483647
Gut recherchiert
Dann gilt diese Grenze (2^31 - 1) auch für den Javascript-Adapter.
-
@paul53
Danke - aber das Lob gehört anderen.Diese Einschränkung wurde in den letzten Monaten im Developer Telegramm publik bzw. mehrfach diskutiert - daher stammt mein Wissen. Problem trat glaub ich beim Admin auf wenn man die Repositories nur mehr 1x Monat aktualisiseren lassen wollte. 1Monat = zu groß = nächste Aktualisierung sofort = ioB Instanz ist dicht ... (oder so ähnlich
)@alle Developer
Prinzipiell wäre es wichtig, dass ALLE Adapter Timerwerte prüfen und vorzugsweise setTimeout/setIntervall und clearXxxx vom adapter Packages (also adapter.setTimeout bzw. this.setTimeout) verwenden. Dort sollte dieses Limit zumindest in den aktuellsten Versionen auch zentral abgesichert sein. -
@mcm57 sagte: beim Admin auf wenn man die Repositories nur mehr 1x Monat aktualisiseren lassen wollte.
Das erfolgt per Timeout bzw. Intervall? Für so lange Zeiträume (mehrere Tage) würde ich es nicht verwenden.
-
@paul53
Sorry, hab da keine Detailinfos und auch nicht im Code gesucht.
Glaub mich nur daran zu erinnern, dass es dort aufgefallen ist. Kann mich aber auch irren wo das auftrat. Und normalerweise werden ja die Repos sowieso täglich aktualisisert.
