[js-mueller]

Ich wollte in einer SQl Tabelle (mysql) ein feld mit dem Wert timestamp oer date haben, muss ich noch sehn was besser ist, aber das selbe Prinzip denk ich ma.
So nun wird autoamtisch das Datum in folgender Form gespeichert: 2006-03-02 16:44
Nun bin ich auf der Suche nach einer Klasse die mir Tag/Monat/Jahr/Stunde/Sekunde ordentlich ausließt.
Ich hab es einmal mit dem Objekt Timestamp versucht, doch der gibt mir bei diesem aufruf das jahr 106 aus, obwohl es ja 2006 sein müsste Oo

timestamp time = erg.getTimestamp("datum"); // Datum aus der Datenabank
System.out.println(time.getYear());

[pago]

java.sql.Date date = erg.getDate("datum");

Könnte dein Freund sein.

[js-mueller]

Ist das selbe Ergebnis, Timestamp/Date machen bei mir den selben Fehler, hab beides schon getestet, Der einzige unterschied ist ja nur das Timestamp die Zeit noch mit einbezieht

[Ben]

Der Thread wurde verschoben, wegen ...
... Postings im falschen Forum. Bitte beim nächsten Mal darauf achten.,

verschoben

[JumperII]

Hallo,

ich gehe mal davon aus, dass Du das Timestamp-Feld einfach mit dem Jahr 106 gefüllt hast. Dann stimmt es auch mit der Ausgabe

Prüf doch mal, wie Du das Timestamp Feld setzt. Bzw. mit welcher Methode. Alternativ kannst Du gerne mit dem Client oder einen php<db>admin reinschauen ...

gruß,
jumper, the II.

[js-mueller]

Ich muss mal gestehen, da ich zufau bin mysql per Konsole zu steuern hab ich nen php server für phpMyAdmin drauf, ist einfach nen nettes tool.

In der Datenbank steht korrekt 2006-03-02
Die eingabe erfolgt automatisch wenn ich in phpMyAdmin nen neuen Beitrag erstelle.

[JumperII]

getYear

public int getYear()
Deprecated. As of JDK version 1.1, replaced by Calendar.get(Calendar.YEAR) - 1900.

Returns a value that is the result of subtracting 1900 from the year that contains or begins with the instant in time represented by this Date object, as interpreted in the local time zone.

Returns:
the year represented by this date, minus 1900.
See Also:
Calendar

[JumperII]

Stimmt ... da war doch noch was gewesen .... Ich bin damals in beide Fallen nacheinander getappt

Gruß,
Jumper, the II.

[js-mueller]

Super das Jahr geht nu wenn ich 1900 druff rechne, aber nu seh ich Tag geht ja auch nicht ^^

Und zwar bekomm ich diese Ausgabe 4.3.2006
obwohl in der Datenbank 2006-03-02 steht
da benutz ich jetzt getDay.
Irgendwie mag ich diese Datumsgeschichte net


edit:

Davon mal abgesehn, in der Doku steht bei vielen Funktionen " Verworfen in Version 1.1."
sollte man vieleicht etwas anderes verwenden?

[JumperII]

Hallo,

Vielleicht geht es, wenn Du statt des timestamps die Infos aus Calendar liest:

import java.util.Calendar;
Calendar cal = Calendar.getInstance();
cal.setTime( timestamp);
cal.get( Calendar.YEAR);
cal.get( Calendar.MONTH);
cal.get( Calendar.DAY_OF_MONTH);

Ich bin mir nicht sicher, ob die veraltete Version es noch richtig macht. Version 1.1 ist lange lange her.

Gruß,
Jumper, the II.

[js-mueller]

Astrein nun funktioniert alles so wie es soll, danke schön

[Murray]

Zitat von js-mueller

Und zwar bekomm ich diese Ausgabe 4.3.2006
obwohl in der Datenbank 2006-03-02 steht
da benutz ich jetzt getDay.

Date#getDay() macht nicht das, was Du vermutest: wie in der API-Doku beschrieben, liefert getDay() genau wie Calendar.get( DAY_OF_WEEK) den Wochentag; die 4 steht für Donnerstag.

Du braucht hier Date#getDate(); das liefert - wie Calendar.get( DAY_OF_WEEK) - das Tagesdatum zwischen 1 und 31 zurück

@jumper: JDK 1.1 gibt es zwar schon lange, aber die APIs funktionieren trotzdem noch.

[JumperII]

Hallo Murray,

das Problem ist, das Date#getDay mit der Version 1.0 gekommen ist und schon unter der Version 1.1 nicht mehr evrwendet werden sollte. Offensichtlich liegt in dieser Funktion ein netter (Jahr-2000?)-Bug bei der Berechnung des Monatstags vor, daher die abweichende Angabe

In sofern ist diese Funktion in klassisches Beispiel, dass man das Verwenden von veralteten Funktionen wirklich unterlassen sollte

Gruß,
Jumper, the II.

[JumperII]

So, jetzt können wir den Thread zumachen *kugel*

Zusammenfassung des Problems .... Wir alle haben nicht in die API-Beschreibbung geschaut .... Es ist kein wirkliches Problem. Der Ansatz, die Calender-Klasse zu verwenden ist richtig und m.E. langfrist sicherer.

Zu Date und der Methode getDay(). Diese Methode gibt den Wochentag aus. Und der ist immer etwas anderes als der Monatstag. Letzteres kann mit der Methode getDate() ausgelesen werden.

Im übrigen nutzt Date intern Calender, um die alten Funktionen zu realisieren ...

Also Asche auf mein Haupt
Gruß,
Jumper, the II.

[Murray]

Zitat von JumperII

das Problem ist, das Date#getDay mit der Version 1.0 gekommen ist und schon unter der Version 1.1 nicht mehr evrwendet werden sollte. Offensichtlich liegt in dieser Funktion ein netter (Jahr-2000?)-Bug bei der Berechnung des Monatstags vor, daher die abweichende Angabe

Das ist - mit Verlaub - Quatsch, das Verhalten ist von jeher dokumentiert und mitnichten ein Bug; ich halte das API von java.util.Data zwar auch nicht für besonders gelungen, aber fehlerhaft ist es nicht wirklich.

Der Grund, warum die Datumsfunktionen mit dem JDK 1.1 auf eine neue Basis gestellt wurden, war m.W. eher die Notwendigkeit der Internationalisierung; mit dem Calendar hat man hier ein deutlich mächtigeres Werkzeug zur Verfügung.

Die erweiterte Funktionalität erkauft man sich aber leider mit Performance-Nachteilen; allein die Instanziierung eines Calendars ist schon eine ziemlich "teuere" Operation. Ich behaupte daher, dass es durchaus Situationen geben kann, in denen man besser java.util.Date verwenden sollten

Insofern ist diese Funktion in klassisches Beispiel, dass man das Verwenden von veralteten Funktionen wirklich unterlassen sollte

Normalerweise sollte man wirklich versuchen, die als "deprecated" gekennzeichneten APIs durch die neueren APIs zu ersetzen; Deine Aussage kann ich aber in der Allgemeinheit nicht teilen.

Gruß,
Murray