proprietäres Datumsformat in DB-Tabelle analysieren

[Sharky]

Hai ihr,

ich habe hier auf einem MS-SQL-Server eine Tabelle mit Einträgen aus der Software einer Drittfirma.
Zu dieser Habe ich keine keinerlei Kontakt oder eine Chance an die Ranzukommen.

In ihrer Tabelle speichern die Date/Time Werte in einer char(20) Feld.

zum Beispiel steht dort:

000B3DC6h0147DE2Ch

Aus dem Frondend weiss ich das dies "16.01.2018 05:58:07"

Kann einer von euch hier ein System erkennen?

000B3DC6 -> Muss wohl das Datum sein da es bei allen Einträgen von heute gleich ist.
0147DE - > Könnte Stunde und Minute zu sein

Gruß

[Sherlock]

Der Datumsanteil scheint die Tage seit dem Jahr 1 zu zählen . Quelle für die Vermutung: https://www.epochconverter.com/seconds-days-since-y0

Der Zeitanteil sind die Millisekunden seit 0 Uhr.

Sherlock

[himitsu]

Jupp, sind erstmal zwei Integer Cardinal
000B3DC6h 0147DE2Ch

000B 3DC6 = 736.710 Tage seit 01.01.0001 = 16.01.2018

((05 * 60 + 58) * 60 + 07) * 1000 = 21.487.000
0147 DE2C = 21.487.148

also genau 16.01.2018 05:58:07.148


Unit SysUtils

Delphi-Quellcode:

{ Units of time }

  HoursPerDay   = 24;
  MinsPerHour   = 60;
  SecsPerMin    = 60;
  MSecsPerSec   = 1000;
  MinsPerDay    = HoursPerDay * MinsPerHour;
  SecsPerDay    = MinsPerDay * SecsPerMin;
  SecsPerHour   = SecsPerMin * MinsPerHour;  
  MSecsPerDay   = SecsPerDay * MSecsPerSec;

{ Days between 1/1/0001 and 12/31/1899 }

  DateDelta = 693594;

Von Wert 1 das DateDelta abziehen,
Wert 2 durch MSecsPerDay teilen,
beides addieren
und schon hast du ein TDateTime.

[Sharky]

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

[himitsu]

Hab noch die Umrechnung nachgetragen.

[DeddyH]

Zitat von Sharky:

In ihrer Tabelle speichern die Date/Time Werte in einer char(20) Feld.

*Boah eyh*

[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

[jobo]

Zitat von DeddyH:

Zitat von Sharky:

In ihrer Tabelle speichern die Date/Time Werte in einer char(20) Feld.

*Boah eyh*

Tja, vermutlich obfuscation oder "historisch gewachsen" aus einer Entwicklung nach Kundenwunsch.
Es ist (oder war) ja offenbar beliebt, Datumse, Rechnungsnummer, Teile. & Artikelnummern unternehmensspezifisch mit Merkmalen zu versehen, die "mehr" ausgesagt haben für den Kenner.
Die 3. Stelle der Teilenummer war dann "Lager Hamburg Hafen" oder "Lager Bremen", 4 und 5 eine Baureihe usw..
Wenn das irgendwann mal in Lochkarten gestanzt wurde, ist es vermutlich besonders hartnäckig.

Alte RDBMS (vermutlich besonders auch alte mysql Versionen) glänzen ja auch nicht unbedingt durch mächtige Datumsfunktionen auf Datumstypen. Also lieber alles zu Fuß und etwas Verschleierung hilft gegen die Konkurrenz (und Forschergeist bei den Kunden selbst).

[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?