[java]Timer raar bij datum/tijd verandering

[Verwijderd]

Voor een applicatie die elke zoveel tijd wat moet doen heb ik de volgende "basis code" (ergens van internet vandaan)

code:

import java.util.Timer;
import java.util.TimerTask;

public class CheckZooi extends TimerTask{
  int x = 0;
  public static void main(String[] args) {
    TimerTask timerTask = new CheckZooi();
    Timer timer = new Timer();
    timer.scheduleAtFixedRate(timerTask,5000,1000);
  }
  public void run(){
    x++;
    System.out.println("weer een nieuwe regel!: " + x);
  }
}

Op zich werkt dit best goed, alleen als je de datum/tijd gaat veranderen. Zodra ik de tijd 1 minuut vooruitzet gaat hij opeens snel nog even 60 keer de run uitvoeren. En als ik de tijd een minuut achteruit zet slaat hij eerst 60 keer over, voordat hij verder gaat.

Is hier op een redelijke manier wat aan te doen?

[farlane]

Zelf nog een keer de tijd controleren in je run is denk ik de meest snelle oplossing.

[Woy]

probeer het anders eens met de volgende methode
schedule(TimerTask task, long delay, long period);
Ik heb het niet uitgeprobeerd maar ik denk dat deze methode gewoon op de eerste mogelijke tijd na de delay time de TimerTask uitvoerd. De scheduleAtFixedRate zorgt er waarschijnlijk voor dat er zowiezo voor elke keer dat de delay verstreken is de TimerTask verstreken wordt terwijl de schedule methode de timer waarschijnlijk pas opnieuw zet als de Timer getriggered wordt. Het is natuurlijk maar de vraag wat je applicatie er precies mee doet of het belangrijk is dat je de garantie hebt dat je methode een vast aantal keer aangeroepen wordt.

[Verwijderd]

Ja, dat klopt, k heb nu al de methode schedule gebruikt. Echter zodra ik de tijd achteruit zet blijft hij wel wachten totdat hij weer terug is op de nieuwe tijd. Dit is nog wel lastig

[Woy]

Verwijderd schreef op 03 november 2003 @ 11:04:
Ja, dat klopt, k heb nu al de methode schedule gebruikt. Echter zodra ik de tijd achteruit zet blijft hij wel wachten totdat hij weer terug is op de nieuwe tijd. Dit is nog wel lastig

Doet hij dit ook niet met de scheduleAtFixedRate?
Het lijkt me dat beide methodes namelijk bijna hetzelfde doet behalve dat de scheduleAtFixedRate als hij nieuwe Timers zet nog even oplet wat de start tijd was en de laatste getriggerde Timer maar bij het terug zetten van de tijd ligt die timer dus gewoon een stuk verder in de toekomst. Ik denk dat je even moet zoeken of het niet mogelijk is om een event te krijgen als de tijd verzet wordt. Dat is denk de enige echt correcte oplossing

[Verwijderd]

Tja, de tijd veranderd constant. Verder gaat het vooral om Zomer/Winter tijd. K ben nu bezig om elke keer te controleren of de oude tijd+interval voor de huidige tijd ligt.
Maar hij heeft nog een null pointer bij timer.cancel, terwijl deze global ik gedeclareerd.

[Verwijderd]

Maarja, dat werkt natuurlijk niet Want pas in de run controleerd hij of de tijd is teruggezet. Dus ben ik dan mooi te laat.

[Woy]

Ik heb al een tijd niet meer met java gewerkt dus ik zou het zo niet weten of het bestaan maar is er niet een of ander System object waar je bijvoorbeeld ook een TimeChangedListener kan registreren?
Als zoiets niet bestaat ( Waar ik trouwens wel bang voor ben ) dan zal het denk moeilijk worden om het goed op te lossen zonder platform afhankelijke code te schrijven ( Ik ga er hier wel vanuit dat windows wel een notification of event heeft als de tijd veranderd. Ik heb alleen even geen tijd om ernaar te zoeken ).