FP Open OS: Clock resets after reboot

You know you can manually set the date and time too right?


This will not help with your Fairphone issue but maybe you can at least repair your mis-tagged pictures:

I once had a camera that was off by 2h03m16s. With this command I could adjust the time of all images from this camera (this was tested under linux … with exiftool installed of course):

exiftool -P -alldates+='0:0:0 2:3:16' -filemodifydate+='0:0:0 2:3:16' -filecreatedate+='0:0:0 2:3:16' *.JPG

You could do the same or something similar, just use a much larger offset.


Thank you @gewuerzketchup, this command worked great on the photos :slight_smile:

Hi Paul,
do you know the status of fixing this bug? How can I help testing bugfixes or discovering the reason of the bug?

Sorry, I’m no developer, so I have no idea.

Just to let you know: I am another user who has this annoying bug. Clock back in the 70ties after each reboot.
I just did a backup of my phone with TWRP and the backup date was epiphany 1970. So it looks to me as if FP Open OS is not updating the built in RTC at all.
AND: Time gets only synced when either WiFi or mobile data is enabled. Usually a phone can sync its clock with a mobile network without data connection - this doesn’t.

I think mine synced fine with cellular network active but no WiFi nor mobile data (I don’t have a data plan)

1 Like

I agree. I was in Yosemite national park and had no WiFi, mobile data or even a network and the clock was always in 1970.

I looked a bit into this on my rooted phone:
Node permissions for /dev/rtc0 seem to be ok.
The RTC is running, but time cannot be set:
hwclock -w throws a “RTC_SET_TIME: Invalid argument” at me instead of setting the hardware clock.
The RTC time and date count “up” - today, after the phone was off over night, we have the 7th. of January instead of the 6th.
Searching the internet with Startpage and search term “Android RTC_SET_TIME: Invalid argument” shows up this interesting article: http://www.96boards.org/forums/topic/cant-set-rtc-time-on-dragon-board/
and I quote:

The way this is implemented in the codeaurora AOSP builds is that the RTC is kept read-only…

I know, we are not running “codeaurora” here, but my suspicion is a crappy kernel build with RTC write access not enabled.
This is probably bad news for those who want a workaround as we are at the mercy of the dev-team to fix this.


FP Open OS (and probably FP OS too) is indeed based on CodeAurora AOSP sources, :wink:. These are the official Qualcomm repos for OEMs with Android sources optimized and preconfigured for Qualcomm boards.

So, thanks to your useful link we now know that writing with hwclock doesn’t have to work on any Snapdragon board, and the bug is localized in the Android’s userspace service that should keep track of the delta between RTC and network time, :wink:


That leaves the obvious answer: When will we get a fix ? I am still waiting for version 16.07 - now probably 16.08. It looks to me as if they released the 1.5.1 FP OS, dropped the hammer and went on holiday.

Here’s a another clock-bug-victim. It’s one of those many really annoying bugs on my FP2 with latest OSOS.

And I’ve just made another observation:

Just having a mobile data connection isn’t enough to get the clock set after reboot. I really need to find a WIFI-Hotspot to connect - and (most interesting) it doesn’t matter if that WIFI-spot has internet connection or not.

So I made this WIFI-AP based on a raspberry pi with no realtime clock or internet connection or anything (basically with random time set), but connecting to that AP is enough to get correct time on my FP2. This is beyond logic…

edit: Another observation:

When using a captive-portal WIFI I wasn’t able to get time set at all. But it was in a foreign country with data roaming disabled so that might be linked somehow.

Once a mobile connection is established it can take a long time until the clock is updated. In the case of Wifi this happens faster. You can speed it up if you go to setup date/time-auto date/time and disable + enable again this setting. Then the clock will usually be updated immediately.


i have the same reboot date problem - travel in the past for free but i can not use the FP2 like that

Looking for a solution

Now with 16.07 being released without this being fixed can we have an update when this will be sorted ? And maybe a suggestion to the devs: I cannot see any purpose in keeping the RTC read only other than avoiding it ticking over before the 19th. January 2038 (the end of the Unix epoch). If this cannot be fixed in the system because its complicated, could you then please just rtc_write_enable=true in the next version - this will give even programs like TWRP that boot independently from the main system the proper time ?
Thanks a lot.


Hi. Interesting fact: my clock doesn’t reset to January 1st 1970 every time but the day changes everyday; January 2nd 1970 the second day after installation, then January 3rd 1970 the third day. I’ve only had my phone three days now, so I don’t know if it goes on… Never took the battery out since the installation though, wonder if it would start all over again!

It goes on. Even if you take the battery out. Regard from. The 18th January 1970!

Let’s hope this bug is fixed before the '80s! :smiley:


First reboot during the night! Result: as I haven’t heard my phone reboot and as I haven’t unlocked the sim card, the alarm clock did not ring… I don’t have many reboots, but this one was at a bad timing!
I will try not to set the time and date automatically for a while.


Same issue here! As I’m for working reasons sometimes in areas without wifi or network coverage I also experienced the alarm clock not working due to the clock reset after reboot. Disabling the automatic time settings didn’t worked for me, as the time was after reboot again in 1970 though I set the time manually before. Did I do something wrong? Is there a way to keep a manual set time after reboot?
And is it really true that, after I switch off my phone for the night a set alarm clock won’t wake me up (like FP1 did flawless)? Due to the mentioned reasons above I HAVE to save battery, so switching the phone of makes sense to me, but waking up on time for a job would also be more than helpful! :slight_smile: