Für das spezifische Beispiel, das Sie für Ihre Frage verwendet haben (Jahr 1200), werden die Dinge technisch funktionieren.
Im Allgemeinen sind Zeitstempel für diese Zwecke jedoch nicht ratsam. Erstens ist die Bereichsbegrenzung willkürlich:In MySQL ist es der 1. Januar 1000. Wenn Sie mit Zeug aus dem 12. bis 13. Jahrhundert arbeiten, läuft alles gut ... aber wenn irgendwann Sie müssen etwas älteres hinzufügen (10. Jahrhundert oder früher), das Datum wird jämmerlich kaputt gehen, und die Behebung des Problems erfordert die Neuformatierung aller Ihrer historischen Daten in etwas Passenderes.
Zeitstempel werden normalerweise als rohe Ganzzahlen mit einem bestimmten "Tick-Intervall" und "Epochenpunkt" dargestellt, sodass die Zahl tatsächlich die Anzahl der Ticks ist, die seit der Epoche bis zum dargestellten Datum vergangen sind (oder umgekehrt für negative Daten). Das bedeutet, dass die Menge der darstellbaren Werte, wie bei jedem Fixed-with-Integer-Datentyp, endlich ist. Die meisten Zeitstempelformate, die ich kenne, opfern den Bereich zugunsten der Genauigkeit, hauptsächlich weil Anwendungen, die Zeitarithmetik durchführen müssen, dies oft mit einer anständigen Genauigkeit tun müssen; während Anwendungen, die mit historischen Daten arbeiten müssen, sehr selten ernsthafte Arithmetik durchführen müssen.
Mit anderen Worten, Zeitstempel sind genau gemeint Darstellung von Daten. Die Genauigkeit von Sekunden (oder sogar Bruchteilen von Sekunden) macht für historische Daten keinen Sinn:Können Sie mir auf Millisekunden genau sagen, wann Heinrich der 8. zum König von England gekrönt wurde?
Im Fall von MySQL ist das Format von Natur aus als "4-stellige Jahreszahl" definiert, sodass sich jede damit verbundene Optimierung auf die Annahme verlassen kann, dass die Jahreszahl 4 Ziffern hat oder dass die gesamte Zeichenfolge genau 10 Zeichen hat ("yyyy- mm-tt") usw. Es ist nur Glückssache, dass das Datum, das Sie in Ihrem Titel angegeben haben, noch passt, aber sich darauf zu verlassen, ist immer noch gefährlich:Neben dem, was die DB selbst speichern kann, müssen Sie wissen, was das Rest Ihres Server-Stacks manipulieren kann. Wenn Sie beispielsweise PHP verwenden, um mit Ihrer Datenbank zu interagieren, stürzt der Versuch, historische Daten zu verarbeiten, sehr wahrscheinlich irgendwann ab (in einer 32-Bit-Umgebung reicht der Bereich für Zeitstempel im UNIX-Stil vom 13. Dezember 1901 bis). 19. Januar 2038).
Zusammenfassend:MySQL speichert jedes Datum mit einer 4-stelligen Jahreszahl ordnungsgemäß; Aber im Allgemeinen führt die Verwendung von Zeitstempeln für historische Daten fast garantiert zu Problemen und Kopfschmerzen. Ich rate dringend von einer solchen Verwendung ab.
Hoffe das hilft.
Bearbeiten/Ergänzen:
Ich glaube nicht, dass irgendeine DB diese Art von Daten zu sehr unterstützt:Anwendungen, die sie verwenden, haben meistens genug mit String-/Text-Darstellung. Tatsächlich ergibt eine Textdarstellung für Daten im Jahr 1 und später sogar korrekte Sortierungen / Vergleiche (solange das Datum in der Größenordnung dargestellt wird:y,m,d-Reihenfolge). Vergleiche werden jedoch unterbrochen, wenn auch "negative" Daten beteiligt sind (sie würden immer noch als früher verglichen als alle positiven, aber der Vergleich zweier negativer Daten würde ein umgekehrtes Ergebnis ergeben).
Wenn Sie nur Daten aus Jahr 1 und später benötigen oder keine Sortierung benötigen, können Sie sich das Leben durch die Verwendung von Zeichenfolgen erheblich erleichtern.
Andernfalls ist der beste Ansatz, eine Art Zahl zu verwenden und Ihr eigenes "Tick-Intervall" und "Epochenpunkt" zu definieren. Ein gutes Intervall könnten Tage sein (es sei denn, Sie brauchen wirklich mehr Genauigkeit, aber selbst dann können Sie sich auf "echte" (Gleitkomma-) Zahlen anstelle von ganzen Zahlen verlassen); und eine vernünftige Epoche könnte der 1. Januar sein. Das Hauptproblem besteht darin, diese Werte in ihre Textdarstellung umzuwandeln und umgekehrt. Sie müssen die folgenden Details beachten:
- Schaltjahre haben einen zusätzlichen Tag.
- Die Regel für Schaltjahre war „ein beliebiges Vielfaches von 4“ bis 1582, als es vom julianischen zum gregorianischen Kalender wechselte und zu „einem Vielfachen von 4 wurde, mit Ausnahme derer, die ein Vielfaches von 100 sind, es sei denn, sie sind auch ein Vielfaches von 400“.
- Der letzte Tag des Julianischen Kalenders war der 4. Oktober 1582. Der nächste Tag, der erste des Gregorianischen Kalenders, war der 15. Oktober 1582. 10 Tage wurden übersprungen, damit der neue Kalender wieder mit den Jahreszeiten übereinstimmt.
- Wie in den Kommentaren angegeben, unterscheiden sich die beiden oben genannten Regeln von Land zu Land:Kirchenstaaten und einige katholische Länder haben den neuen Kalender an den angegebenen Daten übernommen, aber viele andere Länder haben länger dafür gebraucht (das letzte war die Türkei im Jahr 1926). . Dies bedeutet, dass jedes Datum zwischen der päpstlichen Bulle im Jahr 1582 und der letzten Adoption im Jahr 1926 ohne geografischen Kontext mehrdeutig und noch komplexer zu verarbeiten sein wird.
- Es gibt kein "Jahr 0":Das Jahr vor Jahr 1 war Jahr -1 oder Jahr 1 v. Chr.
All dies erfordert ziemlich ausgefeilte Parser- und Formatierungsfunktionen, aber abgesehen von den vielen Fall-zu-Fall-Unterbrechungen gibt es nicht wirklich zu viel Komplexität (es wäre mühsam zu codieren, aber ziemlich einfach). Die Verwendung von Zahlen als zugrunde liegende Darstellung gewährleistet das korrekte Sortieren/Vergleichen für jedes Wertepaar.
Mit diesem Wissen haben Sie nun die Wahl, den Ansatz zu wählen, der Ihren Anforderungen besser entspricht.
