Data offload not working (getting wrong time from strap) and reset not working for 4.0 (just adding straplogs)

[Kazo67-ai]

NOOP version

8.6.2

Platform

iOS

OS version

iOS 26.5

WHOOP strap model

WHOOP 4.0

Where the data is coming from

Live Bluetooth (strap connected)

Test Centre profile

Connection & Sync

What happens

My strap disconnected overnight, which in itself is no issue due to the syncing process in the morning. Long story short, I let it run the syncing, didn't do anything or at least I thought so, it was offloading a lot, then checked livelogs, and saw that NOOP didn't accept the data due to it being from 28k hours ahead.
Tried to reset via NOOP but didn't work (which was already mentioned but I read that strap logs might help so I'm just adding them here as well)

noop-strap-log-260712-1029.txt

What you expected instead

That the strap detects the correct time or the app maybe ignores timestamps from future and interprets them as a step by step from when it last connected

Steps to reproduce

1. Sleep and try to resync

Strap log

Before you submit

• I attached my exported NOOP .zip (not a screenshot of the Live screen). If my bug is a clearly reproducible UI issue I described exactly how to see it instead.
• I attached or pasted a strap log above — or my bug is a clearly reproducible UI issue that doesn't need one (e.g. a typo, a button that does nothing) and I've described exactly how to see it.
• I checked the Troubleshooting guide — especially "history syncs but no data" (most often the strap isn't banking history to flash; charge it to 100% and reconnect).
• I checked the FAQ and — if I'm on a WHOOP 5.0 / MG — the 5.0/MG status page, and this isn't an already-known limit (e.g. SpO₂, or recovery/sleep on the 5/MG).
• I've left out anything personal (strap serial, account email, raw export).

[ryanbr]

Thanks for the strap log — it pins this down clearly. Two separate things are going on:

Your strap's clock is set in the future. The log shows the live clock reading correctly (~2026), but the history banked in the strap's flash is dated 2028-2029, and the alarm reads back as year 2052. The strap's internal RTC has relatched to a future base, so every banked record is stamped ~3 years ahead. NOOP deliberately refuses to import those — if it trusted them, your dashboard would fill with sleep/recovery dated 2028 and "last night" would jump years into the future. So the refusal is correct; the data itself is the problem, not NOOP's decoding.

Why "reset" didn't help: NOOP has no command that can wipe a WHOOP's banked history or force its clock — it's a read-only, clean-room interop app, and erasing strap flash would be a destructive write it won't send. So there's nothing in-app that can clear the future-dated backlog.

What actually helps: the RTC relatches on a full power-cycle. Charge the strap to 100%, take it off the charger, and let it re-pair — that's the most reliable way to get its clock back to real time so it starts banking correctly-dated records again. If a charge cycle doesn't do it, a reset from the official WHOOP app (which CAN clear flash) is the fallback.

Honest caveat: the overnight data already banked with the future date is not recoverable through NOOP — it stays refused. This is about getting the strap healthy again going forward, not rescuing that specific night.

#332 makes this legible: instead of a silent "synced" or a misleading "strap went quiet", NOOP will now tell you plainly when the strap clock is set in the future and point at the charge/power-cycle remedy, and a future strap-log will show exactly which RTC event reset the clock and how far ahead the banked range sits. A follow-up to let NOOP drain-and-discard a fully future-dated backlog automatically (so recovery needs fewer manual steps) is planned separately.