Alexander (HH): "negatives" Datum / v.Chr. in Datenbank speichern

Beitrag lesen

Moin Moin!

Arbeite mit MySql 4.irgendwas

Herzliches Beileid.

Warum überhaupt MySQL und warum dann noch so eine Antiquität?

z.B. Person XYZ geboren 12 v.Chr. gestorben 30 n.Chr.
kann ja nicht schreiben -0012-03-12 ....

Schreiben kannst Du das schon, nur wird MySQL dich wohl nicht verstehen (wollen). ;-)

Andere Datenbanken können durchaus mit Daten "unter Null" umgehen: z.B. PostgreSQL ("free as in beer and as in speech") und Oracle (gegen gutes Geld). MS SQL Server und IBMs DB2 fangen dagegen erst 1 n. Chr. an, das ersparte den Entwicklern einige Kalender-Macken, insbesondere das Jahr Null.

(Zuverlässigkeit bei Angabe von Tagen und Monaten und Verschiebung durch Kalenderreformen u.ä. ist ein seperates Thema ;-)  )

Richtig, und genau die vielen Merkwürdigkeiten der mehrfach reformierten Kalender im - sagen wir mal "europäischen Kulturraum" - machen es fürchterlich schwierig, mit Datumsangaben zu arbeiten. Das fängt bei Schaltsekunden an, geht über das nicht vorhandene Jahr Null, Schaltjahresregeln, örtlich verschiedene Zeitpunkte der Kalenderwechsel, und hört bei Osterberechnungen und ähnlichem noch lange nicht auf. Ein paar weitere Gemeinheiten sind unter http://www.washington.edu/imap/documentation/Y2K.html und http://www.washington.edu/imap/documentation/calendar.txt.html gesammelt.

Man kann es mit dem Datum also eigentlich immer nur falsch machen, wenn man sich um mehr als ein paar Jahrzehnte in die Vergangenheit oder Zukunft wagt. Oft ignoriert man bei der Spezifikation und/oder Implementation Schaltsekunden (z.B. bei der POSIX-Zeit), nimmt den gregorianischen Kalender rückwirkend bis zum Urknall an, und führt ggf. auch ein Jahr 0 zwischen 1 v. Chr. und 1 n. Chr. ein - mit entsprechenden Nebenwirkungen z.B. auf Zeitdifferenzen und Wochentage.

Dazu kommt noch, dass alle Datenbanken, mit denen ich mich bislang rumschlagen mußte, das Datum in sehr eigenen und nicht unbedingt sehr leicht für Computer verdaubaren Formaten ausgeben und erwarten. Letztlich kümmert sich um solche Details in größeren Projekten der eine oder andere Wrapper.

In einem meiner früheren Projekte hab ich irgendwann mal alle Datum- und Zeitangaben als POSIX-Zeit (Nicht-Schaltsekunden seit 1970-01-01 00:00:00 UTC) in einem Integer-Feld abgelegt, für die dort vorkommenen Datums- und Zeitangaben war das perfekt. Du wirst für deine Daten vermutlich mit tagesgenauen Werten auskommen, da könntest Du z.B. über Tage relativ zum 1.1.0001 n. Chr. arbeiten. Oder Du speicherst die Datumsangaben stumpf als Strings im Format ±YYYYMMDD und kümmerst Dich um den Rest außerhalb der Datenbank.

Von Zeitzonen mit und ohne Sommer- und Hochsommerzeit, mit mehr als den physikalisch eigentlich möglichen ±12 Stunden Differenz zu Greenwich / UTC, mit zusätzlichen Differenzen von 15 oder 30 Minuten, will ich jetzt gar nicht anfangen, da rege ich mich nur über irgendwelche wirren Inselkönige auf der anderen Seite der Erde auf.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".