LocalTime to UTC epoch timestamp
-
@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. 
-
@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.
-
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...
-
@firefly sagte in LocalTime to UTC epoch timestamp:
@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...
Falls deine Frage war, wie konvertiert wird: Das kann ich dir nicht sagen. Vermutlich wird auf eine viel zu komplexe Art und Weise, da der Kram sehr alt ist und man früher stark auf Eigenentwicklungen vertraut.
-
@It0101 sagte in LocalTime to UTC epoch timestamp:
Falls deine Frage war, wie konvertiert wird: Das kann ich dir nicht sagen. Vermutlich wird auf eine viel zu komplexe Art und Weise, da der Kram sehr alt ist und man früher stark auf Eigenentwicklungen vertraut.
Dann solltest du das nachprüfen, dann hast du was von dem du starten kannst
