[NiLuJe]

What you're seeing is a bad interaction between the autostandby, nickel's Homescreen clock, how it handles the refresh, and what happens after a resume on suspend.

* On views with a clock, before setting up the standby, Nickel programs a wake alarm to the first second of the next minute.
* Device wakes up according to said alarm.
* Standard "resume from suspend" operations happen, and that includes a hctosys (the system clock is reset based on the hardware clock).
* Nickel updates clock.

Now, NanoClock is setup to refresh *on the dot*, not on the first second.

So, resume from suspend triggers a discontinuous clock change (AFAICT, that one we can't do anything about, it's kernel related on platforms where nothing hardware ticks during suspend).
*Then*, the hctosys triggers a *second* discontinuous clock change.

Since those happen at :01, and we round *up*, latency means that we mostly never actually reach :00, which is what NanoClock expects for a clock tick induced refresh.

And I stopped forcing a clock refresh during those events, because they're not clock ticks per se, they're just the clock being *set*, and they're mostly duplicates of actual events that *do* already refresh the clock (page turns in the reader, and an actual tick here).

EDIT: I'm testing moving our ticks to :02 to ensure we always lose that race and get an actual actionable tick on our end.