"negatives" Datum / v.Chr. in Datenbank speichern
0 
dedlfix
0 2 0
"negatives" Datum / v.Chr. in Datenbank speichern
suitHallo,
habe mal ne Frage:
Arbeite mit MySql 4.irgendwas und möchte mir eine Datenbank zu historischen Personen und Ereignissen anlegen. Nun ist es aber so, dass die teilweise vor unserer Zeitrechnung gelebt haben (bzw. sich ereignet haben) -wie kann ich das in der Datenbank speichern und für Berechnungen berücksichtigen?
z.B. Person XYZ geboren 12 v.Chr. gestorben 30 n.Chr.
kann ja nicht schreiben -0012-03-12 ....
(Zuverlässigkeit bei Angabe von Tagen und Monaten und Verschiebung durch Kalenderreformen u.ä. ist ein seperates Thema ;-) )
Danke und Grüße,
Piggy
-
Hi!
Arbeite mit MySql 4.irgendwas und möchte mir eine Datenbank zu historischen Personen und Ereignissen anlegen. Nun ist es aber so, dass die teilweise vor unserer Zeitrechnung gelebt haben (bzw. sich ereignet haben) -wie kann ich das in der Datenbank speichern und für Berechnungen berücksichtigen?
Mit MySQL jedenfalls nicht mit den Datums- und Zeit-Typen, denn die beginnen sowieso erst 1.1.1000. Du musst dir also ein anderes System ausdenken (oder eins suchen), musst einen anderen Feldtyp verwenden und kannst zu allem Überfluss auch nicht die Datums- und Zeit-Funktionen verwenden.
Lo!
-
Hi there,
Arbeite mit MySql 4.irgendwas und möchte mir eine Datenbank zu historischen Personen und Ereignissen anlegen. Nun ist es aber so, dass die teilweise vor unserer Zeitrechnung gelebt haben (bzw. sich ereignet haben) -wie kann ich das in der Datenbank speichern und für Berechnungen berücksichtigen?
Afaik gar nicht, deshalb empfiehlt sich die Umrechnung in das julianische Datum, die von vielen Programmiersprachen schon automatisch angeboten wird. Da mit sind auch negative Werte möglich, die Du aber erst vor dem Jahr 5000 v.Chr. oder so benötigst...
-
Afaik gar nicht, deshalb empfiehlt sich die Umrechnung in das julianische Datum, die von vielen Programmiersprachen schon automatisch angeboten wird. Da mit sind auch negative Werte möglich, die Du aber erst vor dem Jahr 5000 v.Chr. oder so benötigst...
beispielsweise php (4714 v. Chr.):
http://de.php.net/manual/de/function.gregoriantojd.php
-
-
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".-
Warum überhaupt MySQL und warum dann noch so eine Antiquität?
Die erste Frage ist absolut unsinnig - bei vielen systemen ist man leider an ein spezielles DMBS gebunden, da der Support für andere Fehlt.
Die zweite frage ist natürlich trendentiell berechtigt.
-
MS SQL Server fängt erst im Jahr 1753 an :) (frag mich nicht wieso) und der Tag 0 ist imho der 1.1.1900 ... zumindest gemäss der Integer-Serialisierung von Datumswerten unter MS SQL Server. Ob das mit dem 2008er immer noch so ist, weiss ich nicht. Abhilfe konnte man sich erst unter MS SQL 2005 wirklich schaffen durch einen eigenen .Net Datentypen mit eigener Serialisierung.
Gruss, Frank-
Moin Moin!
MS SQL Server fängt erst im Jahr 1753 an :) (frag mich nicht wieso) und der Tag 0 ist imho der 1.1.1900 ... zumindest gemäss der Integer-Serialisierung von Datumswerten unter MS SQL Server.
Nö, der date-Typ beginnt beim 01.01.0001, jedenfalls laut http://technet.microsoft.com/en-us/library/bb630352.aspx. Die 1753-Nummer ist der "kleine" datetime-Typ, da dürfte die Ursache eher das Enddatum Silvester 9999 in Kombination mit der Auflösung von 3/100 Sekundensein. Der "große" datetime2-Typ beginnt dagagen wieder bei 01.01.0001 und hat eine Auflösung von 100 ns. Und damit es nicht langweilig wird, gibt es noch einen Minutengenauen smalldatetime-Typ, der Neujahr 1900 anfängt und dem mitten in 2079 die Bits ausgehen. Alles nachzulesen unter http://technet.microsoft.com/en-us/library/ms186724.aspx.
Ob das mit dem 2008er immer noch so ist, weiss ich nicht. Abhilfe konnte man sich erst unter MS SQL 2005 wirklich schaffen durch einen eigenen .Net Datentypen mit eigener Serialisierung.
Also letztlich genau das, was ich mit der POSIX-Zeit gemacht hab - DB-Zeittypen vergessen und selbst umrechnen.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".-
Nö, der date-Typ beginnt beim 01.01.0001, jedenfalls laut http://technet.microsoft.com/en-us/library/bb630352.aspx.
Eben, date gibt es erst seit MS SQL 2008.
Ob das mit dem 2008er immer noch so ist, weiss ich nicht.
Gut, dass ich mir dank dir nicht selbst die Mühe machen musste, das im MSDN/Technet nachzusuchen. ;-)
Cheers, Frank
-
-
-
-
Hallo,
habe mal ne Frage:
Arbeite mit MySql 4.irgendwas und möchte mir eine Datenbank zu historischen Personen und Ereignissen anlegen. Nun ist es aber so, dass die teilweise vor unserer Zeitrechnung gelebt haben (bzw. sich ereignet haben) -wie kann ich das in der Datenbank speichern und für Berechnungen berücksichtigen?
z.B. Person XYZ geboren 12 v.Chr. gestorben 30 n.Chr.Das Einzig Sinnvolle, was Du da machen kannst, ist's, das Datum als Julianischen Tag (integer) zu speichern. Und das beginnt mit Tag Null am 1.1.-4713 nach Scaliger.
Btw., heute haben wir Tag 2455139 nach dieser Zählung...
Hotte