Datentypen Kalender problem

[johnjohnson]

Hallo zusammen,
ich habe ein problem. wie kann man verschiedene datentypen am besten zusammen abspeichern? bin gerade beim bau eines kalenders und will einen intwert(das datum) und einen String (terminbeschreibung) zusammen abspeichern können .
:bahnhof:
hab schon über arrays nachgedacht, das man beides in einen string umwandelt aber dann muss man es ja immer wieder zurückwandeln wenn man etwas mit dem datum vergleichen will...komm echt nicht weiter :/
wie macht man das?
lg;
jo

 

[JCODA]

Eine Möglichkeit wäre, eine eigene Klasse zu schreiben, die sowohl das Datum wie auch die Beschreibung hält und die Serializable implementiert. Damit kann man Objekte einfach durch einen ObjectOutputStream abspeichern und mit einem ObectInputStream wieder laden. Siehe hierzu auch: Galileo Computing :: Java ist auch eine Insel – 17.10 Persistente Objekte und Serialisierung

 

[Thallius]

Das Datum als int wert? Wie geht das?

Gruß

Claus

 

[johnjohnson]

indem ich das datum in die zeit seit 01.01.1970 umwandel so hatte ich das gedacht..
oder wie würdest du das machen?

 

[Thallius]

Schade, dann kann ich ja gar nicht meinen Geburtstag eingeben (1966)

Ich würde ein Datum immer als String im SQL Format halten. Also

2014-12-11 12:30:00

Die Uhrzeit solltest Du als UTC speichern. Also unser Zeit -1 Stunde. Dann bist du auch gleich international.
Du kannst die Daten dann ganz einfach mit equal() vergleichen und sortieren.

Gruß

Claus

 

[Java20134]

Du kannst aber auch einfach Java.util.date für dein Datum benutzen.
Java Date und Calendar

 

[Thallius]

Irgendwie war mir klar, dass es vergebens ist auf ein Konzept Problem hinzuweisen und der TO sich nicht mehr dazu merlden wird.
Es funktioniert ja jetzt mit dem int und gut ist. Wen interessiert schon ob das vernünftig durchdacht ist oder nicht.

Gruß

Claus

 

[stg]

Und wo ist nun das Konzept-Problem? Ein Datum in Millisekunden seit dem 01.01.1970 zu speichern, ist ein geläufiger Standard. java.util.Date macht das ebenfalls. Genauso wie 238248924 andere Programme und Entwickler weltweit auch. Es gibt übrigens auch negative Ganzzahlen..

Ein Datum als String zu speichern halte ich hingegen für höchst fragwürdig. Dadurch hast du doch rein gar nichts gewonnen. Ich sehe da nur zahlreiche Nachteile, keinen einzigen Vorteil. Mit Strings kannst du nicht rechnen. Du musst ständig hin- und her parsen. Du brauchst mehr Speicherplatz. Weniger robust. Keine Kompatibilität zu diversen Frameworks, weil gängige Standards nicht eingehalten werden. Usw...

 

[Thallius]

Und wo ist nun das Konzept-Problem? Ein Datum in Millisekunden seit dem 01.01.1970 zu speichern, ist ein geläufiger Standard. java.util.Date macht das ebenfalls. Genauso wie 238248924 andere Programme und Entwickler weltweit auch. Es gibt übrigens auch negative Ganzzahlen..

Ein Datum als String zu speichern halte ich hingegen für höchst fragwürdig. Dadurch hast du doch rein gar nichts gewonnen. Ich sehe da nur zahlreiche Nachteile, keinen einzigen Vorteil. Mit Strings kannst du nicht rechnen. Du musst ständig hin- und her parsen. Du brauchst mehr Speicherplatz. Weniger robust. Keine Kompatibilität zu diversen Frameworks, weil gängige Standards nicht eingehalten werden. Usw...

Wie willst Du denn einen Kalender machen mit einem int der den Zeitraum begrenzt? Auf einem 32bit System hast du gerademal 68 Jahre damit abgedeckt. Das ist ja nicht einmal ein MEnschenleben lang? Wie soll ich da einen vernünftigen Kalender mit abbilden?

Gruß

Claus

 

[stg]

Auch auf einem 32-bit System hat man üblicherweise noch ein bisschen mehr als 32bit Speicher zur Verfügung

32 bit reichen in der Regel nicht aus, da geb ich dir recht. Aber dann nimmt man halt einen größeren Ganzzahl Typ. In Java wurde ein 64 bit long dafür gewählt. Der abgedeckte Bereich reicht dann in der Regel auch aus. Für einen einzelnen char hingegen braucht man hingegen schon 8 bit, das ist glaube ich mehr oder weniger überall der Fall. Damit kannst du dann (bei den besagten 64 bit) ja gerade einmal das Datum abbilden, und auch nur dann, wenn du die Trennzeichen weglässt.

 

[Thallius]

Der Unix Timestamp ist aber definiert das er auf einem 32bit System nur 32bit hat. Wenn die in Java da was selber basteln ist das ja gut aber dann ist es kein definierter Unix Timestamp mehr und davon hatte der TO ja gesprochen.

Außerdem ist es eben sehr teuer aus einem Timestamp eine Datum mit Uhrzeit zu errechnen. Die Frage ist jetzt also was mache ich mit dem Datum? Rechne ich sehr viel damit, dann ist ein Timestamp besser. Denn da kann ich einfach subtrahieren und addieren wie ich möchte. Ich denke das wird in einem Kalender aber eher selten der Fall sein. Hier wird es wesentlich öfter nötig sein das Datum in ein anzeigefähiges Format zu bringen (lokales datumsformat) und da bist du mit einem SQL String eben viel besser unterwegs.

Gruß

Claus

 

[Harry Kane]

Der Unix Timestamp ist aber definiert das er auf einem 32bit System nur 32bit hat. Wenn die in Java da was selber basteln ist das ja gut aber dann ist es kein definierter Unix Timestamp mehr und davon hatte der TO ja gesprochen.

Könnte es vielleicht sein, daß "die in Java" gerade deswegen "was selber basteln", eben weil ein Unix Timestamp nur 32 bit hat und deswegen nicht mehr als die 68 Jahre abbilden kann? Ich verstehe gerade nicht, was du für die beste Lösung hältst: den Unix Timestamp oder die Java-Variante? Übrigens hat nicht der TO von Unix Timestamps gesprochen, sondern du.

Außerdem ist es eben sehr teuer aus einem Timestamp eine Datum mit Uhrzeit zu errechnen.

Ja, es kann schon sein, das ein 10 Jahre alter Rechner für 1 Millionen Timestamps 5 Sekunden braucht.
Du hast vermutlich recht, daß es schneller ist, aus einem String mit einem bekannten, unveränderlichen Format einfach die Angaben zu Jahr, Monat, Tag etc. rauszuschneiden, anstatt aus einem 64 bit Zahlenwert eine Instanz von java.util.Calendar zu machen und dort dann Jahr, Monat, Tag abzufragen, aber ich halte letztere Variante einfach für sicherer und besser nachvollziehbar. Ich würde nur ungern an jeder Stelle, an denen ich mit den Datumsangaben doch rechnen muss (um beispielsweise festzustellen, welche Termine zwischen dem 27.12.2014 und 07.01.2015 liegen ), mit einer Stringbasierten Logik arbeiten. Möglich ist das natürlich.