Hi, when I restart Librem 14 with PureOS, system time is set to 2070-01-01. It also happens when the Librem 14 is put to sleep and wakes up. Today is February 29, could it be related to this special day?
1 Like
Are you sure it’s set at 2070 and not 1970? It turns out that 1970-01-01 00:00:00 UTC is the 0-time. What is Unix time?
Unix time is a way of representing a timestamp by representing the time as the number of seconds since January 1st, 1970 at 00:00:00 UTC. One of the primary benefits of using Unix time is that it can be represented as an integer making it easier to parse and use across different systems.
January 1st, 1970 at 00:00:00 UTC is referred to as the Unix epoch.
What has likely happened is that your CMOS battery has come unseated or has died.
2 Likes
Yes, it is 2070. Also when battery is at 0% it resets to 2070. Some months ago it reset to 1970, I suppose Purism changed the default value in firmware / EC driver from 1970 to 2070 because it is not possible to boot OS with 1970 timestamp due to failed signature checks in Pureboot or somewhere. At that time when the default was 1970 I had to use date -s "<some near date>" and hwclock -w to fix boot.
2 Likes
Indeed, I just tried to manually change system time to 2024-03-01 (tomorrow) and it recovered from sleep with the correct date and time 2024-03-01. So the problem is related to February 29 which is a leap day. February 29 - Wikipedia
2 Likes
Yes, this is a bug because of the leap year. It is a bug in coreboot since 2021. We are working on a fix.
3 Likes
I don’t think there is CMOS battery in Librem 14. Real flossers wear power cords around their shoulder.
1 Like
That was a strange coreboot leap year issue!!!
[ I’m pretty sure you were joking, but of course there is a CMOS battery in the Librem14. Someone is pointing it out here: Librem 14 Battery-Related Time and Date Reset Issue - Seeking Help and Solutions - #2 by gondolyr ]
2 Likes
Only after the initial batch(es).
1 Like
Hi Joao! I just have a couple of questions about this issue if you happen to have the information on-hand.
I ran into this bug today and my clock was reset to midnight at the beginning of the 27th UTC. On the QubesOS forum, someone pointed to this issue as the underlying cause on coreboot.
The commit message there states that the clock will be reverted to the build date, but the last time I installed pureboot was well before the 27th. So maybe the commit message is only correct in some subset of cases, or maybe the bug exhibits itself differently in pureboot due to code changes. Or maybe it’s just a different problem in pureboot and a different fix is needed. Is there any additional context around this issue that you can share?
Thanks!
1 Like
Hi, this issue should solve itself after 00h00. If after that time you set the date for march 01. And what you reported can happen.
2 Likes
WOW 
your L14 is a Time Machine too!!
Cool
1 Like
The Millennium bug is early this time 
1 Like
Just for clarification, does the L15/v4 have a backup battery for the CMOS? I thought it did not and that the chip was being kept alive from the main battery. I am not sure, now. Can someone answer this question?
1 Like
I would be extremely surprised if the L15v4 didn’t have a CMOS battery.
I don’t have one and there seems to be no internals documentation available, but here is a pic of the L15v2 prototype with a CMOS battery visible: Purism Librem 15 rev2 Prototype Certification Results – Purism .
2 Likes
Thank you!
Yes, the MBD picture clearly shows the backup battery.
I’ll check my v4 version next time I need to open the case.
1 Like
On my L5 I previously installed timedatectl to set date time timezone and sync with ntp server.
Maybe I missed something but I did not notice a date issue in Feb.
1 Like
This is a Coreboot issue - and hence does not apply on the Librem 5.
2 Likes