Automatically update time does not work if time is manually set ahead of the real time

[Sam Bull]

Upon another crash which caused my phone to set the time back to 1970, I selected the update automatically option and nothing happened, the time remained in 1970. I then set the time manually, but deliberately set it several minutes ahead before setting it back to automatically, so I could test if it would set the time later on. After several weeks, the time is still several minutes ahead, so clearly hasn't been updated.

Seems this works correctly when the time is behind the current time, but fails to do anything when the time is ahead.

To reproduce:
 - Set time manually a few minutes behind.
 - Select automatic time and observe that the time is corrected.
 - Set time manually a few minutes ahead.
 - Select automatic time and observe that the time is not corrected.

[Pat McGowan (pat-mcgowan)]

Sounds like bug #1390120

What version are you running? Next update should address this

[Sebastien Bacher (seb128)]

What device and OS channel are you using?

[Sam Bull (dreamsorcerer)]

Mako, r19, current stable release. I noticed the behaviour of the other bug also, and thought it might be related. So, I'll update the bug after the next update, to confirm if that has fixed the problem or not.

[Sam Bull (dreamsorcerer)]

So, the "duplicate" bug has been fixed, so if I set it to manual, the setting persists. Regardless, the phone still does not sync the time at any point, as per this bug description. My time is still several minutes fast and hasn't been updated. Since the OTA-4 upgrade, I have rebooted the phone a couple of times and left it running for a couple of days, switched the setting between manual and automatic, nothing has caused it to sync.

[Sebastien Bacher (seb128)]

sync is supposed to happen when connecting to e.g a wifi when the setting is set to automatic. did you do that?

[Sam Bull (dreamsorcerer)]

I don't use WiFi most of the time. Updating the description.

[Sebastien Bacher (seb128)]

does it work/update if/when you connect to a wifi then?

[Sam Bull (dreamsorcerer)]

Tried it this morning, and it does. But, because I use WiFi so infrequently, I have gone months thinking that this was not working at all.

[Pat McGowan (pat-mcgowan)]

This worked for me on the current rc-proposed image
Disable wifi
Manually set time
Set back to automatic
Time was reset within 10 secs

[Sam Bull (dreamsorcerer)]

It doesn't do that for me on stable. So, maybe changed recently? Will be in OTA-5 perhaps?

[Pat McGowan (pat-mcgowan)]

An important detail:

An automatic update always fail if the current system time is *ahead* of the actual time by more 18h, otherwise, automatic update works. This is by design.

But several mins is working here, although I dont see a relevant change

[Sam Bull (dreamsorcerer)]

Nope, updated to OTA-5, still not working. Time is 5-6 mins ahead, and won't update automatically on a mobile network, even after switching the setting to manual and back again.

[Pat McGowan (pat-mcgowan)]

I was able to get the phone in a state where the time did not update because the phone was in an inconsistent state with regard to cellular data status. The indicator did not show a data connection but the pulldown did. Whenever the network indicator shows the data connection, the time was properly set on automatic.

This seems related to bug #1470900

[Sam Bull (dreamsorcerer)]

I played with it some more, and am not seeing it working at all. I have mobile data enable all the time, and WiFi disabled all the time.

This is on a Nexus 4 (mako) if that makes any difference.

[Sam Bull (dreamsorcerer)]

OK, a little more experimenting. Setting the time behind a few minutes works as expected. Setting the time ahead a few minutes will not update the time automatically.

[TarotChen (tarotchen)]

looks like https://bugs.launchpad.net/tangxi/+bug/1462228

[TarotChen (tarotchen)]

Automatically update doesn't work if time is manually set more than 18hrs ahead of the real time.

[Sam Bull (dreamsorcerer)]

This bug was reproducible when only set a few minutes ahead. I've just retested (on OTA-7), and it is now working as expected. I think the >18 hours was mentioned before as a deliberate design. So, this bug is fixed; if you disagree with the >18 hours thing, that should be reported in a new bug.