LocalTime to UTC epoch timestamp



  • @DirkB sagte in LocalTime to UTC epoch timestamp:

    @It0101 sagte in LocalTime to UTC epoch timestamp:

    20000-40000 Zeitstempel pro Sekunde ungefähr. Bissel Luft nach muss auch noch drin sein. 🙂

    Da reichen Millisekunden doch nicht mehr aus.

    Doch die reichen schon. Es ist nicht eine Zeitreihe, sondern es sind 300.000 voneinander unabhängige Zeitreihen. 🙂 Die Zeitstempel kommen nur teilweise in Echtzeit. Vereinzelt ist auch mit Zeitstempeln aus der Vergangenheit zu rechnen.

    Der kritische Punkt ist halt, dass Mitternacht lokale Zeit und Mitternacht UTC-Zeit zwei unterschiedliche Dinge sind. Wenn ich z.B. um 00:50h einen CEST-Timestamp bekomme ist es in UTC erst 22:50, d.h. es ist dort noch "gestern" und lokal schon "heute". Wobei das bei deinem Stunden-basierten Ansatz ja prinzipiell kein Problem sein sollte. Bei meinen 24h-Basistimestamp ist es schon ein Problem. Oder sehe ich das falsch?



  • Nimm doch GMT+1 um einen timestamp für Mitternacht zu erstellen als referenz um den eigentlichen timestamp zu berechnen.
    Um daraus dann einen UTC Timestamp zum generieren musst man dann nur noch 1h abziehen. Bzw wenn es CEST dann halt 2h abziehen.

    Dann hast du während der Berechnung aus einem relativen wert (relative zu mitternacht des aktuellen Tages) keine Probleme da alle daten sich in der selben Zeitzone befinden.

    Wobei ein relativer wert zu einer lokalen Zeitzone probleme hat wenn eine Zeitumstellung stattfindet...
    Denn dann macht das ganze einen sprung. Und wenn die Zeit zurückgestellt wird, kommen dann doppelte absolute Timestamps zustanden

    Die Frage ist halt wie performant man einen Timestamp für Mitternacht des aktuellen Tages bekommen kann.

    Wobei man die Berechnung des Referenzwertes nur einmal machen muss wenn man sich den wert cached mit Datum(eventuell reicht auch nur der Tag des Monats) als key.
    Und den dann erst neu berechnet wenn der Tag sich ändert.



  • @It0101 Du musst ja nicht Mitternacht UTC als Basis nehmen sondern 01:00 oder 02:00 UTC.

    Das Problem sehe ich in der Erkennung der Sommerzeitumstellung.
    Wobei die Rückstellung im Herbst das Problem ist, da der Client dann zweimal Zeiten für 02:00 bis 03:00 sendet

    Das könnte man aber mit dem Vergleich zwischen der letzten und aktuellen Zeit erkennen. Bei ~ 1 h ist es die Sommerzeitumstellung, bei ~ 24 h ist es ein neuer Tag.
    Der Offset dazu sind aber immer Konstanten.

    Bei Werten aus der Vergangenheit wird es um Mitternacht etwas problematisch.

    Schaltsekunden spielen hoffentlich keine Rolle.



  • @DirkB sagte in LocalTime to UTC epoch timestamp:

    @It0101 Du musst ja nicht Mitternacht UTC als Basis nehmen sondern 01:00 oder 02:00 UTC.

    Das Problem sehe ich in der Erkennung der Sommerzeitumstellung.
    Wobei die Rückstellung im Herbst das Problem ist, da der Client dann zweimal Zeiten für 02:00 bis 03:00 sendet

    Das könnte man aber mit dem Vergleich zwischen der letzten und aktuellen Zeit erkennen. Bei ~ 1 h ist es die Sommerzeitumstellung, bei ~ 24 h ist es ein neuer Tag.
    Der Offset dazu sind aber immer Konstanten.

    Bei Werten aus der Vergangenheit wird es um Mitternacht etwas problematisch.

    Schaltsekunden spielen hoffentlich keine Rolle.

    Ich wollte eigentlich den Zeitzone und Zeitumstellungskram loswerden, aber vermutlich komme ich da nicht drum herum. Ich will halt immer so unabhängig von Konfiguration sein, wie möglich. Aber vermutlich geht es nicht ohne eine gewisse Konfiguration:

    • von Datum1 bis Datum2: +2h
    • von Datum2 bis Datum1: +1h


  • @DirkB sagte in LocalTime to UTC epoch timestamp:

    Bei Werten aus der Vergangenheit wird es um Mitternacht etwas problematisch.

    Die kann ich aber inhaltlich sauber vom Rest trennen und es sind so wenige, dass ich da durchaus eine teurere Konvertierung verwenden kann.

    Schaltsekunden spielen hoffentlich keine Rolle.

    Nein. das ist kein Thema.



  • @It0101 sagte in LocalTime to UTC epoch timestamp:

    Ich wollte eigentlich den Zeitzone und Zeitumstellungskram loswerden,

    Dann musst du den Client umkonfigurieren, denn der liefert ja (so lese ich das aus deinen Angaben) die Sommerzeit und muss demnach eine Umstellung haben.

    von Datum1 bis Datum2: +2h
    von Datum2 bis Datum1: +1h

    So einfach ist es dann doch nicht, da sich das Datum am Wochentag (letzter Sonntag im Monat) orientiert.

    • von Datum1 bis Datum2: +2h
    • von Datum2 bis Datum3: +1h
    • von Datum3 bis Datum4: +2h
    • .....

    Aber für diese Vorberechnung hast du ja 5-7 Monate Zeit.



  • @DirkB sagte in LocalTime to UTC epoch timestamp:

    So einfach ist es dann doch nicht, da sich das Datum am Wochentag (letzter Sonntag im Monat) orientiert.

    Stimmt. Das hatte ich total vergessen....



  • Es ist einfach ein unangenehmes Thema. 😀 Ich stelle mir einfach vor, es gäbe nur UTC und sonst nix auf der Welt. 🤩


  • Mod

    @DirkB sagte in LocalTime to UTC epoch timestamp:

    Schaltsekunden spielen hoffentlich keine Rolle.

    Wahrscheinlich schon, denn ein Gerät das solche Werte liefert, klingt doch sehr nach einem Gerät der Messtechnik. Dem ist die menschengemachte Uhrzeit egal, da zählt die echte, physikalische Zeit.

    @It0101: Habe ich mit dieser Vermutung Recht? Wenn das wirklich physikalische Messwerte sind, dann hat das schon seine Gründe, warum das Gerät keine Uhrzeit liefert, sondern absolute Differenzen zu einer Referenzuhrzeit. Versuche, dies sinnvoll und konsistent in ein Uhrzeitkorsett zu zwingen, sind zum Scheitern verurteilt. Und auch kontraproduktiv, wenn man hinterher sinnvolle, konsistente physikalische Auswertungen auf den Daten machen möchte.



  • @SeppJ
    Nein, es handelt sich dabei um Wertpapier-TickDaten. Diese werden in einigen Fällen in lokaler Zeit geliefert. Unser Server, der die Daten entgegen nimmt, wandelt dies in Millisekunden seit Mitternacht um und schickt es weiter.
    Wir sind aktuell dabei, alles auf UTC umzustellen, zumal sogar einige Datenprovider selbst auch UTC liefern. Aber das Risiko ist zu groß, alles gleichzeitig umzustellen, daher braucht mein System temporär diesen Workaround, bis alle Zeitstempel auf UTC umgestellt sind.

    Man könnte zu recht fragen, warum wir nicht zuerst die vordersten Systeme umstellen. Der Hintergrund ist, das das bisherige System, für das ich den Nachfolge entwickele, der größte Flaschenhals war und somit höher priorisiert angegangen wurde. Die Umstellung auf UTC ist da nur ein Nebenprojekt was in dem Zuge mit realisiert wird.


  • Mod

    Ok, das sollte kein Problem sein. Also abgesehen von dem Problem, das du gerade hast 🙂



  • @It0101 sagte in LocalTime to UTC epoch timestamp:

    Unser Server, der die Daten entgegen nimmt, wandelt dies in Millisekunden seit Mitternacht um und schickt es weiter.

    Für das Problem an sich wäre natürlich die beste Lösung diesen Server zu ändern, dass er einen timestamp sendet statt eine differenz zu einer Referenzzeitpunkt.
    Wieso wurde diese Umwandlung überhaupt gemacht? Wenn der eigentliche Datenlieferant schon einen "Timestamp" liefert?

    Wollte man damit früher Daten sparen? Nun beisst sich dass, das das nachfolgende System daraus wieder einen timestamp machen muss.

    Moment es soll jetzt auf UTC umgestellt werden? Was hat das bisherige System mit den differenzzeiten gemacht?
    Wenn es da auch schon die DIfferenzzeit in einen Timestamp umgewandet halt (nur halt für die lokale Zeitzone), dann kann man das doch nehmen und dann den lokalen zeitzonen Timestamp in einen UTC Timestamp konvertieren.

    Ich hoffe mal dass das nicht genau das Problem im bisherigen System war, was es zu einem Flaschenhals machte?



  • @firefly sagte in LocalTime to UTC epoch timestamp:

    @It0101 sagte in LocalTime to UTC epoch timestamp:

    Unser Server, der die Daten entgegen nimmt, wandelt dies in Millisekunden seit Mitternacht um und schickt es weiter.

    Für das Problem an sich wäre natürlich die beste Lösung diesen Server zu ändern, dass er einen timestamp sendet statt eine differenz zu einer Referenzzeitpunkt.
    Wieso wurde diese Umwandlung überhaupt gemacht? Wenn der eigentliche Datenlieferant schon einen "Timestamp" liefert?

    Es gibt einige Datenquellen, die UTC liefern und einige die Lokalzeit liefern. Am Ende werden aber alle Daten in einem zentralen System bereitgestellt, daher muss man sich auf eine gemeinsame Zeitdarstellung einigen. In der Vergangenheit wurde diese Frage eben mit "Lokalzeit" beantwortet und jetzt ändert sich das zu "UTC".

    Moment es soll jetzt auf UTC umgestellt werden? Was hat das bisherige System mit den differenzzeiten gemacht?
    Wenn es da auch schon die DIfferenzzeit in einen Timestamp umgewandet halt (nur halt für die lokale Zeitzone), dann kann man das doch nehmen und dann den lokalen zeitzonen Timestamp in einen UTC Timestamp konvertieren.

    Nein. Die bisherigen Systeme machen das teilweise nicht so sauber, wie sie sollten. Daher entwerfe ich jetzt eine Klasse, die das ganze Thema sauber erschlägt und die dann beim späteren Redesign der Datenquellen verwendet werden kann.

    Ich hoffe mal dass das nicht genau das Problem im bisherigen System war, was es zu einem Flaschenhals machte?

    Nein. Das bisherige System, welches ich neu implementiere, hat nichts umgewandelt. Es ist einfach 20 Jahre alt und per Design veraltet.



  • @It0101 sagte in LocalTime to UTC epoch timestamp:

    Es gibt einige Datenquellen, die UTC liefern und einige die Lokalzeit liefern. Am Ende werden aber alle Daten in einem zentralen System bereitgestellt, daher muss man sich auf eine gemeinsame Zeitdarstellung einigen. In der Vergangenheit wurde diese Frage eben mit "Lokalzeit" beantwortet und jetzt ändert sich das zu "UTC".

    Das beantwortet leider meine Frage nicht.

    @It0101 sagte in LocalTime to UTC epoch timestamp:

    Unser Server, der die Daten entgegen nimmt, wandelt dies in Millisekunden seit Mitternacht um und schickt es weiter.

    Hier schreibst du dass die ein kommenden Timestamps in einen differenzwert umgerechnet werden.
    Und darauf bezog sich meine Frage. Wieso wurde das gemacht?

    Und das ist ja dein Problem dass die Komponenten, welche du neu entwickelst, keine Timestamps bekommt sondern differenzwerte seit Mitternacht.

    Hätte der Server, welche die Daten von den Datenquellen entgegen nimmt, die timestamps, welche in UTC reinkommen, in die Lokale Zeitzone (was du wohl als "Lokalzeit" bezeichnest) übersetzt dann hättest du jetzt kein Problem damit diese in UTC zu vereinheitlichen.

    Und eine meiner anderen Fragen hast du auch nicht beantwortet (ging wohl unter)
    "Was hat das bisherige System mit den differenzzeiten gemacht?"



  • @It0101 sagte in LocalTime to UTC epoch timestamp:

    Der Hintergrund ist, das das bisherige System, für das ich den Nachfolge entwickele, der größte Flaschenhals war und somit höher priorisiert angegangen wurde. Die Umstellung auf UTC ist da nur ein Nebenprojekt was in dem Zuge mit realisiert wird.

    Klingt riskant. Klingt so als wäre es schlauer das Ding erstmal zu refactoren/neu zu schreiben, und erst danach die UTC Umstellung zu machen.



  • @firefly sagte in LocalTime to UTC epoch timestamp:

    @It0101 sagte in LocalTime to UTC epoch timestamp:

    Unser Server, der die Daten entgegen nimmt, wandelt dies in Millisekunden seit Mitternacht um und schickt es weiter.

    Hier schreibst du dass die ein kommenden Timestamps in einen differenzwert umgerechnet werden.
    Und darauf bezog sich meine Frage. Wieso wurde das gemacht?

    Es gibt unterschiedliche Datenquellen.
    Eine Datenquelle schickt Datum und Uhrzeit getrennt, aber in lokaler Zeit ( glaube sogar BCD-Codiert ).
    Eine anderes schickt beides als String in lokaler Zeit.
    Wiederum andere schicken den kompletten UTC--Epochen-Timestamp.

    Es sind eben unterschiedliche Schnittstellen. Und damals hat wohl jemand entschieden, dass die Umwandlung in einen Differenzwert und die Umwandlung des Datums in ein Julianisches ( als Ganzzahl ) am meisten Sinn macht.

    Inzwischen ist die Orientierung des Unternehmens deutlich internationaler, daher liegt UTC nahe.

    Und das ist ja dein Problem dass die Komponenten, welche du neu entwickelst, keine Timestamps bekommt sondern differenzwerte seit Mitternacht.

    Hätte der Server, welche die Daten von den Datenquellen entgegen nimmt, die timestamps, welche in UTC reinkommen, in die Lokale Zeitzone (was du wohl als "Lokalzeit" bezeichnest) übersetzt dann hättest du jetzt kein Problem damit diese in UTC zu vereinheitlichen.

    Korrekt. Das ist dann der nächste Schritt, dass die Datenquellen genau das tun.

    Und eine meiner anderen Fragen hast du auch nicht beantwortet (ging wohl unter)
    "Was hat das bisherige System mit den differenzzeiten gemacht?"

    Das bisherige System speichert die Differenzwerte ( und das julianische Datum ) und gibt sie dann an Clients als formatierten String in lokaler Zeit weiter. Es rechnet damit nicht, falls das deine Frage war.



  • Aber ich habe mir jetzt mittlerweile eine Klasse gebaut ich die ich aktuell noch mit Unittests versehe, die diese Konvertierung zumindest für Live-Daten sauber vornimmt. Einmal pro Stunde gönne ich mir schlichtweg die Ermittlung des DST-Kennzeichens und die Errechnung des Basis-Timestamps.

    Die Wechsel auf Winterzeit bzw. Sommerzeit muss ich noch abtesten.



  • @It0101 sagte in LocalTime to UTC epoch timestamp:

    Das bisherige System speichert die Differenzwerte ( und das julianische Datum ) und gibt sie dann an Clients als formatierten String in lokaler Zeit weiter. Es rechnet damit nicht, falls das deine Frage war.

    Öhm doch es muss was "rechnen" oder wie wird aus dem Differenzwert ein "String in lokaler Zeit"?
    Und im ersten schritt solltest du genau das im neuen nachstellen (wobei man sicher die konvertierung in einen string sparen kann)



  • @firefly sagte in LocalTime to UTC epoch timestamp:

    @It0101 sagte in LocalTime to UTC epoch timestamp:

    Das bisherige System speichert die Differenzwerte ( und das julianische Datum ) und gibt sie dann an Clients als formatierten String in lokaler Zeit weiter. Es rechnet damit nicht, falls das deine Frage war.

    Öhm doch es muss was "rechnen" oder wie wird aus dem Differenzwert ein "String in lokaler Zeit"?
    Und im ersten schritt solltest du genau das im neuen nachstellen (wobei man sicher die konvertierung in einen string sparen kann)

    Nein das machen wir im neuen System nicht mehr. Die Schnittstelle nach außen zu den Clients wurde ebenfalls geändert, so dass ich im grunde fast nur noch weiterleite. Erfreulicherweise 🙂



  • @It0101 sagte in LocalTime to UTC epoch timestamp:

    @firefly sagte in LocalTime to UTC epoch timestamp:

    @It0101 sagte in LocalTime to UTC epoch timestamp:

    Das bisherige System speichert die Differenzwerte ( und das julianische Datum ) und gibt sie dann an Clients als formatierten String in lokaler Zeit weiter. Es rechnet damit nicht, falls das deine Frage war.

    Öhm doch es muss was "rechnen" oder wie wird aus dem Differenzwert ein "String in lokaler Zeit"?
    Und im ersten schritt solltest du genau das im neuen nachstellen (wobei man sicher die konvertierung in einen string sparen kann)

    Nein das machen wir im neuen System nicht mehr. Die Schnittstelle nach außen zu den Clients wurde ebenfalls geändert, so dass ich im grunde fast nur noch weiterleite. Erfreulicherweise 🙂

    Öhm was ist mit meiner Frage? die hast du nicht beantwortet...


Anmelden zum Antworten