Usage of ej.bon.Timer.schedule(TimerTask, Date)

1

Hello,

I think I’ve found an inconsistency in ej.bon.Timer.
Timer provides several methods to schedule a task such as:
Timer.schedule(TimerTask, long delay) and Timer.schedule(TimerTask, Date aDate)

However, since the ej.bon.Timer is based on the platform time and not on system time, it can’t know the date.
That is, when I build a Date from a Calendar, my reference time is the system time (since epoch).
But when I schedule the TimerTask based on this date, it will take a long time to execute since the timer gets the Date.getTime (based on epoch) and schedule it based on the platform time (based on startup time).

NB: on my platform, on EMB the platform time is based on startup time; on SIM the platform time seems to be the current time.

It’s still a bit fuzzy in my head, I may have wrongly interpreted what I observed, but overall, I think the Timer.schedule(TimerTask, Date) should either not exist or do the conversion (assuming the platform knows about epoch).

Am I missing something?

2

Hi @medhi.j ,

The BON Timer is based on the Platform time so that changing the Application Time does not affect the tasks scheduling.

If you plan to use one of the Timer.schedule* APIs taking a Date argument, you should avoid to pass a Date that has been created with the default constructor (aka snapshot of the current Application time (System.currentTimeMillis()).

Instead, you have to create a Date object from a Platform time:

new Date(Util.platformTimeMillis())

However, I agree this API is quite disturbing. It seems to be legacy and not really used, so we will deprecate it in a future version.

–Frédéric

1 Like
3

Hello Frédéric,

Ok thanks, that confirms my observations then.
In my case I got the Date from a Calendar which is based on System.currentTimeMillis() (based on epoch). Also note that the Date API is said to be based on epoch.
With such date, the delay can be computed such as long delay = aDate.getTime() - System.currentTimeMillis()).

Thanks for your answer.
Best,