Customer provided logs for this issue. They can be found at (google.com sign in required) https://drive.google.com/drive/folders/0BzWUz38-X_A9M2hJR2xZeHZyV1U?usp=sharing 
-The issue happened 10:40-50am on the 27th of
April.
-Screenshots are from an old event, not the one on the 27th.
-Customer reports it was replicated on multiple devices, Chromebook 7010, HP Chromebook G1, Samsung Plus. This log comes from a HP Chromebook 13 G1 (Chell).
-I tried to replicate on my end using a Samsung Chromebook (Snow) and a 	
LG Chromebase 22CV241 on 58.0.3029.89, but I was not able to repruduce the problem.
-Will a Chromebook relied on a "CMOS" battery to keep the time?
-I have requested the logs from other unit, but I am adding this information intially, as the bug has already been created.

I can reproduce issue with time change on HP Chromebook 13 G1 on 58.
On the first boot after full battery discharge, time jumps from 6:35pm to 5pm on the next boot, but once WiFi connection established time has been auto corrected:
https://drive.google.com/a/google.com/file/d/0By9xEkAUmm_cTk9TeldVeVVybTA/view?usp=sharing

bhthompson@ - Could you please help to triage this issue?  

Hello, 

Our time is not updated automatically as ChromeOS used another protocol than NTP not authorized. 
This is why our user has to do it manually. 

As our Chromebook in Air Liquide is used by a lot of VIP/Executive, travelling often and working until the battery died, it is highly visible. 

The consequence is that is the time/Date is not the correct one, they can't access to the wifi. 

Do you know when it will be fixed?  

+power experts

I believe this may be expected behavior in modern Chrome OS systems which rely on the main battery to keep the RTC alive. In some of the earlier systems there was a separate RTC coin cell battery that would keep it going (IIRC snow and the chrome base have a coin cell), but this would cause other problems (e.g. coin cells eventually die and cause the clock to be off on every reset). 

Maybe a potential work around would be to have the device shut down earlier, at a higher battery %, such that the RTC can keep alive longer when the battery is 'dead'?

I can't say to my exec of a big company that they need to shutdown they
device when they got 1% left...

Agreed, what I mean is that we can adjust how the power manager behaves to shut down an extra % or two earlier. The down side is that the user would loose that last few minutes of run time, but it may buy a few days/weeks for the RTC.

I am not certain if this is a valid solution though, I am hoping Dan or Todd may have insight here, and perhaps a better idea.

Hey, good idea! If you can cheat the system to always have 1% of the
battery left and shutdown the system... You should recalculate the timeleft
to take into account the 1% left...

Assessment in #c7 is correct.

We do reserve a small percentage of main battery for RTC maintenance purposes.

For chell,

low_battery_shutdown_percent = 3
This will shutdown device cleanly providing its in active mode when threshold is crossed.

If device is suspended, the EC will shutdown the device uncleanly via,
#define BATTERY_LEVEL_SHUTDOWN                  3

So 3% of the battery should remain to support RTC function.

So data from #c6 indicates that the RTC loss accord over this period,

from eventlog:
247 | 2017-04-26 18:55:08 | ACPI Enter | S3
from #c7:
happened 10:40-50am on the 27th of April.

Or ~16hrs (19:00 -> 11:00)

I'd expect 3% of battery to support longer than that under expected powered-off consumption.

In addition it seems strange that eventlog RTC recovery is significantly back in time. (4/26 -> 4/10)

247 | 2017-04-26 18:55:08 | ACPI Enter | S3
248 | 2000-00-00 00:00:00 | System boot | 1
249 | 2000-00-00 00:00:00 | Power Fail
250 | 2000-00-00 00:00:00 | SUS Power Fail
251 | 2000-00-00 00:00:00 | RTC Reset
252 | 2000-00-00 00:00:00 | System Reset
253 | 2000-00-00 00:00:00 | ACPI Wake | S5
254 | 2000-00-00 00:00:00 | Wake Source | Power Button | 0
255 | 2000-00-00 00:00:00 | Log area cleared | 1029
256 | 2000-00-00 00:00:00 | EC Event | Lid Open
257 | 2017-04-10 10:06:49 | Kernel Event | Clean Shutdown
...
277 | 2017-04-10 10:39:15 | EC Event | Power Button

and remains that way for ~33min.  Perhaps chicken & egg w/ cert getting access to the network?

Guess I would have thought we could periodically write the value to nvram somewhere such that it would have been much closer to 2017-04-26 18:55:08

Finally this is easily reproducible by performing battery cutoff on machine.

How can we implement the fix? Is it a patch/setting that we can implement
via Google Console?

Or you write a setting that will apply on all devices that will be good on
rtc system

I should have also pointed out that tlsdate looks particularly unhappy throughout the log

./tlsdate.log.1:2017-04-10T10:14:43.476165+02:00 NOTICE tlsdate[2566]: [event:action_tlsdate_timeout] tlsdate timed out
<repeated every 30-40secs>
./tlsdate.log.1:2017-04-10T10:33:53.262995+02:00 NOTICE tlsdate[2497]: [event:action_tlsdate_timeout] tlsdate timed out

Is tlsdate just failing due to the network being missing, or is this having some trouble talking to the RTC?

Per the event log it seems like we go to S3 suspend, then the battery dies at which point we loose the RTC. Does this mean our 3% shut down does not work in the S3 case (powerd is not alive to check)? 

In such a case we would need the EC to do something about this perhaps?

Sorry, rereading comment 11, the EC does do something about it, but something still goes wrong. I guess either the 3% is not sufficient, or the act of the EC pulling the plug on the AP is somehow tripping up the RTC?

For the Chell case it looks like the RTC is in the SKL SoC here, but the EC and the PMIC both potentially have control over keeping it alive, I guess we would need an instrumented board to be sure. Comment 2 suggests this may happen on many systems though, so we seem to have a more general problem.

It seems like it was suspended just overnight, though we don't know exactly when the RTC died, it died in under 15 hours, which seems short for a real 3%.

Assuming the original time was ok, and the user set time was accurate:
2017-04-27T10:41:00.000364+02:00 INFO tlsdated[2465]: [event:handle_time_setter] time set from the platform-feature (1493282460)

Hello, 

Do you have an update about the fix? 

Given this happens on multiple systems, I am not sure a simple 'add 1% more battery to shut down early' would necessarily help here. 

Also note that there is eventually nothing we can do, if the user leaves the device without power for a long enough time (e.g. if they let the battery die and let it sit for a week, it will probably always do this), so we don't have a solution for a reliable permanent fix.

Sameer, is this something that would fall under your team's jurisdiction? I am not sure exactly where to route this sort of thing.

I will look at this.

The 3% battery cut off should last about 5 days. So I will look just why it seems to be dying overnight.

Are the EC & powerd thresholds based off of design charge or last charge?

Hey guys, 

any news about the fix? 

It is getting complicated here and put at risk our chromeos deployement in my WW compagny... 

https://chromium-review.googlesource.com/c/514982/ should help lessen the occurrences but as mentioned in #comment17.  Its only in M-60 (Dev) however.

Next steps:
1. Request CL:514982 merge to beta M-59 ( https://chromium-review.googlesource.com/c/525932 )
2. Examine current power consumption in S3 & S5 @ low battery to make sure RTC maintenance time seen by user matches expectations
3. Examine if there's a means to recover more gracefully once RTC is lost as pointed out earlier its unavoidable. 
- #comment6, mentions CrOS don't use NTP.  I believe CrOS updates RTC using tlsdate via (tlsdated).  
  - Is there any way to address customer's security concerns here to properly enable use of tlsdate?
  - Could there be some type of fallback to NTP or another date service that does meet customer security requirements?
- #comment11, has details of non-network recovery time (  2017-04-10 10:06:49 ).  
  - Where does this come from?  I'd heard mentioned known secure things like kernel version string ('uname -a') but I can't locate 2017-04-10 in logs at least to confirm its origin.
  - How close to real time do we need this to make certificate valid and can we implement something that meets that?  For example we're talking to update server quite a bit could we trust 'date' from there and save it in a non-volatile location to more accurately recover RTC.

I'll finish w/ 1&2 and puthik@ will hopefully have some cycles later this week to explore 3 from Google side.

This bug requires manual review: Request affecting a post-stable build
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), gkihumba@(ChromeOS), Abdul Syed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

> - How close to real time do we need this to make certificate valid and
> can we implement something that meets that?  For example we're talking
> to update server quite a bit could we trust 'date' from there and save
> it in a non-volatile location to more accurately recover RTC."

I think that we've talked about (and maybe use) the build timestamp as a fallback for new devices that may have dead batteries when they're first booted, but I'm not sure that we do anything similar for systems after they've been booted.

Could we make tlsdated (or some other process) write the network-supplied time to the stateful partition whenever it's received and then use that as a lower bound at boot? I don't know enough about 802.1x to know how close the actual time the clock needs to be, but maybe this would help in the battery-runs-down-to-zero case. Or do we already do something like this?

Hmmm good question, I don't know if tlsdated is doing that, I thought it did but maybe I'm wrong.

I found /var/cache/tlsdate/timestamp

I think tlsdate already cache the current timestamp in the disk

Yeah that's what I thought.

Okay. Any guesses about why it doesn't seem to be helping here?

Maybe we should also write the current time to disk on shutdown and suspend in case the system has been up for a while since the last sync.

At least for the current failure customer can't support access to network time via tlsdate (#comment6).

So is there a fallback to writing a similar value based off the manual setting of date by user?

@Airliquide, could you provide more detail with respect to concerns w/ tlsdate support?

The Chrome OS tlsdated installation just makes HTTPS connections to clients3.google.com (per src/third_party/chromiumos-overlay/net-misc/tlsdate/files/tlsdated.conf).

> So is there a fallback to writing a similar value based off the manual setting of date by user?
Probably no.

I propose that we should write the current time to disk when
1. tlsdate get the current time from server
2. a day pass since last write
3. system is going to suspend
4. system is going to shutdown
5. user manually set date and time

This should make sure that tlsdate can get relatively correct time when it can't connect to network

Hey guys, 

Do you have any news? 

Thanks for the ping.

Todd, are you still planning to commit https://chromium-review.googlesource.com/c/525932 to update the shutdown percent in M59?

Opal, can you make the changes proposed in #31? I can take a look if you don't have cycles to do it soon.

Will look at this tomorrow

+TPM for m59 merge grant

Found the root cause.

We already write time to disk when
- Get time from network
- 24 hours since last write
- Before shutdown
- At boot

But all of above will only happen when the source of time is from network. As mention in #6, customer network block tlsdate protocol, so the time is never sync to disk as the time source is never from network.

I upload http://crrev.com/c/544631 to allow manually-set time source.


This matches proposal in #31 except "system is going to suspend" part, but looking at it again, I think that is not necessary because less than 24 hours
drift probably won't cause the 802.1x cert invalid and this will affect suspend time performance

I still don't understand why/how tlsdate connections are blocked. Per #30, I thought it just uses an HTTPS connection to a google.com hostname. Is that really getting blocked?

I second Dan's question. Is this getting blocked because of VPN issues or something? Chrome OS is not very useful if you cannot reach Google.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/board-overlays/+/901c25941d658fd10b80ac4dc112a2b3f0906015

commit 901c25941d658fd10b80ac4dc112a2b3f0906015
Author: Todd Broch <tbroch@chromium.org>
Date: Thu Jun 22 23:40:42 2017

cave/caroline/chell: Increase powerd low battery shutdown to 4%

These boards all have EC low battery shutdown at 3% via battery.h
BATTERY_LEVEL_SHUTDOWN.  Increase powerd's shutdown to 4% to provide a
buffer to avoid race between EC & powerd which if won by EC would
perform an unclean shutdown.

BUG= chromium:708177 
TEST=manual,
1. emerge bsp
2. cat /build/<board>/usr/share/power_manager/board_specific/low_battery_shutdown_percent
4.0

Change-Id: I7bd99675257ca36953f7c47b7af4f61d120af6ff
Reviewed-on: https://chromium-review.googlesource.com/514982
Commit-Ready: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Reviewed-by: Puthikorn Voravootivat <puthik@chromium.org>
(cherry picked from commit 9e6ec7b25b43d5985ca4d7ee64df7ee7cd8cabc4)
Reviewed-on: https://chromium-review.googlesource.com/525932
Reviewed-by: Dan Erat <derat@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>

[modify] https://crrev.com/901c25941d658fd10b80ac4dc112a2b3f0906015/overlay-chell/chromeos-base/chromeos-bsp-chell/files/powerd_prefs/low_battery_shutdown_percent
[rename] https://crrev.com/901c25941d658fd10b80ac4dc112a2b3f0906015/overlay-chell/chromeos-base/chromeos-bsp-chell/chromeos-bsp-chell-0.0.1-r19.ebuild
[modify] https://crrev.com/901c25941d658fd10b80ac4dc112a2b3f0906015/overlay-caroline/chromeos-base/chromeos-bsp-caroline/files/powerd_prefs/low_battery_shutdown_percent
[modify] https://crrev.com/901c25941d658fd10b80ac4dc112a2b3f0906015/overlay-cave/chromeos-base/chromeos-bsp-cave/files/powerd_prefs/low_battery_shutdown_percent
[rename] https://crrev.com/901c25941d658fd10b80ac4dc112a2b3f0906015/overlay-cave/chromeos-base/chromeos-bsp-cave/chromeos-bsp-cave-0.0.1-r20.ebuild
[rename] https://crrev.com/901c25941d658fd10b80ac4dc112a2b3f0906015/overlay-caroline/chromeos-base/chromeos-bsp-caroline/chromeos-bsp-caroline-0.0.1-r14.ebuild

Re #38/#39

Here is the /var/log/tlsdate.log from #3

Look like clients3.google.com:443 was blocked

2017-04-10T10:14:40.479025+02:00 NOTICE tlsdate[2566]: V: time is currently 1491812080.478982735
2017-04-10T10:14:40.479177+02:00 NOTICE tlsdate[2566]: V: time is greater than RECENT_COMPILE_DATE
2017-04-10T10:14:40.485060+02:00 NOTICE tlsdate[2566]: V: using TLSv1_client_method()
2017-04-10T10:14:40.485890+02:00 NOTICE tlsdate[2566]: V: opening socket to clients3.google.com:443
2017-04-10T10:14:43.476165+02:00 NOTICE tlsdate[2566]: [event:action_tlsdate_timeout] tlsdate timed out
2017-04-10T10:14:43.476177+02:00 INFO tlsdated[2564]: [event:action_tlsdate_timeout] tlsdate timed out
2017-04-10T10:14:43.476706+02:00 INFO tlsdated[2564]: [event:handle_child_death] tlsdate reaped => pid:6466 uid:234 status:9 code:2
2017-04-10T10:14:43.476711+02:00 NOTICE tlsdate[2566]: [event:handle_child_death] tlsdate reaped => pid:6466 uid:234 status:9 code:2
2017-04-10T10:15:03.128720+02:00 NOTICE tlsdate[2566]: SSL connection failed
2017-04-10T10:15:08.535587+02:00 INFO tlsdated[2564]: [event:action_resolve_proxy] resolving proxy for clients3.google.com:443
2017-04-10T10:15:08.535589+02:00 NOTICE tlsdate[2566]: [event:action_resolve_proxy] resolving proxy for clients3.google.com:443
2017-04-10T10:15:08.547138+02:00 INFO tlsdated[2564]: invalid host:port: 165.225.76.40:80;PROXY 165.225.72.40:80
2017-04-10T10:15:08.547148+02:00 NOTICE tlsdate[2566]: invalid host:port: 165.225.76.40:80;PROXY 165.225.72.40:80

Maybe the real problem is that tlsdated doesn't know how to parse non-trivial PAC strings? I noticed this earlier when updating its call to get proxy info from Chrome. See Will's TODO for canonicalize_pac() in src/platform-cros.c:

/* TODO(wad) support multiple proxies when Chromium does:
 * PROXY x.x.x.x:yyyy; PROXY z.z.z.z:aaaaa
 */

Even just using the first proxy would probably be better than what we do now.

(This is all non-unit-tested C string parsing code. What can go wrong?)

You are right.

The proxy string probably was "PROXY 165.225.76.40:80;PROXY 165.225.72.40:80"

and tlsdate parse "165.225.76.40:80;PROXY 165.225.72.40:80" as IP:port and failed. (src/platform-cros.c)

Will submit patch for that too. But I think we still should write user setted time to disk even if we fix this.

Agreed re writing user-supplied times to disk.

I've uploaded a speculative tiny fix to tlsdate at https://chromium-review.googlesource.com/545181.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/tlsdate/+/0d5a64f29c0e6e91bd40a4b87ac1f3781153edec

commit 0d5a64f29c0e6e91bd40a4b87ac1f3781153edec
Author: Daniel Erat <derat@chromium.org>
Date: Fri Jun 23 17:19:29 2017

tlsdate: Use first proxy when multiple are supplied.

Update tlsdated's proxy-parsing code to just use the first
host it finds in a multi-proxy PAC string (e.g. "PROXY
host1.example.com:8080; PROXY host2.example.com:8080")
instead of giving up entirely.

BUG= chromium:708177 
TEST=added unit tests

Change-Id: I4a0e1d88792a3ee437bad14e23a7c85e6c12bf31
Reviewed-on: https://chromium-review.googlesource.com/545181
Commit-Ready: Dan Erat <derat@chromium.org>
Tested-by: Dan Erat <derat@chromium.org>
Reviewed-by: Jorge Lucangeli Obes <jorgelo@chromium.org>

[modify] https://crrev.com/0d5a64f29c0e6e91bd40a4b87ac1f3781153edec/src/platform-cros-util-unittest.c
[modify] https://crrev.com/0d5a64f29c0e6e91bd40a4b87ac1f3781153edec/src/platform-cros-util.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/tlsdate/+/76dd49e9ad7584bca9fc16eb7a7a66b477129db5

commit 76dd49e9ad7584bca9fc16eb7a7a66b477129db5
Author: Daniel Erat <derat@chromium.org>
Date: Fri Jun 23 17:19:28 2017

tlsdate: Add tests for proxy-parsing code.

Move get_valid_hostport() and canonicalize_pac() out of
platform-cros.c and into a new platform-cros-util.c file.
Add a bunch of unit tests for canonicalize_pac() that get
compiled into a new platform-cros-util_unittest executable.

No functional changes.

BUG= chromium:708177 
TEST=built with FEATURES=test

Change-Id: Ide07f77292ee5f7fee133a3ad8b27e0afb4de800
Reviewed-on: https://chromium-review.googlesource.com/545225
Commit-Ready: Dan Erat <derat@chromium.org>
Tested-by: Dan Erat <derat@chromium.org>
Reviewed-by: Jorge Lucangeli Obes <jorgelo@chromium.org>

[add] https://crrev.com/76dd49e9ad7584bca9fc16eb7a7a66b477129db5/src/platform-cros-util.h
[modify] https://crrev.com/76dd49e9ad7584bca9fc16eb7a7a66b477129db5/src/platform-cros.c
[add] https://crrev.com/76dd49e9ad7584bca9fc16eb7a7a66b477129db5/src/platform-cros-util.c
[modify] https://crrev.com/76dd49e9ad7584bca9fc16eb7a7a66b477129db5/src/include.am
[add] https://crrev.com/76dd49e9ad7584bca9fc16eb7a7a66b477129db5/src/platform-cros-util-unittest.c
[modify] https://crrev.com/76dd49e9ad7584bca9fc16eb7a7a66b477129db5/Makefile.am

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/tlsdate/+/27c3d790346933897a8178227eeca031ce6583f9

commit 27c3d790346933897a8178227eeca031ce6583f9
Author: Puthikorn Voravootivat <puthik@chromium.org>
Date: Sat Jun 24 05:56:44 2017

tlsdate: Save user manually set time to disk

Some enterprise network only support NTP protocol which make
tlsdate never get time synced via network. As tlsdate currently
flags all non-network source of time to not sync to disk. This
will make time to be incorrect when RTC lost power.

This CL make tlsdate to also sync time from platform to disk to
solve this issue.

BUG= chromium:708177 
TEST=manual. Set time, remove battery, time still correct after boot.

Change-Id: Icf77fb492e3f617d6358027f3d8e29bc590d5974
Signed-off-by: Puthikorn Voravootivat <puthik@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/544631
Reviewed-by: Dan Erat <derat@chromium.org>
Reviewed-by: Jorge Lucangeli Obes <jorgelo@chromium.org>

[modify] https://crrev.com/27c3d790346933897a8178227eeca031ce6583f9/src/events/save.c

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

#41 contains the merge for 4% battery to R59 which was already part of R60/61

I could see value in adding #46,#47,#49 R60.  Anyone disagree?

Adding r60 request +josafat for visibility.

This bug requires manual review: M60 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/tlsdate/+/47b81dcbe6d366a39c006e3b66cd4693eddf4c35

commit 47b81dcbe6d366a39c006e3b66cd4693eddf4c35
Author: Daniel Erat <derat@chromium.org>
Date: Tue Jun 27 05:44:39 2017

tlsdate: Add tests for proxy-parsing code.

Move get_valid_hostport() and canonicalize_pac() out of
platform-cros.c and into a new platform-cros-util.c file.
Add a bunch of unit tests for canonicalize_pac() that get
compiled into a new platform-cros-util_unittest executable.

No functional changes.

BUG= chromium:708177 
TEST=built with FEATURES=test

Change-Id: Ide07f77292ee5f7fee133a3ad8b27e0afb4de800
Reviewed-on: https://chromium-review.googlesource.com/545225
Commit-Ready: Dan Erat <derat@chromium.org>
Tested-by: Dan Erat <derat@chromium.org>
Reviewed-by: Jorge Lucangeli Obes <jorgelo@chromium.org>
(cherry picked from commit 76dd49e9ad7584bca9fc16eb7a7a66b477129db5)
Reviewed-on: https://chromium-review.googlesource.com/549661
Reviewed-by: Dan Erat <derat@chromium.org>
Commit-Queue: Dan Erat <derat@chromium.org>
Trybot-Ready: Dan Erat <derat@chromium.org>

[add] https://crrev.com/47b81dcbe6d366a39c006e3b66cd4693eddf4c35/src/platform-cros-util.h
[modify] https://crrev.com/47b81dcbe6d366a39c006e3b66cd4693eddf4c35/src/platform-cros.c
[add] https://crrev.com/47b81dcbe6d366a39c006e3b66cd4693eddf4c35/src/platform-cros-util.c
[modify] https://crrev.com/47b81dcbe6d366a39c006e3b66cd4693eddf4c35/src/include.am
[add] https://crrev.com/47b81dcbe6d366a39c006e3b66cd4693eddf4c35/src/platform-cros-util-unittest.c
[modify] https://crrev.com/47b81dcbe6d366a39c006e3b66cd4693eddf4c35/Makefile.am

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/tlsdate/+/192bbc0ae8ae925890e2fff3cd121f7de356e23e

commit 192bbc0ae8ae925890e2fff3cd121f7de356e23e
Author: Daniel Erat <derat@chromium.org>
Date: Tue Jun 27 05:46:13 2017

tlsdate: Use first proxy when multiple are supplied.

Update tlsdated's proxy-parsing code to just use the first
host it finds in a multi-proxy PAC string (e.g. "PROXY
host1.example.com:8080; PROXY host2.example.com:8080")
instead of giving up entirely.

BUG= chromium:708177 
TEST=added unit tests

Change-Id: I4a0e1d88792a3ee437bad14e23a7c85e6c12bf31
Reviewed-on: https://chromium-review.googlesource.com/545181
Commit-Ready: Dan Erat <derat@chromium.org>
Tested-by: Dan Erat <derat@chromium.org>
Reviewed-by: Jorge Lucangeli Obes <jorgelo@chromium.org>
(cherry picked from commit 0d5a64f29c0e6e91bd40a4b87ac1f3781153edec)
Reviewed-on: https://chromium-review.googlesource.com/549662
Reviewed-by: Dan Erat <derat@chromium.org>
Commit-Queue: Dan Erat <derat@chromium.org>
Trybot-Ready: Dan Erat <derat@chromium.org>

[modify] https://crrev.com/192bbc0ae8ae925890e2fff3cd121f7de356e23e/src/platform-cros-util-unittest.c
[modify] https://crrev.com/192bbc0ae8ae925890e2fff3cd121f7de356e23e/src/platform-cros-util.c

Thanks for the approval. I'm also going to merge https://chromium-review.googlesource.com/c/548217/, a tiny x86 build fix that went in after the other changes.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/tlsdate/+/81a7992ffa6bd2fc5ff28f76efee31554cd0579f

commit 81a7992ffa6bd2fc5ff28f76efee31554cd0579f
Author: Puthikorn Voravootivat <puthik@chromium.org>
Date: Tue Jun 27 17:52:12 2017

tlsdate: Save user manually set time to disk

Some enterprise network only support NTP protocol which make
tlsdate never get time synced via network. As tlsdate currently
flags all non-network source of time to not sync to disk. This
will make time to be incorrect when RTC lost power.

This CL make tlsdate to also sync time from platform to disk to
solve this issue.

BUG= chromium:708177 
TEST=manual. Set time, remove battery, time still correct after boot.

Change-Id: Icf77fb492e3f617d6358027f3d8e29bc590d5974
Signed-off-by: Puthikorn Voravootivat <puthik@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/544631
Reviewed-by: Dan Erat <derat@chromium.org>
Reviewed-by: Jorge Lucangeli Obes <jorgelo@chromium.org>
(cherry picked from commit 27c3d790346933897a8178227eeca031ce6583f9)
Reviewed-on: https://chromium-review.googlesource.com/550598

[modify] https://crrev.com/81a7992ffa6bd2fc5ff28f76efee31554cd0579f/src/events/save.c

I merged https://chromium-review.googlesource.com/c/548217/ to M60 as https://chromium-review.googlesource.com/c/549663/.