I’ve talked with people outside the forum, turns out yes this actually correct. I’m used to Chrony’s behavior when dealing with NTP, so I apologize for my inaccuracy on knowing how NTP services work.
However, I have set my Framework into similar conditions described above that should trigger the issue, and I haven’t experienced them, additionally there’s so much sheer misinformation, overreaction, and whining I can’t help but respond.
Not sure what this is supposed to mean. Could you enlighten us?
No problem at all, super cool for you to reply with this! I really appreciate it. I was just as shocked as you when I experienced it because I have never seen this before. I too thought NTP would save me as it has on every other machine I’ve ever used. Framework was the first time I even learned there was such a NTP tolerance in Windows because the sync time not working was driving me crazy! Turns out, those CMOS batteries lasting for years and years were keeping system time all along. When they fail in other platforms, swapping the battery is truly no big deal because it buys so many more years of usage. Reminds me of the first time I had to replace battery in a Casio watch (after 12 years of service)!
You weren’t able to trigger the issue where it won’t boot without connecting to AC? Or you weren’t able to get it to go into the dead-CPU state where it requires the reboot? My understanding is as my above post - it should be easy for anyone to get into the #1 state where the main battery is juiced but the framework won’t boot because RTC is dead. This state might be fixed quickly (plug in AC and wait a few minutes for RTC to charge) or it might trigger #2 (harder to recover).
I very much understand this. I think this is likely a passionate community. I think that’s what got framework so much attention out the gate. For me personally, I am loud and obnoxious but I’m also fair about it. I cheer just as loudly when I think Framework does something great - I tell different groups of friends and coworkers about the good just as well as the bad. I expect several visiting this thread or forum may be similar ¯_(ツ)_/¯
I wasn’t able to trigger the issue at all, perhaps I got lucky and my RTC battery was completely topped off before the system was shut down, or the CPU never got into a bad state and Chrony recovered the time just fine before I noticed, not sure. After all, this problem is caused by a mistake on Intel’s side and an oversight Framework made due to not knowing about the Intel issue. 12th gen boards allow the battery to actively supply the RTC chip with power and has an automatic reset function. Combined with other changes, it should outright circumvent any issue experienced from RTC dying other than time resetting.
I hope that’s true. It’s not completely clear from @nrp post:
It does confirm the RTC power consumption is lowered that should extend the idle time - which is great. I’m not sure what “designed in a path” means with regards to the charging. I’d love to know more about this. It seems they have maybe planned for it but haven’t figured out how to implement it? Definitely seems like an improvement for sure.
I’m optimistic about the 12th Gen revisions. My big concern as someone who ordered an 11th Gen in July and received it in October and only has a half dozen hours of total use is - where does that leave me? There is no fix for 11th Gen users or any trade in process. I need the idle time to be as long as possible for my use case as I am using this computer specifically for field. I have tried to engage support on this and offered to pay for a trade up also but they just stopped replying to my ticket mid last week.
This is the most concerning piece of it all that can really infuriate us super loyal and passionate framework fans - nrp points to support, support just ignores 
This most likely means “We’ve designed an electrical path so the main battery can directly charge the RTC battery”, a physical electrical fix.
Admittedly I’m not sure if it’ll be charged during poweroff or just when the system is alive. Considering the hardware and firmware poweroff drain fixes coming in the future, I hope it’s the former.
Yep maybe you needed longer idle but hey, I’m super happy for you honestly. Possibly this issue just won’t effect you at all and that’s great. Be happy and don’t go looking for things to be upset about.
For me, I have a work issued MacBook and a gaming desktop so Framework is a 3rd machine that I only get to use for certain hobbies and vacations and so my time between uses is spread.
That makes sense. Maybe an electrical path that needs some logic / firmware on when to “wake up” the main battery to charge the RTC battery (when it gets too low). I was thinking of path more like “a series of steps or directions we need to take but we haven’t traveled down it yet”
I’m not lol, it’s mainly other people trying to find things to be upset about that upsets me.
Sometimes electrical circuits are described as “paths”, like how you would walk a path to say, a convenience store, electricity would go through a path to where it needs to go.
To clarify my post to @Tai_Kahn and to reply to @Shiroudan’s comment about it, I am not looking to take advantage of anyone’s situation. In the case of @Tai_Kahn, if the return period still applies, it would appear to be the path of choice. If not, and the poster is frustrated with trying to achieve a resolution, I am curious as to the price for which the machine would be sold.
There are several reasons behind this:
So, @Tai_Kahn, my questions stand, they were not intended to be snarky, I have no hidden agenda, and I am sorry that you are so frustrated, I wouldn’t wish that on anyone. If you are interested in selling, please reach out either here or via a direct message.
Be well, all.
PM sent 
…
What is preventing you from just … buying a ML2032, say (because it’s beefy) and connecting it to the board. It’s attached via wires through to a connector. Right?
Physical constraints
ok. so not enough room. What’s the most room (a.k.a.) battery that can fit inside?
(yeah I should really get myself one immediately)
ML1220, nothing larger will fit.
that’s actually quite tiny. Although I think my previous Dell also use that (and have displayed absolutely no issues)
Maybe battery supplier issues?
(You would think that’s more prominent, since if it is a design flaw this issue would have surfaced immediately after launch, not a few months after)
Issues lie with Intel and oversights on Framework’s side that they could not predict.
@d_p my framework is my personal laptop and I use my work laptop much more frequently – usually only running the framework when I take it somewhere on weekends, etc. It’s running Manjaro Linux (with sometimes Windows 11 in VirtualBox but then I always feel dirty!). It’s a Batch 3 i7-1165.
I’m certain I haven’t run my Framework in 4 weeks (because I haven’t used it since I was sick with Covid) and I just powered it up. It hasn’t been plugged in since the time I used it before the last time I used it. Main battery is @ 62% and it started up without any drama. I didn’t notice any problem with the time – although it might’ve reset the time automatically already if it was out. But I definitely didn’t need to open it up to turn it on.
I do feel bad for those of you that are having a serious problem and I really do wish you luck sorting it out with Framework. In my experience they really are interested in making things right so hopefully this is just snafu on the support/communication and you’ll get the attention you need soon.
Do you recall whether you had to plug in the USB-C/PD to power it on after not using it for weeks? i.e. Assuming the laptop was completely unplugged all this time.
Not having to open it up means one thing: You didn’t run into the Intel silicon bug…that time.
Hey @Richard_Lees, that’s great! Just like @Second_Coming said, I have to plug into AC even if mine is at 60%+ internal battery and because Windows is my native OS, the clock must be set manually.