That’s right. It’s empty. The purpose of the file is only to show the time of the last sync. (I am unclear on whether it’s the time that was derived from the last sync or the time at which that last sync occurred - but there should be negligible difference between those times.)
On my system, the time syncs every 2048 seconds (that’s the default), so the time on that file jumps forward about 34 minutes at a time, about every 34 minutes. That’s probably over the top for my purposes - don’t need it highly accurate and system clock is not so inaccurate.
Which presumably means that you shut the computer down the day before.
According to the man page … if time synch was not possible then the file shows the date of the systemd build i.e. it would be the same on each boot if time synch was never possible (e.g. airgapped network with no local NTP server or airgapped computer) but the date would settle on a new fixed starting date after upgrading systemd (but again such an upgrade might never happen in a truly airgapped environment).
that would be a highly accurate assumption indeed that is when i manually enabled the sync to happen from the GUI then disabled it again (i don’t need mine to sync daily just when i want to check if noticeable differences happen)
btw my electronic hand-watch is a few minutes ahead of my ntp-synced system-clock that’s probably why i’m a few minutes early everytime
on my Librem-Mini-v1/PureOS-9-Amber(Stable)/GNOME when completely disconnected from the power-source and then after a few hours of complete power-starvation when powered-ON again i find the time-clock reset to > nov 06, 2020 @ 03:00 morning-time (i believe this would be AM for American convention)
that ofc is not a major issue for me since i can update-manually the time-server when online from the www but for people that do NOT have internet available on demand it might be somewhat problematic if you don’t have another accurate-time device to manually set the values into the GNOME settings GUI
I don’t know. It’s still not working the way I would expect. It is still working the way the documentation suggests that it can under certain assumptions that various things aren’t working properly (since there are multiple fallbacks to maintain the correct time before reverting to a build date).
It was confirmed here that the Librem Mini v2 has an RTC with button cell.
Do you want to open yours up and see whether you can see a button cell? I would carefully extract the battery and check the orientation (polarity) of the battery. If you have a multimeter, I would also check the voltage on the battery.
i don’t want to … but when i get my v2 and i open it up i’ll do the same thing to the v1
is it the upper side or the bottom side (with the SOC) that i need to inspect ?
No idea where the button cell is. If noone else jumps in with the answer, I suggest you ask Purism. After all, eventually the battery goes flat and every customer will have to replace the button cell.
i have a hard time believing that Purism would ship my v1 with a dead battery … it’s only been a few months since july and a CR2032 (what it usually is on most desktop-motherboards) lasts longer than 6 months (let’s say it was last checked in june)
urgh ! i’d rather not mess with it in such a cramped chassis. i don’t mind getting ‘dirty’ in a standard mITX or larger desktop case but the NUC is so tight … oh well, i guess i’ll see when i get the v2
indeed that is when i manually enabled the sync to happen from the GUI then disabled it again (i don’t need mine to sync daily just when i want to check if noticeable differences happen)
that’s probably why i’m a few minutes early everytime 