Laden...

Date als Long bzw. Iso Konvertieren zu DateTime

Erstellt von .unreal vor 17 Jahren Letzter Beitrag vor 17 Jahren 3.063 Views
.unreal Themenstarter:in
563 Beiträge seit 2004
vor 17 Jahren
Date als Long bzw. Iso Konvertieren zu DateTime

Hallo Community

Ich habe ein Datum als Long in meinen Logfiles (z.B. 1144101600000). Wie kann ich diesen in ein DateTime konvertieren?

Gruss,
.unreal

.unreal Themenstarter:in
563 Beiträge seit 2004
vor 17 Jahren

Habs rausgefunden: kommt von Java, ist ab 1.1.1970 + den Longwert in Milisekunden.

Gruss,
.unreal

6.862 Beiträge seit 2003
vor 17 Jahren

Ist es so schwer sich mal in der Doku anzuschaun was für Funktionen DateTime bietet? Erstell dir nen DateTime mit dem 1.1.1970 als Datum und addiere einfach die Millisekunden hinzu.

Baka wa shinanakya naoranai.

Mein XING Profil.

.unreal Themenstarter:in
563 Beiträge seit 2004
vor 17 Jahren

Original von talla
Ist es so schwer sich mal in der Doku anzuschaun was für Funktionen DateTime bietet? Erstell dir nen DateTime mit dem 1.1.1970 als Datum und addiere einfach die Millisekunden hinzu.

Ich habe vieliecht die Frage nicht richtig Formuliert. Ich wusste nicht, ab wann der Long anfängt (-> 1.1.1970), und ob es wirklich Milisekunden sind. In der MSDN findest du nix von Datum als Long, diese Definitionen habe ich in der Javadokumentation gefunden. Mit diesen Definitionen ist es ein Kinderspiel, aber eben ohne gehts nit.

Gruss,
.unreal

p.s -> close

S
8.746 Beiträge seit 2005
vor 17 Jahren

Original von .unreal
In der MSDN findest du nix von Datum als Long...

Stimmt, weil da steht:

"Time values are measured in **100-nanosecond units **called ticks, and a particular date is the number of ticks **since 12:00 midnight, January 1, 0001 A.D. **(C.E.) in the GregorianCalendar calendar. For example, a ticks value of 31241376000000000L represents the date, Friday, January 01, 0100 12:00:00 midnight. A DateTime value is always expressed in the context of an explicit or default calendar."

4.506 Beiträge seit 2004
vor 17 Jahren

Hallo zusammen,

in der Online-Hilfe zu DateTime Structure (MSDN) habe ich folgenden Ausschnitt gefunden:

The DateTime value type represents dates and times with values ranging from 12:00:00 midnight, January 1, 0001 Anno Domini (Common Era) through 11:59:59 P.M., December 31, 9999 A.D. (C.E.)

Time values are measured in 100-nanosecond units called ticks, and a particular date is the number of ticks since 12:00 midnight, January 1, 0001 A.D. (C.E.) in the GregorianCalendar calendar. For example, a ticks value of 31241376000000000L represents the date, Friday, January 01, 0100 12:00:00 midnight. A DateTime value is always expressed in the context of an explicit or default calendar. Quelle: MSDN- DateTime Structure (english)

Das mit dem Long und den Millisekunden ist keine definitive Eigenschaft der DateTime Struktur!

Ich kenne das Spielchen mit dem 1.1.1970 (weil Montag und glatte Jahreszahl und ein Long (Millisekunden) deckt dann den Bereich bis 2036 ab (glaube ich)), das hat aber überhaupt nix mit DateTime zu tun.

Das hat vielmehr mit UTC Zeit und den entsprechenden Umrechnungsfunktionen zu tun. Kann sein, dass Java intern nur mit UTC Zeit arbeitet, bei .NET ist das definitv nicht so, das muss bei Bedarf mittels der .ToUniversalTime() gewandelt werden.

Also kann man solche Informationen nicht in der MSDN finden...

Die Frage ist eher, woher hast Du Deinen Long, denn bei dieser Quelle musst Du nach Hilfe suchen, nicht bei dem DateTime...

.NET DateTime unterstützt so weit ich weiß nur das Property "Ticks", das einen Long wert zurück liefert, und dieser gibt folgendes an:

The value of this property represents the number of 100-nanosecond intervals that have elapsed since 12:00:00 midnight, January 1, 0001. Quelle MSDN Hilfe zu Property Ticks bei DateTime Structure

Gruß
Norman-Timo

A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”

S
8.746 Beiträge seit 2005
vor 17 Jahren

1.1.1970 ist der Beginn des klassischen UNIX-Timestamp. Ist allerdings schön blöd. Man stelle sich eine Anwendung vor, die historische Daten verwaltet. Für UNIX beginnt die Welt mit UNIX, lol. Für Java wohl auch. 😉

Mit UTC hat das nix zu tun, denn hier handelt es sich nur um die Festlegung auf eine bestimmte Zeitermittlung (entspricht quasi GMT). Dann gibt es diverse ISO-Normen, die festlegen, die Daten als String abzulegen sind.

6.862 Beiträge seit 2003
vor 17 Jahren

Okay, ich dachte du bekommst es trotz der Erkenntnis das der Long Wert die Millisekunden ab dem 1.1.1970 sind, nicht hin. Deshalb die klein bissle forsche Antwort, sorry deswegen 🙂

Aber die weitere Diskussion versteh ich net 🤔
Am Anfang hätt ich beim Long Wert als Datum auch natürlich an die Ticks gedacht, passt aber net weil ich mir kein Logfile vorstellen kann, das Daten weit vor unserer aktuelen Zeit speichert 😉
Mit der Angabe vom Startdatum und das der Wert die seit daher vergangenen Millisekunden sind, ist die Diskussion doch gegessen oder? Einfach den Wert als Millisekunden aufaddieren und fertig.

Die Frage ist eher, woher hast Du Deinen Long, denn bei dieser Quelle musst Du nach Hilfe suchen, nicht bei dem DateTime... Das hast du ja gemacht und die Lösung gefunden, ohne das hättest lange rätseln können wie man daraus nen aktuelles Datum gewinnt.

Baka wa shinanakya naoranai.

Mein XING Profil.

S
8.746 Beiträge seit 2005
vor 17 Jahren

Meine Ausage bezüglich UTC bezog nur auf das Format. Bei der Umrechnung muss es natürlich beachtet werden (UtcNow statt Now, etc.).

B
1.529 Beiträge seit 2006
vor 17 Jahren

Nur zur Ehrenrettung des UNIX-Timestamp: dieser diente ursprünglich dazu, Dateien den Zeitstempel aufzudrücken. Und da macht der Beginn ab 1970 und ein absehbares Ende durchaus Sinn (neues Filesystem kann das ja ändern).
Da ist der Vorteil, einfach jede Milisekunde den Timer zu inkrementieren, sicherlich größer.

Wenn jetzt natürlich wieder total unkreative Programmierer den gleichen Timestamp für historische Daten nutzen wollen: selbst schuld...

.unreal Themenstarter:in
563 Beiträge seit 2004
vor 17 Jahren

Original von talla
Okay, ich dachte du bekommst es trotz der Erkenntnis das der Long Wert die Millisekunden ab dem 1.1.1970 sind, nicht hin. Deshalb die klein bissle forsche Antwort, sorry deswegen 🙂

Ja, war zuerst ziemlich verärgert über deine Aussage, und wollte entsprechend eine Antwort schreiben. Hab dann aber gemerkt, dass ich mich nicht sehr klar ausgedrückt habe 🙂 Ist kein Thema mehr!

Original von talla
Am Anfang hätt ich beim Long Wert als Datum auch natürlich an die Ticks gedacht Ich auch 🙂 Ticks sind Nanosekunden, das könnte man umrechnen lassen, allerdings stimmt auch hier wieder der Startpunkt nicht -> falscher Weg.

Original von talla
Mit der Angabe vom Startdatum und das der Wert die seit daher vergangenen Millisekunden sind, ist die Diskussion doch gegessen oder? Einfach den Wert als Millisekunden aufaddieren und fertig. Ja, sie war eigentlich für mich gegessen, darum hab ich geschrieben "Habs rausgefunden".

Original von norman_timo
Die Frage ist eher, woher hast Du Deinen Long, denn bei dieser Quelle musst Du nach Hilfe suchen, nicht bei dem DateTime... Kommt aus einem Log einer Java-Portalsoftware. Es existieren auch keine Defintionen 🙁 Mir sind da die Hände gebunden, kann nur nehmen was da ist 🙂

Original von svenson
Ist allerdings schön blöd

Es gibt noch dooferes: Bei Visual Basic (nicht .NET) steht der Wert 0 für den 30.12.1899. Super Idee! Excel beginnt einen Tag später, beim 1.1.1900. Wie bereits gesagt, der UNIX Timestamp beginnt bei 1.1.1970.

Gruss,
.unreal

S
8.746 Beiträge seit 2005
vor 17 Jahren

Bleibt die Frage, warum, Java einen File (!) -Zeitstempel als internes Datumsformat übernommen hat. Aber vermutlich wollte man ja nur "Spielraum für Kreativität" lassen. 😉

.... Herausforderung statt Problem.... Potential statt Mangel.....