Re: Uhrzeit auslesen, Minuten addieren
Marco Schwarz
Stefan Lintner <stefan....@wu-wien.ac.at> schrieb:
>Ich möchte gerne die aktuelle Uhrzeit auslesen um nachher x Minuten zu
>addieren und in einem entsprechenden String (?) speichern. Nur komm ich
>damit nicht ganz klar.
>
>Ich weiß, dass ich java.util.Calendar und java.util.GregorianCalendar
>verwenden muss.
>
>Lt. API bekomm ich mit
>Calendar rightNow = Calendar.getInstance();
>ein Objekt mit Datum und Uhrzeit. Datum brauch ich aber nicht.
>
>Die Uhrzeit kann ich ausgeben:
>GregorianCalendar cal = new GregorianCalendar();
>System.out.println((cal.get(Calendar.HOUR_OF_DAY)+":"+cal.get(Calendar.MINUTE)));
>
>Mit der API komm ich nicht gut weiter; kann ich die aktuelle Uhrzeit
>(Stunde:Minute reicht vollends) in einer Variable abspeichern um nachher
>x Minuten addieren zu können?
Schau Dir mal die Methode GregorianCalendar.add(int field,int amount)
an. Die stellt dir alle Änderungen am Datum zur verfügung.
Mit getTime() kannst Du Dir dann ein neues Date-Object holen.
Marco
Stefan Waldmann
> Marco Schwarz schrieb:
>> Schau Dir mal die Methode GregorianCalendar.add(int field,int amount)
>> an. Die stellt dir alle Änderungen am Datum zur verfügung.
>> Mit getTime() kannst Du Dir dann ein neues Date-Object holen.
>
java.util.Calendar myCal = Calendar.instance();
myCal.add(Calendar.MINUTE, 10);
java.util.Date date = myCal.getTime();
Hilfreich genug?
Das erhaltene Date-Objekt kannst du dann mit einem DateFormat in einen
String mit dem gewünschten Ausgabeformat umwandeln.
> getTime(): Returns the number of milliseconds since January 1, 1970,
> 00:00:00 GMT represented by this Date object. Ufff...
Marco meinte Calendar#getTime(). Was du hier schreibst hört sich ganz
nach java.util.Date#getTime() an...
Falls du allerdings der Meinung bist, getTime() wäre unpassend für eine
Methode, die ein Date-Objekt zurückgibt, bist du nicht alleine ;-)
Gruß
Stefan
--
Programmierer [m], seltener auch ~in [w]:
Irdische, i.a. humanoide Lebensform, die in einem komplizierten
biochemischen Prozess Kaffee, Cola und Pizza in maschinenlesbaren
Programmcode umwandelt.
Bernd Post
> Stefan Waldmann wrote:
>> java.util.Calendar myCal = Calendar.instance();
>> myCal.add(Calendar.MINUTE, 10);
>
>
> Ich habs mittlerweile so:
>
> ===
> SimpleDateFormat zeitdf = new SimpleDateFormat("km");
> Calendar aktuelleZeit = Calendar.getInstance();
>
> (...)
>
> public int berechneETAnp(double dSN) {
>
> (...)
>
> switch (dSNInt) {
> case 1: return aktuelleZeit.add(Calendar.MINUTE, 10);
> (...)
> }
> return aktuelleZeit;
> }
> ===
>
> Java meint dann:
> incompatible types
> found : void
> required: int
> case 1: return aktuelleZeit.add(Calendar.MINUTE, 10);
> ^
> 1 error
>
>
> Alle imports sind da. Was ist falsch?
Das schreibt dir doch Java
incompatible types
/*Aha irgendwie kommt da irgendwo was falsches an*/
found: void
/*Mir wurde ein leeres Argument zurückgegeben nichts finito garnichts
tabula rasa*/
required: int
/* Dabei hat mein return doch eigentlich nen int zurückgeben wollen...*/
Aaaalso... dann gucken wir doch mal was Calendar#add(int, int)
zurückliefert.
http://java.sun.com/j2se/1.5.0/docs/api/java/util/Calendar.html#add(int,%20int)
Oh, offensichtlich ein void.
Dann wäre es wohl besser eine Methode zu nehmen, die ein int am besten
sogar das richtige zurückliefert ;-).
[...]
case 1:
aktuelleZeit.add(Calendar.MINUTE, 10);
return aktuelleZeit.get(Calendar.DAY_OF_MONTH);
[...]
HTH
Bernd
Bernd Post
> Stefan Waldmann wrote:
>> myCal.add(Calendar.MINUTE, 10);
>
return aktuelleZeit.get(Calendar.HOUR_OF_DAY);
[...]
HTH
Bernd
Stefan Waldmann
Genau.
Wieso gibt deine Methode berechneETAnp(...) denn ein int zurück? Was
willst du damit anfangen? Wenn du es mit deinem SimpleDateFormat
verwenden willst, solltest du eher ein java.util.Date zurückgeben:
public Date berechneETAnp(double dSN) {
// ...
case 1:
aktuelleZeit.add(Calendar.MINUTE, 10);
return aktuelleZeit.getTime();
// ...
}
Was dir außerdem bewusst sein muss ist, dass das Calendar-Objekt
"aktuelleZeit" mutable (=veränderbar) ist; d.h. die Methode "add(...)"
verändert die vom Objekt repräsentierte Zeit, addiert also 10 Minuten!
Will heißen, nachdem du die berechne-Methode aufgerufen hast, ist es in
"aktuelleZeit" 10 Minuten später (in Bezug auf den Erstellungszeitpunkt
der Calendar-Objektinstanz). Nach einem weiteren Methodenaufruf wäre es
dann 20 Minuten später, nach einem dritten 30 Minuten, usw.
Wenn die "berechneETAnp(...)" Methode also bei jedem Aufruf eine Zeit 10
Minuten in der Zukunft zurückliefern soll (in Bezug auf den Zeitpunkt
des Methodenaufrufs), musst du die Calendar-Instanz auch lokal in der
berechne-Methode instanzieren.
Gruß
Stefan
P.S.: @Bernd: müsstest du nicht "Doppelpost" heißen? *SCNR*
Stefan Waldmann
Stattdessen könntest du "aktuelleZeit" auch außerhalb der Methode
definiert lassen und bei jedem Methodenaufruf die Zeit aktualisieren
(wahrscheinlich performanter als immer eine neue Instanz zu erstellen):
aktuelleZeit.setTimeInMillis(System.currentTimeMillis());
//...
case 1:
aktuelleZeit.add(Calendar.MINUTE, 10);
return aktuelleZeit.getTime();
//...
Falls das nicht sowieso schon in dem von dir ausgelassenen Code
enthalten sein sollte...
Gruß
Stefan
Bernd Post
> Bernd Post wrote:
>
> P.S.: @Bernd: müsstest du nicht "Doppelpost" heißen? *SCNR*
>
War ein Unfall. Das eine Posting hat geklemmt und dann doch nicht
geklemmt, und anschließend gab es zwei Posts mit selber ID. Sozusagen
ich und mein böser Clon, und die wollte Thunderbird mir dann nicht mehr
canceln, aber ich gelobe Besserung ;-)
Grüße
Bernd
Stefan Waldmann
> Stefan Waldmann wrote:
>> Wieso gibt deine Methode berechneETAnp(...) denn ein int zurück? Was
>> willst du damit anfangen?
>
> bestimmte Anzahl von Minuten dazuaddieren. Je nachdem, welche Bedingung
> eintritt, soll eine andere Minutenanzahl addiert werden.
>
> Das ganze dann per return-Anweisung zurück...
Wenn du die Uhrzeit haben willst, reicht dir ein int aber nicht aus.
> Scheinbar geht das also nicht... d.h. ich kann nur die aktuelle Zeit
> auslesen; wenn ich dann Minuten addiere, dann kann ich diese also nicht in
> einer neuen Variable abspeichern... OK :)
Doch, das geht schon. Wie hätten Sie's denn gern? ;-) Du kannst dir vom
Calendar-Objekt die Minuten als int holen (dann ginge allerdings die
Information für die Stunde verloren), oder die Zeit/das Datum als Date,
woraus du wiederum einen formatierten String machen kannst...
Ich glaube was du haben willst ist ungefähr das:
public java.util.Date berechneETAnp(double dSN) {
// erzeugt neuen Calendar mit aktueller Zeit
Calendar aktuelleZeit = Calendar.getInstance();
switch (dSNInt) {
case 1: aktuelleZeit.add(Calendar.MINUTE, 10); break;
case 2: aktuelleZeit.add(Calendar.MINUTE, 20); break;
case 3: aktuelleZeit.add(Calendar.MINUTE, 30); break;
...
}
// hier wird der berechnete Zeitpunkt einer Date-Variable zugewiesen.
// Diese wird dann zurückgegeben:
return aktuelleZeit.getTime();
}
Und die Verwendung geht dann so:
SimpleDateFormat zeitdf = new SimpleDateFormat("k:mm");
Date date = berechneETAnp(dSN);
String zeitString = zeitdf.format(date);
System.out.println(zeitString);
Es wundert mich nicht sehr, dass dich die Handhabung von Zeit/Datum in
Java verwirrt - mir ging es anfangs ähnlich. Die Java-API für Datum/Zeit
ist nicht gerade optimal (um nicht zu sagen "grottenschlecht ;-)
Nicht zuletzt deswegen gibt es dafür auch alternative Bibliotheken, wie
z.B. Joda-Time.
Über die Java-API musst du wissen:
Objekte vom Typ Calendar sind mutable, können also verändert werden.
Daher braucht man Calendar-Objekte wenn man mit Zeit/Datum rechnen will.
Dummerweise kann man Calendar-Objekte nicht in (Simple)DateFormat
verwenden, obwohl es doch nahe läge. Zum Formatieren in ein gewünschtes
Format braucht man also ein Date-Objekt (wie oben). Date-Objekte sind
wiederum "immutable", d.h. einmal erzeugt, kann die Zeit/das Datum das
sie repräsentieren nicht mehr verändert werden. So ein Date-Objekt, das
das Datum und die Zeit des Calendar-Objekts repräsentiert, kannst du dir
mit Calendar#getTime() holen.
Einen Datentyp für die reine Zeit ohne Datum gibt's in der Standard-API
von Java übrigens nicht. Du musst Date/Calendar benutzen und den
Datum-Teil dabei ignorieren.
Hoffe ich hab dir damit genug auf's Pferd geholfen, damit du jetzt
selber weiter reiten kannst ;-)
Gruß
Stefan
Frank Dreyer
> ich will einfach nur folgendes:
>
> 1. aktuelle Uhrzeit holen und in einer Variable abspeichern (aktuelleZeit)
Date aktuelleZeit = new Date();
> 2. bei Eintritt eines bestimmten Ereignisses (switch-Anweisung) x Minuten
> dazuaddieren und in einer neuen Variable speichern (aktuelleZeitNeu)
Calendar cal = Calendar.getInstance();
cal.setTime(aktuelleZeit);
cal.add(Calendar.MINUTES, x);
Date aktuelleZeitNeu = cal.getTime();
IMHO hätte man Calendar und Date in eine einzelne Klasse packen sollen.
Wenn man dann den Wert irgendwie "rausholen" will, kann man ja immer
noch getTimeInMillis() verwenden.
Oder man hätte die add() usw. Methoden ähnlich wie StringBuffer durch
ein "return this" ergänzen können, dann könnte man solche Sachen
zumindest auf
> Date aktuelleZeitNeu = Calendar.getInstance(aktuelleZeit).add(Calendar.MINUTES, 10).getTime();
reduzieren.
Stefan Waldmann
Sowas in der Art hab ich mir schon gedacht. War ja auch nicht als Kritik
gemeint, ich konnt' bei deinem Namen halt nicht widerstehen :-)
Viele Grüße
Stefan
Stefan Waldmann
> gelernt :) Diese Datum/Zeit-Sache ist in Java, zumindest für einen
> Anfänger, doch alles andere als trivial... ;)
Freut mich dir helfen gekonnt zu haben :-)
Es gibt übrigens noch eine Alternative, die ohne Calendar auskommt:
public Date berechneETAnp(double dSN) {
// ...
int minutesToAdd = 0;
switch (dSNInt) {
case 1: minutesToAdd = 10; break;
case 2: minutesToAdd = 20; break;
// ...
}
return new Date(System.currentTimeMillis() +
(minutesToAdd * 60000));
Ralf Ullrich
>Mittlerweile bin ich schon total verwirrt: es gibt mindestens 2 Klassen in
>Java, die sich um Datum/Uhrzeit kümmern... ich will einfach nur folgendes:
Also erstens, würde ich sagen, dass dieser Thread ein wenig entgleist ist,
denn es hat dich keiner gefragt, warum du eigentlich ein Calender-Objekt
benutzen musst, wie du in deinem Eingangspost behauptet hast. Ich sehe
diese Notwendigkeit nämlich nicht, und das macht die Sache dann vielleicht
einfacher.
Zu den zwei Klassen: So kompliziert ist das gar nicht.
java.util.Date ist im wesentlichen nur ein Wrapper um einen long-Wert, da
alle Methoden, die irgendwie Locale-Spezifisch sein könnten, deprecated
sind. Dieser long-Wert enthält die Anzahl Millisekunden, die seit dem 1.
Januer 1970 0:00 Uhr (GMT) verstrichen sind. Man braucht sich aber
eigentlich nur merken, dass es halt Millisekunden seit irgendwann sind, da
man mit solchen Zeitwerten eh nur relativ zueinander rechnet, und außerdem
sind solche Zeitwerte nur für den Computer interessant, oder könntest du
mir auf Anhieb sagen ob 1138100400357L irgendein besonderer Zeitpunkt ist?
java.util.Calendar ist nun eine Locale-abhängige Brücke zwischen solchen
Zeitwerten, wie sie der Computer und die Klasse Date verwenden, und der
Art Zeitpunkt darzustellen, wie sie für uns Menschen gebräuchlich ist. Die
konkrete Klasse GregorianCalendar, ist dabei nur eine Möglichkeit, die
aber vom allergrößten Teil der Menschheit benutzt wird. In einem Kalender
werden Zeitpunkte zusammengefasst, zunächst (meist) in Jahre, dann Monate,
evtl. Wochen, dann Tage, Stunden, Minuten und Sekunden und evtl.
Sekundenbruchteile. Diese Aufteilung kann in verschiedenen Kulturen aber
auf abweichenden Fundamenten stehen. Die für uns so selbstverständliche
Basis mit Jesu Geburt im Jahre 1 und zwölf Monaten mit 28 bis 31 Tagen,
muss nicht für alle Kulturkreise die passende Basis sein. Die Java
Runtime-Library enthält zwar bisher nur einen einzigen leicht abweichenden
Fall (th_TH liefert einen buddhistischen Kalender, nach dem es im Moment
"23/6/2549, 9:20 ?." ist. (Wobei das Fragezeichen eigentlich das Zeichen
für die Buddhist Era sein sollte, aber ich habe es gerade nur an der
Konsole getestet, wo das Zeichen nicht verfügbar ist.) Mit Java 6 kommt
dann noch ein weiterer für uns "exotischer" Kalender hinzu:
http://java.sun.com/javase/6/docs/technotes/guides/intl/calendar.doc.html
Ergo: Man kann sich einfach merken, dass sowohl Date, als auch Calendar
bis auf die Millisekunde genau einen Zeitpunkt bezeichnen, aber Date dabei
nichts anderes als Millisekunden zu Aufteilung kennt, während Calendar
auch noch die kultur spezifischen Zeiteinteilungen wie Tage, Stunden,
Wochen, etc. kennt.
>1. aktuelle Uhrzeit holen und in einer Variable abspeichern (aktuelleZeit)
>
>2. bei Eintritt eines bestimmten Ereignisses (switch-Anweisung) x Minuten
>dazuaddieren und in einer neuen Variable speichern (aktuelleZeitNeu)
>
>Mehr nicht...Wie nur? Hilfe!
Bei dieser Aufgabe stellt sich nun die Frage, was meinst du mit x Minuten
dazuaddieren?
Wie ich oben geschrieben habe, sind Minuten prinzipiell eine
Locale-spezifische Einteilung, und deswegen müsstest du eigentlich
Calendar verwenden:
private static Calendar cal = Calendar.getInstance(DEINE_LOCALE);
public Date addMinutes(int x, Date d) {
synchronized (cal) {
cal.setTime(d);
cal.add(Calendar.MINUTES, x);
return cal.getTime();
}
}
...
aktuelleZeitNeu = addMinutes(10, aktuelleZeit);
...
Das löst deine Aufgabe im wörtlichen Sinne.
Wenn du aber in 2. eigentlich meintest:
2. bei Eintritt eines bestimmten Ereignisses (switch Anweisung) einen Zeitpunkt berechnen, der 10 Minuten (= 600 Sekunden = 600,000 Millisekunden) später liegt
dann kannst du dir den Umweg über Calendar auch sparen, da du dann deine
Wünsche ja auch direkt in für den Computer "verständlichen" Einheiten
ausdrücken konntest. Du brauchst dann nur noch zu schreiben:
...
aktuelleZeitNeu = new Date(aktuelleZeit.getTime() + 600000 );
...
Du kannst dann sogar noch auf Date verzichten und direkt mit den davon
gekapselten long-Werten arbeiten, und somit sogar schreiben:
...
aktuelleZeitNeu = aktuelleZeit + 600000;
...
Ich denke damit wäre das Problem "x Minuten addieren" ausreichend
besprochen. Fehlt noch das Teilproblem: "aktuelle Uhrzeit auslesen".
Am einfachsten ist wohl:
long aktuelleZeit = System.currentTimeMillis();
Das liefert dir die aktuelle Zeit im Computerformat, also als große Zahl,
die der Anzahl Millisekunden seit ..... (s.o.)
Alternativ ginge auch:
Date aktuelleZeit = new Date();
oder
Date aktuelleZeit = new Date(System.currentTimeMillis());
und schließlich auch:
Calendar cal = Calendar.getInstance(DEINE_LOCALE);
bzw.
Calendar cal = Calendar.getInstance(DEINE_LOCALE);
...
cal.setTime(new Date());
oder
Calendar cal = Calendar.getInstance(DEINE_LOCALE);
...
cal.setTime(new Date(System.currentTimeMillis()));
oder
Calendar cal = Calendar.getInstance(DEINE_LOCALE);
...
cal.setTimeInMillis(System.currentTimeMillis());
Warum zeige ich dir soviele Varianten? Ganz einfach: Damit du siehst, dass
alle Varianten letztlich (verdeckt oder offen) auf
System.currentTimeMillis() zurückzuführen sind. Um die aktuelle Zeit zu
holen, brauchst du dir nur diesen einen Aufruf merken. Und dann solltest
du nur noch wissen wie du zwischen den inzwischen drei Zeitformaten hin
und her wandelst:
long <--> Date:
long lTime = dTime.getTime();
Date dTime = new Date(lTime); bzw. dTime.setTime(lTime);
Date <--> Calendar:
Date dTime = cTime.getTime();
cTime.setTime(dTime);
long <--> Calendar:
long lTime = cTime.getTimeInMillis();
cTime.setTimeInMillis(lTime);
Ich hoffe die Erklärungen helfen dir jetzt bei Java in Sachen Zeiten
besser durchzublicken. Abschließend noch ein Wort zum verbleibenden
Teilproblem: "in einen entsprechenden String speichern".
Ich nehme nicht an, dass dir ein String der Art "1138100400357" ausreicht,
obwohl es ein "entsprechender String" ist. Was du also eigentlich willst,
ist eine "einem bestimmten Kulturkreis entsprechende textliche Darstellung
eines Zeitpunkts" die du in einem String speichern möchtest, richtig? Dazu
nimmst du einen entsprechend konfigurierten Formatter aus dem java.text
Package. Zum Beispiel:
DateFormat df = DateFormat.getTimeInstance(DateFormat.SHORT, DEINE_LOCALE);
String s = df.format(dTime);
cu
P.S.: Überall wo ich DEINE_LOCALE geschrieben habe, kannst du den Wert
ggf. auch einfach weglassen, wenn du die Vorgabe-Lokale des Rechners
verwenden willst. Besser wäre aber dein Programm konfigurierbar zu machen,
so dass der Anwender ggf. einstellen kann, welche Lokale er haben möchte.
Natürlich sollte diese Einstellung auf die Vorgabe-Lokale des Rechners
voreingestellt sein. ;-)
Ralf Ullrich
>Allerdings hab ich ein neues Problem: kann ich die Differenz in Minuten
>zwischen 2 Zeitangaben bilden?
>In der Calendar-API konnt ich folgendes finden:
>"abstract void roll(int field, boolean up)
>Adds or subtracts (up/down) a single unit of time on the given time field
>without changing larger fields."
>
>Nur, wie wende ich diese richtig an?
In diesem Fall gar nicht.
Ein Calendar-Objekt repräsentiert einen Zeitpunkt. Die Differenz zweier
Zeitpunkte wäre eine Zeitspanne. Leider gibt es in der Java-API weder eine
Klasse die eine Zeitspanne repräsentieren kann, noch gibt es bei den
Klassen, die Zeitpunkte repräsentieren, Methoden, die die Zeitspanne
zwischen zwei Zeitpunkten bilden.
Ergo: Es bleibt dir nichts anderes üblich als in "Computerzeit" zu
rechnen, du bist also wieder auf die Millisekunden seit .... (siehe
anderer Post) angewiesen.
long zeitpunktDavor = ...
long zeitpunktDanach = ...
long zeitspanne = zeitpunktDanach - zeitpunktDavor;
Das ist natürlich in Millisekunden, also:
double zeitspanneInMinuten = zeitspanne / 60000.0d;
HTH
cu
Timo Stamm
> Stefan Waldmann schrieb:
>> Es gibt übrigens noch eine Alternative, die ohne Calendar auskommt:
>
> Die Lösung funktioniert jetzt schon prächtig :) Allerdings hab ich ein
> bilden?
Les' dir das Posting von Ralf Ullrich mal gründlich durch. Dann
verstehst du vielleicht Stefan Waldmans Vorschlag besser. Es ist
eigentlich ganz einfach: Zeitangaben in Java sind intern immer mit einem
einfachen long repräsentiert. Auf so ein long kann man ganz normale
Arithmetik anwenden:
final int minute = 1000 * 60;
long start = System.currentTimeMillis();
long end = ...
long minutesBetweenStartAndEnd = (end - start) / MINUTE;
Stefan Waldmann
> Stefan Lintner wrote:
>
>> Allerdings hab ich ein neues Problem: kann ich die Differenz in
>> Minuten zwischen 2 Zeitangaben bilden?
>
>> In der Calendar-API konnt ich folgendes finden:
>> "abstract void roll(int field, boolean up)
>> Adds or subtracts (up/down) a single unit of time on the given time
>> field without changing larger fields."
>>
>> Nur, wie wende ich diese richtig an?
>
> In diesem Fall gar nicht.
>
> Ein Calendar-Objekt repräsentiert einen Zeitpunkt. Die Differenz zweier
> Zeitpunkte wäre eine Zeitspanne. Leider gibt es in der Java-API weder
> eine Klasse die eine Zeitspanne repräsentieren kann, noch gibt es bei
> den Klassen, die Zeitpunkte repräsentieren, Methoden, die die Zeitspanne
> zwischen zwei Zeitpunkten bilden.
Jupp. Das heißt, entweder du berechnest die Differenz über die
Milliseconds, oder du verwendest doch eine andere Bibliothek die das kann.
Das schon früher von mir angesprochene Joda-Time zum Beispiel:
http://joda-time.sourceforge.net
Kannst's dir ja mal anschauen ob was für dich dabei ist.
Vorteil: die ganze Library ist runder und besser durchdacht als das
Datum-/Zeit-Handling in Standard Java. Außerdem wird bei Kalendern per
Default der ISO8601-Standard verwendet (was bei den Sun-Klassen nicht
der Fall ist). Und der enthaltene DateFormatter kann das Format
"Kalenderwoche-Jahr" korrekt darstellen, was mit Java-Bordmitteln auch
nicht geht.
Nachteil: du benötigst ein zusätzliches jar-File in deiner Applikation
und musst dich in eine neue API einarbeiten (die allerdings sehr gut
dokumentiert ist).
Ralf Ullrich
>Das schon früher von mir angesprochene Joda-Time zum Beispiel:
>
>http://joda-time.sourceforge.net
>
>Kannst's dir ja mal anschauen ob was für dich dabei ist.
Hab's mir gerade mal angeschaut, und während ich sonst extrem dagegen
eingestellt bin, extra Libraries zu nehmen, für Dinge, die man schon mit
der Standard-API brauchbar erledigen kann, muss ich sagen, falls ich je in
einem Programm mal mehr als das aktuelle Datum ausgeben und eine
Zeitspanne messen muss, werde ich mir joda-time ins Projekt dazunehmen.
Sieht sehr sauber und durchdacht aus, schon allein, dass es einen
Unterschied zwischen Duration und Period gibt gefällt mir sehr.
cu
Stefan Waldmann
> Ralf Ullrich schrieb:
>> aktuelleZeitNeu = new Date(aktuelleZeit.getTime() + 600000 );
>> ...
>> ...
>
Den essenziellen Satz, den Ralf zwischen die oben von dir zitierten
Zeilen geschrieben hat, hast du aus deinem Zitat rausgekürzt:
> "Du kannst dann sogar noch auf Date verzichten und direkt mit den
> davon gekapselten long-Werten arbeiten, und somit sogar schreiben:"
>
> ...
> aktuelleZeitNeu = aktuelleZeit + 600000;
> ...
Damit wollte er sagen, dass "aktuelleZeit" in diesem Fall nicht vom Typ
"Date" ist, sondern vom nativen Typ "long".
Ralf Ullrich
>Ralf Ullrich schrieb:
>>(ganz tolle Erklärung)
>
>Ralf, vielen Dank für Deine ausführliche Erklärung! Was ich noch nicht
>hinbekomme ist eine if-Abfrage bezüglich eines Zeitraumes: der Benutzer
>gibt eine Zeit ein und ich möchte prüfen, ob diese Zeit mit der
>errechneten Zeit plus minus 15min übereinstimmt. Jetzt dachte ich an eine
>Konstruktion à la:
>
>if (zeitZiel.add(Calendar.MINUTE, -15) <=
>equals(zeitInputTextFeld.getText() && zeitZiel.add(Calendar.MINUTE, 15) >
>equals(zeitInputTextFeld.getText() { (...) }
>
>...was aber nicht funktioniert. Muss ich wieder auf Millisekunden
>herunterrechnen?
1. Calendar Objekte implementieren Comparable, sie sind also "sortierbar".
Um zwei als Calendar-Objekte vorliegende Zeitpunkte zu vergleichen kannst
du also folgendes machen:
Pseudo-Code:
calZeitPunktA <cmpOP> calZeitpunktB
Java-Code:
calZeitpunktA.compareTo(calZeitpunktB) <cmpOP> 0
mit <cmpOP> einer aus <, <=, ==, >=, >. Näheres siehe Javadoc zu Comparable.
2. Calendar#add ist ein Mutator, verändert also das zugrundeliegende
Objekt, hier die Calendar Instanz. Daher kannst du es nicht in der Weise
anwenden, wie du oben geschrieben hast. Nicht zuletzt auch weil add()
keinen Rückgabewert hat.
Um dein Problem mit Calendar-Objekten zu lösen, müsstest du also folgendes
schreiben:
Calendar zeitZiel = ...; // hast du ja wohl von irgendwoher
Calendar zeitTest = ...; // solltest du aus dem TextField holen
// (Stichwort: DateFormat#parse)
Calendar zeitFrühestens =
zeitZiel.clone().add(Calendar.MINUTE, -15);
Calendar zeitSpätestens =
zeitZiel.clone().add(Calendar.MINUTE, 15);
if ((zeitFrühestens.compareTo(zeitTest) <= 0) ||
(zeitSpätestens.compareTo(zeitTest) >= 0)) {
// zeitTest ist im +/- 15 Minuten Intervall
}
3. Einfacher ist es aber auch hier in Millisekunden zu rechnen, was
problemlos machbar ist, das es nur um relative Zeitintervalle geht.
15 Minuten = 15 * 60 Sekunden = 900 Sekunden = 900000 Millisekunden.
long zeitZiel = ...; // hast du wieder von irgendwoher
long zeitTest = ...; // siehe oben
if (Math.abs(zeitZiel - zeitTest) <= 900000) {
// zeitTest ist im +/- 15 Minuten Intervall
}
wobei du die 90000 besser als static final Konstante definierst und nicht
direkt im Code stehen hast. (Gilt auch für die 15 oben.)
HTH
cu
Ralf Ullrich
>Ralf Ullrich schrieb:
>> Calendar zeitTest = ...; // solltest du aus dem TextField holen
>> // (Stichwort: DateFormat#parse)
>>(...)
>>
>> long zeitTest = ...; // siehe oben
>
>Damit hab ich ein Problem:
>
>===
>DateFormat dateFormat = new SimpleDateFormat("kkmm");
>
>(...)
>
>long zeitAnwenderEingabeMillis =
>dateFormat.parse(zeitInputTextFeld.getText());
>===
>
>"incompatible types: found: java.util.Date required: long"
>
>
>??? Ich definier zeitAnwenderEingabeMillis ja extra als long...?
>
>Die letzte Hürde :/
Deren Überwindung ich dir in meinem langen Post schon gezeigt habe.
Ich werde dir nicht alles vorkauen, ein wenig Transferleistung musst du
schon noch selbst erbringen, sonst lernst du ja nichts bei der ganzen
Aktion. ;-)
cu
Stefan Waldmann
> Ralf Ullrich schrieb:
>
> Verwirrung mit Calendar, Date, Strings, Longs, Millis :/
Das was du tatsächlich brauchst, hast du in deiner Liste nicht
aufgezählt ;-) Direkt von String nach Millis geht nicht.
Tipp: such doch mal im Index der Java-API nach einer Methode
"parse(...)". Davon gibt's einige, aber vielleicht ja eine in einem
Objekt, das du schon kennst :-) Achja, als "deprecated" markierte
Methoden gelten nicht.
Ralf Ullrich
>Stefan Lintner wrote:
>>Ralf Ullrich schrieb:
>>>Deren Überwindung ich dir in meinem langen Post schon gezeigt habe.
>>
>>Das ganze resultiert aus meiner mittlerweilen annähernd totalen
>>Verwirrung mit Calendar, Date, Strings, Longs, Millis :/
>
>Das was du tatsächlich brauchst, hast du in deiner Liste nicht aufgezählt
>;-) Direkt von String nach Millis geht nicht.
>
>Tipp: such doch mal im Index der Java-API nach einer Methode "parse(...)".
>Davon gibt's einige, aber vielleicht ja eine in einem Objekt, das du schon
>kennst :-) Achja, als "deprecated" markierte Methoden gelten nicht.
Das DateFormat#parse kennt er ja schon und hat es auch, soweit ich sehen
kann, richtig gemacht.
Was ihm "fehlt" ist der Übergang von Date zu long, aber den habe ich ihm
ja schon gezeigt. Das kriegt er schon noch hin, wenn er meinen langen Post
nochmal gründlich durchliest. ;-)
cu
Stefan Waldmann
> Stefan Waldmann schrieb:
>> Tipp: such doch mal im Index der Java-API nach einer Methode
>> "parse(...)". Davon gibt's einige, aber vielleicht ja eine in einem
>> Objekt, das du schon kennst :-) Achja, als "deprecated" markierte
>> Methoden gelten nicht.
>
>
> java.text.DateFormat
> public Date parse(String source)
> throws ParseException
>
> ...wobei ich immer eine ParseEception bekomme:
>
> ===
> DateFormat anwenderdf = DateFormat.getDateInstance(DateFormat.SHORT);
> Date anwenderDate;
>
> (...)
>
> public void actionPerformed(ActionEvent e) {
> try {
> String zeitOutput = zeitInputTextFeld.getText();
> anwenderDate = anwenderdf.parse(zeitOutput);
> System.out.println(anwenderDate);
> } catch (ParseException ex) {
> ex.printStackTrace();
> }
>
> (...)
> ===
Nimm mal deine DateFormat-Instanz, formatiere damit ein beliebiges
Date-Objekt - z.b. anwenderdf.dormat(new Date()); und schau dir mal an
was dabei rauskommt. Dasselbe Format muss auch der String haben, der mit
dieser DateFormat-Instanz geparst werden soll, ansonsten gibt's 'ne
ParseException. Fällt dir was auf? ;-)
Ralf Ullrich
>Ralf Ullrich schrieb:
>>Was ihm "fehlt" ist der Übergang von Date zu long, aber den habe ich ihm
>>ja schon gezeigt. Das kriegt er schon noch hin, wenn er meinen langen
>>Post nochmal gründlich durchliest. ;-)
>
>Danke für Dein Vertrauen in mir :)
>
>Ich weiß was Du meinst:
>
>>long <--> Date:
>>
>>long lTime = dTime.getTime();
>>
>>Date dTime = new Date(lTime); bzw. dTime.setTime(lTime);
>
>Nur hab ichs ja jetzt zusätzlich auch noch mit einem String vom Textfeld
>zu tun. Was ja auch kein Problem sein sollte, da mir parse ja Date
>zurückliefert. Trotzdem bekomm ichs immer noch nicht hin :(
>
>===
>DateFormat anwenderdf = DateFormat.getDateInstance(DateFormat.SHORT);
>
>// User-Eingabe vom Textfeld
>String zeitOutput = zeitInputTextFeld.getText();
>
>// User-Eingabe im Date-Format
>Date anwenderDate = anwenderdf.parse(zeitOutput);
>
>// Nach long
>long lTime = anwenderDate.getTime();
>
>Schaut von meinen Anfängerkenntissen jetzt eigentlich gut aus...
Ja, ist auch korrekt.
Allerdings permanent:
>java.text.ParseException: Unparseable date
Nun, das heißt, dass die Eingabe nicht dem Format, das für
DateFormat.SHORT erwartet wird entspricht.
Ausgehend von deiner vorherigen Verwendung von SimpleDateFormat mit "kkmm"
gehe ich mal davon aus, dass du z.B. "1200" eingibst.
DateFormat.SHORT erwartet dafür aber (zumindest für die meisten Locales)
"12:00".
Daher die ParseException.
Wie gesagt dein Code ist jetzt erstmal als solcher korrekt. Es gibt aber
wahrscheinlich immer noch etliche Stolperfallen, in die du treten wirst,
bis dein Programm so läuft, wie du willst. Nicht entmutigen lassen, du
wirst viel dabei lernen.
cu
Ralf Ullrich
>Ralf Ullrich schrieb:
>>Nun, das heißt, dass die Eingabe nicht dem Format, das für
>>DateFormat.SHORT erwartet wird entspricht.
>
>Ahhhh.. natürlich! Jetzt seh ich in der API von DateFormat aber nichts,
>wie ich aufs "kkmm" Format kommen könnte. Geht das? Oder bin ich mit
>DateFormat aufgeschmissen?
DateFormat ist nur die Oberklasse für verschiedene Implementationen (daher
mein Stichwort-Verweis darauf).
Die konkrete Implementation die du brauchst kannst du entweder über eine
der get*Instance Methoden holen, oder wie du es schon richtig in deinem
früheren Posting gemacht hast über "new UnterklasseVonDateFormat" also zum
Beispiel "new SimpleDateFormat(...)"
BTW: Bist du sicher, dass du "kkmm" wolltest und nicht eher "HHmm" ?
cu
PS: Du könntest natürlich deinen Code auch einfach so lassen wie er ist,
und 12:00 statt 1200 in das TextField eingeben.