[ONE Original Android Development] Lanchon:
ok surprise!

well first, my system time on android and recovery are both correct, so i don't experience the bug. but ive seen this 1-hour bug on some phone or other... just cant remember where. anyway, recovery is set with my timezone without DST.

so, on both android and recovery i found out that the RTC (hwclock) is set to whatever. it seems that writes to the RTC are disabled here:

https://github.com/CyanogenMod/andr...11.0/arch/arm/mach-msm/board-8930-pmic.c#L300

and moreover that this is standard practice for these qualcomm chips.

so i thought that maybe system time was being fetch from the network on boot. but no: turn off phone. later boot straight into recovery, and system time is ok, and there is no network available.

so this must be it: the RTC is set to any time, but works (ie: advances one second per second, with the phone on or off). whenever the system time is set (eg: during sync with network time), the difference between the RTC and system time is recorded as a non-volatile property somewhere. this difference should be nearly constant, as both times, RTC and system time (which approximates UTC) advance at nearly the same real-time rate. on boot, either into android or recovery, this recorded value is read and added to RTC to initialize the system time. this way the RTC is never written to, and serves as a 'relative' time source (relative to the stored value).

my RTC has the value of 8 months and some after the unix epoch, and im guessing this means that the battery was put into place in my phone during its manufacturing 8 months ago. this particular RTC circuit seems to have a working power-on reset subsystem and it has been running from power-on ever since.

im also guessing that there is no lithium backup cell, so the RTC would reset if i ever discharged the main battery to the point where the lithium-ion protection circuit would cut the cell off (a thing that i never plan to do!).

so this value must be stored somewhere, but where? in /data? then if you boot recovery, factory reset, and reboot recovery, system time should be lost and set to something meaningless. could this be why recoveries mount /data on boot? or maybe it's stored on some small partition as loose bytes like some other settings.

whatever be the case, it's really silly that android is not also storing the timezone info in the same place, so that recoveries could read both values and always have the same times (UTC and local) as android.

now on the matter that brought us here: sometimes twrp has the wrong local time. but is it trwps fault? first, the non-volatile value could be anything: the difference between RTC and UTC, or RTC and local time. (lets hope it's UTC because otherwise the developers behind this should be fed to the lions.) assuming its UTC, android time could theoretically be off in the problematic cases in this way: local time set ok, net-time sync disabled, timezone off by one (maybe due to DST), and thus android UTC time off by one. in this case, twrp would correctly report the wrong local time based on the wrong UTC set by android. it'd appear to be a twrp bug, but it'd actually be misconfiguration of android (not even an android bug).

SO TO THOSE SUFFERING FROM THIS BUG:

first run 'date -u' on android and recovery (via adb shell), and note whether both times are ok.

they should match UTC, which you can find here. (please report your result.)

if android UTC is off, fix it and then twrp time should be fixed too.

to fix: on android, enable network time. after UTC sync, your local time should be off; this is expected. now select your proper timezone and DS settings, and you local time should be back to being right. now get into twrp and your local and UTC times should both be ok. if only UTC is ok, configure your recovery timezone settings correctly.

and please report.

---------- Post added at 04:09 AM ---------- Previous post was at 03:25 AM ----------

so a little bit of googling confirmed my suspicions.

this is the change to twrp, with explanation including where in /data the value is stored:

https://gerrit.omnirom.org/#/c/5327/6/twrp-functions.cpp

and yes, it mounts /data on boot.