interval sometimes gets stopped when time changed on Android

[galwaychia]

Observable.interval(
0,
1000,
TimeUnit.MILLISECONDS,
Schedulers.io()
).map {
println("xxxxxxx interval interval interval $it")
}
.sample(
2000,
TimeUnit.MILLISECONDS,
Schedulers.io()
)
.map {
println("xxxxxxx sample sample sample $it")
}.subscribe()

---

When you change the system time by android setting, the interval maybe stop working. BUT when change the scheduler to Schedulers.computation(), it is gonna be ok.
Looks like interval only works stably on Schedulers.computation().

[akarnokd]

Which RxJava version are you running?

Both should work the same and also tolerate clock changes that are bigger than 15 minutes by default. You can read about how to configure this in the Scheduler class' JavaDocs.

[galwaychia]

rxjava version: 3.0.0

I changed the code like:

thread(start = true) {
while (true) {
Thread.sleep(1000)
val currentTime = java.time.LocalDateTime.now().format(java.time.format.DateTimeFormatter.ISO_LOCAL_TIME)
println("xxxxxxx looper looper looper $currentTime")
}
}
Observable.interval(
0,
1000,
TimeUnit.MILLISECONDS,
Schedulers.io()
).map {
val currentTime = java.time.LocalDateTime.now().format(java.time.format.DateTimeFormatter.ISO_LOCAL_TIME)
println("xxxxxxx interval interval interval $it, $currentTime")
}
.sample(
2000,
TimeUnit.MILLISECONDS,
Schedulers.io()
)
.map {
val currentTime = java.time.LocalDateTime.now().format(java.time.format.DateTimeFormatter.ISO_LOCAL_TIME)
println("xxxxxxx sample sample sample $it $currentTime")
}.subscribe()

---

logcat output like:

2025-06-06 22:01:49.397 12463-21808 System.out I xxxxxxx interval interval interval 76, 22:01:49.397643
2025-06-06 22:01:49.494 12463-21804 System.out I xxxxxxx looper looper looper 22:01:49.492828
2025-06-06 22:01:50.397 12463-21808 System.out I xxxxxxx interval interval interval 77, 22:01:50.395204
2025-06-06 22:01:50.497 12463-21804 System.out I xxxxxxx looper looper looper 22:01:50.495581
2025-06-06 22:01:51.396 12463-21808 System.out I xxxxxxx sample sample sample kotlin.Unit 22:01:51.394853
2025-06-06 22:01:51.398 12463-21808 System.out I xxxxxxx interval interval interval 78, 22:01:51.397615
2025-06-06 22:01:51.499 12463-21804 System.out I xxxxxxx looper looper looper 22:01:51.498402
2025-06-06 22:01:52.395 12463-21808 System.out I xxxxxxx interval interval interval 79, 22:01:52.39497
// change the time to 21:57:00, then interval looks like paused
2025-06-06 21:57:00.024 12463-21804 System.out I xxxxxxx looper looper looper 21:57:00.024116
2025-06-06 21:57:00.917 12463-21808 System.out I xxxxxxx sample sample sample kotlin.Unit 21:57:00.91733
2025-06-06 21:57:00.918 12463-21808 System.out I xxxxxxx interval interval interval 80, 21:57:00.918239
2025-06-06 21:57:01.026 12463-21804 System.out I xxxxxxx looper looper looper 21:57:01.025612
2025-06-06 21:57:02.028 12463-21804 System.out I xxxxxxx looper looper looper 21:57:02.027806
2025-06-06 21:57:03.030 12463-21804 System.out I xxxxxxx looper looper looper 21:57:03.029338
2025-06-06 21:57:04.033 12463-21804 System.out I xxxxxxx looper looper looper 21:57:04.032376
2025-06-06 21:57:05.035 12463-21804 System.out I xxxxxxx looper looper looper 21:57:05.034165
2025-06-06 21:57:06.038 12463-21804 System.out I xxxxxxx looper looper looper 21:57:06.036733
2025-06-06 21:57:07.040 12463-21804 System.out I xxxxxxx looper looper looper 21:57:07.039017
2025-06-06 21:57:08.042 12463-21804 System.out I xxxxxxx looper looper looper 21:57:08.041435

[akarnokd]

You induced a drift that is smaller than the default 15 minutes, in your case, 5 minutes. That means that when cycle 80 triggered, it would schedule cycle 81 to 22:01:53.395, which is now 5 minutes further into the future.

Set the rx3.scheduler.drift-tolerance system parameter to 1 and it no longer schedule cycles that far into the future anymore.

[galwaychia]

1 minutes looks like the minimum of the drift, so maybe more smaller change of android system time the interval could not handle, right?

BUT what weird is that if i change Schedulers.io() to Schedulers.computation(), the interval worked very well no matter how long i changed time. And i just keep rx3.scheduler.drift-tolerance default 15 minutes without any change.
With all due respect, IMO, interval logic should not care the change of system time.

[akarnokd]

It is weird because both io() and computation() are implemented to use the very same periodic schedule logic with the drift compensation.

The only scheduler that is not using this logic is the ExecutorScheduler which delegates to the underlying ScheduledExecutorService implementation. Here is an explanation how it avoids the drift

You can enable this behavior for io()/computation() by setting the rx3.scheduler.use-nanotime system property to true.

[akarnokd]

Btw, it was implemented with 3.0.10 years ago so if you really meant you are using the very first release of v3.0.0, you'll have to upgrade.

[galwaychia]

Thanks a lot. I‘v upgraded to 3.0.10, and then had a test, the issue still existed.
ScheduledExecutorService looks like from JDK, the java doc of which says: An ExecutorService that can schedule commands to run after a given delay...
SO, i think this is the root cause of this issue, looks like ScheduledExecutorService handle interval stably.
BTW i have a test showing that Schedulers.computation().schedulePeriodicallyDirect will handle stably, BUT if you change to Schedulers.io().schedulePeriodicallyDirect, this kind of time changed issue occurs...
So maybe you guys consider all delegates to ScheduledExecutorService by default

[akarnokd]

Is there a reason you weren't using the latest 3.1.10 to begin with?

Please try with the latest.

[galwaychia]

Sorry, i got a mess at you comment > #7872 (comment), and though 3.0.10 is the latest version.
And i'v tested using the latest 3.1.10, that kind of issue still happens...

[akarnokd]

Alright, double checked the code. Indeed computation() and io() are coded differently in this regard. Still, enabling rx3.scheduler.use-nanotime makes them work the same:

import java.time.LocalDateTime;
import java.util.concurrent.TimeUnit;

import io.reactivex.rxjava3.schedulers.Schedulers;

public class TimerDrift {

    public static void main(String[] args) throws Throwable {

        System.setProperty("rx3.scheduler.use-nanotime", "true");
        
        Schedulers.io().schedulePeriodicallyDirect(() -> {
            System.out.println(LocalDateTime.now());
        }, 1, 1, TimeUnit.SECONDS);

        Thread.sleep(100000);
    }
}

[galwaychia]

Alright, double checked the code. Indeed computation() and io() are coded differently in this regard. Still, enabling rx3.scheduler.use-nanotime makes them work the same:

import java.time.LocalDateTime;
import java.util.concurrent.TimeUnit;

import io.reactivex.rxjava3.schedulers.Schedulers;

public class TimerDrift {

public static void main(String[] args) throws Throwable {

    System.setProperty("rx3.scheduler.use-nanotime", "true");
    
    Schedulers.io().schedulePeriodicallyDirect(() -> {
        System.out.println(LocalDateTime.now());
    }, 1, 1, TimeUnit.SECONDS);

    Thread.sleep(100000);
}

}

Close this issue for System.setProperty("rx3.scheduler.use-nanotime", "true") is the right solution. And maybe set to true is a better practice for android platform.