Exactly how this happened remains unclear at this early stage
Actually I had an idea and posted this on the earlier article:
Officially it's been stated the clock was 11 hours out, this discounts the UTC - EST difference theory but not yours.
Perhaps it went like this:
After take off, the clock would have counted 36 minutes, i.e. 00:36 if written as a timer, but this was actually assumed to be "12:36" when written as an AM/PM clock or date time type that held timezone (which was subsequently ignored or somebody stupidly used a toString parser) as the value was taken from an onboard RTC, an API to retrieve the value used this value type (as opposed to the engineer using the epoch milliseconds calculation).
The onboard clock correction/precision/sync software was likely expecting 00:36 minutes but told when attempting to be sync'd with "hey my booster clock says it's been a little over 12 hours from launch, not 36 minutes", i.e. exact time correction cannot be applied as the difference is too great and the validity range was meant to be within 1 hour, or within the first hour of takeoff, thus any value 11 hours previous to the one given would have worked.
The 1 hour validity range is (IIRC) exactly how Microsoft's Windows NTP updates used to work, e.g. when correcting time from a default dead CMOS battery value it would fail due to significant difference.