[jirogit]

Adds FAQ 6.9 with recovery steps for a companion whose clock is stuck in
the future (contacts stamped with a future date restore the clock on every
boot, and the app can only move it forward). Also links to it from the
6.1/6.2 answer.

Recovery steps verified on a Heltec Mesh Node T1 (companion BLE).

Related firmware fix: #3534

[LitBomb]

are you confident the FAQ you added is the correct fix? I haven't seen this problem myself. I use Liam's MeshCore app on iPhone and on Windows. I never need to worry if the companion's time is correct or not. The app does all the work. Does this happen on all radio hardware?

If it is indeed a bug and your matching firmware fix #3534 fixes it, we would not need this FAQ.

[jirogit]

Thanks, fair question.

Some context:

Not all hardware. I've only confirmed this on a Heltec T1. On v1.17.1, the onboard IMU (ICM-42607-P at 0x68) was misdetected as a DS3231, which corrupted the clock. #3301 fixes that root cause, but it isn't in v1.17.1.

Why the app can't fix it: the corrupted clock drifts to a far-future date at irregular steps (it reached 2095 in my case, so others will likely see a different year).

Contacts touched during that time get a far-future lastmod. On every boot, bootstrapRTCfromContacts() restores the clock from the max lastmod.

CMD_SET_DEVICE_TIME only moves the clock forward, so app sync can't pull it back. In normal cases you're right, the app handles time.

#3534 ignores lastmod values at or beyond Jan 1 of (build year + 4) at boot, so the clock itself recovers in the far-future case.

What #3534 doesn't clean up:

Smaller jumps. I've seen fairly random years, so a jump of only a few years ahead is possible. That stays below the #3534 threshold and is still restored at boot.
Leftover future-dated entries. Contacts and discovered nodes with far-future timestamps stay in the lists and sort to the top. Discovered nodes don't feed the clock restore, so they're cosmetic only. A few are harmless, but with many of them the list is hard to use until they're deleted.

The receiving side. Other nodes that got a far-future advert keep dropping this node's later adverts as replays (observed on one node). The contact has to be deleted on that side.

Older firmware. Users without #3301/#3534 still need the manual steps.

So I'd suggest keeping the FAQ, reframed as cleanup rather than a workaround. I'll update it to mention that the year varies and that discovered nodes are cosmetic only. The note about newer firmware ignoring far-future dates belongs with #3534, so I'll add that doc change there so the two land together.

If you'd still rather not have this FAQ, I'm fine closing it.