proprietäres Datumsformat in DB-Tabelle analysieren

[Sherlock]

Zitat von Sharky:

Danke euch beiden. DA wäre ich nicht drauf gekommen.

Das glaube ich nicht, Du hattest nur grad keine Langeweile

Vom Ansatz her mußten erst die Hexen ins Dezimalsystem konvertiert werden. Ich habe mit dem Datumsanteil angefangen, erhaltene Zahl war zu klein für "Sekunden seit" und zu groß für Tage seit 1900 oder gar 1970. Dann blieb eigentlich nur noch Tage seit 0 (der mysql-Referenzpunkt). Google spuckte für die Suche "736710 days since 0" die von mir verlinkte Seite aus, und darin ist der "seit dem Jahr 1" Referenzpunkt zu finden.
Die Zeit war dann einfach: Das gibt sogar Google selbst her, wenn man annimmt, daß die recht große Zahl Millisekunden sein könnten führt folgende Suche zum Ziel: "21487148 milliseconds to hours". Da sieht man dann die von Dir angegebene 5, und der Rest ist dann ein Klacks. Wie Du also siehst, mit Langeweile, oder meinetewegen Prokrastination kommt man zum Ziel. Nur mein eigenes Ziel ist wieder etwas weiter in die Ferne gerückt... *Seufz*

Sherlock

[himitsu]

Zitat:

Tja, vermutlich obfuscation oder "historisch gewachsen" aus einer Entwicklung nach Kundenwunsch.

Ich vermute billiger: es ist einfach nur der Datumstyp (Record) nach binär umgewandelt.
TMyDate = record Date, Time: Integer; end;


Jupp, im Prinzip gibt es ja mehrere Möglichkeiten, die es hätten sein können.

* es ist ein Record, also die Stunden, Minuten, Sekunden, Tage, Monat und Jahr liegen in eigenen Bytes/Words.
** das könnte auch mathematisch gelöst sein, also z.B. jeweils mit 100 Multipiziert und aneinander gehängt (beim Byte-Record quasi mit 256 multipliziert)
* es sind zwei Integer (2x 4 Byte)
* es ist ein 64 Bit Integer
* es ist was gemischtes ala z.B. ein 5 Byte und ein 3 Byte Wert

Record und die 2-Byte sind am wahrscheinlichsten, was auch deine Beobachtung mit dem gleichen Datumsanteil bestätigten.
Also erstmal die Teile nach Dezimal umwandeln die größe des Wertes mit bekannten Datumsformaten vergleichen. siehe die Ausführung von Sherlock.

Beim Datumsteil kann man da auch einfach erstmal die Datumsanteile der Größe nach zusammenrechnen, bis man etwa auf den Zielwert kommt.
Ohne Millsekunden ist es ims 1000-fache (3 Dezimalstellen) zu groß und für Nanosekunden fehlt noch bissl was.
Aber die 1000 entsprechen zufällig den Millisekunden.


Falls man die Möglichkeit hat, kann man im Programm sich auch noch ein paar Vergleichswerte mit Tagesanfang 00:00:00, Halbtags 12:00:00 und Halbzeit 12:30:30,
sowie Jahresanfang 01.01.2000, ein Vergleichstag 02.01.2000 und ein Vergleichsjahr 01.01.2010 erstellen.
Die Differenzwerte besagen dann für Wert 1 = 1 pro Tag und bei Wert zwei 1000 pro Sekunde. (bei deinem Zielformat)

Oder in der Datenbank einfach mal eine 0 (00000000h00000000h) einstellen schauen was das Programm anzeigt, bzw. auch für 00000000h0147DE2Ch und 000B3DC6h00000000h.
Bei Letzterem siehst dann, ob die beiden Werte wirklich nur für Datum und Uhrzeit stehen oder ob es sich überlappt.

[jobo]

Zitat von himitsu:

Zitat:

Tja, vermutlich obfuscation oder "historisch gewachsen" aus einer Entwicklung nach Kundenwunsch.

Ich vermute billiger: es ist einfach nur der Datumstyp (Record) nach binär umgewandelt.
TMyDate = record Date, Time: Integer; end;

Ja, aber dann zufällig in einem String Typ gespeichert?

[himitsu]

Zitat von jobo:

Ja, aber dann zufällig in einem String Typ gespeichert?

In was denn sonst?

BLOBs kennt doch kein Schwein.
Viele kennen eben nur Integer, String und Float.

[jobo]

Zitat von himitsu:

In was denn sonst?

Naja, ich hab mal davon gehört das die gesamte EDV sich irgendwie binär abbilden lässt. Das gilt dann u.a. auch für Strings, naheliegender Weise aber auch für Ganzzahlen und andere Zahlen.
Ein Zahlentyp zur Datumsspeicherung zu verwenden wäre auch bei der Herleitung aus
TMyDate = record Date, Time: Integer; end; nicht ganz an den Haaren herbeigezogen.

[himitsu]

Jetzt wo du es sagst, mal schnell nachgesehn, ob meine beschriebene Berechnung stimmt.

Delphi-Quellcode:

function TimeStampToDateTime(const TimeStamp: TTimeStamp): TDateTime;
asm
{$IFDEF ALIGN_STACK}
        SUB    ESP, 4
{$ENDIF ALIGN_STACK}
        PUSH    EBX
{$IFDEF PIC}
        PUSH    EAX
        CALL    GetGOT
        MOV     EBX,EAX
        POP     EAX
{$ELSE !PIC}
        XOR     EBX,EBX
{$ENDIF !PIC}
        PUSH    EAX
        CALL    ValidateTimeStamp
        POP     EAX
        MOV     ECX,[EAX].TTimeStamp.Time
        MOV     EAX,[EAX].TTimeStamp.Date
        SUB     EAX,DateDelta
        IMUL    [EBX].IMSecsPerDay
        OR      EDX,EDX
        JNS     @@1
        SUB     EAX,ECX
        SBB     EDX,0
        JMP     @@2
@@1:    ADD     EAX,ECX
        ADC     EDX,0
@@2:    PUSH    EDX
        PUSH    EAX
        FILD    QWORD PTR [ESP]
        FDIV    [EBX].FMSecsPerDay
        ADD     ESP,8
        POP     EBX
{$IFDEF ALIGN_STACK}
        ADD    ESP, 4
{$ENDIF ALIGN_STACK}
end;

Aua, wozu muß das unbedingt in Assembler sein (XE),
wenn auch sowas reicht?

Delphi-Quellcode:

function TimeStampToDateTime(const TimeStamp: TTimeStamp): TDateTime;
begin
  ValidateTimeStamp(TimeStamp);
  Result := TimeStamp.Time / MSecsPerDay + TimeStamp.Data - DateDelta;
end;

// Mein Vorschlag sagte zwar
// Result := TimeStamp.Data - DateDelta + TimeStamp.Time / MSecsPerDay;
// aber ohne Zwischenvariable für die Division isses bestimmt besser.

Integer.Parse: StrToInt in alten Delphis.

[Uwe Raabe]

Zitat von himitsu:

TMyDate = record Date, Time: Integer; end;

Sowas gibt's doch schon in System.SysUtils:

Delphi-Quellcode:

  TTimeStamp = record
    Time: Integer;      { Number of milliseconds since midnight }
    Date: Integer;      { One plus number of days since 1/1/0001 }
  end;

Eine simple Umwandlung (ohne Fehlerkontrolle) könnte in einem aktuellen Delphi etwa so aussehen:

Delphi-Quellcode:

var
  arr: TArray<string>;
  timeStamp: TTimeStamp;
  dateTime: TDateTime;
  S: string;
begin
  S := '000B3DC6h0147DE2Ch';
  arr := S.Split(['h']);
  timeStamp.Date := Integer.Parse('$' + arr[0]);
  timeStamp.Time := Integer.Parse('$' + arr[1]);
  dateTime := TimeStampToDateTime(timeStamp);
end;

[Ghostwalker]

Da lob ich mir doch einen einfachen Int64 (BigInt) und gut.

[Sherlock]

Zitat von Ghostwalker:

Da lob ich mir doch einen einfachen Int64 (BigInt) und gut.

In der Tat kommt man da auch mit Millisekunden seit Jahr 0 gut zurecht...sofern man Christ ist. Auch als Hebräer hat man keine Probleme, wehe aber man rechnet das Jahr 0 als Zeitpunkt des Big Bang

Sherlock

[Ghostwalker]

Zitat von Sherlock:

Zitat von Ghostwalker:

Da lob ich mir doch einen einfachen Int64 (BigInt) und gut.

In der Tat kommt man da auch mit Millisekunden seit Jahr 0 gut zurecht...sofern man Christ ist. Auch als Hebräer hat man keine Probleme, wehe aber man rechnet das Jahr 0 als Zeitpunkt des Big Bang

Sherlock

Naja..also bei den meisten Anwendungen braucht man keine Millisekunden. Da reichen Sekunden. Also ein simpler Unixtimestamp Int64 wg. des 2038'er Problems.

Und wer ein Datum bzw. eine Zeitangabe vor dem BigBang braucht hat imho einen klitzekleinen Denkfehler (aber wirklich nur ein kleiner )