# Timestamp nur Time



## Generic1 (2. Jun 2011)

Hallo,

ich bekomme (über das Netzwerk) nur eine Zeit als String und möchte diese Zeit in meine MySQL- Datenbank speichern -> in der MySQL DB habe ich den Datentyp TIME -> im Domain- Objekt habe ich den Datentype Timestamp.
Meine Frage wäre jetzt, wie ich die empfangene Zeit (z.B.: 09:30:15.342 -> also HH:mm:ss.SS) in einen Timestamp ohne Datum umwandeln kann.
Vielen Dank,
lg


----------



## Spacerat (2. Jun 2011)

Wenn man genau weis, an welchem Datum das Unix-Zeitalter begann (01.01.1970), ist's kein Problem, dann schreibt man es davor...

```
java.sql.Timestamp ts = java.sql.Timestamp.valueOf("1970-01-01 " + "09:30:15.342");
long stamp = ts.getTime();
```
deswegen habe ich es mal in 2 Strings aufgeteilt. Wichtig ist das Leerzeichen nach diesem Date.

@Edit: Meines Erachtens sollte dieses Datum im Computerzeitalter stets unvergessen bleiben und deswegen wenigstens in der Klasse *java.sql.Timestamp* als Konstante auftauchen.


----------



## Landei (2. Jun 2011)

Und der obligatorische Hinweis auf eine ordentliche Zeitbibliothek: Joda-Time - Java date and time API - Home


----------



## Spacerat (2. Jun 2011)

Landei hat gesagt.:


> Und der obligatorische Hinweis auf eine ordentliche Zeitbibliothek: Joda-Time - Java date and time API - Home


Joa... sieht gut aus...
Einziger Nachteil: *Es ist ein Replacement*... für Dinge, welche in Java schon vorhanden sind und bei deren Verwendung man mal wieder gezwungen ist, eine Bibliothek mit zu verbreiten über dessen Lizenz (bei Joda die Apache2 Lizenz) man sich auch erst mal klar werden muß und dessen Installation ein weiteres an unnötiger Mehrarbeit beinhaltet. Ich mach mir diese Arbeit jedenfalls erst, wenn in Java wirklich etwas fehlt, z.B. Schnittstellenkommunikation wie RXTX oder JSSC und/oder OpenXX-Geschichten wie JOGL, JOAL, JOCL oder LWJGL.


----------



## faetzminator (3. Jun 2011)

Also ich verwende bei komplexeren Sachen auch Joda


----------



## Generic1 (3. Jun 2011)

Hätte noch eine Frage bei der ich jetzt schon eine Zeit lange dabei bin und nicht draufkomm wie ich das machen kann:

ich habe auf der einen Seite einen Timestamp in der DB:

2011-06-03 09:30:54.554

und auf der anderen Seite java.sql.Time:

10:12:56.555

und möchte jetzt die Differenz ausrechnen, also rauskommen soll:

00:42:02.001 -> also 42 min und 2 sec danach.
Weiß jemand wie ich das bewerkstelligen kann?
Vielen Dank,
lg


----------



## Landei (3. Jun 2011)

Spacerat hat gesagt.:


> Joa... sieht gut aus...
> Einziger Nachteil: *Es ist ein Replacement*...



Na ja, auf Grundlage von Joda Time wird ja an JSR-310 für Zeitangaben gebastelt. Früher oder später wird also etwas ganz ähnliches in den Systembibliotheken landen. Die Frage ist nur, wann?


----------



## Spacerat (3. Jun 2011)

Hmmm... eigentlich so:

```
java.sql.Timestamp ts1 = java.sql.Timestamp.valueOf("2011-06-03 09:30:54.554");
java.sql.Date d = new java.sql.Date(ts1.getTime());
java.sql.Timestamp ts2 = java.sql.Timestamp.valueOf(d.toString() + " 10:12:56.555");
java.sql.Time t = new java.sql.Time(ts2.getTime() - ts1.getTime());
```
Aber ich fürchte... da hat sich grad' jemand um 'ne Stunde verhauen... bei mir ist das Ergebnis zumindest 01:42:02 (die Millisekunden bekommt man bei Time nur über "getTime()" als long) - fälschlicherweise natürlich. :bahnhof:


----------



## Generic1 (3. Jun 2011)

Genau das ist das Problem,
bei mir kommt auch 01:42:02 heraus, das kappier ich nicht, ist das ein Bug oder mach ich da was falsch,
Wie kann ich da das richtige Ergebnis herausbekommen?
Vielen Dank,
lg


----------



## Ebenius (3. Jun 2011)

java.sql.Time ist ein java.util.Date-Derivate. Es bezieht sich auf eine Zeit an einem konkreten Tag. [c]new java.sql.Time(2522000L)[/c] ist 00:42:02 am 1. Januar 1970 GMT. Bei uns ist das 01:42:02 (da CET am 1. Januar; keine Sommerzeit). Lässt Du das ganze Programm in der Zeitzone Londons laufen, hast Du keine Stunde Versatz; an der Ostküste der USA bekommst Du 18:42:02 ausgeben (31.12.1969).

Ebenius


----------



## Ebenius (3. Jun 2011)

Nachtrag: Wenn Du nur die Zeitdauer rechnen willst, dann in etwa:

```
long remainder = t1.getTime() - t2.getTime();
final long millis = remainder % 1000;
final long seconds = (remainder /= 1000L) % 60;
final long minutes = (remainder /= 60L) % 60L;
final long hours = (remainder /= 60L)  % 24L;
final long days = remainder;
```
Ebenius


----------



## Spacerat (3. Jun 2011)

@Ebenius: Okay, dass klingt einleuchtend. Was nicht sehr einleuchtet, ist, ich instanziere das Time-Objekt über den Konstuktor mit der Differenz zweier Timestamps. Diese beiden Timestamps liegen nur rd. 42 Minuten auseinander und sind auch in der gleichen Timezone. Daraus folgt, dass der übergebene Longwert definitiv den richtigen Zeitunteschied anzeigt. An welcher Stelle wird diesem Wert denn nun was "angedichtet"? Naja, ich seh's mir noch mal an. Danke für den Tip.

@Edit: Gesagt, getan. Also am Wert der Millisekunden wird nichts Zeitzonen abhängiges rum gerechnet. Die Zeitzone kommt wahrhaftig erst in der "toString()"-Methode hinzu. Es gibt da noch eine @Deprecated Methode; "toGMTString()", welche halt die Zeit ohne TimeZone anzeigt. Will man diese nicht verwenden, bleibt einem dessen replacement "DateFormat.format(Date d)", womit man die gewünschte Ausgabe aber auch erst nach "setTimezone(Timezone.getTimeZone("GMT"))" bekommt. Hoff des ist bei Joda nicht so. Dann wird's Zeit für das, was Landei als letztes sagte 

```
DateFormat df = DateFormat.getTimeInstance();
df.setTimeZone(TimeZone.getTimeZone("GMT"));
System.out.println(df.format(t));
```
Des doch 'n Witz wa? :lol:


----------



## Ebenius (3. Jun 2011)

Man sollte einfach immer daran denken, dass [c]java.sql.Time[/c] einen konkreten Zeitpunkt unabhängig von der Zeitzone abbildet. [c]new java.sql.Time(0)[/c] definiert den konkreten Zeitpunkt 0:00:00 Neujahr 1970 in London. Die Darstellung dieses Zeitpunkts ist nunmal abhängig von der jeweiligen Ortszeitzone. Meiner Meinung nach macht es [c]java.sql.Time[/c] genau richtig. Es ist einfach die falsche Klasse um ein Interval abzubilden.

Ebenius


----------



## Spacerat (3. Jun 2011)

Nur bei der bzw. den "toString()"-Methoden machen alle Java-Klassen etwas falsch. Diese sollten nämlich stets das anzeigen, was sie abbilden, nämlich jenen konkreten Zeitpunkt unabhängig von der Timezone. Erst wenn eine Ausgabe in einer speziellen Timezone benötigt wird, sollte man DateFormat verwenden müssen. So wäre es vergleichbar mit z.B. einem ordinär erstelltem Vector3D, dessen "toString()"-Methode die Koordinaten in einem Paralleluniversum wiedergibt welches zufällig als Standard eingestellt ist. Wie würde man denn mit so etwas vernünftig rechnen können?


----------

